Đã bao nhiêu lần lập kế hoạch dự án và chạy 80% theo kế hoạch đó? Việc dành quá nhiều thời gian cho việc lập kế hoạch không đồng nghĩa với có một bản kế hoạch tốt hơn, thậm chí có thể phản tác dụng, đặc biệt trong môi trường biến động cao. Tuy nhiên, “không lập kế hoạch tức là lập kế hoạch cho sự thất bại”. Vậy Project Manager nên lập kế hoạch như thế nào để đảm bảo dự án thành công mà vẫn linh hoạt trước những thay đổi?
Thất bại trong lập kế hoạch là một trong những nguyên nhân hàng đầu dẫn đến dự án không thành công. Sau đây là một số nguyên nhân dẫn đến việc lập kế hoạch không hiệu quả:
Project Manager (PM) bẻ nhỏ các công việc và phân phối việc cho từng thành viên. Điều này dẫn đến mỗi người tập trung vào hoàn thành từng tác vụ của mình mà có thể không để ý đến mục tiêu chung. Điều không may là luôn xảy ra tình trạng có các hoạt động không hoàn thành đúng hẹn dẫn đến hiệu ứng dây chuyền cho các công đoạn phía sau, khiến cho hàng loạt hạn chót bị ảnh hưởng, khó kiểm soát. Bởi vì các hoạt động trong một nhóm dự án không hoàn toàn độc lập với nhau mà có sự tương tác, phụ thuộc qua lại. Trong các dự án phức tạp, luôn có những việc sẽ phát sinh không đoán trước được. Do vậy, khi không để ý tới mục tiêu là các kết quả có thể đóng gói và hoàn thành từng phần, tình trạng mất kiểm soát có thể diễn ra.
Chúng ta cũng cần chú ý hai hiện tượng tâm lý học có tên Luật Parkinson và hội chứng sinh viên.
Luật Parkinson nói rằng chúng ta sẽ luôn liền đẩy các hoạt động cho vừa khít một khung thời gian nào đấy. Có nghĩa rằng việc lập danh sách các việc làm (hay các tác vụ – task) trong một khoảng thời gian luôn hàm chứa những việc không cần thiết, hoặc không mang lại kết quả gì. Con người vẽ ra các công việc có thể chỉ đơn giản vì chúng ta cần điền hết vào khoảng thời gian chúng ta có. Xu hướng này cũng dẫn đến việc lập kế hoạch theo tác vụ sẽ luôn có rủi ro nhất định.
>> Tìm hiểu thêm về quản trị rủi ro dự án tại đây !
Còn Hội chứng sinh viên lại nói đến hiện tượng sinh viên chỉ thực sự làm việc tập trung vào cuối hoặc sát các kì thi và hầu như trong một khoảng thời gian tương đối dài họ không làm gì cả. Cho nên, nếu một dự án lập kế hoạch cho việc chuyển giao sản phẩm sau ba tháng, mà trong suốt ba tháng đó nhóm không bàn giao gì, thì nhiều khả năng là mọi việc sẽ được hoàn thành vào vài tuần cuối, còn lại các tháng trước đó, nhóm sẽ rất đủng đỉnh. Bài học quan trọng được rút ra là hãy lưu ý tới việc chuyển giao thường xuyên các giá trị từ dự án. Rút ngắn các chu trình đóng gói để quá trình lập kế hoạch hiệu quả hơn.
Trên thực tế, có nhiều thành viên nhóm dự án cùng một lúc làm nhiều dự án hoặc phải làm nhiều nhiệm vụ đồng thời. Tình trạng này dẫn đến việc mất thì giờ chuyển đổi từ ngữ cảnh này sang ngữ cảnh khác. Nhưng sự chuyển đổi này hầu như không được ước tính trong khi lập kế hoạch.
Nghiên cứu cho thấy khi phải làm cùng lúc vài dự án thì năng suất lao động của một lập trình viên có thể giảm xuống dưới 50% so với khi chỉ làm một dự án. Như vậy, khi lập kế hoạch, cần lưu ý thành viên đội dự án phải có được sự chuyên tâm với đội dự án. Ước tính về nỗ lực cần tính tới hiện trạng đa nhiệm của thành viên đội dự án, và lưu ý nhân lực không phải là “nguồn lực” có thể dễ dàng quy ra công số man-month khô cứng.
Các yêu cầu dự án không được lựa chọn theo thứ tự ưu tiên mà làm một cách tuần tự từ đầu đến hết. Điều này dẫn đến dự án rất khó chuyển giao được giá trị từ sớm và không biết để lại cái gì, bỏ đi cái gì khi thời gian không còn.
Việc không sắp xếp thứ tự các yêu cầu của dự án cũng dẫn đến khả năng thích nghi của dự án không cao. Thói quen này cũng gần gũi với cách tiếp cận lập kế hoạch theo tác vụ thuần túy, mà không tính tới khả năng đóng gói từng phần và chuyển giao giá trị thường xuyên hơn.
Trong quá trình lập kế hoạch, đội dự án thường lựa chọn các phương án thuận lợi nhất mà không tính tới các rủi ro và bất định hoặc không có khả năng lường trước và dự báo những bất định tồn tại trong dự án.
5 bước trong quy trình quản trị rủi ro hiệu quả giúp lập kế hoạch thành công
Các PM giàu kinh nghiệm luôn phải lưu tâm tới việc một cách có hệ thống. Không chỉ vậy, trong những dự án phức tạp có độ bất định lớn, PM cần phải tiếp cận dự án theo cách linh hoạt hơn, để có thể thích nghi với những sự thay đổi thường xuyên từ môi trường xung quanh, yêu cầu của khách hàng cũng như biến động trong nội bộ.
Các PM thường có một ước lượng về nỗ lực cần bỏ ra trước khi bắt đầu dự án. Dự án này cần bao nhiêu ngày công để hoàn thành, cần bao nhiêu người trong bao nhiêu tháng để hoàn tất. Điều này vốn là rất tốt, nhưng các PM lại mắc sai lầm khi đinh ninh rằng ước lượng là cam kết. Và sử dụng các ước lượng này để ép tiến độ. Đây có lẽ là một sai lầm mang tính nguyên tắc.
Thực tế ước lượng không bao giờ chính xác. Nhất là với các dự án có tính thay đổi cao và cần sự tương tác giữa các thành viên dự án. Chưa kể, ước tính ban đầu không hoàn toàn chính xác bởi vì đội dự án có ít kinh nghiệm hơn, ít hiểu biết hơn về dự án so với thời điểm đã triển khai được một thời gian. Do vậy, ước tính cũng cần phải thường xuyên được làm mịn, để có thể trở thành công cụ dự báo về thời điểm hoàn thành dự án hay khả năng đạt được những cột mốc quan trọng.
Trên thực tế, việc lên kế hoạch kỹ càng, chi tiết, rồi thi hành và kiểm soát thật chặt để đạt được kết quả tốt đã không còn phù hợp đối với các dự án hiện nay, nhất là với các dự án linh hoạt, có độ phức tạp lớn và thường xuyên phải đối mặt với thay đổi.
Các dự án lớn và phức tạp thường bao gồm nhiều giai đoạn liên kết chặt chẽ với nhau, trong đó một sự thay đổi trong giai đoạn này có thể ảnh hưởng đến giai đoạn khác. Quản trị dự án theo Agile sẽ không lập kế hoạch dài hạn, thay vào đó là chia nhỏ dự án thành nhiều phần nhỏ, kéo dài trong một khoảng thời gian ngắn. Bất kỳ sự thay đổi nào, kể cả vào phút chót, đều có thể được điều chỉnh mà không ảnh hưởng đến kết quả cuối cùng hay làm gián đoạn tiến độ dự án.
Theo Agile Coach Nguyễn Khắc Nhật, CEO CodeGym Việt Nam, Agile nói chung và Scrum nói riêng rất chú trọng đến việc Lập kế hoạch. Bản Tuyên ngôn Agile thể hiện rất rõ tư tưởng này khi đánh giá cao “Phản hồi với thay đổi hơn là bám sát kế hoạch”. “Kế hoạch” là yếu tố cố định và cứng nhắc, trong khi đó “phản hồi” là hoạt động nhằm đạt được sự linh hoạt và thích ứng tốt.
Mô hình Scrum chú trọng đến việc lập kế hoạch
Trong Scrum, hoạt động Lập kế hoạch diễn ra ở nhiều khía cạnh và cấp độ khác nhau, từ sản phẩm cho đến công việc, từ dài hạn cho đến ngắn hạn.
Chẳng hạn, về mặt sản phẩm, khi bắt đầu dự án, chúng ta bắt đầu hoạt động Lập kế hoạch thông qua việc xây dựng Product Backlog khởi điểm, lập kế hoạch phát hành và một số mốc điểm quan trọng khác của sản phẩm. Trong suốt quá trình sản xuất, Product Backlog luôn được cập nhật, điều chỉnh để phù hợp với tình hình mới. Các hạng mục được thêm vào, loại bỏ, chỉnh sửa, làm mịn, đánh giá lại độ ưu tiên, ước tính lại kích thước… Trong các phiên Sơ kết Sprint, lộ trình phát triển sản phẩm cũng có thể được điều chỉnh nhờ vào sự cộng tác giữa Product Owner, Nhóm Phát triển và các bên liên quan. Như vậy, không hề có một bản Kế hoạch cố định cho sản phẩm, thay vào đó hoạt động Lập kế hoạch được diễn ra liên tục và Kế hoạch luôn được điều chỉnh một cách phù hợp nhất.
Về mặt tổ chức sản xuất, việc đóng khung thời gian theo các Sprint ngắn hơn 1 tháng với các sự kiện Lập kế hoạch Sprint diễn ra ngay đầu mỗi Sprint là một cơ chế để phát huy tính hiệu quả của hoạt động Lập kế hoạch ở cấp độ trung hạn. Hoạt động Scrum Hằng ngày diễn ra đều đặn với sự tham gia của tất cả các thành viên Nhóm Phát triển, đây cũng là lúc để nhóm Lập kế hoạch sản xuất trong ngày làm việc tiếp theo. Như vậy, xét về mặt tổ chức công việc, chúng ta cũng không có một bản kế hoạch cố định, thay vào đó, việc sản xuất luôn được điều chỉnh với một tần suất rất thường xuyên.
Để minh họa chi tiết cho phương pháp quản lý dự án theo Agile trong lập kế hoạch, hãy cùng tham khảo case study của một nhóm dự án được giao nhiệm vụ build một hệ thống app phần mềm đặt đồ ăn trong 1 Quý.
Nhóm bắt tay vào thực hiện:
Sprint 1 – Truy cập hệ thống (Giúp người dùng truy cập vào hệ thống)
Sprint 2 – Đặt hàng (Giúp người dùng có thể đặt món)
Sprint 3 – Chế biến
Sprint 4 – Thanh toán
Sprint 5 – Hóa đơn
Sprint 6 – Báo cáo
Chi tiết lập kế hoạch hành động theo từng tuần (Sprint 2 tuần)
Chi tiết Backlog cụ thể trong mỗi Sprint quyết định việc lập kế hoạch dự án thành công
Một Project Manager chuyên nghiệp cần phải cân bằng giữa việc lập kế hoạch chi tiết và thích ứng với những thay đổi liên tục. Hãy nhớ rằng:
Bài viết liên quan:
Khóa học liên quan:
