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
- Xem thêm -