Lời Mở Đầu: Thay Đổi – Một Thực Tế Không Thể Tránh Khỏi Trong Dự Án
Trong quản lý dự án, thay đổi là một thực tế không thể tránh khỏi. Dù bạn đã lập kế hoạch kỹ lưỡng đến đâu, các yêu cầu có thể thay đổi, những vấn đề mới có thể phát sinh, hoặc điều kiện thị trường có thể dịch chuyển. Việc Project Manager có khả năng giám sát công việc mới và quản lý những thay đổi này một cách hiệu quả là yếu tố then chốt để giữ cho dự án đi đúng hướng.
Bài viết này sẽ đưa bạn đi sâu vào Giám sát công việc mới và thay đổi (Monitoring New Work and Changes) – một khía cạnh quan trọng của Miền Hiệu Suất Công Việc Dự Án (Project Work Performance Domain) trong PMBOK® Guide – Phiên bản 7. Chúng ta sẽ khám phá cách quản lý công việc mới trong môi trường Agile, quy trình kiểm soát thay đổi trong Predictive, và tầm quan trọng của việc kiểm soát những thay đổi đó.
Xem video hướng dẫn chi tiết về "Giám sát công việc mới và thay đổi (Monitoring New Work and Changes)" tại đây:
1. Trong Dự Án Adaptive (Agile): Thêm Công Việc Vào Product Backlog & Product Owner Ưu Tiên
Trong các dự án sử dụng phương pháp Adaptive (Agile), có một kỳ vọng rằng công việc sẽ phát triển và thích nghi liên tục. Do đó, công việc mới có thể được thêm vào Product Backlog khi cần thiết, thay vì phải trải qua một quy trình thay đổi phức tạp và cứng nhắc.
Product Backlog là nguồn công việc duy nhất:
Mô tả: Product Backlog là một danh sách có thứ tự các yêu cầu tập trung vào người dùng (User Stories) mà nhóm duy trì cho một sản phẩm. Nó là nguồn thông tin duy nhất về tất cả các yêu cầu và công việc cần làm cho sản phẩm/dự án.
Tính linh hoạt: Trong Agile, Product Backlog không phải là một tài liệu cố định; nó là một tài liệu sống (living artifact) được liên tục cập nhật, tinh chỉnh (refinement) và ưu tiên lại.
Vai trò của Product Owner trong ưu tiên:
Mô tả: Product Owner chịu trách nhiệm quản lý Product Backlog và liên tục ưu tiên các hạng mục công việc dựa trên giá trị kinh doanh, mức độ khẩn cấp và sự phù hợp với mục tiêu sản phẩm.
Xử lý công việc mới/thay đổi: Khi có yêu cầu mới hoặc thay đổi, Product Owner sẽ thêm chúng vào Product Backlog. Sau đó, họ làm việc với nhóm để quản lý kỳ vọng xung quanh việc thêm phạm vi này và tác động tiềm ẩn đến ngân sách và khả năng sẵn có của thành viên nhóm. Product Owner sẽ quyết định thứ tự ưu tiên của hạng mục mới so với các hạng mục hiện có.
Kết thúc dự án trong Agile: Nếu có nhiều công việc được thêm vào hơn là được hoàn thành, hoặc nếu số lượng công việc thêm vào bằng với số lượng công việc hoàn thành, dự án sẽ không bao giờ kết thúc. Trong trường hợp lịch trình hoặc ngân sách bị giới hạn, Product Owner có thể xem xét dự án đã "hoàn thành" khi các hạng mục có ưu tiên cao nhất đã được bàn giao (value-driven completion).
Ví dụ: Một nhóm đang phát triển ứng dụng di động. Khách hàng đột nhiên yêu cầu thêm tính năng "đăng nhập bằng Face ID". Product Owner sẽ thêm tính năng này vào Product Backlog, thảo luận với nhóm về nỗ lực cần thiết, và quyết định thứ tự ưu tiên của nó so với các tính năng khác dựa trên giá trị kinh doanh và chiến lược sản phẩm. Nếu tính năng này cực kỳ quan trọng, nó có thể được ưu tiên cao và một tính năng khác sẽ bị đẩy xuống hoặc loại bỏ.
2. Trong Dự Án Predictive: Quản Lý Thay Đổi Để Bảo Đảm Tính Toàn Vẹn Của Phạm Vi
Trong các dự án sử dụng phương pháp Predictive (Dự đoán), việc quản lý thay đổi đòi hỏi một cách tiếp cận chặt chẽ và chính thức hơn nhiều, vì phạm vi được xác định rõ ràng và "chốt" từ đầu.
Bảo vệ Scope Baseline (Đường cơ sở phạm vi):
Mô tả: Scope Baseline là phiên bản đã được phê duyệt của Bản tuyên bố phạm vi (Scope Statement), cấu trúc phân rã công việc (WBS) và từ điển WBS liên quan của nó. Nó được sử dụng làm cơ sở để Project Manager đo lường hiệu suất dự án.
Tính toàn vẹn: Khác với Product Backlog linh hoạt, Scope Baseline là một tài liệu được kiểm soát thay đổi chặt chẽ. Chỉ những thay đổi đã được phê duyệt thông qua quy trình chính thức mới được tích hợp vào Scope Baseline.
Tác động của thay đổi: Bất kỳ thay đổi nào đối với phạm vi đều cần được đi kèm với các thay đổi phù hợp về con người, tài nguyên, lịch trình và ngân sách. Các thay đổi phạm vi có thể làm tăng sự không chắc chắn, do đó, bất kỳ yêu cầu thay đổi nào cũng nên đi kèm với đánh giá về các rủi ro mới được đưa vào do việc thêm hoặc thay đổi phạm vi.
Ví dụ: Nếu một yêu cầu thay đổi làm tăng phạm vi, Project Manager cần phân tích tác động của nó lên lịch trình, chi phí và tài nguyên. Liệu có cần thêm tiền? Có bị chậm tiến độ không?
Vai trò của Project Manager và Change Control Board (CCB):
Mô tả: Project Manager làm việc với Hội đồng kiểm soát thay đổi (Change Control Board - CCB) và người yêu cầu thay đổi để hướng dẫn các yêu cầu thay đổi thông qua quy trình kiểm soát thay đổi. CCB là một nhóm chính thức được thành lập để xem xét, đánh giá, phê duyệt, trì hoãn hoặc từ chối các thay đổi.
Quyết định: Các thay đổi đã được phê duyệt sẽ được tích hợp vào các tài liệu lập kế hoạch dự án, và phạm vi dự án có liên quan. Các thay đổi cũng sẽ được truyền đạt đến các bên liên quan phù hợp.
3. Quy Trình Kiểm Soát Thay Đổi (Change Control Process): Đảm Bảo Sự Kiểm Soát
Dù là dự án Predictive hay Hybrid (kết hợp), việc có một quy trình kiểm soát thay đổi (Change Control Process) rõ ràng là vô cùng quan trọng. Quy trình này mô tả cách các sửa đổi đối với các tài liệu dự án và sản phẩm bàn giao được quản lý và kiểm soát.
Các bước cơ bản của quy trình kiểm soát thay đổi thường bao gồm:
Yêu cầu thay đổi (Change Request Submission):
Mô tả: Bất kỳ ai cũng có thể đề xuất một yêu cầu thay đổi (Change Request). Yêu cầu này cần được tài liệu hóa rõ ràng, mô tả thay đổi mong muốn và lý do của nó.
Ví dụ: Một khách hàng gửi yêu cầu bổ sung tính năng "báo cáo tài chính chi tiết" vào phần mềm.
Phân tích tác động (Impact Analysis):
Mô tả: Project Manager và nhóm dự án (hoặc các chuyên gia liên quan) sẽ phân tích toàn diện tác động của yêu cầu thay đổi lên tất cả các ràng buộc dự án (phạm vi, lịch trình, chi phí, chất lượng, tài nguyên, rủi ro).
Ví dụ: Tính năng báo cáo tài chính chi tiết sẽ làm tăng phạm vi, kéo dài 2 tuần lịch trình, tăng chi phí 5.000 USD, và có thể tạo rủi ro về bảo mật dữ liệu.
Ra quyết định (Decision Making):
Mô tả: CCB hoặc Product Owner (trong Agile, đối với Product Backlog) sẽ xem xét phân tích tác động và đưa ra quyết định: Phê duyệt (Approve), Từ chối (Reject) hoặc Trì hoãn (Defer) yêu cầu thay đổi.
Ví dụ: CCB họp và quyết định phê duyệt yêu cầu thay đổi với điều kiện tăng ngân sách và kéo dài lịch trình.
Cập nhật tài liệu (Document Update):
Mô tả: Nếu yêu cầu được phê duyệt, các tài liệu dự án liên quan (Project Management Plan, Baselines, Risk Register, Issue Log, v.v.) sẽ được cập nhật để phản ánh thay đổi.
Ví dụ: Scope Baseline, lịch trình, và ngân sách dự án được cập nhật để bao gồm tính năng báo cáo mới.
Truyền đạt quyết định (Communicate Decision):
Mô tả: Quyết định về thay đổi và lý do của nó cần được truyền đạt đến tất cả các bên liên quan bị ảnh hưởng để đảm bảo mọi người đều được thông tin và liên kết.
Lời Kết: Kiểm Soát Thay Đổi – Bảo Vệ Dự Án Của Bạn
Giám sát công việc mới và thay đổi là một nhiệm vụ liên tục và phức tạp, đòi hỏi sự linh hoạt trong Adaptive và sự kiểm soát chặt chẽ trong Predictive. Bằng cách hiểu rõ quy trình trong từng bối cảnh (Product Backlog trong Agile và Change Control Process trong Predictive), bạn sẽ giữ cho dự án luôn đi đúng hướng, thích nghi với các điều kiện thay đổi và bàn giao giá trị một cách thành công.
Hãy nhớ rằng, quản lý thay đổi hiệu quả không phải là ngăn chặn mọi thay đổi, mà là quản lý chúng một cách có hệ thống để bảo vệ mục tiêu dự án. Trong bài viết tiếp theo, chúng ta sẽ đi sâu vào Học hỏi liên tục trong dự án (Learning Throughout the Project) – biến mọi dự án thành cơ hội học hỏi.
0 Comments