Lập dự án theo mô hình phân tích stake holders

Có rất nhiều phương pháp để xây dựng một dự án. Có thể bạn đã lập rất nhiều đề án, đã viết rất nhiều “proposal”, và bạn vẫn cảm thấy ổn, mặc dù bạn chẳng cần đến phương pháp nào, nó hoàn toàn là kết quả của việc bạn tự sắp xếp suy nghĩ của mình lại một cách trật tự, theo logic và cuối cùng thành một dự án hoàn chỉnh.Như thế cũng tốt thôi, và tôi cá là bạn cũng đã thành công ít nhiều với công việc của mình. Nhưng, không phải ai cũng có năng lực tư duy tốt để có thể sắp xếp suy nghĩ thành đề án, hơn nữa, có nhiều cách để giúp bạn giảm thiểu được thời gian và tối ưu hóa quá trình lập dự án của mình, giúp bạn không phải đôi khi giật mình thảng thốt vì sực nhớ ra mình đã bỏ qua một điểm quan trọng nào đó.

Xin được chia sẻ một mô hình mà tôi đã học được từ một Tiến sỹ (ông ta tự giới thiệu như vậy) tên là David Uata, đến từ Mỹ, quê quán tại Tonga, một người rất thú vị, nhiều hành tung…”rất khó xác định”, (từng là CEO của tôi trong vòng gần 1 năm trước khi chuyển sang Bộ kế hoạch đầu tư làm trong một dự án nâng cao năng lực gì đó) nhưng có một số kiến thức ở ông lại hết sức hữu ích. (Ông cũng tự giới thiệu mình từng là tư vấn cao cấp về quy trình CMMI5 cho hãng máy bay Boeing, tung tích trên mạng tìm được có thế này).

Trở lại với mô hình phát triển dự án như hình tôi vẽ ở trên, mô hình này có phương châm lấy “Stakeholders” làm trung tâm. Đây là mô hình có thể áp dụng để xây dựng dự án đồng thời cũng là phương pháp để xác định vấn đề, lập kế hoạch chiến lược cũng như kế hoạch thực hiện chi tiết. Trước tiên, chúng ta đi vào các khái niệm xương sống của mô hình này.

Scope: Phạm vi dự án

Khi bắt tay vào xây dựng dự án hoặc đưa một vấn đề ra nghiên cứu hoặc giải quyết, bạn phải xác định được phạm vi của nó.

Một nguyên tắc quan trọng khi bạn tiếp cận mô hình này là bạn phải hết sức nghiêm khắc với chính mình khi xác định phạm vi vấn đề bạn cần giải quyết. Bởi vì nếu không làm như vậy, bạn sẽ rơi vào trạng thái lan man, và kéo theo mọi phân tích bên dưới của bạn sẽ không có trọng tâm, mất định hướng, và kết quả đầu ra vì thế cũng không chính xác, làm mất rất nhiều công sức và nỗ lực của bạn.

Ví dụ, vấn đề của bạn là tổ chức sự kiện ra mắt một sản phẩm, thì những vấn đề như hoạt động marketing cho sản phẩm, điều tra thái độ người tiêu dùng… sẽ nằm ngoài phạm vi của “scope” này. Bởi vì, nếu bạn đưa cả những vấn đề này vào trong phạm vi một dự án tổ chức sự kiện sẽ không phù hợp, dẫn tới bạn phân tích “stakeholders” sai, kéo theo hàng loạt cái sai khác. Còn nếu vấn đề của bạn là xây dựng một chiến dịch IMC (Integrated Marketing Communications) để tung ra một sản phẩm nào đó, thì những vấn đề bạn đưa ra lại là phù hợp.

Trong suốt quá trình xây dựng đề án, bất kỳ khi nào bạn thấy một ý tưởng, một phân tích, một hoạt động nào đó đi chệch ra khỏi phạm vi dự án, không phục vụ cho “scope of work”, lập tức bạn phải bật đèn đỏ cho mình, và quay trở lại trong vòng tròn bạn đã vạch ra từ đầu.

Thông thường, mô hình này được áp dụng để làm việc team work, trong quá trình “brainstorming” để giải quyết vấn đề, người “leader” sẽ là người phát hiện ra ai đó đưa ra ý kiến nằm ngoài “scope” và sẽ bật đèn đỏ báo hiệu để họ quay trở lại đúng phạm vi của vấn đề cần giải quyết. Các thành viên trong nhóm cũng có thể phát hiện và giúp nhau trong suốt quá trình tìm kiếm ý tưởng.

Trong tương quan của một chiến dịch truyền thông, thì “Scope” sẽ giống như “Mục tiêu”. Nói cách khác, xác định “Scope” chính là trả lời câu hỏi “Where do you want to go today?” – Bạn muốn đi tới đâu?

Sau khi xác định được nơi bạn cần đi, phần còn lại trong suốt quy trình này là xác định xem làm thế nào để đi được đến đích đó.

Stakeholders – Các bên liên quan

Ở mô hình này, khác với mô hình Kế hoạch truyền thông mà tôi đã giới thiệu trước đây, “Stakeholders” (các bên liên quan, hay các đối tượng liên quan) không phải chỉ là những người “bị tác động” bởi chương trình của bạn, mà còn là những người “chi phối” – có tác động tới, chương trình của bạn.

Nói một cách hết sức dễ hiểu, thì “Stakeholders” là những người dù ít hay nhiều, có tác động trực tiếp hay gián tiếp, có ảnh hưởng hay bị ảnh hưởng tới dự án, chương trình của bạn.

Cách thứ nhất, bạn có thể chia “Stakeholder” thành hai loại: loại “ẩn” (hidden) và loại “có thể nhìn thấy” (visible).

Loại ẩn (hay còn gọi là gián tiếp) là những stakeholder rất dễ bị bỏ qua. Ví dụ, một trong những Stakeholder của bạn là các cổ đông chiến lược. Chẳng hạn, ông Phạm Văn A là cổ đông nắm tới 45% cổ phần trong doanh nghiệp của bạn, nhưng trên thực tế, ông A chỉ là đại diện hợp pháp của một nhóm nhà đầu tư, vậy thì Stakeholder ẩn ở đây chính là nhóm nhà đầu tư này. Việc xác định ra họ rất quan trọng, bởi vì bạn phải biết họ là ai, thì mới biết được họ có mong muốn như thế nào và làm thế nào để thỏa mãn mong muốn của họ sau này. Nếu bạn không xác định được ông A bị chi phối bởi ai, bạn rất khó thỏa mãn được ông A.

Một ví dụ khác mà tôi cho rằng rất dễ hình dung về tác Stakeholder ẩn, đó là bạn thử tưởng tượng nếu bạn phải xây dựng kế hoạch cho chiến dịch tranh của của Hillary Cliton, thì chắc chắn một Stakeholder hết sức quan trọng chính là Bill Clinton, mặc dù ông này không tham gia trực tiếp vào chiến dịch, nhưng lại là một trong những người có ảnh hưởng và có tác động mạnh mẽ tới nhân vật chính của chiến dịch là vợ ông ta. Bằng cách nghiên cứu về Bill Clinton, những ảnh hưởng của ông này tới vợ mình, bạn có thể xác định được ông ta
có mong muốn như thế nào, sẽ làm gì hoặc không làm gì để giúp cho kế hoạch tranh cử của bạn thắng lợi.

Đối với từng chiến dịch, từng dự án lại có các stakeholder khác nhau, nhưng dưới đây là danh sách các stakeholder phổ biến mà bạn cần phải nghĩ tới trong quá trình phân tích, đặc biệt đối với doanh nghiệp.

• Chính phủ, các nhà làm chính sách
• Các bộ luật, thể chế chi phối
• Cơ quan quản lý nhà nước về lĩnh vực bạn đang theo đuổi
• Cổ đông
• Hội đồng quản trị
• Ban lãnh đạo
• Nhân viên (gia đình nhân viên)
• Khách hàng mục tiêu
• Báo chí mục tiêu
• Công chúng mục tiêu
• Dư luận xã hội

Không phải trong dự án nào bạn cũng phải liên hệ tới chừng này Stakeholder, thậm chí có dự án Stakeholder của bạn rất cụ thể, chỉ là một số cá nhân nhất định trong phạm vi hẹp, với tên họ cụ thể. Chỉ cần bạn xác định được là đó là những đối tượng có thể tác động hoặc bị tác động bởi dự án của bạn.

Bạn nên sắp xếp Stakeholder theo thứ tự từ trên xuống theo mô hình xã hội, hoặc theo trật tự ưu tiên về mức độ tác động.

Mời bạn tham khảo thêm một bài khác về Phân tích Stakeholder tại đây.

Requirements – Yêu cầu của các bên liên quan

Sau khi xác định được các bên liên quan (nhớ là cố gắng không bỏ sót một stakeholder quan trọng nào) bạn phải thực hiện việc phát hiện ra các yêu cầu mà họ có thể đòi hỏi đối với công việc, dự án của bạn.

Mỗi một Stakeholder lại có thể có nhiều yêu cầu. Ví dụ, Scope của bạn là Phát triển một sản phẩm phần mềm mới cho công ty, một Stakeholder quan trọng của bạn là Giám đốc công ty, Requirements của ông này chắc chắn sẽ như sau:

– Lợi nhuận

– Tiết kiệm chi phí sản xuất

– Danh tiếng, uy tín do sản phẩm đem lại

– Có khả năng phát triển lâu dài

– …

Nói một cách khác, bạn phải tìm ra được đủ các nhu cầu, mong muốn, hy vọng của những Stakeholder quan trọng của mình, đây chính là chìa khóa giúp bạn chỉ ra bạn sẽ phải làm gì để đạt được mục tiêu – Scope, của mình.

Sau khi xác định được danh sách này, bạn lại sắp xếp chúng theo thứ tự ưu tiên. Nếu như mục tiêu cao nhất của sếp của bạn là Lợi nhuận thì bạn sẽ dành nhiều nỗ lực hơn để thỏa mãn nhu cầu này so với các yêu cầu khác. Nếu danh tiếng là cái được coi trọng nhất thì cách bạn tìm phương pháp để đáp ứng được mong đợi này cũng vì thế mà sẽ khác.

Nếu không sắp xếp theo thứ tự ưu tiên, bạn sẽ bị “loạn”, sẽ đẩy bạn tới tình trạng bạn phải cố gắng đáp ứng mọi thứ, và dự án của bạn sẽ phình ra không có giới hạn, và chi phí của nó cũng phình ra tương ứng. Hãy găm “Scope” trong đầu, làm hệ quy chiếu trong quá trình sắp xếp thứ tự ưu tiên các Requirement. Requirement nào mà việc thỏa mãn nó lại giúp bạn tiến gần tới việc đạt được “Scope” nhất thì bạn đưa lên đầu.

Việc xác định Requirement nếu không được cân nhắc cẩn thận sẽ rất dễ đưa bạn tới chỗ đi chệch ra khỏi phạm vi “Scope of work”.

Success Criteria – Tiêu chí đảm bảo thành công

Để đảm bảo được bạn sẽ thỏa mãn được các Requirement của các Stakeholder, bạn phải suy nghĩ xem bạn phải làm những gì để đảm bảo bạn đáp ứng được mong muốn của họ.

Quay trở lại ví dụ ở trên, nếu mong muốn của Giám đốc công ty bạn về sản phẩm phần mềm bạn đang phát triển là Lợi nhuận, thì tiêu chí đảm bảo thành công mà bạn đặt ra cho sản phẩm của mình phải là:

– Dễ bán (sản phẩm phải đúng là sản phẩm mà thị trường đang mong đợi).

– Doanh số tháng 500 triệu (vì sếp của bạn sẽ không đầu tư cho phát triển sản phẩm nào có khả năng đem lại lợi nhuận dưới con số này).

– …

Còn nếu sếp của bạn lại đặt Uy tín lên hàng đầu, thì sản phẩm của bạn phải đáp ứng được:

– Sử dụng công nghệ mới nhất

– Frame work hoàn hảo nhất

– Được giới chuyên môn thừa nhận, đánh giá cao

– …

Bạn cũng có thể song song cùng lúc phải đáp ứng cả 2 yêu cầu này, thậm chí nhiều hơn, nhưng hãy nhớ là sắp xếp chúng theo thứ tự ưu tiên để xác định mức độ đầu tư phù hợp.

Nếu bạn đọc kỹ bài viết về Lập kế hoạch truyền thông, bạn sẽ thấy phần này giống như là việc xác định chiến lược tiếp cận như thế nào.

Deliverables – Kết quả đầu ra

Đây là kết quả đầu ra, hay chính là những việc cụ thể mà bạn phải làm. Nếu như xác định Tiêu chí đảm bảo thành công là Chiến lược, thì Kết quả đầu ra như là Chiến thuật – Tactics.

Bạn phải chỉ ra trong phần này những hạng mục công việc cụ thể của Tiêu chí đảm bảo thành công.

Với ví dụ trên, sếp của bạn mong muốn lợi nhuận, tiêu chí đảm bảo thành công là Dễ bán, và Doanh số trên 500 triệu/tháng. Vậy thì bạn phải làm cụ thể nó bằng các công việc cụ thể:

– Dễ bán: Là giá rẻ, hay dễ đóng gói, hay dễ cài đặt, dễ download, dễ tìm thấy? … Bạn phải tự quyết định các kết quả đầu ra này theo đặc thù công việc hoặc vấn đề của bạn.
– Doanh số trên 500 triệu/tháng, để đạt được điều này, bạn phải:

• Nghiên cứu thị trường
• Nghiên cứu sản phẩm
• Nghiên cứu kênh phân phối…

Hay với yêu cầu về mặt Uy tín, tiêu chí đảm bảo thành công là Sử dụng công nghệ mới nhất, thế thì kết quả cụ thể ở đây phải là:

• Công nghệ .Net
• Web-based
• 3.0…
• SQL 2008

Giờ thì bạn đã nhìn thấy các công việc trong dự án của bạn dần dần hiện ra rõ ràng, logic, đảm bảo thỏa mãn yêu cầu của các bên và đi đúng hướng giúp bạn đạt được mục tiêu. Chỉ còn một việc cuối cùng bạn phải làm.

Roles & Responsibilities – Vai trò và trách nhiệm

Bạn đã biết mình phải Nghiên cứu thị trường trước khi bắt tay vào xây dựng sản phẩm. Bạn là một người quản lý dự án phần mềm chứ không phải một nhân viên kinh doanh, vậy thì ai sẽ giúp bạn thực hiện đầu việc này. Chắc chắn người chịu trách nhiệm giúp bạn là Giám đốc kinh doanh, hoặ

c Trưởng phòng kinh doanh, sẽ là người thực hiện, cung cấp thông tin về thị trường, giúp bạn hoạch định xem một sản phẩm như thế nào thì sẽ đáp ứng được nhu cầu của thị trường và dễ bán.

Bạn sẽ không phát hoảng lên vì thấy mình phải làm quá nhiều việc, nếu như bạn biết xác định đúng vai trò và trách nhiệm của những người tham gia dự án hoặc những nguồn hỗ trợ bạn.

Đối với việc áp dụng .Net 3.0 hay SQL Server 2008, nếu bạn không rành nốt về mặt này, mặc dù bạn là quản trị dự án, nhưng bạn không phải là người giỏi nhất hoặc chịu trách nhiệm cao nhất trong công ty hoặc trong đội dự án của bạn về mảng này, bạn hãy đặt công việc này vào tay người đó. Bạn chỉ cần nghiệm thu kết quả cuối cùng có đúng là những việc mà bạn đã chỉ ra cho họ hay không mà thôi.

Bạn đã thấy mình làm việc khoa học đúng như một nhà quản trị dự án thực sự chưa?

“Last but not least”, bạn nên nhớ đặt ra deadline cho từng Deliverable bên cạnh tên của mỗi người mà bạn vừa chỉ ra trong phần này.

Well done! Bạn đã lập xong kế hoạch của một dự án. Bạn hãy tưởng tượng ra một dự án hoặc nếu bạn đang có một dự án cần lập kế hoạch, hãy bắt tay ngay vào với mô hình này. Nếu bạn gặp khó khăn hoặc cảm thấy khó kiểm soát (tôi chắc chắn bạn sẽ trải qua cảm giác này), hãy gọi cho tôi, tôi có thể chia sẻ được một vài kinh nghiệm.