Phạm vi dự án là một trong ba yếu tố cốt lỗi của quản lý dự án: Phạm vi – Thời gian và Chi phí. Trong xu hướng phát triển dự án hiện đại, việc phát sinh phạm vi dự án là việc thường xảy ra. Xây dựng kĩ năng quản trị phạm vi cũng như xử lý các phát sinh về phạm vi dự án là một yêu cầu quan trọng đối với dự án nói chung và nhân sự quản lý dự án nói riêng. Bài viết này tập trung vào việc giới thiệu các bước để quản trị phạm vi dự án một cách hiệu quả. Tiếp sau là tìm hiểu nguyên nhân và cách xử lý đối với việc phát sinh phạm vi dự án.

GIỚI THIỆU

Một trong những khía cạnh quan trọng và phức tạp nhất của việc quản lý dự án chính là quản trị phạm vi công việc. Phạm vi công việc được hiểu là tất cả những gì liên quan đến sản phẩm dự án và các tiến trình tạo ra sản phẩm đó. Trong bài viết này, tác giả sẽ trình bày các quy trình chính liên quan đến quản trị phạm vi dự án, đồng thời, đề cập tới những khó khăn thường gặp và phương án xử lý để quản trị phạm vi dự án một cách hiệu quả.

QUY TRÌNH QUẢN LÝ PHẠM VI

Quản trị phạm vi dự án bao gồm các tiến trình liên quan đến việc định nghĩa và kiểm soát những công việc bao gồm và không bao gồm trong một dự án. Mục đích của việc này là đảm bảo tất cả các nhân sự thuôc dự án cùng thống nhất về sản phẩm đầu ra cũng như quy trình thực hiện, sản xuất ra sản phẩm của dự án đó (Kathy, 2014). Quản trị phạm vi dự án bao gồm 06 (sáu) quy trình chính:

• Lập kế hoạch quản trị phạm vi dự án
• Thu thập yêu cầu dự án
• Định nghĩa phạm vi dự án
• Xây dựng bảng phân chia công việc dự án
• Đánh giá phạm vi dự án
• Kiểm soát quản trị phạm vi dự án

Lập kế hoạch quản trị phạm vi dự án

Bước đầu tiên trong quản lý phạm phi là lập kế hoạch quản lý trong suốt thời gian thực hiện dự án. Quy trình này có hai sản phẩm đầu ra quan trọng: kế hoạch quản lý phạm vi và kế hoạch quản lý yêu cầu. Vậy yêu cầu của dự án là gì? Khái niệm yêu cầu của dự án được diễn giải trong PMBOK® Guide, Fifth Edition như sau “đó là các điều kiện hoặc khả năng phải được đáp ứng trong dự án hoặc được thể hiện trong sản phẩm, dịch vụ hay kết quả để thỏa mãn một thỏa thuận hoặc thông số kĩ thuật được áp dụng”.

Kế hoạch quản lý yêu cầu sẽ tài liệu hóa chi tiết việc các yêu cầu dự án được phân tích, ghi chép và quản lý như thế nào. Kế hoạch này thường bao gồm các thông tin như sau:

• Cách thức lập kế hoạch, theo dõi và báo cáo các hoạt động yêu cầu;
• Cách thức thể biện các hoạt động quản lý cầu hình;
• Làm sao để sắp xếp thứ tự ưu tiên các yêu cầu;
• Làm sao để sử dụng ma trận sản phẩm;
• Làm sao để theo dõi và ghi lại những thuộc tính của yêu cầu.

Thu thập yêu cầu dự án

Quy trình tiếp theo, thường cũng là quy trình khó khăn nhất trong số các quy trình quản lý phạm vi dự án – đó là thu thập yêu cầu dự án. Vấn đề của bước này chính là việc không có một quy trình chuẩn để thu thập và tài liệu hóa các yêu cầu của dự án.

Có một số phương pháp để thu thập yêu cầu. Trong số đó, phỏng vấn một-một thường rất hiệu quả nhưng lại tốn kém thời gian và nguồn lực. Tổ chức các nhóm tập trung và hội thảo, sử dụng các nhóm sáng tạo, kĩ thuật ra quyết định… thông thường sẽ nhanh chóng và tối ưu hơn về mặt chi phí so với việc phỏng vấn trực tiếp. Ngoài ra, phát câu hỏi khảo sát cũng là một phương pháp khả thi nếu đối tượng tham gia cung cấp được thông tin một cách trung thực và kĩ lưỡng. Đối với dự án công nghệ thông tin, việc thu thập yêu cầu dự án còn có thể áp dụng phương pháp hai phương pháp phổ biến: tạo mẫu (prototyping) và phân tích tài liệu (document analysing).

Định nghĩa phạm vi dự án

Bước tiếp theo trong quản lý phạm vi dự án là định nghĩa chi tiết các công việc cần thiết cho dự án. Việc này có ý nghĩa rất quan trọng và quyết định thành công của dự án vì nó giúp cải thiện tính chính xác của thời gian, chi phí và nguồn lực dự kiến. Kết quả chính của định nghĩa phạm vi là tuyên bố phạm vi dự án và cập nhật tài liệu dự án.

Các yếu tố đầu vào chính để chuẩn bị tuyên bố phạm vi dự án bao gồm điều lệ dự án, kế hoạch quản lý phạm vi, tài liệu yêu cầu và tài sản quy trình tổ chức như các chính sách và thủ tục liên quan đến tuyên bố phạm vi, cũng như các tệp dự án và bài học kinh nghiệm từ các dự án tương tự trước đó. Mặc dù nội dung khác nhau, nhưng các tuyên bố về phạm vi dự án phải bao gồm ít nhất mô tả phạm vi sản phẩm, tiêu chí chấp nhận của người dùng sản phẩm và thông tin chi tiết về tất cả các sản phẩm dự án.

Xây dựng bảng phân chia công việc dự án

Sau khi thu thập yêu cầu và định nghĩa phạm vi, bước tiếp theo của quản lý phạm vi dự án là lập bảng phân chia công việc (WBS). Bảng WBS thường được mô tả giống như một sơ đồ tổ chức, lấy các công việc làm trung tâm. Một nhóm dự án thường tổ chức WBS dựa vào sản phẩm, các giai đoạn hay các nhóm tiến trình của dự án. Trong WBS, gói công việc là đơn vị thấp nhất. Một gói công việc nên được xác định ở cấp độ thích hợp để người quản lý dự án có thể thiết lập một cách rõ ràng ước tính về nỗ lực cần thiết để hoàn thành nó, ước tính chi phí của tất cả các nguồn lực cần thiết và đánh giá chất lượng của kết quả khi gói công việc hoàn thành.

Có một số phương pháp khác nhau để xây dựng bảng phân công công việc:

• Sử dụng hướng dẫn có sẵn
• Phương pháp áp dụng tương đương
• Tiếp cận từ trên xuống
• Tiếp cận từ dưới lên
• Phương pháp sơ đồ tư duy

Xác nhận phạm vi dự án

Rất khó để tạo một tuyên bố phạm vi dự án tốt và WBS cho một dự án. Tuy nhiên, còn khó khăn hơn nữa, đặc biệt là đối với các dự án CNTT, để xác minh phạm vi dự án và giảm thiểu thay đổi phạm vi. Một số nhóm dự án ngay từ đầu đã biết rằng phạm vi rất không rõ ràng và họ phải làm việc chặt chẽ với khách hàng dự án để thiết kế và sản xuất các sản phẩm khác nhau. Trong trường hợp này, nhóm dự án phải phát triển một quy trình xác nhận phạm vi đáp ứng các nhu cầu duy nhất của dự án. Các quy trình cẩn thận phải được phát triển để đảm bảo rằng khách hàng nhận được những gì họ muốn và nhóm dự án có đủ thời gian và tiền bạc để sản xuất các sản phẩm và dịch vụ mong muốn.

Xác nhận phạm vi liên quan đến việc chấp nhận chính thức các sản phẩm dự án đã hoàn thành. Sự chấp nhận này thường đạt được bằng sự kiểm tra của khách hàng và sau đó ký tên trên các sản phẩm chính. Để nhận được sự chấp nhận chính thức về phạm vi dự án, nhóm dự án phải xây dựng tài liệu rõ ràng về các sản phẩm và thủ tục của dự án để đánh giá xem chúng có được hoàn thành một cách chính xác và đạt yêu cầu hay không.

Kiểm soát quản trị phạm vi dự án

Kiểm soát phạm vi liên quan đến việc quản lý các thay đổi đối với phạm vi dự án trong khi vẫn lưu ý các mục tiêu dự án và chiến lược kinh doanh. Người dùng thường không chắc chắn họ muốn màn hình trông như thế nào hoặc họ sẽ cần chức năng gì để cải thiện hiệu suất kinh doanh. Các nhà phát triển không chắc chắn chính xác cách giải thích các yêu cầu của người dùng và họ cũng phải đối phó với các công nghệ thay đổi liên tục.

Mục tiêu của kiểm soát phạm vi là tác động đến các yếu tố gây ra thay đổi phạm vi, để đảm bảo rằng các thay đổi được xử lý theo các thủ tục được phát triển như một phần của kiểm soát thay đổi tích hợp và quản lý các thay đổi khi chúng xảy ra. Kế hoạch quản lý dự án, tài liệu yêu cầu, ma trận xác định nguồn gốc yêu cầu, dữ liệu thực hiện công việc và tài sản quy trình tổ chức là những yếu tố đầu vào chính để kiểm soát phạm vi.

PHÁT SINH PHẠM VI DỰ ÁN

Phát sinh (tăng) phạm vi dự án là gì?

Tăng phạm vi dự án xảy ra khi khi phạm vi, các sản phẩm phân phối hoặc các tính năng trong một dự án mở rộng so với những gì đã được thiết lập ban đầu — mà không bị tính vào thời gian hoặc ngân sách bổ sung (Suzana, 2018). Nó có thể ảnh hưởng đến bất kỳ dự án phạm vi cố định nào. Đó là một điều rất phổ biến, vì nó có thể xảy ra cả cố ý và vô ý, bắt nguồn từ bất kỳ số lượng người nào tham gia vào một dự án.

Điều đáng lo ngài là thay đổi phạm vi có thể dẫn đến thất bại của dự án: có thể bạn không đạt thời hạn, bạn đốt cháy toàn bộ ngân sách (và hơn thế nữa) và tất cả mà không mang lại điều phù hợp.

Giảm thiểu việc tăng phạm vi dự án

• Không có phạm vi rõ ràng

Đối với bất kỳ dự án nào, tính rõ ràng là hết sức quan trọng và cần thiết. Nếu ngay từ đầu không thể định nghĩa một cách rõ ràng phạm vi dự án thì chắc chắn sẽ gây ra những vấn đề nan giải sau này. Chính vì thể, các cá nhân thuộc dự án cần phải hiểu rất rõ phạm vi của dự án. Cách tốt nhất để thực hiện việc này là “kéo” cả đội cùng tham gia vào việc xây dựng phạm vi dự án ngay từ đầu.

• Không có sự thống nhất với khách hàng

Nếu khách hàng không tham gia vào việc xác định phạm vi dự án, rất có thể họ sẽ thay đổi quyết định và cả yêu cầu về sản phẩm bàn giao. Do đó, cần chắc chắn ràng khách hàng hiểu rõ những công việc gì thuộc và không thuộc phạm vi dự án. Việc chỉ gửi một số tài liệu mô tả các sản phẩm bàn giao sẽ không hiệu quả bằng trao đổi trực tiếp và kĩ lưỡng với họ về phạm vi dự án. Chúng ta cần tường minh mọi thứ bằng cách đặt những câu hỏi như: Anh chị đã rõ sản phẩm bàn giao là gì chưa? Hay anh chị sẽ nhận được gì sau dự án chưa?

• Khách hàng không tham gia xuyên suốt quá trình dự án

Sau một hoặc hai tháng triển khai công việc, kết quả được chuyển cho khách hàng để lấy ý kiến phải hồi. Kết quả rất đáng ngạc nhiên – phải làm lại toàn bộ hoặc điều chỉnh rất nhiều. Việc này ảnh hưởng lớn đến thời gian triển khai và chi phí dự án. Để tránh việc này xảy ra, đội dự án cần phối hợp chặc chẽ với khách hàng để họ thấy được công việc đang tiến triển, xoay vòng liên tục.

• Không chủ động đưa ra các vấn đề

Ban đầu, việc che giấu các vấn đề và không minh bạch với khách hàng hoặc bên liên quan có vẻ dễ dàng hơn nhưng sau này bạn sẽ phải hối hận. Khi gặp phải vẫn đề phát sinh ngoài ý muốn, quản lý dự án cần đưa ra ngay lập tức. Tất nhiên, trước đó bạn cũng cần phải phân tích và đưa ra một số giải pháp để việc phối hợp xử lý hiệu quả và nhanh chóng hơn.

• Kiểm soát chất lượng (QA) cần nhiều thời gian hơn dự kiến

Việc QA ước tính luôn là vấn đề khó khăn. Làm sao có thể ước lượng chính xác được bao nhiêu lỗi có thể xảy ra hay mất bao lâu để xử lý được hay ảnh hưởng của chúng là gì? Việc ước tính các công việc dựa trên độ phức tạp của sản phẩm và cộng thêm dự phòng.

Đưa ra phần trăm ước lượng là không đủ mà cần nói chuyện với chuyên viên QA và yêu cầu họ đánh giá. Ngoài ra, cần chuẩn bị trước các thông tin liên quan như việc chạy sản phẩm trên môi trường nào, thiết bị nào… Tất cả sẽ giúp QA đưa ra những ước tính chi tiết và chất lượng hơn.

• Không đặt ưu tiên giữa các tính năng

Đối với một dự án kiểu thác nước (Waterfall), sản phẩm được phát triển lần lượt các tình năng cho đến khi mọi thứ hoàn chỉnh và đi vào hoạt động. Điều này sẽ khiến đội dự án có xu hướng mọi thứ đều là ưu tiên. Tuy nhiên, khi không có một định nghĩa ưu tiên rõ ràng cho các tính năng, thì sẽ rất khó để xác định được phần nào cần gỡ bỏ, thu gọn khi yêu cầu bắt đầu có sự điều chỉnh.

Uu tiên các tính năng bằng cách xác định những gì cần thiết để triển khai một sản phẩm có thể sử dụng được. Xác định các tính năng nào là thực sự cần thiết cho người dùng và xây dựng một sản phẩm hoạt động có thể được khách hàng thử nghiệm và sử dụng ở mỗi giai đoạn.

• Không thống nhất về cách xử lý các thay đổi

Nếu ngày từ đầu dự án, không thống nhất được các xử lý các thay đổi thì sẽ rất khó khăn để thực hiện các thay đổi về phạm vi khi có phát sinh sau này. Do đó, cần phải đưa vào trong tài liệu tuyên bố phạm vi công việc cách mà bạn định xử lý các thay đổi. Nếu sử dụng Yêu cầu thay đổi thì cần thật chi tiết những gì trong phạm vi và ngoài phạm vi cũng như cách đưa ra Yêu cầu thay đổi.

• Ước tính sai

Ước tính thì rất khó để chính xác. Thách thức lớn nhất của việc này chính là khi dự án có quá nhiều yếu tố chưa rõ ràng. Để xử lý việc này hiệu quả, quản lý dự án cần ngồi lại với cả đội để cùng thực hiện việc ước tính.

Đảm bảo bạn đã khám phá và xác định các yêu cầu của khách hàng và doanh nghiệp so với yêu cầu của người dùng trước khi ước tính. Thay vì ước tính dựa trên sản phẩm bàn giao, có thể dự vào các yếu tố sau:

• • Ước tính cho một giai đoạn khám phá để xác định những gì bạn sẽ xây dựng — khi kết thúc giai đoạn này, bạn có thể cung cấp ước tính chính xác hơn cho phần còn lại của dự án.
  • Cân nhắc sử dụng mô hình định giá Thời gian và Vật liệu thay vì Giá cố định. Vì bạn đang thanh toán số giờ thực tế trong dự án, nên nó có thể linh hoạt hơn nhiều.
  • Không chỉ định chính xác những tính năng nào đang được xây dựng và cách thức trong phạm vi — hãy cho phép thay đổi.
• Không thẩm định các yêu cầu mới

Khi có một yêu cầu hay một ý tưởng mới từ phía khách hàng hoặc thành viên dự án, sẽ rất dễ dàng nếu ta tin rằng đó là nhưng thứ đúng đẵn và chỉ cần làm theo. Đây có thể là nguyên nhân của việc tăng hạm vi dự án. Nếu các yêu cầu này không được thẩm định một cách cẩn thận, rất có thể bạn sẽ chấp nhận chúng mà không biết rằng đây là một việc thừa hay một tính năng không cần thiết.

Để tránh việc này, cần phải đánh giá tất cả các yêu cầu mới cùng với cả đội dự án. Tạo hiểu biết rõ ràng về yêu cầu là gì, tác động của việc kết hợp yêu cầu và kết quả của yêu cầu đối với người dùng. Sau đó, sắp xếp thứ tự ưu tiên cho yêu cầu mới và kiểm tra chéo để đảm bảo yêu cầu đó chưa được thực hiện trong một tính năng tương tự trước đây.

• Người dùng tham gia quá muộn

Đã có rất nhiều dự án đi đến bước cuối cùng mà không có sự tham dự của người dùng thực tế. Rất sai lầm khi cho rằng khách hàng, doanh nghiệp và cả đội dự án biết đúng và đủ nên không cần tương tác với người dùng của hệ thống.

Cần phải thu hút người dùng sử dụng sản phẩm hoặc dịch vụ sớm nhất có thể. Nếu khách hàng hoặc chủ ngân sách không muốn trả tiền cho việc này, thì cần chỉ rõ lợi ích của việc này cũng như những tác động tiêu cực nếu không thực hiện nó một cái bài bản. Có kế hoạch giải quyết phản hồi của người dùng ở bất cứ đâu trong dự án.

KẾT LUẬN

Trong xu hướng phát triển hiện nay, việc phát sinh hay tăng phạm vi dự án là điều khó tránh khỏi. Tuy nhiên, không nên nhìn nhận việc đó với một thái độ cực đoan và cứng nhắc. Hãy coi đó là những thay đổi thay vì là vấn đề phát sinh. Những thay đổi thì thực chất luôn xuất phát từ mong muốn đem lại lợi ích cho dự án hay sản phẩm. Việc quản lý những thay đổi này cần tập trung vào góc độ ảnh hưởng của nó tới dự án như thế nào chứ không phải nó thay đổi như thế nào. Tất cả những gì chúng ta cần làm là cần nhận biết được những thay đổi đó sớm đặc biệt là với những thay đổi không rõ ràng. Cần đưa ngay trước khi chúng tiến triển mà không có một kế hoạch cụ thể để thực hiện và kiểm soát.

Thay đổi thực sự có thể mang lại lợi ích to lớn cho sản phẩm bạn đang tạo ra. Xét cho cùng, tất cả chúng ta đều ở đây để xây dựng các sản phẩm và dịch vụ tốt nhất có thể, và nếu điều đó có nghĩa là các yêu cầu phải thay đổi, thì chúng ta, với tư cách là người quản lý dự án, cần phải dẫn đường để thích ứng với điều này.

THAM KHẢO

Kathy Schwalbe (2014). Information Technology Project Management. Course Technology, Cengage Learning.

Project Management Institute. (2017). A guide to the Project Management Body of Knowledge (PMBOK guide) (6th ed.). Project Management Institute.

Suzanna, H. (2018, October 1). Identify And Avoid Project Scope Creep. Retrieved from https://thedigitalprojectmanager.com/scope-creep/

Natalie, S. (2917, May 9). Why Do Projects Fail? Stories of Project Failure, And Lessons Learned. Retrieved from https://thedigitalprojectmanager.com/why-do-projects-fail-stories-of-project-failure/