Sau quá trình tích cực tham gia công tác quản lý dự án từ năm 1971 đến nay, tôi dần giác ngộ được một sự thật: Các nhà quản lý dự án thành công đã sử dụng các công cụ, khái niệm và kỹ thuật từ rất lâu trước khi quy trình Quản Lý Dự Án (QLDA) được chính thức tiêu chuẩn hoá.
Kể từ thời kỳ xây dựng kim tự tháp, đã có những nhân vật được phân bổ nhiệm vụ lập kế hoạch, tìm nguồn cung ứng, theo dõi, chỉ đạo, cộng tác, báo cáo tiến độ và nhiều hơn nữa. Có lẽ dự án tầm vóc đầu tiên của con người trong thời kỳ hiện đại là việc xây dựng đường sắt xuyên lục địa.
Các phương thức giao tiếp và tiêu chuẩn hóa QLDA phát triển theo dòng chảy thời gian. Nhưng trên hết, hầu hết các nhà quản lý dự án dày dạn kinh nghiệm đều thực hành từ những điều cơ bản và xem xét tất cả các công cụ và kỹ thuật như tài sản để sử dụng khi cần thiết. Do đó, có thể nói rằng QLDA Kết Hợp – sử dụng các công cụ cần thiết để hoàn thành công việc – đã tồn tại song hành với chúng ta từ thời cổ đại.
Điều quan trọng là phải có một ngôn ngữ và thuật ngữ chung để chia sẻ và trò chuyện về QLDA. Trở ngại phát sinh khi chúng ta suy nghĩ quá nhiều và bị phân tâm với việc dán nhãn công việc khiến trọng tâm bị chệch hướng. Khi đó, ta phạm phải một sai lầm: tập trung vào hình thức hơn là chức năng.
Lấy ví dụ, nhiều lần sau khi hoàn thành xuất sắc một dự án (dự án này đã đạt được mục tiêu về thời gian và ngân sách, triển khai với sự đồng lòng và được hỗ trợ, đồng thời vẫn tôn trọng các giá trị, văn hóa của tổ chức), tôi lại được hỏi, “Dự án này dựa trên phương pháp Agile phải không?” (Hoặc “Hay là triết lý Lean?”, “Công ty đã sử dụng phương pháp Thác nước truyền thống à?”).
Hãy tưởng tượng nếu bạn mới đóng một mái nhà mới cho ngôi nhà của mình và câu hỏi đầu tiên bạn nhận được là là “Bạn đã dùng cái búa nào thế?”. QLDA Kết Hợp không giới hạn quy trình và công cụ cho một khuôn khổ công việc cụ thể, mà cốt lõi là tạo ra một cách tiếp cận linh hoạt, phù hợp để sử dụng các công cụ và kỹ thuật cần thiết nhằm phục vụ mục đích cuối cùng – hoàn thành công việc.
Nói một cách đơn giản, những doanh nghiệp, tổ chức theo đuổi phương pháp QLDA Kết Hợp sẽ làm tất cả những gì mang lại hiệu quả. Họ không thực sự quan tâm hoặc suy nghĩ về cách gọi tên các kỹ thuật, mà sự quan tâm của họ dành cho việc hiểu những công cụ và kỹ thuật nào hoạt động tốt nhất và làm thế nào để sử dụng chúng một cách tối ưu nhất.
Vào tháng 5 , tôi đã viết một bài báo có tựa đề “Lập kế hoạch & Quản lý Dự án Đang Phát triển – Con đường Kết Hợp”. Tôi cung cấp một biểu đồ như sau, liệt kê các công cụ và kỹ thuật được sử dụng trong các khung và quy trình công việc khác nhau:
THÀNH PHẦN | KHUNG/ QUY TRÌNH | VÍ DỤ ĐẦU RA |
Xác nhận căn chỉnh dự án – phân phối dự án và định lượng dự án trong bối cảnh hướng đến các mục đích và mục tiêu của tổ chức; xác định các bên liên quan chính, các quy trình kinh doanh bị ảnh hưởng, các chuyên gia kiến thức, v.v. | Tập hợp các phiên làm việc thuận lợi cùng với phân tích kinh doanh. | · Bản đồ căn chỉnh · Các quy trình kinh doanh bị ảnh hưởng với kiến thức liên quan/ các chuyên gia phân tích vấn đề và hệ thống liên đới · Phân tích GAP mức độ cao (thách thức và trở ngại ngăn chặn đạt được mục tiêu ngay lập tức) · Nhu cầu nén thời gian và cân bằng · Chỉ số hiệu suất sau triển khai |
Khám phá các yêu cầu – Mục tiêu tổ chức và phân tích đối tượng GAP, phân tích quy trình nghiệp vụ, các yêu cầu hỗ trợ quy trình CNTT (rõ ràng / ngụ ý), căn chỉnh và ánh xạ truy vết |
Hội thảo Lean, Helix BPI, Kaizen, v.v.
| · Phân tích GAP · Các mô hình quy trình trạng thái hiện tại và tương lai · Sự kiện chuyển đổi dữ liệu, trình kích hoạt và quy tắc |
Thiết kế Vĩ Mô – Mô hình dữ liệu và bản đồ từ điển, các kết quả chuyển giao, các thành phần, quy tắc nghiệp vụ, v.v | Phân tích cấu trúc dữ liệu. | · Mô hình dữ liệu và các vấn đề chuyển đổi được phát hiện · Quy tắc nghiệp vụ · Thuật toán chính · Danh sách yêu cầu |
Chiến lược phát triển – Làm thế nào các yêu cầu, thiết kế, lập trình, thử nghiệm, đào tạo và quá trình triển khai sẽ hoạt động (tiêu tốn bao nhiêu thời gian, sử dụng bao nhiêu công cụ, v.v…) | Phân tích và cộng tác dự án. | · Kế hoạch phát hành · Sản phẩm/kết quả chuyển giao (được phân tách thành từng kế hoạch và gói riêng lẻ) · Các tùy chọn phát triển đồng thời (phân phối nguồn lực và triển khai thời gian) |
Phát triển – Yêu cầu thông số kỹ thuật, thiết kế, xây dựng, thử nghiệm / đào tạo | · Phương pháp truyền thống theo mô hình Thác nước · Phương pháp Agile · Phương thức/Khung làm việc Scrum | · Các hàm, mô-đun, v.v. có thể triển khai |
Thực hiện kế hoạch – Quản lý, hiệu chỉnh lại, v.v.) | Tất cả các khung quản lý dự án. | · Báo cáo tiến độ dự án · Thông tin liên lạc của bên liên quan · Loại bỏ khoanh vùng · Kiểm tra tình trạng · Quản lý ngân sách · Quản lý thời gian · Tuân thủ quản trị |
Triển khai và giám sát kết quả | Một hoặc nhiều dựa trên chiến lược phát hành. Giám sát số liệu. | · Phân tích và đánh giá thành tích hiệu suất/ROI |
Trong hai dự án gần đây, các phương pháp tôi đã sử dụng và kết quả đầu ra được tạo ra có nhiều điểm tương đồng và đều mang tính đa dạng. Trong lần đầu tiên (một dự án phát triển), công việc được tổ chức thành các mô-đun và các sản phẩm chuyển giao sẽ được tạo ra trong mỗi mô-đun. Các đội sẽ kiểm tra các mô-đun thường xuyên và phát triển các yêu cầu chi tiết, thiết kế các thông số kỹ thuật và các nguyên mẫu liên quan. Bằng cách này, các mô-đun có thể được xử lý cùng một lúc. QA của mỗi mô-đun được tập trung tối đa. Thành phần thiết kế cơ sở dữ liệu cũng được chú trọng.
Trong dự án thứ hai (triển khai lại ERP), nỗ lực tập trung vào việc tạo điều kiện cho người dùng thông qua một quá trình phân tích biến động dẫn đến khoảng 45 sự chuyển dịch – thay đổi, sau đó được tổ chức thành khoảng 20 dự án nhỏ. Các dự án nhỏ được ưu tiên, với mỗi dự án được thiết kế để khắc phục một vấn đề cụ thể. Thông số kỹ thuật cho các chuyển dịch-thay đổi này bao gồm các câu chuyện, các trường hợp nghiệp vụ và các quy tắc quy trình. Cuối cùng, các chuyển dịch đã được kiểm tra, phê duyệt và thực hiện bằng cách sử dụng phương pháp triển khai liên tục.
Vấn đề ở đây là các phương pháp khả dụng được xây dựng từ nhu cầu của dự án; nó thuận theo tự nhiên. Không bao giờ có một cuộc thảo luận về khung nào là tốt nhất. Chỉ có kết quả đạt được và việc sử dụng con người, quy trình và công cụ hiệu quả tới mức độ nào để đạt được chúng. Đó là cách QLDA Kết Hợp hoạt động trong thực tế.
Với tất cả những kiến thức trên, tôi vẫn phải thú nhận rằng tôi có một khung phát triển ưu tiên khi nói đến các dự án cải tiến quy trình hàng đầu sở hữu một yếu tố CNTT phát triển mạnh. Các công cụ và kỹ thuật được rút ra từ nhiều nguyên lý khác nhau, và đều tôn trọng khởi nguồn của nó – quy luật kết hợp trong tự nhiên. Dưới đây là tóm tắt về quy trình:
- Xác thực và định lượng các mục tiêu: Dành thời gian với quản lý và các bên liên quan chính để xác nhận mục tiêu của dự án — và định lượng các mục tiêu đó theo cách hỗ trợ theo dõi số liệu thành công sau triển khai.
- Tiến hành các buổi tìm hiểu và phân tích yêu cầu công việc: Tổ chức các nhóm hoạt động theo các quy trình từ kết thúc-đến-kết thúc, để chịu đựng tác động bởi những thay đổi mà các mục tiêu mang lại. Với mỗi đội, hãy làm như sau:
- Cộng tác với họ để xác định những vấn đề, thực tiễn và điều kiện nào ảnh hưởng đến việc đạt được các mục tiêu và những thay đổi nào cần phải được thực hiện để thành công trong mục tiêu đó.
- Làm việc với các nhóm trên để phá bỏ các quy trình hiện tại (trạng thái hiện tại) về các giai đoạn cơ bản của chúng và xác định yếu điểm của quy trình đã bị phá vỡ để ngăn cản nhóm đạt mục tiêu.
- Khi đã xong, hãy lặp lại quy trình để phản ánh dòng chảy công việc với những thay đổi tại vị trí cần thiết để hỗ trợ các mục tiêu (trạng thái trong tương lai).
- Thực hiện chẩn đoán về các quy trình mới để xác định điểm tiếp xúc CNTT, theo dõi và báo cáo quy tắc và sản phẩm chuyển giao có liên quan (rõ ràng và ngụ ý).
- Phát triển các khái niệm thay đổi / tận dụng các trường hợp / quy tắc kinh doanh cho từng điểm tiếp xúc và sản phẩm chuyển giao.
- Thực hiện phân tích cấu trúc dữ liệu để tạo ra một mô hình dữ liệu hỗ trợ các quy trình và sản phẩm chuyển giao
- Xây dựng các quy trình mẫu cho từng quy trình / sản phẩm chuyển giao mà ở đó mô tả được cách mỗi quy trình tương tác với các bảng mô hình dữ liệu (các quy tắc I / O).
- Xác định các chức năng và sản phẩm chuyển giao bổ sung được tiết lộ bởi nỗ lực lập mô hình quy trình I / O.
- Chuẩn bị ước tính công việc cho mỗi sản phẩm chuyển giảo cho từng giai đoạn của SDLC dựa trên phân loại và độ phức tạp.
- Chuyển đổi kết quả chuyển giao thành gói công việc: Khi hoàn thành, mỗi gói chứa tất cả dữ liệu và thông tin cần thiết để triển khai (bao gồm quy tắc nghiệp vụ, quy tắc, mẫu, nguyên mẫu, thông số thiết kế, mã, yêu cầu kiểm tra, yêu cầu đào tạo, v.v.). Sử dụng phương pháp chạy nước rút Sprints hoặc các phương pháp đóng khung theo thời gian khác để phát triển từng gói riêng.
- Lắp ráp, thử nghiệm, triển khai: Điều chỉnh nỗ lực này dựa trên các ứng dụng và môi trường có liên quan.
Vấn đề là, mặc dù có sự khác biệt giữa khung phát triển công việc kết hợp và khung quản lý dự án kết hợp, cả hai vẫn thường được sử dụng đồng thời, phối hợp với nhau. Trong thực tế, cách thức các khung phát triển công việc trên được quản lý rất ít liên quan đến quá trình triển khai. Người quản lý dự án vẫn cần phát triển các điều lệ, chuẩn bị kế hoạch truyền thông, chuẩn bị kế hoạch dự án, quản lý thay đổi phạm vi, quản lý ngân sách, phân công và quản lý tài nguyên, tiến hành đánh giá, chuẩn bị báo cáo trạng thái, xóa chướng ngại vật, v.v…
Các công cụ và kỹ thuật thay đổi dựa trên tổ chức, hoàn cảnh, văn hóa và hơn thế nữa. Các nhà quản lý dự án thường xuyên thay đổi, thích ứng cách tiếp cận của họ để phù hợp với nhu cầu, từ quá trình tạo sản phẩm đến cách họ làm việc với con người. Đối với người tuân theo phương pháp QLDA Kết Hợp, một kích thước không thể phù hợp với tất cả — cũng như một khuôn khổ không thể phù hợp với mọi tình huống (ít nhất, đó là quan điểm của tôi).
Trong tổ chức của bạn, những mức độ và quyền tự do nào mà các nhà quản lý dự án phải nhào nặn để phù hợp với các khuôn khổ, quy trình và công cụ khả dụng cho dự án mà họ dẫn dắt? Mức độ thành công nào của dự án – với giá trị dự định ban đầu – đi đôi với phương pháp tiếp cận nào tổ chức của bạn đang sử dụng? Tôi rất mong được mở rộng tầm nhìn thông qua cái nhìn sâu sắc và khoan dung của các bạn độc giả. Các ý kiến đóng góp và nhận định sáng suốt của quý độc giả thật sự rất giá trị. Vì vậy, xin hãy thể hiện quan điểm của bạn ở đây hoặc kết nối với tôi!
Nguồn: www.projectmanagement.com Hybrid PM: The Organic Option.
Người dịch: Kat – Masterskills
một số bài viết liên quan.
