Tài liệu Quản lý quy mô dự án (project scope management)

TRƯỜNG ĐẠI HỌC HÀNG HẢI VIỆT NAM ---------------------------- BÁO CÁO TIỂU LUẬN MÔN HỌC: QUẢN LÝ DỰ ÁN CÔNG NGHỆ THÔNG TIN Đề tài: QUẢN LÝ QUY MÔ DỰ ÁN (PROJECT SCOPE MANAGEMENT) GVHD : TS. Trần Đăng Hoan Nhóm 01 : Lê Hoàng Dương Nguyễn Trường Giang Nguyễn Thị Giang Hải Phòng, tháng 5 năm 2014 MỤC LỤC Tổng quan....................................................................................................................... 3 I. Thu thập yêu cầu (Collect Requirement): ............................................................... 6 1.1. Khái niệm: ...........................................................................................................6 1.2. Yêu cầu trong dự án bao gồm những gì? ......................................................... 6 1.3. Để thu thập yêu cầu của dự án thì phải làm như thế nào? ............................. 7 II. Xác định quy mô (Define Scope):............................................................................ 9 2.1. Khái niệm: ...........................................................................................................9 2.2. Mục đính, vai trò của việc xác đinh quy mô dự án .......................................10 2.3. Phương pháp xác định quy mô dự án ............................................................. 11 2.3.1. Các bước để xác định quy mô của một dự án: .......................................11 2.3.2. Những công cụ, kỹ thuật để nhà quản trị xác định quy mô dự án ...............12 2.4. Sản phẩm, đầu ra của việc xác định quy mô dự án .......................................12 III. Tạo Work Breakdown Strutue (cây phân rã công việc – WBS) : .................... 13 3.1. Khái niệm: .........................................................................................................13 3.2. Lợi ích của việc dùng WBS ..............................................................................14 3.3. Một số luật để tạo WBS....................................................................................14 3.4. Cách xây dựng WBS: ....................................................................................... 15 c ti p c n ph t tri n W S: ......................................................................15 2 c nguyên lý cơ bản tạo WBS:..................................................................16 3.4.3. Một số dạng WBS ....................................................................................... 16 3.5. Vai trò của WBS trong việc thay đổi quy mô dự án .....................................18 3.6. WBS Dictionary: ............................................................................................... 19 3.7. Scope baseline: ..................................................................................................20 IV. Xác minh quy mô (Verifying Scope) ................................................................... 21 V. Kiểm soát quy mô (Controlling Scope) ................................................................. 22 5.1. Khái niệm: .........................................................................................................22 5.2 Theo dõi và kiểm soát thực hiện dự án ............................................................ 22 5.2.1 Theo dõi dự án: ............................................................................................. 22 5.2.2. Quản lý quy mô dự án .................................................................................23 5.3 Kiểm soát dự án ................................................................................................ 25 5 Điều phối và theo v t dự án:.........................................................................25 5.3.2 Ki m soát vấn đề: ......................................................................................... 25 Trang 1 5.3.3 Họp định kì ...................................................................................................26 5.3.4.Ki m soát nguồn lực .....................................................................................26 5.3.5 Quản lí mua sắm chi phí ...............................................................................26 5.3.6 Ki m soát chất lượng và ki m soát rủi ro.....................................................27 KẾT LUẬN .................................................................................................................. 28 TÀI LIỆU THAM KHẢO .......................................................................................... 29 Trang 2 Tổng quan Đ đạt được thành công cho một dự án thì cần phải có rất nhiều các y u t c động vào đòi hỏi người quản lý dự án phải x c định và ki m so t được đ có th quản lý được dự n do mình đảm nh n và hơn h t là đảm bảo cho dự án không bị hỏng. Một trong những khía cạnh quan trọng nhất và khó khăn nhất của người quản lý dự án là phải xác định được quy mô của dự án. Quy mô của dự án ở đây là đề c p đ n tất cả các công việc liên quan trong việc tạo ra các sản phẩm của dự án và các quá trình đ tạo ra chúng. Việc quản lý quy mô dự án ở đây bao gồm quản lý các công việc liên quan đ n dự án, các yêu cầu đối với sản phẩm, các tài sản trong quá trình thực hiện, quản lý c c bên liên quan đ n dự án, những nhà tài trợ,...Mục tiêu cuối cùng của việc x c định những y u tố trên đ đảm bảo rằng các nhóm dự án và các bên liên quan có cùng sự hi u bi t về những sản phẩm sẽ được sản xuất trong dự án và những ti n trình mà nhóm dự án sẽ sử dụng đ sản xuất chúng ó năm qu trình chính liên quan đ n việc quản lý quy mô dự án: 1. Thu thập các yêu cầu: quá trình này x c định và ghi lại c c tính năng và chức năng của các sản phẩm sản xuất trong dự n cũng như c c quy trình được sử dụng đ tạo ra chúng. Nhóm dự án phải x c định được những yêu cầu các bên liên quan, k hoạch quản lý các yêu cầu, c c điều lệ, văn bản, giấy tờ liên quan đ n quy trình cửa dự án. Tại giai đoạn này, các kỹ thu t và công cụ được sử dụng như: phỏng vấn đ x c định yêu cầu, hội thảo, họp nhóm đ có th dựa vào khả năng làm việc của t p th mà phân tích, xác định được những yêu cầu cần thi t, ngoài ra cần phải x c định được các y u tô t c động qua việc khảo sát, so s nh, x c định các tiêu chuẩn,…K t quả của quá trình này là nhóm dự án sẽ x c định được tất cả các yêu cầu liên quan đ n dự án và một ma tr n nguồn gốc các yêu cầu. 2. Xác định quy mô dự án: quá trình này sẽ thực hiện việc xem xét c c điều lệ của dự án, yêu cầu tài liệu, tài sản và quá trình tổ chức đ tạo ra bảng kê về quy mô dự án, bổ sung thêm các thông tin cho tài liệu của dự án về các yêu cầu được xét duyệt, được thêm mới.Tại giai đoạn này, các kỹ thu t và công cụ dược sử dụng như: sử dụng c c đ nh gi , ph n xét của chuyên gia thông qua những hi u bi t, kinh nghiệm được tích lũy qua c c dự án khác; phân tích sản phẩm đ xác định được quy mô mức độ của các y u tốt liên quan đ n việc tạo ra sản phẩm. K t quả đầu ra chính của qu trình x c định quy mô là báo cáo về quy mô của dự án và việc c p nh t các tài liệu của dự án. 3. Tạo cây phân rã công việc WBS (Work Breakdown Structure): quá trình này sẽ thực hiện phân chia dự án lớn thành các dự án, các công việc nhỏ hơn đ dễ dàng quản lý hơn Đ thực hiện xây dựng được một cây phân rã công việc, cần phải có các kỹ năng và kinh nghiệm trong việc đ nh gi , phân tích, từ đó thực hiện phân rã hệ thống thành các công việc và các yêu cầu nhỏ hơn K t quả đầu ra chính bao gồm một cây phân rã công việc, một từ đi n WBS, quy mô ban đầu, và việc c p nh t những thay đổi của tài liệu dự án. Trang 3 4. Xác minh quy mô: quá trình này sẽ thực hiện việc sự chấp nh n chính thức sự phân chia công việc trong dự án. Đối tượng thực hiện quá trình này chính các bên liên quan đ n dự án: chẳng hạn như kh ch hàng và nhà tài trợ cho dự án, ki m tra và sau đó chính thức chấp nh n sự phân phối trong quá trình này. N u khả năng đ p ứng là không th chấp nh n được, khách hàng hoặc nhà tài trợ thường yêu cầu thay đổi. Các k t quả chính của quá trình này là những yêu cầu thay đổi và sự thay đổi trong ma tr n nguồn gốc yêu cầu. 5. Kiểm soát quy mô: quá trình này sẽ thực hiện việc thay đổi về quy mô dự án. Vì trong suốt quá trình thực hiện dự án sẽ có những thay đổi về: k hoạch phát sinh trong thực t , hiệu suất lao động của nhân viên, sự thay đổi về tài sản trong quá trình thực thi dự n,… chính vì v y quy mô dự án bắt buộc phải có sự điều chỉnh trong từng giai đoạn khác nhau. Khi quy mô dự n thay đổi thường ảnh hưởng đ n khả năng đ p ứng về các mặt thời gian dự án và mục tiêu chi phí. Các nhà quản lý dự án cần cân nhắc kỹ các chi phí và lợi ích của quy mô thay đổi. Các k t quả chính của quá trình này là yêu cầu thay đổi, thông tin hiệu quả công việc, và c p nh t tài sản quá trình thực hiện, các tài liệu quản lý dự án. Trang 4 Mô hình tổng quan về việc quản lý quy mô dự án Quản lý quy mô dự án I. Thu thập yêu cầu Đầu vào: - K hoạch quản lý quy mô - K hoạch quản lý yêu cầu - K hoạch quản lý các bên liên quan - c điều lệ của dự án - Sự đăng ký của các bên liên quan. 2. Công cụ & kỹ thu t: - Phỏng vấn - T p trung nhóm - Hội thảo - Kỹ thu t sáng tạo nhóm - Kỹ thu t đưa ra quy t định nhóm - Khảo s t và điều tra - Quan sát - Nguyên mẫu - Tiêu chuẩn - Sơ đồ ngữ cảnh - Tài liệu phân tích Đầu ra: - Những yêu cầu - Ma tr n nguồn gốc yêu cầu II. Xác định quy mô: Đầu vào: - K hoạch quản lý quy mô - Điều lệ dự án - Những yêu cầu - Các tài sản trong quá trình thực hiện 2. Công cụ & kỹ thu t: - Sự đ nh gi chuyên gia - Phân tích sản phẩm - Th hệ thay th - Hội thảo Đầu ra: - Bảng kê quy mô dự án - Những c p nh t cho tài liệu dự án III. Tạo cây phân rã công việc Đầu vào: - K hoạch quản lý quy mô - Bảng kê quy mô dự án - Những yêu cầu - Các y u tố môi trường doanh nghiệp. - Các tài sản trong quá trình thực hiện 2. Công cụ & kỹ thu t: - Phân rã chức năng - Sự đ nh gi chuyên gia Đầu ra: - Quy mô cơ sở - Những c p nh t cho tài liệu dự án IV. Xác minh quy mô Đầu vào: - K hoạch quản lý dự án - Những yêu cầu - Ma tr n nguồn gốc yêu cầu - Xác minh phân phối - Dự liệu hiệu suất công việc 2. Công cụ & kỹ thu t: - Ki m tra - Kỹ thu t đưa quy t định nhóm Đầu ra: - Những yêu cầu - Ma tr n nguồn gốc yêu cầu V. Kiểm soát quy mô Đầu vào: - K hoạch quản lý dự án - Những yêu cầu - Ma tr n nguồn gốc yêu cầu - Dữ liệu hiệu suất công việc - Các tài sản trong quá trình thực hiện 2. Công cụ & kỹ thu t: - Phân tích phương sai Đầu ra: - Thông tin hiệu quả công việc - Thay đổi yêu cầu - Những thay đổi về k hoạch quản lý dự án - Những c p nh t về tài liệu dự án - Những c p nh t về tài sản trong quá trình thực hiện Trang 5 I. Thu thập yêu cầu (Collect Requirement): 1.1. Khái niệm: Giai đoạn đầu tiên trong việc quản lý quy mô dự n thường là khó khăn nhất: thu th p các "yêu cầu". Một h u quả của việc không x c định yêu cầu thường là phải làm lại, mà việc này có th làm lãng phí đ n một nửa chi phí của dự n, đặc biệt là các dự án phát tri n phần mềm. Ta có th quan sát hình minh họa 1.1 th hiện chi phí phải mất đ sửa chữa một phần mềm bị lỗi: Hình 1.1. Chi phí để sửa một phần mềm bị lỗi Ta có th quan sát thấy rằng việc sửa chữa một phần mềm được sửa chữa trong các giai đoạn phát tri n sau này sẽ tốn kém hơn rất nhiều so với việc sửa chữa nó ở giai đoạn yêu cầu. Bên cạnh đó, một phần của khó khăn liên quan đ n việc người ta không xác định được những "yêu cầu" là gì, làm c ch nào đ có th thu th p và văn bản hóa được chúng. 1.2. Yêu cầu trong dự án bao gồm những gì? Năm 990 tổ chức IEEE đã định nghĩa trong từ đi n kỹ thu t phần mềm về "yêu cầu" như sau: (1). Là một điều kiện, một tác nhân cần thi t cho người sử dụng đ giải quy t một vấn đề hoặc đạt được một mục tiêu nào đó (2). Một điều kiện, một tác nhân phải được đ p ứng hoặc sở hữu bởi hệ thống hay một thành phần của hệ thống đ đ p ứng các hợp đồng, tiêu chuẩn, đặc đi u kỹ thu t hoặc các tài liệu được p đặt khác. (3). Một tài liệu trình bày những điều kiện, t c nhân được trình bày ở mục (1) và (2) Trang 6 Trong cuốn PMBOK ® Guide, phiên bản thứ tư, định nghĩa về "yêu cầu" gần giống như ở mục (2) ở trên: nó nêu ra rằng một "yêu cầu" là một điều kiện, tác nhân phải được đ p ứng hoặc sở hữu bởi một hệ thống, sản phẩm, dịch vụ, k t quả, hoặc một thành phần đ đ p ứng hợp đồng, tài liệu tiêu chuẩn chính thức,các đặc đi m kỹ thu t, hoặc những vẫn đề khác. Điều quan trọng là những tài liệu yêu cầu cần phải chi ti t đ đảm bảo cho những người thực hiện dự án có th đo và ki m tra mức độ thực hiện yêu cầu trong suốt quá trình thực hiện dự án. Ví dụ khi thực hiện một dự án nâng cấp hệ thống máy tính cho một công ty ta thấy rằng người thực hiện dự án sẽ nh n được những đề nghị từ phía công ty về cấu hình x c định của một chi c m y bàn hay m y tính x ch tay như: loại bộ vi xử lý, kích thước bộ nhớ, kích thước đĩa cứng, loại bo mạch chủ,… Vì v y những tài liệu liên quan đ n dự án này sẽ phải ghi lại những đề nghị từ phía công ty xác l p về vấn đề cấu hình của các thi t bị và những tài liệu này sẽ chính là cơ sở đ cho các bên liên quan đ n dự án sẽ ki m tra lại sản phẩm của dự n có đúng với yêu cầu được ghi trong tài liệu dự án hay không. Trong một số dự án công nghệ thông tin, sẽ hữu ích khi thực hiện chia các yêu cầu phát tri n thành những mục như: khảo sát, phân tích, đặc đi m kỹ thu t, và xác nh n. Những mục này bao gồm tất cả các hoạt động liên quan đ n việc thu th p, đ nh giá các tài liệu yêu cầu cho sản phẩm phần mềm. Việc chia thành các mục như v y cũng quan trọng trong việc sử dụng cách ti p c n lặp đi lặp lại đ x c định các yêu cầu từ giai đoạn đầu của dự án. 1.3. Để thu thập yêu cầu của dự án thì phải làm như thế nào? Có một số phương ph p đ có th thu th p được yêu cầu của dự án. (1) . Đầu tiên có th k đ n phương ph p phỏng vấn một – một Đây được đ nh giá là phương ph p hiệu quả mặc dù nó sẽ tốn kém và mất thời gian. Người được giao nhiệm vụ thu th p các yêu cầu có th thực hiện hẹn gặp và phỏng vấn những người liên quan đ n dự n đ thu th p được những yêu cầu cần thi t. Với phương ph p này sẽ trực quan, yêu cầu có th được trao đổi 2 chiều giữa người nêu yêu cầu và người thu thâp, phân tích yêu cầu. K t quả mang lại của phương ph p này là yêu cầu thu th p được sẽ sát với những vấn đề của c c bên liên quan đặt ra, Nhưng thực sự nó tốn kém và mất thời gian. (2) . Ngoài ra việc t p sử dụng phương ph p trung nhóm, sử dụng những ý tưởng và quy t định của nhóm sẽ giúp cho việc thu th p yêu cầu sẽ diễn ra nhanh hơn và đỡ tốn kém hơn là việc phỏng vấn một - một Người thu th p yêu cầu sẽ thực hiện t p trung những người liên quan đ n dự án, tổ chức họp đ lấy ý ki n trước mọi người, những yêu cầu, những ý ki n đề xuất sẽ được đ nh gi , góp ý, qua đó những yêu cầu sẽ có tính tổng quát hóa cho nhiều đối tượng hơn Trang 7 (3) . Khảo s t và điều tra trên cơ sở những tiêu chuẩn và những mẫu có sẵn cũng là một phương ph p được sử dụng thường xuyên trong trường hợp phải thu th p yêu cầu từ một số lượng đối tượng lớn. Ví dụ cần khảo s t đ thu th p yêu cầu về việc lựa chọn thi t bị thay th cho một công ty có đ n hàng ngàn công nhân thì sẽ không th thực hiện phương ph p (1) hay (2) trong trường hợp này được, bắt buộc phải sử dụng phương ph p khảo sát và điều tra mới có th thu lại được k t quả. Tùy vào quy mô, tính chất phức tạp, tầm quan trọng của dự án mà sẽ phải thu th p nhiều hay ít những yêu cầu cần thi t. Ví dụ, một đội ngũ làm việc trong một dự án nâng cấp toàn bộ hệ thống k toán doanh nghiệp cho một công ty có trị giá hàng tỷ USD được đặt ở hơn 50 vị trí địa lý sẽ cần bỏ ra một số tiền hợp lý cho giai đoạn thu th p yêu cầu đ đảm bảo cho việc tri n khai hệ thống sau này sẽ gặp ít rủi ro nhất. Một dự án nâng cấp phần cứng và phần mềm cho một công ty k toán nhỏ với 5 nhân viên sẽ cần những nỗ lực và chi phí bỏ ra nhỏ hơn .Vì v y người quản lý dự án phải có quy t định đúng đắn trong việc sử dụng phương ph p nào đ có th thu được những yêu cầu cần thi t cho dự án mà không quá tốn kém về chi phí hay thời gian. 1.4. Thực hiện văn bản hóa những yêu cầu như thế nào? Như ở phần trên ta đã thấy đ thu th p được những yêu cầu thì cũng có một số cách khác nhau, đ văn bản hóa chúng thì cũng như v y. Những đối tượng liên quan đ n việc phân tích yêu cầu cần phải nắm được những điều lệ của dự n trước: c c văn bản giấy tờ, c c phương ph p l p hợp đồng mua bán, các vấn đề liên quan đ n thu , tính pháp lý của dự n trước pháp lu t (có vi phạm pháp lu t hay không),… sau đó sẽ thực hiện sắp x p những yêu cầu theo mức độ từ cao đ n thấp cho dự án. Họ cũng nên xem lại danh sách những người liên quan đ n dự n đ đảm bảo rằng tất cả những người liên quan đều có những yêu cầu x c định. Các tài liệu thường được tạo ra bởi phần mềm và bao gồm văn bản, hình ảnh, sơ đồ, video, và c c phương tiện khác. Các yêu cầu cũng thường được chia thành các loại kh c nhau như: yêu cầu chức năng, yêu cầu về dịch vụ, yêu cầu thực hiện, yêu cầu về chất lượng, yêu cầu về đào tạo,…Và đ chuẩn bị tài liệu cho những đối tượng liên quan đ n dự án, những người thu th p và phân tích yêu cầu phải tạo ra "k hoạch quản lý yêu cầu" và "ma tr n nguồn gốc yêu cầu" – RTM (Requirement Traceability Matrix). "K hoạch quản lý yêu cầu" sẽ mô tả những yêu cầu của dự n đã được phân tích, văn bản hóa, và quản lý như th nào. Còn "ma tr n nguồn gốc yêu cầu" là một bảng các danh sách yêu cầu, có những thuộc tính cho mỗi yêu cầu khác nhau và cả trạng thái của yêu cầu đ chắc chắn rằng tất cả các yêu cầu đã được x c định. Mục đích chính của "ma tr n nguồn gốc yêu cầu" là đ duy trì mỗi liên k t từ nguồn của mỗi yêu cầu thông qua việc phân rã nó đ thực hiện và xác minh. Trang 8 Hình 1.2. Một hàng trong bảng "ma trận nguồn gốc yêu cầu" II. Xác định quy mô (Define Scope): 2.1. Khái niệm: X c định quy mô dự án là việc tìm ra và mô tả chi ti t quy mô của dự án, trong đó có cả quy mô của sản phẩm do dự án tạo ra. Việc x c định quy mô tốt rất quan trọng cho thành công của dự n vì nó giúp tăng độ chính xác về thời gian, giá thành và ước tính nguồn lực của dự án. X c định quy mô dự án giúp mô tả ranh giới dự án, dịch vụ, hoặc k t quả bằng việc chuy n hóa những yêu cầu thu th p được thành những việc cần làm, được làm, sẽ được đưa vào dự án hoặc loại trừ khỏi quy mô dự án. Ti n trình x c định quy mô chủ y u liên quan đ n cái gì bao gồm và cái gì không bao gồm trong dự án và các k t quả chính (deliverables) của nó. Những công cụ và kỹ thu t chính được sử dụng trong việc x c định quy mô bao gồm: những đ nh gi của chuyên gia, phân tích sản phẩm, x c định lựa chọn thay th , hội thảo. K t quả đầu ra chính của ti n trình này là bảng kê quy mô dự án và c p nh t cho tài liệu của dự án. Ti n trình này dùng tài liệu yêu cầu đã được l p trong ti n trình thu th p yêu cầu, điều lệ của dự án và những thông tin bổ sung như rủi ro, các mối ràng buộc,… đ x c định quy mô dự án và quy mô của sản phẩm. Những điều lệ, điều khoản sẽ mô tả về quy mô, thời gian, chi phí cho những mục tiêu dự án và tiêu chuẩn hoàn thành, cách ti p c n đ hoàn thành mục tiêu dự án, những vai trò và trách nhiệm chính của những bên liên quan quan trọng của dự án. Trang 9 Hình 2.1. Ví dụ về một điều khoản dự án Lưu ý rằng hoạch định có thuộc tính lặp đi lặp lại (iterative) Khi những yêu cầu được x c định, Project manager sẽ theo ti n trình hoạch định quản trị dự n đ x c định thời gian và ngân s ch N u k t quả cho ra thời gian và ngân s ch không phù hợp với mong muốn của nhà tài trợ hoặc lãnh đạo công ty thì người quản lý dự n cần cân bằng c c yêu cầu (scope) dựa trên c c mối ràng buộc về ngân s ch, thời gian và c c y u tố kh c Ti n trình lặp lại được nêu lên với những tuỳ chọn đ phù hợp với những mục tiêu về quy mô, thời gian, chi phí của dự n và trình bày những tuỳ chọn này đ lãnh đạo quy t định ông việc này có th bao gồm dùng c c kỹ thu t rút ngắn thời gian tri n khai dự n, nh n diện c c giải ph p thay th hoặc điều chỉnh ngân s ch hoặc quy mô. 2.2. Mục đính, vai trò của việc xác đinh quy mô dự án Hai lý do quan trọng của ti n trình x c định quy mô dự n: Trang 10 - Nhiều người quản lý dự n than phiền về những bản ti n độ (Schedule) không thực t , nhưng bạn cần hi u rằng bản ti n độ không thực t là lỗi của chính người quản lý dự n bởi vì họ đã không thực hiện k hoạch theo c ch “lặp đi lặp lại” như đề c p ở trên - Trong khi công việc đang thực hiện, có th xuất hiện xu hướng đi xa baseline, người quản lý dự n sẽ dành phần lớn thời gian tìm ki m những c ch đ làm cho dự n thực hiện theo ti n độ và ngân s ch dự n Do đó, tất cả công cụ được dùng đ tìm ra ti n độ và ngân s ch khả thi Ví dụ đàm ph n quy mô công việc và p dụng kỹ thu t rút ngắn thời gian cũng là những hoạt động chính trong khi công việc đang thực hiện Ti n trình x c định quy mô sẽ ti p tục khi dự n diễn ra và sẽ lặp đi lặp lại Mục đích của nó là luôn luôn x c định quy mô c i gì thuộc dự n và c i gì không thuộc dự án. Như v y, có th m tóm lại mục đích của pha này như sau: - Giúp cải ti n sự chính x c về thời gian, chi phí và tài nguyên - X c định nền tảng đ đo hiệu suất v n hành và điều khi n dự n - Giúp truyền đạt rõ ràng các trách nhiệm của mỗi công việc. 2.3. Phương pháp xác định quy mô dự án 2.3.1. Các bước để xác định quy mô của một dự án: Đ x c định một quy mô dự n , trước tiên bạn phải x c định những điều sau đây: - Mục tiêu dự n - Mục tiêu của từng giai đoạn dự n - Nhiệm vụ - Tài nguyên - Ngân sách - Lịch, hay thời gian thực hiện Điều đầu tiên đ x c định quy mô dự n là phải hi u được mục tiêu dự n: Mục tiêu của một dự n có th đ tạo ra một sản phẩm mới, dịch vụ mới đ cung cấp trong tổ chức, hoặc chỉ là ph t tri n một thêm modul mới của sản phẩm, dịch vụ có sẵn. Một dự n có th có nhiều mục tiêu, mục tiêu nào cũng có th là là trung tâm, đầu tiên cần x c định được mục tiêu chính của một dự n - đó là vai trò của người quản lý dự án. Sau khi bạn đã thi t l p những điều này, bạn cần phải làm rõ những hạn ch , những thông số, tiêu chuẩn mà Nhóm thực hiện dự n và c c bên liên quan không được vượt qua, không được làm Trang 11 Quy mô dự n cần nêu rõ vai trò, nhiệm vụ, tr ch nhiệm của c c bên liên quan, k cả đội ngũ cố vấn, chuyên gia hỗ trợ dự n. 2.3.2. Những công cụ, kỹ thuật để nhà quản trị xác định quy mô dự án - Phân tích sản phẩm (Product Analysis): Như đề c p ở phần đầu, một phần của x c định quy mô là x c định sản phẩm của dự n Mục đích của phân tích sản phẩm là phân tích những mục tiêu và mô tả sản phẩm được định bởi kh ch hàng hoặc nhà tài trợ và diễn tả chúng thành những k t quả cụ th (tangible deliverables) - Những hạn ch : Những hạn ch này thường được th hiện trong hợp đồng đã được ký k t giữa c c bên - K t quả, kinh nghiệm được k thừa từ c c dự n kh c, c c dự n đã làm của nhóm hoặc vài thành viên trong nhóm, điều này rất quan trọng, kinh nghiệm giúp nhà quản trị x c định quy mô chính x c và tr nh nhầm lẫn - Kinh nghiệm, tư vấn của chuyên gia, cố vấn: Một nhóm dự n nên có những chuyên gia sâu về một số lĩnh vực liên quan, nhà quản trị không phải lúc nào cũng có chuyên môn sâu về dự n, nhà quản trị có th chỉ tổ chức thực hiện và tranh thủ chuyên môn của c c nhà tư vấn, chuyên gia 2.4. Sản phẩm, đầu ra của việc xác định quy mô dự án Bảng kê quy mô dự án (Project Scope Statement): K t quả chính hay đầu ra của ti n trình x c định quy mô là bảng kê quy mô dự n (Project scope statement). Tài liệu này là một c ch nói “đây là những gì chúng tôi sẽ làm cho dự n này” hoặc ” đây là quy mô dự n và quy mô sản phẩm đã được phê duyệt cho dự n này” Xây dựng bảng kê quy mô dự n có th mất nhiều thời gian và sự tham gia của c c chuyên gia cũng như nhiều bên liên quan Trong khi x c định yêu cầu và x c định quy mô, bạn nên nh n diện những “khu vực nhạy cảm”, nơi mà mọi người đã yêu cầu quy mô nhưng không được phê duyệt ạn cũng nên làm rõ những “khu vực nhạy cảm” nơi mà Scope dễ gây hi u lầm Nó làm lãng phí thời gian và tiền bạc đ tạo ra những quy mô không cần thi t hoặc không được phê duyệt, nhưng lại dễ xảy ra Một thủ thu t tr nh những vấn đề như th này là x c định những gì không nằm trong quy mô dự n đ làm rõ ràng thêm. ảng kê quy mô dự n cùng với W S và W S dictionary (mô tả sau), tạo thành giới hạn quy mô (Scope baseline) Đây là một phần của k hoạch quản lý dự n. ảng kê quy mô dự n có th bao gồm: - Phạm vị sản phẩm (Product scope) - Quy mô dự n (Project scope) - c k t quả chính (Deliverables) Điều kiện nghiệm thu sản phẩm i gì không thuộc quy mô dự n Trang 12 - c ràng buộc và c c giả thi t Ngoài ra sau giai đoạn này thì việc cập nhật lại các tài liệu của dự án là cần thi t III. Tạo Work Breakdown Strutue (cây phân rã công việc – WBS) : 3.1. Khái niệm: W S là một thành phần cần thi t trong quản trị dự n ông cụ này th hiện tất cả quy mô của dự n, chia nhỏ dự n thành những k t quả chính có th quản lý (manageable deliverable) Không có W S, dự n sẽ kéo dài hơn, c c thành phần sẽ ph t sinh và dự n sẽ bị t c động tiêu cực Không có lựa chọn nào kh c, tất cả c c dự n, th m chí dự n nhỏ cũng cần W S Nhiều người chỉ dùng một danh s ch (list) những điều cần làm như là một phương ph p x c định c c hoạt động cho dự n Đây là một thi u sót, có nhiều lợi ích to lớn từ việc dùng W S Đối với danh s ch bạn có th không chú ý tới một số deliverables i u đồ W S giúp bạn đảm bảo rằng không có điều gì bị bỏ sót Danh s ch có th bề bộn và không cho phép bạn chia dự n lớn thành những phần nhỏ hơn Với W S bạn dễ dàng chia thành từng gói công việc (Work packages) W S th hiện làm th nào Work packages được tạo ra Một danh s ch thường tạo bởi một c nhân W S được tạo bởi nhóm dự n và những Stakeholders Tăng cường sự tham gia của mọi người sẽ tăng hiệu quả Mặt kh c danh s ch có th làm mọi người nghi ngờ dự n bởi vì họ không hi u dự n khi nhìn vào danh s ch hoặc họ không hi u nó được tạo ra như th nào Ti n trình tạo W S cho phép c c thành viên thấu hi u dự n trong đầu họ do đó cải thiện được k hoạch dự n Thực hiện dự n dễ dàng hơn và ít rủi ro hơn Tham gia tạo W S giúp mọi người có nhiều cảm xúc hơn với những k t quả đạt được W S th hiện toàn bộ phân cấp của dự n, dễ dàng thấy một deliverable liên quan th nào với những thứ kh c Dưới đây là một ví dụ về W S: Hình 3.1. Ví dụ về WBS (Work Breakdown Structures) Trang 13 Thông thường tên dự n sẽ đặt ở đầu, mức độ đầu tiên thường như vòng đời dự n, k ti p sẽ chia nhỏ dự n ra những thành phần nhỏ hơn Việc phân rã sẽ ti p tục cho đ n khi Project manager cảm thấy phù hợp cho việc quản trị Mặc dù nhìn W S giống như sơ đồ của một tổ chức nhưng không phải, nó được tạo ra đ phục vụ một mục đích kh c W S cho phép bạn chia nhỏ dự n thành những phần đ bạn hoạch định, tổ chức, quản trị và ki m so t L p một W S là ti p c n từ tổng th đ n chi ti t (Top-Down), phân rã những deliverables và c c yêu cầu công việc đ bi n chúng thành những phần nhỏ hơn gọi là gói công việc (work packages). W S là k t quả có định hướng Điều này không có nghĩa là chỉ những dilerviables của kh ch hàng mới nằm trong W S Quy mô đầy đủ của dự n gồm quy mô sản phẩm, quy mô dự n và những k t quả đạt được trong việc quản trị dự n 3.2. Lợi ích của việc dùng WBS - Phòng ngừa việc thi u quan tâm đ n công việc nào đó (sót việc) ung cấp cho c c thành viên dự n hi u phần công việc của họ trong k hoạch quản trị dự n tổng th và cho họ thấy ảnh hưởng công việc của họ với toàn bộ dự n - Thu n lợi cho việc truyền thông và hợp t c giữa c c thành viên nhóm dự n và với c c bên liên quan. - Giúp giảm sự thay đổi - T p trung vào những trải nghiệm của nhóm, k t quả là chất lượng tốt hơn và dự n dễ quản trị hơn - ung cấp cơ sở đ ước lượng nhân lực, chi phí, thời gian - ung cấp bản nh p về nhu cầu nhân lực, chi phí, thời gian - c thành viên tham gia, góp phần xây dựng làm việc nhóm Giúp mọi người suy nghĩ về dự n W S là nền tảng cơ bản của dự n, nghĩa là mọi thứ xảy ra trong Planning process group sau khi W S được tạo sẽ liên quan trực ti p đ n W S Ví dụ chi phí và thời gian của dự n được ước lượng dựa trên Work package hoặc Activity Những rủi ro được nh n diện bởi Work packge Work package được phân công tới những c nhân hoặc c c bộ ph n thực hiện tuỳ theo kích cỡ dự n 3.3. Một số luật để tạo WBS. W S tạo bởi hai người cho một dự n giống nhau có th kh c nhau Điều đó là bình thường, miễn là tuân thủ một số lu t sau: - W S được tạo với sự tham gia của c c thành viên - Mức đầu tiên được hoàn tất khi khi chia xuống c c mức dưới Trang 14 - Mỗi mức được chia nhỏ hơn mức trên nó - Toàn bộ dự n được bao gồm ở mức cao nhất của W S Một số nh nh sẽ được chia nhỏ hơn c c nh nh kh c - W S chỉ bao gồm c c Deliverables được yêu cầu trong dự n - Những Deliverables không nằm trong W S không phải là một phần của dự án. c thành viên chia nhỏ W S cho đ n khi đạt tới Work packages Điều này xảy ra khi deliverables là: - ó th ước lượng - ó th hoàn thành nhanh - ó th hoàn thành mà không cần thêm thông tin - ó th thuê nhà ngoài 3.4. Cách xây dựng WBS: 3.4.1. Các tiếp cận phát triển WBS: - Dùng tài liệu hướng dẫn: một số tổ chức như DoD (Department of Defense) có tài liệu hướng dẫn đ chuẩn bị WBS. Những tài liệu này sẽ cung cấp những hướng dẫn cho việc phát tri n và tạo những WBS. Nó còn bao gồm cả những ví dụ mẫu về WBS cho nhiều dự án trong các ngành công nghiệp, truyền thông, dịch vụ và thực thi phần mềm Người quản lý dự n và đội ngũ của họ nên xem những thông tin cần thi t đ phát tri n WBS cho dự án của họ một các thích hợp. - Ti p c n tương tự: xem lại các WBS của dự n tương tự và sửa đổi cho phù hợp với dự n hiện hành. Một số công ty giữ WBS và những tài liệu dự n kh c đ hỗ trợ cho người làm việc với dự án. Một số công cụ phần mềm như Project 2007 có những ví dụ tương tự đ hỗ trợ những người dùng trong việc tạo một WBS. Xem ví dụ của một dự n tương tự sẽ giúp bạn hi u những c ch kh c nhau đ tạo ra WBS. - Tri p c n từ trên xuống: bắt đầu với thành phần lớn nhất của dự n, sau đó chia nhỏ dần - Ti p c n từ dưới lên: bắt đầu từ c c công việc chi ti t và k t hợp dần thành công việc lớn hơn - Ti p c n Mind-mapping: ghi ra c c công việc dưới dạng phi tuy n và sau đó tạo WBS. Thay cho việc phải vi t những công việc thành một danh sách, mà cách ti p c n này cho phép vi t th m chí là vẽ những ý tưởng dưới dạng phi tuy n Dưới đây là một ví dụ về việc sử dụng cách ti p c n Mind-mapping đ tạo WBS cho một dự án nâng cấp IT. Trang 15 Hình 3.2 Xây dựng WBS bằng phương pháp Mind-mapping Vòng tròn trung tâm đại diện cho dự án. Mỗi vòng nhánh xung quanh trong 4 vòng là một yêu cầu công việc hay một phần tử ở cấp 2. 3.4.2. Các nguyên lý cơ bản tạo WBS: W S tạo bởi hai người cho một dự n giống nhau có th kh c nhau Điều đó là bình thường, miễn là tuân thủ một số nguyên tắc sau: - W S chỉ bao gồm c c Deliverables được yêu cầu trong dự n Những Deliverables không nằm trong W S không phải là một phần của dự n - Một đơn vị công việc chỉ xuất hiện một nơi trong W S - Nội dung công việc trong một mục WBS bằng tổng c c công việc dưới nó. - Một mục W S là nhiệm vụ của chỉ một người, ngay cả khi có nhiều người thực hiện công việc này - WBS phải nhất qu n với cách thực hiện công việc, trước h t nó phải phục vụ nhóm dự án và các mục đích kh c n u thực t cho phép - Các thành viên nhóm dự án phải tham gia ph t tri n W S đ bảm bảo tính nhất qu n c thành viên chia nhỏ W S cho đ n khi đạt tới Work packages Điều này xảy ra khi deliverables là: + ó th ước lượng + ó th hoàn thành nhanh + ó th hoàn thành mà không cần thêm thông tin - Mỗi mục WBS phải có tài liệu đi k m đ đảm bảo hi u được chính x c quy mô công việc - WBS phải là công cụ linh họat đ đ p ứng những thay đổi không th tr nh được, điều khi n nội dung công việc theo đúng tuyên bố về quy mô 3.4.3. Một số dạng WBS WBS có th được xây dựng ở 2 dạng - Dạng Lish, danh sách. VD: Xây dựng Website Trang 16 Hình 3.3. WBS ở dạng danh sách - Dạng đồ họa. VD: Hình 3.4. WBS ở dạng đồ họa Dù WBS có xây dựng ở dạng nào cũng phải th hiện đầy đủ các công việc: - Công việc của quản trị dự án: chi phí và tài nguyên cần thi t cho viêc quản trị dự n như: lương cho trưởng dự n, văn phòng làm việc, máy tính,.. - Vi t tài liệu:hồ sơ ph t tri n sản phẩm, các kinh nghiệm quản trị dự án này, ài đặt sản phẩm: huấn luyện người dùng, lên k hoạch truyền thông, k hoạch Maketing,... - Đóng dự án: gồm thời gian, chi phí và tài nguyên cần đ đóng cửa văn phòng dự án, tái phân công nhân sự và đóng c c tài khoản ngân hàng. Trang 17 - Thu hồi sản phẩm: gồm k hoạch thu hồi sản phẩm sau khi đã h t vòng đời sử dụng Có th phân rã theo bất kỳ phạm trù nào miễn là có ý nghĩa cho dự án. Phạm trù đó có th là các thành phần của sản phẩm, các chức năng, c c đơn vị của tổ chức, lãnh thổ địa lý, các chi phí, lịch bi u, hoặc các công việc W S thường được phân rã theo công việc. Các ví dụ trên minh họa cho phân rã theo công việc Các thành phần được phân rã ở mức cuối cùng – mức lá hay còn gọi là gói công việc, phải thỏa các tiêu chí sau: 1. Tình trạng/tính hoàn tất của công việc có th đo được. 2. Thời gian, tài nguyên và chi phí dễ ước lượng. 3. Lu t 80 giờ: công việc nên thực hiện trong khoảng 80 giờ 4. Thời gian hoàn thành công việc trong giới hạn cho phép. 5. Công việc được phân công độc l p Nghĩa là một khi công việc đó được thực hiện thì nó sẽ được thực hiện cho đ n h t mà không bị dừng giữa chừng đ chờ k t quả của công việc khác Trong lúc phân rã, n u có một tiêu chí không thỏa thì phải phân rã ti p. Tránh đưa ra một W S không đủ chi ti t. N u công việc được x c định ở mức độ thô (còn mơ hồ) thì việc ước lượng nhân sự, thời gian thực hiện, ngân sách cho công việc sẽ trở nên khó khăn Những thông tin được ước lượng đó không đ ng tin c y, nó là nguyên nhân khi n k hoạch không khớp với thực t . WBS càng chi ti t, việc lên k hoạch càng chính x c hơn và khả năng theo dõi quá trình thực hiện tốt hơn Một phương ph p phổ bi n được sử dụng là phương ph p 80 giờ: mỗi công việc thuộc tầng thấp nhất trong WBS phải không được vượt quá 80 giờ lao động. N u như công việc cần nhiều giờ hơn, trưởng dựán phải chia nhỏ công việc đó thành những công việc nhỏ hơn Do đó W S được liên tục cải ti n khi trưởng dự n ước lượng thời gian thực hiện của công việc. Những mức của W S thường được đ nh số đ sau này dễ định vị Khi W S hoàn thành, những số nh n diện được g n đ phân biệt vị trí của Work packages trong WBS. Khi ti n trình hoạch định đang xảy ra c thành viên chia nhỏ Work package thành c c hoạt động (activity) cần thi t đ thực hiện Work packages Nhớ rằng chia nhỏ hơn nữa W S tới mức activity được thực hiện như một phần của ti n trình quản trị thời gian (Time management) Thành viên nhóm dự n dùng Project scope statement, W S, W S dictionary đ x c định những activities nào cần thi t đ thực hiện deliverables N u công ty bạn làm việc với nhiều dự n tương tự nhau, bạn cần nh n thức rằng W S cho một dự n có th dùng cho dự n kh c như là một mẫu tham khảo PMO có th thu th p c c W S này đ t i sử dụng cho nhiều dự n 3.5. Vai trò của WBS trong việc thay đổi quy mô dự án Trang 18 Một khi hoàn tất W S bạn có th dùng bất kỳ lúc nào mà quy mô dự n cần đ nh gi lại ví dụ bạn có th dùng W S: - Khi có yêu cầu thay đổi quy mô dự n ạn dùng W S cùng với Project scope statement giúp bạn thấy quy mô mới có nằm trong quy mô đã hoạch định - Là một phần của ki m so t thay đổi tích hợp đ đ nh gi bất kỳ t c động của những thay đổi kh c về quy mô. - Là một c ch đ phòng ngừa việc mất ki m so t quy mô, nhắc nhở mọi người những công việc gì phải làm - Là một công cụ đ truyền thông, giúp những thành viên mới nh n ra vai trò của họ 3.6. WBS Dictionary: W S Dictionary là một tài liệu mô tả một c ch chi ti t thông tin về mỗi phần tử trong WBS. W S dictionary là một k t quả đầu ra của ti n trình tạo W S Tài liệu này được dùng như là một phần của hệ thống uỷ quyền công việc, nó thông b o cho c c thành viên dự n bi t khi nào công việc của họ bắt đầu W S dictionary cũng mô tả cả đi m mốc chính, c c điều kiện nghiệm thu và những thông tin kh c về Work package Một số dự n có th yêu cầu mô tả về những phần tử W S còn bao gồm cả tr ch nhiệm của tổ chức, nguồn lực cần thi t, chi phí ước tính, và một số thông tin kh c ạn cũng có th dùng nó đ ki m so t công việc gì, khi nào thì hoàn tất, phòng ngừa việc mất ki m so t quy mô công việc (Scope creep) và tăng mức thấu hi u của những bên liên quan về yêu cầu của mỗi Work package W S dictionary đặt giới hạn c i gì bao gồm trong một Work package Trang 19