Cách lập kế hoạch dự án: 7 bước và ví dụ

Bent Flyvbjerg đã nghiên cứu 258 dự án tại 20 quốc gia trong vòng 70 năm. 9 trên 10 dự án đã vượt quá ngân sách. Trung bình, chi phí cao hơn 28% so với dự báo.

Nguyên nhân không phải do việc thực hiện kém, mà là cách các nhóm đối xử với kế hoạch. Họ soạn thảo kế hoạch một lần, được phê duyệt, rồi sau đó ngừng sử dụng nó. Khi tình hình thay đổi, kế hoạch vẫn không thay đổi.

Hầu hết các kế hoạch đều bị bỏ dở vào tuần thứ ba. Chúng được lập ra để được phê duyệt, chứ không phải để áp dụng. Chúng nhầm lẫn giữa việc lập kế hoạch (việc cần làm và tại sao) với việc lập lịch trình (khi nào thực hiện). Và chúng không có phương án rõ ràng để xử lý sự thay đổi phạm vi mà không làm gián đoạn tiến độ.

Hướng dẫn này sẽ chỉ cho bạn cách viết kế hoạch dự án qua bảy bước có thể áp dụng trên bất kỳ công cụ nào. Bạn cũng sẽ được tham khảo các ví dụ thực tế trong các lĩnh vực như Waterfall, Agile, tiếp thị và xây dựng. Ngoài ra, bạn còn được so sánh trực tiếp các nơi lưu trữ kế hoạch thực tế: bảng tính, tài liệu chia sẻ trên Google Docs và các công cụ quản lý dự án chuyên dụng.

Kế hoạch dự án là gì?

Kế hoạch dự án là một tài liệu chính thức mô tả cách thức dự án sẽ được triển khai, theo dõi và kết thúc. Tài liệu này bao gồm phạm vi, tiến độ, nguồn lực, rủi ro và các quy trình giao tiếp, đồng thời đóng vai trò là cơ sở để nhóm làm việc khi quá trình triển khai bắt đầu.

Kế hoạch dự án không phải là gì

Kế hoạch dự án không phải là bản tuyên bố dự án. Bản tuyên bố dự án phê duyệt dự án và trao quyền cho người quản lý dự án. Nó trả lời câu hỏi “liệu việc này có cần làm không, và ai là người chịu trách nhiệm?” Kế hoạch dự án tiếp nối từ nơi bản tuyên bố dự án kết thúc, và trả lời các câu hỏi “thực hiện như thế nào, khi nào, do ai thực hiện, và với chi phí bao nhiêu?”

Kế hoạch dự án cũng không phải là bản mô tả phạm vi. Bản mô tả phạm vi xác định những gì dự án sẽ cung cấp và những gì dự án sẽ không cung cấp. Nó cho bạn biết “hoàn thành” trông như thế nào. Kế hoạch dự án bao gồm bản mô tả phạm vi cộng với lịch trình, nguồn lực, rủi ro, giao tiếp và kiểm soát thay đổi. Nó cho bạn biết nhóm sẽ thực hiện như thế nào, ai làm việc gì và điều gì sẽ xảy ra khi có sự thay đổi.

5 giai đoạn của một kế hoạch dự án

Kế hoạch dự án bao gồm năm giai đoạn mà Viện Quản lý Dự án (PMI) định nghĩa là vòng đời dự án: khởi động, lập kế hoạch, thực hiện, giám sát và kiểm soát, và kết thúc.

Kế hoạch này được xây dựng trong giai đoạn Lập kế hoạch, nhưng vẫn được sử dụng tích cực trong suốt các giai đoạn Thực hiện và Giám sát. Một kế hoạch đã đóng khi giai đoạn Lập kế hoạch kết thúc chính là kế hoạch dễ bị bỏ dở sớm nhất.

Tại sao kế hoạch dự án lại quan trọng?

Nếu bỏ qua kế hoạch, những vấn đề tương tự sẽ tiếp tục lặp lại. Phạm vi dự án bị mở rộng do không ai xác định rõ ranh giới, xung đột về nguồn lực do hai luồng công việc cùng yêu cầu một kỹ sư, và việc không đáp ứng được thời hạn do các mối phụ thuộc ẩn được phát hiện quá muộn.

Kế hoạch dự án giúp ngăn chặn những thất bại đó bằng cách hiển thị công việc trước khi bắt đầu thực hiện.

Kế hoạch là cơ sở tham chiếu, không phải bản thiết kế chi tiết

Hầu hết các nhà quản lý dự án coi kế hoạch như một tài liệu trình bày. Bạn soạn thảo nó để trình bày cho các bên liên quan biết những gì bạn sẽ thực hiện, sau đó chỉ cập nhật khi buộc phải làm vậy. Điều này khiến kế hoạch chỉ là một bức tranh tổng quan, chứ không phải là công cụ ra quyết định.

Nhiệm vụ thực sự của một kế hoạch dự án là cung cấp cho bạn một cơ sở cụ thể để dựa vào khi tương lai diễn ra khác với dự kiến. Các yêu cầu thay đổi phạm vi được đánh giá dựa trên cơ sở tham chiếu, chứ không phải dựa trên cảm tính. Sự chậm trễ về dòng thời gian được đo lường dựa trên kế hoạch, chứ không phải dựa trên ký ức. Kế hoạch thành công là kế hoạch được cập nhật tại mỗi cột mốc quan trọng.

Từ đó, có hai quy tắc được rút ra, và phần còn lại của hướng dẫn này được xây dựng dựa trên hai quy tắc đó:

Cách tiếp cận này giải quyết vấn đề mà Flyvbjerg gọi là thiên lệch lạc quan: xu hướng có hệ thống khiến các nhà lập kế hoạch thường đánh giá thấp chi phí, dòng thời gian và rủi ro, đồng thời đánh giá quá cao lợi ích. Kế hoạch được xây dựng dưới dạng dự báo tĩnh sẽ mang theo thiên lệch đó ngay từ ngày đầu tiên và không bao giờ được điều chỉnh để khắc phục.

Các thành phần chính của kế hoạch dự án

Mọi kế hoạch dự án, dù ở mức tổng quan hay chi tiết sâu sắc, đều dựa trên các thành phần cốt lõi giống nhau. Danh sách công việc dưới đây liệt kê từng thành phần và những nội dung mà mỗi thành phần cần đề cập.

Tuy nhiên, không phải dự án nào cũng cần tất cả tám phần này với mức độ chi tiết như nhau. Một dự án nội bộ kéo dài hai tuần có thể gộp nhiều phần lại thành một trang duy nhất. Trong khi đó, một dự án trong ngành có quy định chặt chẽ, ví dụ như một sáng kiến tuân thủ trong lĩnh vực dược phẩm, có thể mở rộng từng phần thành một tài liệu con riêng biệt với các bước phê duyệt chính thức.

Cách soạn thảo kế hoạch dự án trong 7 bước

Bảy bước này áp dụng được cho mọi phương pháp: Waterfall, Agile hay kết hợp. Thứ tự các bước rất quan trọng vì mỗi bước là nền tảng cho bước tiếp theo. Bỏ qua các bước sẽ dẫn đến việc phải làm lại, điều này tốn kém hơn so với việc lập kế hoạch đúng cách ngay từ đầu.

Bước 1: Xác định mục tiêu và các bên liên quan

Hãy bắt đầu từ các mục tiêu của bạn. Sai lầm phổ biến nhất trong kế hoạch là vội vàng chuyển sang câu hỏi “việc cần làm là gì?” trước khi trả lời câu hỏi “thành công trông như thế nào?”. Hãy gắn mỗi mục tiêu với một kết quả có thể đo lường được và một thời hạn cụ thể.

Ví dụ, “Thiết kế lại trang web” là một công việc. “Tăng tỷ lệ chuyển đổi trên trang giá cả lên 15% trước quý 3” là một mục tiêu định hướng cho mọi quyết định tiếp theo.

Tiếp theo, lập danh sách tất cả những người có quyền hạn, ảnh hưởng hoặc phụ thuộc vào dự án. Phân loại họ theo vai trò. Nhà tài trợ phê duyệt các thay đổi về ngân sách và phạm vi, những người đóng góp thực hiện công việc, còn các bên được thông báo cần nhận thông tin cập nhật nhưng không tham gia ra quyết định. Một bản đồ các bên liên quan đơn giản sẽ giúp sắp xếp mọi thứ một cách có tổ chức.

Bước 2: Xác định phạm vi dự án và các sản phẩm đầu ra

Phạm vi là ranh giới. Mọi thứ nằm trong phạm vi sẽ được phân bổ nguồn lực và lên lịch; mọi thứ nằm ngoài phạm vi sẽ được hoãn lại hoặc từ chối một cách rõ ràng. Danh sách công việc “trong phạm vi/ngoài phạm vi” gồm hai cột giúp tránh sự mơ hồ có thể dẫn đến hiện tượng mở rộng phạm vi sau này.

Phân biệt giữa sản phẩm đầu ra của dự án và các công việc. Sản phẩm đầu ra là kết quả cụ thể mà các bên liên quan nhận được: “cơ sở dữ liệu đã được di chuyển”, “mô hình thiết kế đã được phê duyệt”, “tài liệu API đã được công bố”. Các công việc là công việc cần thực hiện để tạo ra sản phẩm đầu ra đó. Sự phân biệt này rất quan trọng vì các bên liên quan quan tâm đến sản phẩm đầu ra; còn nhóm của bạn quan tâm đến các công việc.

Lỗi phổ biến nhất liên quan đến phạm vi dự án là gì? Đó là việc xác định phạm vi quá rộng đến mức không thể dùng để từ chối các yêu cầu bổ sung.

“Cải thiện trải nghiệm người dùng” có thể có nghĩa là bất cứ điều gì. “Thiết kế lại luồng thanh toán cho trình duyệt di động, không bao gồm bố cục dành cho máy tính bảng và các thay đổi liên quan đến nhà cung cấp dịch vụ thanh toán” sẽ cung cấp cho bạn một lý do rõ ràng để từ chối khi ai đó yêu cầu hỗ trợ máy tính bảng giữa chừng dự án.

Bước 3: Xây dựng cấu trúc phân chia công việc

Lấy từng sản phẩm đầu ra từ Bước 2 và chia nhỏ chúng thành các công việc nhỏ nhất có thể được phân công, ước tính và theo dõi riêng lẻ. Cấu trúc phân cấp này — dự án → sản phẩm đầu ra → gói công việc → công việc — chính là cấu trúc phân chia công việc (WBS) của bạn.

Một nguyên tắc thực tiễn hữu ích: nếu một công việc mất nhiều hơn vài ngày để hoàn thành, có xác suất nó có thể được chia nhỏ thêm.

Cấu trúc phân chia công việc (WBS) là nền tảng cho kế hoạch tiến độ và kế hoạch nguồn lực. Nếu WBS không đầy đủ, mọi công việc tiếp theo sẽ không đáng tin cậy. Dòng thời gian của bạn sẽ không chính xác vì bạn đã bỏ sót các công việc, và kế hoạch nguồn lực của bạn sẽ có những lỗ hổng.

Ví dụ, đây là cách thực hiện trong ClickUp:

Bước 4: Xây dựng lịch trình dự án và các cột mốc quan trọng

Lấy các công việc trong WBS của bạn và sắp xếp thứ tự thực hiện: những công việc nào phụ thuộc vào việc các công việc khác phải hoàn thành trước (phụ thuộc), và những công việc nào có thể thực hiện song song.

Các cột mốc quan trọng của dự án đánh dấu việc hoàn thành các giai đoạn chính hoặc các sản phẩm đầu ra. Chúng là các điểm kiểm tra: “hoàn thành giai đoạn thiết kế” hoặc “đã nhận được xác nhận UAT”. Hãy sử dụng chúng để tạo ra các điểm đánh giá tự nhiên với các bên liên quan. Đối với các dự án phức tạp, hãy trực quan hóa lịch trình dưới dạng biểu đồ Gantt để làm rõ các mối quan hệ phụ thuộc và đường dẫn quan trọng.

Hãy dự trù một khoảng thời gian dự phòng trong lịch trình để đối phó với những yếu tố không lường trước được. Sau đó, hãy phân bổ thời gian dự phòng cho từng giai đoạn, đặc biệt là giai đoạn kiểm thử và đánh giá, thay vì gom lại thành một khối thời gian ở cuối dự án rồi bị cắt giảm khi áp lực gia tăng.

Bước 5: Phân công vai trò và phân bổ nguồn lực

Phân công từng công việc từ WBS cho một người chịu trách nhiệm cụ thể. Việc chia sẻ quyền sở hữu đồng nghĩa với việc không ai có quyền sở hữu. Phân bổ nguồn lực có nghĩa là xác nhận rằng những người được phân công có sức chứa trong khoảng thời gian đã lên lịch.

Đây chính là lúc kế hoạch va chạm với thực tế. Chuyên viên phát triển chính của bạn có thể được phân công tham gia ba dự án cùng lúc. Kế hoạch sẽ giúp phơi bày mâu thuẫn đó trước khi nó dẫn đến việc trễ hạn.

Khung RACI (Responsible, Accountable, Consulted, Informed) giúp làm rõ ai làm gì mà không cần lập quá nhiều tài liệu. Nếu dự án yêu cầu phần mềm mới hoặc nhà thầu, những nội dung đó sẽ được phê duyệt cùng với kế hoạch.

Bước 6: Đánh giá rủi ro và lập kế hoạch truyền thông

Xác định những rủi ro có thể xảy ra, đánh giá mức độ khả năng xảy ra và tác động của từng rủi ro, đồng thời lập kế hoạch ứng phó cho từng trường hợp.

Ghi chép các rủi ro thường gặp của dự án vào sổ đăng ký rủi ro để chúng được hiển thị rõ ràng và có người chịu trách nhiệm. Dưới đây là một ví dụ.

Bước 7: Nhận sự chấp thuận của các bên liên quan và thiết lập cơ sở tham chiếu

Kế hoạch chỉ được coi là chính thức sau khi nhà tài trợ và các bên liên quan chính phê duyệt chính thức. Việc phê duyệt này xác lập cơ sở tham chiếu của dự án: phạm vi, tiến độ và ngân sách đã được thống nhất, làm tiêu chuẩn để đánh giá mọi thay đổi trong tương lai.

Nếu không có cơ sở tham chiếu, sẽ không thể phân biệt được sự thay đổi hợp lệ với thỏa thuận ban đầu.

Sau khi kế hoạch được cài đặt, bất kỳ thay đổi nào về phạm vi, dòng thời gian hoặc ngân sách đều phải tuân theo quy trình quản lý thay đổi mà bạn đã xác định trong kế hoạch. Chia sẻ kế hoạch đã được phê duyệt với tất cả các bên liên quan. Lưu trữ kế hoạch tại một địa điểm chung, được kiểm soát phiên bản và luôn có thể truy cập được. Đừng để nó bị chôn vùi trong một chủ đề email từ ba tháng trước.

Ví dụ về kế hoạch dự án

Các ví dụ dưới đây minh họa cách các thành phần cốt lõi giống nhau được điều chỉnh để phù hợp với các bối cảnh khác nhau. Mỗi ví dụ đều mô tả cấu trúc, điểm đặc trưng và thời điểm nên áp dụng.

Ví dụ về kế hoạch dự án theo mô hình Waterfall

Kế hoạch theo mô hình Waterfall diễn ra theo thứ tự: yêu cầu, thiết kế, phát triển, kiểm thử, triển khai. Mỗi giai đoạn kết thúc bằng một bước kiểm tra chính thức. Các bên liên quan sẽ xem xét công việc và phê duyệt giai đoạn tiếp theo. Không có giai đoạn nào được tiến hành cho đến khi giai đoạn trước đó được phê duyệt.

Mẫu trình tự:

Điểm khác biệt: Phạm vi dự án được xác định rõ ràng ngay từ giai đoạn xác định yêu cầu. Biểu đồ Gantt là tài liệu chính, thể hiện từng giai đoạn theo thứ tự. Các yêu cầu thay đổi phải được thực hiện theo quy trình chính thức và tốn kém. Phương pháp Waterfall đánh đổi tính linh hoạt để đổi lấy tính dự đoán được.

Phù hợp nhất với: Các dự án có yêu cầu, quy tắc và quy định cố định, hoặc các nhóm bên ngoài cần phạm vi công việc được xác định rõ ràng. Các hợp đồng chính phủ, công việc tuân thủ và sản xuất là những lĩnh vực phù hợp.

Không phù hợp nếu: Bạn không thể xác định rõ ràng khái niệm “đã xong” ngay từ buổi khởi động dự án với mức độ tự tin cao. Việc cố định phạm vi công việc mà bạn chưa hiểu rõ sẽ tốn kém hơn so với việc điều chỉnh dần dần.

Ví dụ về kế hoạch dự án theo phương pháp Agile

Một kế hoạch Agile xác định tầm nhìn sản phẩm, danh sách công việc ưu tiên, nhịp độ sprint (thường là hai tuần) và vai trò của các thành viên trong nhóm. Kế hoạch chi tiết sẽ được phát triển dần qua từng sprint. Nhóm sẽ rút kinh nghiệm từ mỗi vòng và điều chỉnh cho phù hợp.

Mẫu trình tự:

Điểm khác biệt: Kế hoạch không cố định phạm vi công việc vượt quá sprint tiếp theo. Các bên liên quan sẽ thấy một lộ trình các chủ đề theo quý, chứ không phải danh sách công việc đầu ra theo từng sprint. Buổi retro là vòng phản hồi. Nếu thiếu nó, Agile sẽ biến thành tình trạng mở rộng phạm vi công việc một cách không kiểm soát kèm theo các bước thừa.

Phù hợp nhất với: Các dự án có nhu cầu thay đổi, công việc được định hướng bởi phản hồi của khách hàng hoặc nhóm thực hiện theo từng đợt nhỏ. Phương pháp Agile thường được áp dụng trong lĩnh vực phần mềm, thiết kế sản phẩm và các công cụ nội bộ.

Bỏ qua nếu: các bên liên quan yêu cầu phạm vi và thời hạn cố định ngay từ đầu. Sự linh hoạt của phương pháp Agile sẽ gây bất lợi cho bạn khi hợp đồng có tính chất cứng nhắc.

Ví dụ về kế hoạch dự án chiến dịch tiếp thị

Một chiến dịch tiếp thị đa kênh kết hợp nội dung, quảng cáo trả phí, email và các sự kiện. Chiến dịch này tạo ra các sản phẩm sáng tạo với các chu kỳ đánh giá, phối hợp với các nhà cung cấp bên ngoài (các công ty quảng cáo, freelancer) và đảm bảo tất cả các kênh đều ra mắt cùng một ngày.

Mẫu trình tự:

Điểm khác biệt: Kế hoạch tiếp thị thường có nhiều bên liên quan đưa ra ý kiến hơn là những người có quyền quyết định. Nếu không có quy trình phê duyệt rõ ràng, mọi tài liệu sẽ phải trải qua tới năm vòng chỉnh sửa, và ngày ra mắt sẽ bị trì hoãn. Ma trận RACI ở đây không phải là tùy chọn. Đó chính là yếu tố bảo vệ ngày ra mắt.

Một rủi ro khác cần lưu ý: Các kênh truyền thông đều tập trung vào một ngày cụ thể, nhưng mỗi kênh lại có thời gian chuẩn bị khác nhau. In ấn cần sáu tuần. Quảng cáo trên mạng xã hội trả phí cần hai tuần. Email cần một tuần. Nếu bạn lập kế hoạch theo hướng tiến tới từ ngày khởi động thay vì lùi lại từ ngày ra mắt, các kênh có thời gian chuẩn bị dài sẽ đã bị trễ ngay từ ngày đầu tiên.

Phù hợp nhất cho: Ra mắt sản phẩm, chiến dịch theo mùa, tái định vị thương hiệu hoặc bất kỳ công việc nào được triển khai trên nhiều hơn hai kênh vào cùng một ngày.

Bỏ qua phần này nếu: Bạn đang vận hành một chương trình chỉ trên một kênh và hoạt động liên tục (chỉ là một blog, chỉ là một tài khoản trả phí). Lịch nội dung và việc kiểm tra tiến độ hàng tuần là đủ. Một kế hoạch chiến dịch đầy đủ sẽ là gánh nặng không cần thiết mà bạn sẽ không sử dụng đến.

Ví dụ về kế hoạch dự án xây dựng

Các dự án xây dựng phải tuân thủ các quy định nghiêm ngặt (giấy phép, kiểm tra) và các mối phụ thuộc vật lý chặt chẽ. Bạn không thể lắp đặt hệ thống điện trước khi khung nhà được dựng xong.

Mẫu trình tự:

Điểm khác biệt: Lịch trình mới là rủi ro chính, chứ không phải phạm vi dự án. Sự chậm trễ ở một giai đoạn sẽ ảnh hưởng đến mọi giai đoạn tiếp theo. Nếu công đoạn lắp khung bị chậm một tuần, các công đoạn điện, nước và hệ thống HVAC đều sẽ bị dời lại. Các kế hoạch thi công cần xây dựng khoảng đệm bên trong từng giai đoạn, chứ không phải ở cuối dự án. Tại sao? Khoảng đệm ở cuối dự án luôn bị “nuốt chửng” bởi những bước đã bị chậm trễ từ trước đó.

Phù hợp nhất cho: Bất kỳ công việc nào có sự phụ thuộc về mặt vật lý, rủi ro thời tiết hoặc cần phối hợp nhiều ngành nghề khác nhau.

Bỏ qua phần này nếu: Bạn đang thực hiện công việc trí óc. Việc mượn những cánh cổng cồng kềnh từ ngành xây dựng cho một chiến dịch tiếp thị sẽ gây ra chi phí phát sinh mà không mang lại sự bảo vệ thực sự.

Đừng bắt đầu dự án tiếp theo của bạn từ một trang giấy trắng. Mẫu Kế hoạch Dự án Tổng quan của ClickUp cung cấp cho bạn một cấu trúc sẵn sàng sử dụng với trạng thái công việc, các Trường Tùy chỉnh để theo dõi sự phê duyệt và phân công công việc cho nhóm, cùng năm chế độ xem tích hợp sẵn, bao gồm Dòng thời gian và Danh sách công việc.

Tải mẫu miễn phí

Kế hoạch dự án nên được lưu trữ ở đâu?

Phương pháp quyết định cách bạn sắp xếp thứ tự công việc. Công cụ quyết định liệu kế hoạch có thể duy trì được qua tuần thứ ba hay không. Bạn có ba lựa chọn.

Bảng tính (Google Trang tính, Excel)

Đây là những công cụ mặc định dành cho các nhóm luôn sử dụng bảng tính. Một bảng tính dành cho công việc, một bảng tính dành cho dòng thời gian và một bảng tính dành cho danh sách rủi ro. Mọi người đều có thể chỉnh sửa. Hệ thống vẫn hoạt động bình thường ngay cả khi có người không kết nối mạng.

Những phương pháp hiệu quả

Điểm yếu

Phù hợp nhất cho: Các dự án do một nhóm thực hiện với dưới 20 công việc, có một người chịu trách nhiệm rõ ràng và không có các phụ thuộc lồng nhau.

Bỏ qua nếu: Có hơn hai nhóm cần phối hợp với nhau, hoặc dòng thời gian thay đổi nhiều hơn một lần mỗi tuần.

Tài liệu chia sẻ (Tài liệu Google, Notion, Confluence, ClickUp Docs)

Một kế hoạch dựa trên tài liệu (Doc-based plan) sẽ hiệu quả khi phần lớn nội dung kế hoạch được trình bày dưới dạng văn bản: tuyên bố phạm vi, bản đồ các bên liên quan, tiêu chí thành công và danh mục rủi ro. Các công việc được liệt kê dưới dạng danh sách gạch đầu dòng kèm theo người chịu trách nhiệm và thời hạn.

Những phương pháp hiệu quả

Điểm yếu

Phù hợp nhất cho: Các dự án ngắn hạn (dưới một tháng), các kế hoạch có nhiều nội dung mô tả, hoặc dùng làm giai đoạn đầu cho công cụ theo dõi công việc. Phạm vi dự án và các bên liên quan được ghi trong tài liệu. Các công việc được quản lý ở nơi khác.

Bỏ qua phần này nếu: Bạn cần biết ai đang bị khối nào đó chặn ngay hôm nay.

Các công cụ quản lý dự án chuyên dụng (ClickUp, Asana, Jira, Monday)

Các hệ thống được thiết kế chuyên dụng, trong đó các công việc, mối quan hệ phụ thuộc, người chịu trách nhiệm và dòng thời gian chia sẻ chung một mô hình dữ liệu. Kế hoạch và công việc là cùng một đối tượng.

Những phương pháp hiệu quả

Điểm yếu

Phù hợp nhất với: Các dự án liên quan đến nhiều nhóm, có các phụ thuộc thay đổi và cần một cơ sở tham chiếu vẫn giữ nguyên ngay cả khi phạm vi dự án thay đổi.

Bỏ qua nếu: Đây là một dự án đơn giản với một người chủ trì, một nhóm, phạm vi cố định và thời lượng thực hiện dưới ba tuần. Sử dụng tài liệu (Doc) sẽ nhanh hơn.

6 lý do khiến kế hoạch dự án thất bại

Hầu hết các kế hoạch dự án đều mất đà vì những lý do có thể dự đoán được.

1. Xác định phạm vi dự án quá rộng đến mức không thể từ chối

Phạm vi chỉ thực sự hữu ích khi nó cung cấp cho bạn một lý do được ghi chép rõ ràng để từ chối các yêu cầu bổ sung. Nếu bạn không thể trích dẫn tài liệu về phạm vi và nói rằng “Điều đó nằm ngoài phạm vi”, thì phạm vi đó quá mơ hồ để bảo vệ dự án.

Viết mọi ranh giới phạm vi dưới dạng một tuyên bố có thể kiểm chứng được. “Thiết kế lại luồng thanh toán cho trình duyệt di động, không bao gồm bố cục trên máy tính bảng và các thay đổi liên quan đến nhà cung cấp dịch vụ thanh toán” là một ranh giới. “Cải thiện trải nghiệm” thì không.

2. Thu thập ước tính từ các nhà quản lý

Các ước tính từ trên xuống thường có xu hướng lạc quan. Đây chính là thiên kiến lạc quan đã đề cập trước đó, được áp dụng vào việc ước tính. Người giao công việc hầu như luôn đánh giá thấp khối lượng công việc so với người thực hiện.

Chính người phát triển đang thực hiện công việc mới là người biết rõ những điểm gây cản trở thực sự nằm ở đâu. Hãy xây dựng WBS một cách hợp tác, nếu không sẽ phải làm lại.

3. Dồn toàn bộ khoảng trống vào cuối

Một lịch trình bổ sung hai tuần “dự phòng” vào cuối dự án kéo dài bốn tháng thực chất là một lịch trình không có dự phòng thực sự. Khoảng thời gian dự phòng đó sẽ là thứ đầu tiên bị cắt giảm khi áp lực gia tăng.

Hãy dành thời gian dự phòng trong từng giai đoạn, đặc biệt là giai đoạn kiểm thử và đánh giá, nơi thời gian này thường bị tiêu tốn. Khoảng thời gian dự phòng được tích hợp ngay trong công việc sẽ vẫn còn hiệu lực. Ngược lại, khoảng thời gian dự phòng được đặt ở cuối dự án thường sẽ biến mất trước khi dự án thực sự cần đến nó.

4. Không định nghĩa rõ ràng khái niệm “hoàn thành”

Khi các tiêu chí hoàn thành không được quy định rõ ràng, khái niệm “đã xong” sẽ có ý nghĩa khác nhau đối với từng bên liên quan:

Hãy xác định rõ "hoàn thành" có nghĩa là gì đối với từng sản phẩm đầu ra. Ghi chú các tiêu chí mà sản phẩm đó phải đáp ứng, định dạng của nó sẽ như thế nào và ai sẽ phê duyệt. Các tiêu chí không rõ ràng là nguyên nhân chính dẫn đến việc phải làm lại vào giai đoạn cuối của dự án.

5. Lưu kế hoạch dưới dạng tệp đính kèm trong email

Một kế hoạch mà không ai tìm thấy được thì về mặt chức năng cũng giống như không có kế hoạch.

Nếu nhóm phải thắc mắc xem phiên bản hiện tại ở đâu, họ sẽ không tham khảo nó khi đưa ra quyết định, không nhận ra khi nó đã lỗi thời, hoặc không cập nhật nó khi tình hình thực tế thay đổi.

Lưu trữ kế hoạch tại nơi nhóm làm việc, đảm bảo kế hoạch được quản lý phiên bản và liên kết với các công việc mà nó điều phối. Kế hoạch nên chỉ cách không gian làm việc của bất kỳ thành viên nào trong nhóm hai cú nhấp chuột.

6. Coi kế hoạch như một tài liệu chỉ được lập một lần

Dấu hiệu rõ ràng nhất: Ngày sửa đổi lần cuối của kế hoạch cũ hơn so với công việc mới nhất mà bạn đã thêm vào. Nếu công việc đã thay đổi nhưng kế hoạch thì không, điều đó có nghĩa là kế hoạch đã ngừng điều hành dự án từ một thời gian trước, và không ai nhận ra điều đó.

Dành ra 15 phút để rà soát kế hoạch tại mỗi cột mốc quan trọng và mỗi khi yêu cầu thay đổi được phê duyệt. Mục đích không phải là viết lại kế hoạch từ đầu, mà là để xác nhận xem kế hoạch cơ sở có còn phản ánh thực tế hay không, hoặc ghi nhận những điểm không còn phù hợp.

Cách chúng tôi lập và quản lý kế hoạch dự án trong ClickUp

Chúng tôi không chỉ soạn thảo kế hoạch dự án trên Tài liệu Google rồi hy vọng mọi việc sẽ suôn sẻ. Các kế hoạch của chúng tôi được lưu trữ ngay trong ClickUp, ngay bên cạnh công việc mà chúng mô tả. Nhờ vậy, kế hoạch luôn được cập nhật và không bao giờ trở nên lỗi thời.

Tài liệu về phạm vi và bản đồ các bên liên quan (Bước 1 và 2)

ClickUp Docs lưu trữ bản mô tả phạm vi, các chỉ số thành công và bảng các bên liên quan. Vì tài liệu này nằm trong cùng không gian làm việc với các công việc, nên câu hỏi “việc này có nằm trong phạm vi không?” rất dễ trả lời. Khi ai đó đề xuất một thay đổi, chúng tôi chỉ cho họ xem chính tài liệu mà người tài trợ đã phê duyệt, chứ không phải một tài liệu Google Doc từ ba tháng trước.

Các công việc và công việc con trong WBS (Bước 3)

Chế độ xem Gantt để phân tích các mối phụ thuộc và đường dẫn quan trọng (Bước 4)

Kéo một đường nối giữa các công việc trong <14>chế độ xem Gantt của ClickUp để cài đặt mối quan hệ phụ thuộc. Đường dẫn quan trọng sẽ hiển thị rõ ràng, và khi một công việc bị trễ, các công việc tiếp theo sẽ tự động điều chỉnh theo. Lịch trình vẫn đảm bảo tính thực tế mà không cần ai phải xây dựng lại thủ công. Đây chính là phần thường gặp sự cố nhanh nhất khi sử dụng bảng tính, và cũng là lý do khiến các công cụ quản lý dự án (PM) trở nên cần thiết.

Bảng điều khiển cho cơ sở tham chiếu (Bước 7)

Sau khi người tài trợ phê duyệt kế hoạch, Bảng điều khiển ClickUp sẽ hiển thị dữ liệu thời gian thực về tỷ lệ hoàn thành, các công việc quá hạn và khối lượng công việc. Câu trả lời cho câu hỏi “chúng ta đang ở đâu?” được lấy từ chính dữ liệu mà nhóm đang xử lý, chứ không phải từ một tài liệu theo dõi trạng thái riêng biệt. Các bên liên quan sẽ kiểm tra Bảng điều khiển thay vì yêu cầu tổ chức cuộc họp cập nhật trạng thái.

Khi ClickUp không phải là lựa chọn phù hợp

ClickUp thực sự phát huy hiệu quả khi các dự án liên quan đến nhiều người, dòng thời gian thay đổi liên tục và việc bàn giao công việc giữa các bộ phận. Công việc của bạn càng cần sự kết nối, bạn càng nhận được nhiều giá trị từ ClickUp.

Bỏ qua phần này nếu: Bạn là một freelancer đang theo dõi một vài đầu việc, hoặc một nhóm cần các mô hình tài chính phức tạp và bảng pivot. Trong trường hợp này, một tài liệu đơn giản hoặc bảng tính sẽ phù hợp hơn.

Xây dựng kế hoạch dự án mà nhóm của bạn sẽ sử dụng

Một kế hoạch dự án chỉ thực sự hiệu quả khi nó phản ánh đầy đủ bức tranh tổng thể: mọi sản phẩm đầu ra, người chịu trách nhiệm, mối quan hệ phụ thuộc và rủi ro đều được tập hợp tại một nơi. Ngoài ra, kế hoạch này phải được tham chiếu trong suốt công việc, chứ không được bỏ quên khi đến cột mốc đầu tiên.

Qua hàng trăm dự án, các nhóm luôn hoàn thành dự án đúng tiến độ đều coi kế hoạch của mình như những tài liệu sống. Họ rà soát tại mỗi cột mốc quan trọng, cập nhật các giả định khi điều kiện thay đổi và đưa mọi yêu cầu điều chỉnh phạm vi dự án qua quy trình thay đổi được ghi chép rõ ràng. Đó chính là yếu tố giúp dự án luôn đi đúng hướng.

Nếu nhóm của bạn đã vượt quá khả năng quản lý của các tài liệu chia sẻ và bảng tính cơ bản, thì bạn nên thử một công cụ như ClickUp. Bạn có thể quản lý phạm vi, công việc, mối quan hệ phụ thuộc, người chịu trách nhiệm và bảng điều khiển tại một nơi duy nhất, với các chế độ xem luôn được đồng bộ hóa khi kế hoạch phát triển.

Đăng ký ClickUp ngay hôm nay!

Các câu hỏi thường gặp về kế hoạch dự án

Sự khác biệt giữa kế hoạch dự án và kế hoạch quản lý dự án là gì?

Kế hoạch dự án tập trung vào các sản phẩm đầu ra cụ thể, tiến độ và nguồn lực cho một dự án riêng lẻ. Kế hoạch quản lý dự án (một thuật ngữ của PMI) có phạm vi rộng hơn, bao gồm các kế hoạch phụ về quản lý thay đổi, quản lý rủi ro, truyền thông và mua sắm, quy định cách thức quản lý dự án. Đối với hầu hết các nhóm làm việc ngoài môi trường PMI chính thức, thuật ngữ “kế hoạch dự án” bao gồm cả hai khía cạnh này.

Bạn có thể lập kế hoạch dự án mà không cần phần mềm quản lý dự án không?

Đúng vậy, đối với các dự án ngắn hạn chỉ có một người chịu trách nhiệm chính và ít hơn khoảng 20 công việc. Một tài liệu chia sẻ (Doc) bao gồm bản mô tả phạm vi, danh sách các bên liên quan và một bảng đơn giản liệt kê người chịu trách nhiệm cùng ngày đáo hạn sẽ nhanh hơn so với việc cài đặt một công cụ quản lý dự án. Điểm giới hạn thường là sự phụ thuộc giữa các nhóm: khi có hơn hai nhóm cần phối hợp, bảng tính sẽ bắt đầu mất đi độ chính xác.

Đường dẫn quan trọng trong kế hoạch dự án là gì?

Đường dẫn quan trọng là chuỗi các công việc phụ thuộc dài nhất trong lịch trình của bạn, quyết định ngày hoàn thành dự án sớm nhất có thể. Bất kỳ sự chậm trễ nào đối với một công việc trên đường dẫn quan trọng đều làm chậm trễ toàn bộ dự án; trong khi đó, sự chậm trễ đối với các công việc không quan trọng có thể được bù đắp bằng khoảng trống thời gian. Biểu đồ Gantt giúp trực quan hóa đường dẫn quan trọng để các nhà quản lý dự án biết được những sự chậm trễ nào thực sự quan trọng và những sự chậm trễ nào không.

Ai là người chịu trách nhiệm lập kế hoạch dự án?

Người quản lý dự án chịu trách nhiệm về kế hoạch, nhưng họ không nên soạn thảo kế hoạch một mình. Các chuyên gia trong lĩnh vực cung cấp ước tính công việc, nhà tài trợ phê duyệt phạm vi và ngân sách, còn các thành viên tham gia xác nhận các mối phụ thuộc. Các kế hoạch được xây dựng theo phương pháp từ trên xuống mà không có sự đóng góp ý kiến từ những người trực tiếp thực hiện công việc thường xuyên đánh giá thấp mức độ nỗ lực cần thiết – một xu hướng đã được nghiên cứu của Bent Flyvbjerg ghi nhận qua hàng nghìn dự án.

Sự khác biệt giữa kế hoạch dự án và lịch trình dự án là gì?

Kế hoạch dự án xác định những công việc sẽ được thực hiện, do ai thực hiện, với chi phí bao nhiêu và cách thức quản lý rủi ro. Lịch trình dự án là một thành phần của kế hoạch, trong đó xác định thời điểm thực hiện các công việc và thứ tự thực hiện. Việc nhầm lẫn giữa hai yếu tố này sẽ dẫn đến tình trạng dòng thời gian chi phối phạm vi công việc thay vì ngược lại, đây là một trong những sai lầm phổ biến nhất trong quá trình lập kế hoạch.

Bạn nên cập nhật kế hoạch dự án bao lâu một lần?

Bạn nên cập nhật kế hoạch dự án tại mỗi cột mốc quan trọng và mỗi khi yêu cầu thay đổi được phê duyệt. Một kế hoạch vẫn dựa trên các giả định của tuần đầu tiên khi đã sang tháng thứ ba sẽ tạo ra sự tự tin sai lầm. PMI khuyến nghị tiến hành các cuộc đánh giá kế hoạch chính thức tại mỗi giai đoạn kiểm soát, kèm theo các cập nhật đột xuất khi rủi ro trở thành hiện thực hoặc các thay đổi về phạm vi được phê duyệt thông qua quy trình kiểm soát thay đổi.