Tải bản đầy đủ (.pdf) (84 trang)

Giáo trình môn Quản lý dự án Công nghệ thông tin

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (825.72 KB, 84 trang )

<span class='text_page_counter'>(1)</span><div class='page_container' data-page=1>

<b>TRƯỜNG CAO ĐẲNG KINH TẾ KỸ THUẬT </b>
<b>THÀNH PHỐ HỒ CHÍ MINH </b>


<b> </b>


<b> </b>
<b> </b>
<b> </b>


<b>GIÁO TRÌNH </b>



<b>MƠ ĐUN: QUẢN LÝ DỰ ÁN </b>



<b>CÔNG NGHỆ THÔNG TIN </b>


<b>NGHỀ: ỨNG DỤNG PHẦN MỀM </b>



<b>TRÌNH ĐỘ: CAO ĐẲNG </b>


<b> </b>









</div>
<span class='text_page_counter'>(2)</span><div class='page_container' data-page=2>

<b>TRƯỜNG CAO ĐẲNG KINH TẾ KỸ THUẬT </b>
<b>THÀNH PHỐ HỒ CHÍ MINH </b>



<b> </b>
<b> </b>


<b> </b>


<b>GIÁO TRÌNH </b>



<b>MƠ ĐUN: QUẢN LÝ DỰ ÁN </b>



<b>CÔNG NGHỆ THÔNG TIN </b>


<b>NGHỀ: ỨNG DỤNG PHẦN MỀM </b>



<b>TRÌNH ĐỘ: CAO ĐẲNG</b>


<b> </b>




<b> THÔNG TIN CHỦ NHIỆM ĐỀ TÀI </b>
Họ tên: Nguyễn Minh Thiện


Học vị: Thạc sĩ


Đơn vị: Khoa Công nghệ thông tin
Email:




<b>TRƯỞNG KHOA </b> <b>TỔ TRƯỞNG </b>


<b>BỘ MÔN </b> <b>CHỦ NHIỆM ĐỀ TÀI </b>


<b>HIỆU TRƯỞNG </b>


<b>DUYỆT </b>


</div>
<span class='text_page_counter'>(3)</span><div class='page_container' data-page=3>

Tài liệu này thuộc loại sách giáo trình nên các nguồn thơng tin có thể được phép
dùng nguyên bản hoặc trích dùng cho các mục đích về đào tạo và tham khảo.


</div>
<span class='text_page_counter'>(4)</span><div class='page_container' data-page=4>

Trên thế giới, có rất nhiều dự án có chất lượng khơng như kỳ vọng của khách hàng
hoặc không cung cấp các phần mềm trong phạm vi ngân sách và thời gian hồn thành. Một
phân tích cho thấy khoảng một phần ba các dự án có chi phí và thời gian hồn thành vượt
hơn 125%.


Tại sao quá nhiều dự án phần mềm thất bại? Mặc dù có rất nhiều lý do, một trong
những lý do quan trọng nhất là quản lý dự án khơng phù hợp. Ví dụ, các lý do chính làm
cho dự án chệch ra khỏi tầm kiểm soát là mục tiêu không rõ ràng, lập kế hoạch tồi, công
nghệ mới, thiếu một phương pháp quản lý dự án, và khơng đủ nhân sự.


Ít nhất ba trong năm lý do này rõ ràng liên quan đến quản lý dự án.


Hai lý do còn lại - không đủ nhân sự và công nghệ mới - có thể được coi như những
rủi ro mà để quản lý chúng cũng là một phần của quản lý dự án.


Rõ ràng, bằng cách sử dụng các kỹ thuật quản lý dự án có hiệu quả, một người quản
lý dự án có thể cải thiện các cơ hội để thành cơng.


Quản lý dự án nói chung hay quản lý dự án công nghệ thông tin nói riêng, là một
trong những lĩnh vực kiến thức mang tính kinh nghiệm, có ý nghĩa quan trọng trong các
nhiệm vụ hàng ngày của bất kỳ một nhà quản lý hay một cá nhân có tham vọng trở thành
nhà quản lý.


Để hiểu rõ và làm chủ được những kiến thức, nội dung xung quanh nhiệm vụ, hoạt
đông quản lý dự án, trước tiên ta cần phải trang bị những kiến thức cơ bản nhằm khai thông


khái niệm, thuật ngữ về quản lý dự án công nghệ thông tin.




Tp.HCM, ngày10 tháng 07 năm 2020
Tham gia biên soạn


</div>
<span class='text_page_counter'>(5)</span><div class='page_container' data-page=5>

<b>TRANG </b>


Lời giới thiệu ... 1


Mục lục ... 2


Chương trình mơ đun ... 5


Chương 1: Khởi động dự án ... 6


1.1. Tại sao phải quản lý dự án ... 6


1.2. Phương pháp luận quản lý dự án truyền thống và quản lý dự án thực hành ... 6


1.3. Quyền lãnh đạo dự án ... 8


1.4. Định nghĩa dự án ... 9


1.4.1. Xác định mục đích và mục tiêu dự án ... 9


1.4.2. Phát biểu về công việc ... 10


1.4.3. Công bố dự án ... 10



1.4.4. Khai trương dự án ... 10


1.4.5. Vai trò và trách nhiệm ... 11


Bài tập ... 13


Chương 2: Lập kế hoạch ... 14


2.1. Quản lý phạm vi ... 14


2.1.1. Bản kế hoạch phạm vi dự án ... 14


2.1.2. Bản kế hoạch chi tiết phạm vi dự án ... 17


2.1.3. WBS (Work Breakdown Structure) ... 21


2.1.4. Các nguyên lý cơ bản tạo WBS ... 22


2.2. Quản lý thời gian ... 29


2.2.1. Tầm quan trọng của lập lịch ... 29


2.2.2. Quản lý thời gian ... 30


2.2.3. Quy trình quản lý thời gian ... 30


2.2.3.1. Xác định các hoạt động ... 30


2.2.3.2. Sắp thứ tự các hoạt động ... 31



2.2.3.3. Ước lượng thời gian cho mỗi hoạt động ... 31


2.2.3.4. Phát triển lịch biểu ... 32


2.2.3.5. Điều khiển lịch biểu ... 32


2.3. Quản lý chi phí ... 33


2.3.1. Chi phí ... 33


</div>
<span class='text_page_counter'>(6)</span><div class='page_container' data-page=6>

2.3.3.2. Ước lượng chi phí ... 35


2.3.3.3. Dự thảo chi phí ... 38


2.3.3.4. Kiểm sốt, điều chỉnh chi phí ... 38


2.4. Quản lý chất lượng ... 40


2.4.1. Chất lượng ... 40


2.4.2. Quy trình quản lý chất lượng ... 41


2.4.2.1. Lập kế hoạch chất lượng ... 41


2.4.2.2. Đảm bảo chất lượng ... 42


2.4.2.3. Kiểm tra chất lượng ... 43


2.5. Quản lý nguồn nhân lực ... 47



2.5.1. Tầm quan trọng của quản lý nguồn nhân lực ... 47


2.5.2. Cơ cấu tổ chức nhân sự cho dự án ... 48


2.5.3. Vai trò của từng thành viên ... 49


2.5.4. Tuyển đội ngũ nhân sự ... 51


2.6. Quản lý rủi ro ... 52


2.6.1. Khái niệm quản lý rủi ro ... 52


2.6.2. Quy trình quản lý rủi ro ... 52


2.6.2.1. Nhận biết rủi ro ... 53


2.6.2.2. Phân tích rủi ro theo định tính ... 55


2.6.2.3. Phân tích định lượng rủi ro ... 56


2.6.2.4. Kế hoạch đối phó rủi ro ... 56


2.6.2.5. Giám sát và kiểm soát rủi ro ... 57


2.6.3. Kỹ thuật để quản lý rủi ro ... 58


2.6.4. Phần mềm quản lý rủi ro ... 60


Bài tập ... 61



Chương 3: Thực hiện và kết thúc dự án ... 62


3.1. Điều khiển và kiểm soát dự án ... 62


3.1.1. Giám sát dự án ... 64


3.1.1.1. Giám sát từ ban chỉ đạo dự án ... 64


3.1.1.2. Giám sát từ các cấp quản lý cao hơn ... 65


3.1.1.3. Giám sát từ phía khách hàng ... 66


3.1.2. Phát hiện và giải quyết các vấn đề ... 66


3.1.2.1. Vấn đề lịch biểu ... 66


</div>
<span class='text_page_counter'>(7)</span><div class='page_container' data-page=7>

3.1.3.1. Thông qua họp định kỳ và báo cáo ... 68


3.1.3.2. Thông qua họp kỹ thuật ... 70


3.1.3.3. Thông qua họp quản lý ... 71


3.1.3.4. Thông qua họp đặc biệt ... 71


3.2. Kết thúc dự án ... 74


3.2.1. Đánh giá tài chính ... 74


3.2.1.1. Xác định chi phí ... 74



3.2.1.2. So sách các phương án ... 75


3.2.1.3. Điểm hòa vốn ... 75


3.2.2. Đánh giá hiệu quả dự án ... 76


3.2.2.1. Thu hồi vốn đơn giản ... 76


3.2.2.2. Thu hồi vốn có chiết khấu ... 77


3.2.2.3. Đánh giá các chỉ tiêu chất lượng ... 77


Bài tập ... 78


Mục lục hình ảnh ... 79


Mục lục bảng ... 80


</div>
<span class='text_page_counter'>(8)</span><div class='page_container' data-page=8>

<b>Tên mô đun: Quản lý Dự án Công nghệ thông tin </b>
<b>Mã mô đun: </b>MĐ3101325


<b>Thời gian thực hiện mô đun: 60 giờ; (Lý thuyết 30 giờ; Thực hành, thảo luận, bài tập: 28 </b>
giờ; Kiểm tra 02 giờ)


<b>Đơn vị quản lý mơ đun: Khoa Cơng nghệ thơng tin </b>
<b>I. Vị trí, tính chất của mơ đun: </b>


- Vị trí: là mơn học chuyên ngành, học kỳ 4.
- Tính chất: là mơn học tích hợp, mơn tự chọn.


<b>II. Mục tiêu mơ đun: </b>


- Về kiến thức:


+ Trình bày được các nội dung cơ bản của việc quản lý một dự án Cơng nghệ Thơng
tin có quy mơ nhỏ và trung bình.


- Về kỹ năng:


+ Lập được hồ sơ quản lý một dự án Công nghệ Thông tin có quy mơ nhỏ và trung bình.
+ Quản lý được một dự án Cơng nghệ Thơng tin có quy mô nhỏ với yêu cầu quản lý
đơn giản.


- Về năng lực tự chủ và trách nhiệm:


</div>
<span class='text_page_counter'>(9)</span><div class='page_container' data-page=9>

<b>CHƯƠNG 1: KHỞI ĐỘNG DỰ ÁN </b>


<b>Giới thiệu: </b>


Nội dung bài này trình bày những vấn đề cơ bản về dự án, phân loại dự án theo cáo
tiêu chí thơng dụng, ý nghĩa thực tiễn của việc quản lý dự án và quy trình cơ bản về quản
lý dự án.


<b>Mục tiêu: </b>


Giới thiệu quản lý dự án.
<b>Nội dung chính: </b>


<b>1.1. Tại sao phải quản lý dự án </b>



Quản lý dự án là một trong những lĩnh vực kiến thức mang tính kinh nghiệm, có ý
nghĩa quan trọng trong các nhiệm vụ hàng ngày của bất kỳ một nhà quản lý hay một cá
nhân có tham vọng trở thành nhà quản lý.


Theo quan điểm chung dự án là một lĩnh vực hoạt động đặc thù, một nhiệm vụ cần
phải thực hiện theo một phương pháp riêng, trong khuôn khổ nguồn lực riêng, kế hoạch
tiến độ cụ thể nhằm tạo ra một sản phẩm mới. Từ đó cho thấy, dự án có tính cụ thể, mục
tiêu rõ ràng xác định để tạo ra một sản phẩm mới.


Tóm lại có thể nói ta phải quản lý dự án vì cần phải quản lý một chuỗi các công việc
(nhiệm vụ, hoạt động), được thực hiện nhằm đạt được mục tiêu đề ra trong điều kiện ràng
buộc về phạm vi, thời gian và ngân sách.


Hiểu theo cách khác, quản lý dự án là ứng dụng kiến thức, kỹ năng, công cụ và kỹ
thuật vào các hoạt động dự án để thỏa mãn các yêu cầu của dự án.


Xét theo khía cạnh khác, quản lý dự án là một quá trình lập kế hoạch, điều phối thời
gian, nguồn lực và giám sát quá trình phát triển của dự án nhằm đảm bảo cho dự án hoàn
thành đúng thời hạn, trong phạm vi ngân sách được duyệt và đạt được các yêu cầu đã định
về kỹ thuật, chất lượng của sản phẩm, dịch vụ, bằng các phương pháp và điều kiện tốt nhất
cho phép.


</div>
<span class='text_page_counter'>(10)</span><div class='page_container' data-page=10>

quay lui về giai đoạn trước hay nhảy vượt giai đoạn (rõ ràng thì trong một thác nước nước
không thể chảy ngược).


Phương pháp truyền thống chọn cách tiếp cận một kế hoạch theo định hướng và tập
trung vào hoạt động để quản lý dự án. Điều này dẫn đến một loạt các quá trình có đầu vào
và đầu ra khác nhau. Người quản lý phải đảm bảo rằng việc bàn giao dự án trung gian đều
phải được lập kế hoạch và thực hiện ở các giai đoạn khác nhau của dự án.



Đó là một trong nhiều lý do khiến nhiều công ty ào ạt chuyển sang áp dụng phương
pháp Agile – bởi với Agile, họ không thể chống lại được sự quyến rũ của kết quả công việc
nhanh hơn, chi phí thấp hơn, và sẽ khơng có biểu đồ Gantt nữa!


Trong suốt vòng đời của một dự án, Agile nhấn mạnh việc tạo ra những kết quả hữu
hình càng sớm, càng thường xuyên thì càng hiệu quả và chú trọng việc quản lý mối quan
hệ, tạo điều kiện tương tác giữa các thành viên trong nhóm quản lý dự án. Điều này có
nghĩa là vai trò của một người quản lý dự án Agile hồn tồn khơng giống với một người
quản lý dự án TPM.


- Kế hoạch hóa so với tập trung vào giá trị.


Agile/Scrum đưa ra cách tiếp cận hướng tới giá trị trong khi TPM lại hướng tới mục
tiêu để lên kế hoạch cho toàn bộ dự án. Điều này khơng có nghĩa là một dự án Agile/Scrum
thì khơng có kế hoạch. Với Scrum, mỗi phân đoạn đều có một kế hoạch, nhưng các kế
hoạch tập trung vào việc ưu tiên các tính năng mang lại giá trị nhất. Điều này hoàn toàn
khác với TPM, nơi một kế hoạch hoàn chỉnh được tạo ra trước khi đi vào chi tiết hoạt động
và nhiệm vụ cần thiết cho dự án.


- Tiên đoán so với Thực nghiệm


</div>
<span class='text_page_counter'>(11)</span><div class='page_container' data-page=11>

- Cấp trên quản lý so với nhóm tự quản


Một trong những vai trò căn bản của một người quản lý dự án truyền thống là phải
tích cực tổ chức và sắp xếp sao cho hợp lý đội ngũ của mình, phân cơng các vai trị và trách
nhiệm cho mỗi thành viên trong dự án. Còn một Scrum Master sẽ lùi lại và cho phép nhóm
tự tổ chức. Người quản lý dự án phải tạo điều kiện, cung cấp mơi trường để nhóm tự giao
tiếp và thực hiện công việc.


- Quản lý các bên liên quan so với sự gắn bó



Trong TPM, việc quản lý các bên liên quan là một phần quan trọng trong công việc
của người quản lý. Thông thường, điều này được thực hiện thông qua các báo cáo tình hình
cơng viêc, biểu đồ tiến độ, và báo cáo của người quản lý ở những cuộc họp cập nhật tình
hình dự án.Với Scrum thì khách hàng- những chủ sản phẩm được coi là một phần của đội
ngũ dự án. Bởi vì các bên liên quan là một phần của nhóm phát triển và là một bên đưa ra
tất cả quyết định về việc sử dụng điều kiện phức tạp và báo cáo tiến độ là không cần thiết.


- Lập kế hoạch từ dưới lên so với trên xuống


Quản lý dự án truyền thống theo hướng lập kế hoạch từ dưới lên, có nghĩa là một
dự án được lên kế hoạch ngay từ đầu bằng cách lên chi tiết các công việc của mỗi cá nhân
trong Cơ cấu phân chia cơng việc (Work Breakdown Structure – WBS), từ đó dẫn đến một
kế hoạch dự án hoàn chỉnh trước khi bắt đầu dự án. Scrum thì ngược lại, nó theo hướng lập
kế hoạch từ trên xuống, nghĩa là một lộ trình được phát triển trong giai đoạn đầu của dự án
được xây dựng dần dần thành các phân đoạn release (bản phát hành) và sprint (phân đoạn).


<b>1.3. Quyền lãnh đạo dự án </b>


</div>
<span class='text_page_counter'>(12)</span><div class='page_container' data-page=12>

Ban quản lý, điều hành dự án: quản lý các nhóm dự án, điều hành, động viên...Chịu
trách nhiệm đối với việc phối hợp, quan hệ bên ngoài, với lãnh đạo cấp trên và tích hợp
chung. Mục đích chính là làm sao cho dự án thành công (Kế hoạch, theo dõi, dán tiếp).


Nhóm trưởng kỹ thuật: chỉ giám sát các cán bộ kỹ thuật, cán bộ lập trình....về các
chi tiết kỹ thuật. Có trách nhiệm (nhưng khơng nhất thiết phải trực tiếp làm) về các hoạt
động kỹ thuật có liên quan như phân tích, thiết kế và các cơng việc lập trình chính. Mục
đích chính là đảm bảo chất lượng của sản phẩm.


Cán bộ kỹ thuật: chịu trách nhiệm trực tiếp về các phần việc kỹ thuật cụ thể.



<b>1.4. Định nghĩa dự án </b>


Dự án là một chuỗi các công việc (nhiệm vụ, hoạt động), được thực hiện nhằm đạt
được mục tiêu đề ra trong điều kiện ràng buộc về phạm vi, thời gian và ngân sách.


Nội dung cơ bản của các dự án CNTT đều xoay quanh các vấn đề về phần cứng, phần mềm,
sự tích hợp giữa phần cứng/ phần mềm và con người. Cụ thể hơn, đó là những cơng việc
liên quan đến chọn mua hoặc/và phân tích, thiết kế, xây dựng và tích hợp hệ thống máy
móc, tổ chức thơng tin, xây dựng các ứng dụng, đảm bảo trao đổi giữ các hệ thống ... cũng
như đào tạo người sử dụng vận hành.


Cần xác định rõ rằng bản thân các dự án CNTT chỉ tạo ra các công cụ và dịch vụ kỹ
thuật mới để hỗ trợ hiệu quả hơn cho hoạt động của các nhà lãnh đạo, các nhà quản lý và
đông đảo người dùng trong xã hội, chứ không thể thay thế và bao quát hết mọi vấn đề về
nghiệp vụ ở mọi nơi, mọi chỗ. Do vậy, để đưa CNTT vào ứng dụng thực sự trong các hoạt
động của nhà nước, đòi hỏi các cơ quan phải có các hoạt động khác, được thực hiện đồng
bộ, để hoàn thiện cơ cấu tổ chức, hợp lý hố các hệ thống thơng tin dữ liệu, lựa chọn và
động viên nguồn vốn, hợp lý hố các hệ thống thơng tin dữ liệu, lựa chọn và động viên
nguồn vốn để phát triển các hoạt động nghiệp vụ của mình.


Quản lý dự án là ứng dụng kiến thức, kỹ năng, công cụ và kỹ thuật vào các hoạt
động dự án để thỏa mãn các yêu cầu của dự án.


<b>1.4.1. Xác định mục đích và mục tiêu dự án </b>


Nói một các tổng qt hơn thì Mục đích được định nghĩa là cái đích cuối cùng cần
đạt được (dù có thể thay đổi), và Mục tiêu là con đường được chọn, cùng với những chặng
phải đi qua để đạt tới Mục đích.


</div>
<span class='text_page_counter'>(13)</span><div class='page_container' data-page=13>

<b>1.4.2. Phát biểu về cơng việc </b>



Thiết lập bảng mô tả cơ bản về từng công việc sẽ được tiến hành trong dự án.


<b>1.4.3. Công bố dự án </b>


Lên ý tưởng, xây dựng chủ đề


- Đối với những người muốn làm sự kiện thì 3 yếu tố: Ý tưởng – Chủ đề – Đối tượng
là những yếu tố then chốt có liên quan mật thiết với nhau.


- Từ những thông tin mà khách hàng/cấp trên cung cấp như: mục đích của buổi tổ
chức, số lượng khách mời, đối tượng tham gia … ta phải lên được những ý tưởng,
thiết kế lên một chương trình của buổi khai trương phù hợp, đáp ứng được những
yêu cầu mà cấp trên/khách hàng đưa ra, và thu hút sự quan tâm của những người
tham dự.


Lên kế hoạch


- Công việc đầu tiên mà cần phải khi tổ chức event đó chính là nên một bản kế hoạch
thật chi tiết, cụ thể nhất.


- Từ việc kinh phí đầu tư mà doanh nghiệp bỏ ra, ta có thể căn cứ vào đó mà thiết lập
nên những hạng mục, những kế hoạch chi tiêu sao cho phù hợp, chính xác nhất khi
tổ chức lễ khai trương. Khi mà ta xây dựng xong một bản kế hoạch thì cơng việc
thực hiện trở nên tiện lợi, nhanh chóng và đơn giản hơn rất nhiều.


<b>1.4.4. Khai trương dự án </b>


Lên nội dung cho buổi lễ khai trương



- Chắc chắn làm kinh doanh ai cũng sẽ coi trọng hình ảnh của doanh nghiệp, họ ln
cố gắng gây dựng lên những hình ảnh đẹp nhất trong mắt khách hàng. Và đây chính
là cơ hội tốt cho họ, sự phát triển của doanh nghiệp sẽ được phụ thuộc rất nhiều vào
buổi event khai trương này. Chính vì thế ta cần phải lên một nội dung độc đáo, đặc
sắc,và ấn tượng nhất.


- Ví dụ như ta có thể đan xen các tiết mục văn nghệ, trình diễn thời trang, hoặc những
trị chơi có câu hỏi liên quan đến doanh nghiệp giúp cho khách hàng ghi nhớ tới
buổi tổ chức lễ khai trương, khánh thành, tới doanh nghiệp lâu hơn.


Các công việc cần chuẩn bị cho buổi khai trương


</div>
<span class='text_page_counter'>(14)</span><div class='page_container' data-page=14>

- Thiết kế sơ đồ tổng thể khu vực tổ chức , các hạng mục trang trí
- Lên danh sách số lượng khách mời


- Khảo sát địa điểm tổ chức buổi lễ
- Tiến hành lễ khai trương


Setup trang trí


- Trang trí khu vực bên ngồi: treo banner, cờ..
- Khu vực cổng chào


- Khu vực tổ chức: thường được lắp đặt nhà bạt, sân khấu, trải thảm..
- Khu vực tiệc


- Dọn dẹp vệ sinh


Nội dung buổi lễ



- Tiếp tân phải là những người chuyên nghiệp xử lý mọi tình huống nhanh nhẹn, đặc
biệt ngoại hình phải ưa nhìn mặc đồng phục đón khách và cài hoa đại biểu lên áo
cho khách mời


- Tổ chức múa lân rồng để mở đầu buổi lễ
- Các tiết mục văn nghệ phải hấp dẫn, độc đáo
- Thơng báo mục đích, ý nghĩa của buổi lễ


- Giới thiệu các đại biểu tham gia và lời phát biểu của chủ doanh nghiệp
- Tiến hành các nghi thức khai trương khánh thành: cắt băng khánh thành
- Tiếp tân tiễn khách ra về, tặng quà (nếu có)


Kết thúc việc tổ chức lễ khai trương


- Dọn dẹp các thiết bị cũng như vệ sinh khu tổ chức để trả mặt bằng cho doanh nghiệp,
địa phương.


<b>1.4.5. Vai trò và trách nhiệm </b>


</div>
<span class='text_page_counter'>(15)</span><div class='page_container' data-page=15>

Đặc biệt đối với các dự án ứng dụng CNTT, vai trò của những cán bộ nghiệp vụ
trong việc xác định yêu cầu, phân tích quy trình, thơng tin... tại chính đơn vị của mình là
rất quan trọng.


Ta thấy, nhìn chung có thể phân các đối tượng trên ra làm ba mức chính. Đó là
- Những nơi quản lý dự án (gián tiếp) ở mức cao:


Đó là BCĐ CNTT (của quốc gia và/hoặc bộ ngành, địa phương), Bộ (Sở) Tài chính,
Bộ (Sở) Kế hoạch và Đầu tư. Thực chất đó là những nơi quản lý dự án, nhưng ở mức cao
hơn, có thính chất tổng hợp hơn, vì dự án cụ thể chỉ là một trong những dự án nằm trong
một chương trình chung nào đó. Để phân biệt, đơi khi có thể gọi đó là những nơi quản lý


chương trình.


- Những người trực tiếp có trách nhiệm đối với dự án:


Đó là những đối tượng được mơ tả bên trong của vịng trịn lớn. Những người này
đóng vai trị quan trọng nhất trong việc quản lý dự án và thực hiện dự án. Về tổ chưc quản
lý, ta thấy có thể phân biệt và phải biết rõ chức năng của từng người dưới đây:


 Giám đốc dự án: tổ chức, phối hợp, đối ngoại


 Giám đốc điều hành: trực tiếp điều hành, tích hợp


 Nhóm trưởng kỹ thuật: chịu trách nhiệm từng phần kỹ thuật


 Nhân viên kỹ thuật trong mỗi nhóm: thực hiện cơng việc kỹ thuật cụ thể.


Thực chất, họ đều là những người quản lý dự án, nhưng ở những mức độ chi tiết
khác nhau mà thôi.


Mức quản lý cuối cùng là các nhóm trưởng phụ trách từng phần cơng việc kỹ thuật.
Có thể coi đó là “giao diện” giữa việc quản lý và thực hiện dự án - tức là với các nhóm kỹ
thuật, những người trực tiếp xây dựng và phát triển hệ thống. Cần lưu ý nếu những người
này nằm trong sự quản lý trực tiếp của đơn vị hiện tại thì việc tham gia vào dự án ít nhiều
như là một trách nhiệm mà cơ quan giao cho.


- Các đối tác bên ngồi:


 Ví dụ như những hợp đồng chuyên gia bên ngoài, các nhà cung cấp thiết
bị...Những người này có thể cũng sẽ có vai trị nhất định đối với việc thực hiện


dự án, thậm chí tham gia vào việc điều hành kỹ thuật...vào chức năng nào đó
của nhóm ở bên trong vịng trịn, nhưng họ làm việc theo cơ chế hợp đồng thoả
thuận giữa hai bên.


</div>
<span class='text_page_counter'>(16)</span><div class='page_container' data-page=16>

<b>Hình 1.2: Những người có trách nhiệm với dự án </b>
<b>Bài tập </b>


Bạn là giám đốc dự án cho một dự án lớn đã tiến hành một vài lần. Bạn vừa hoàn
tất giai đoạn thiết kế giao diện người dùng của dự án và đang tiến hành công việc trong
giai đoạn triển khai. Tại thời điểm này, hãy liệt kê ba thay đổi có thể xẩy ra mà khơng có
rủi ro tiến hành lại cơng việc tồn bộ dự án. Và giải thích tại sao.
























Ch ủ (Giám
đố c) d ự án


Đ i ề u hành (v ề k ỹ thu ậ t)


Tr ưở ng
nhóm 1


Tr ưở ng
nhóm 2


Tr ưở ng
nhóm 3


Các nhóm phát tri ể n
Ban Ch ỉ đạ o


VP BC Đ


Nhà h ợ p đồ ng


Nhà cung c ấ p
Tài chính


</div>
<span class='text_page_counter'>(17)</span><div class='page_container' data-page=17>

<b>CHƯƠNG 2: LẬP KẾ HOẠCH </b>


<b>Giới thiệu: </b>



Nội dung bài này trình bày những vấn đề cơ bản về quản lý phạm vi và thời gian.
Nội dung tập trung chính vào tạo tôn chỉ dự án, lập bảng kê công việc và Work Breakdown
Structure (WBS), tầm quan trọng của quản lý thời gian và quy trình quản lý thời gian.


Bên cạnh đó cũng đề cập những vấn đề cơ bản về chi phí, quản lý chi phí, quy trình
quản lý chi phí, các kỹ thuật ước lượng và lập dự tốn chi phí, chất lượng và quản lý chất
lượng, quy trình giám sát và kiểm sốt chất lượng, nguồn nhân lực, tầm quan trọng của
nguồn nhân lực, quy trình tuyển dụng nhân sự, cách quản lý nguồn nhân lực, những rủi ro
cơ bản trong quản lý dự án và quy trình quản lý rủi ro.


<b>Mục tiêu: </b>


Lập kế hoạch để quản lý các vấn đề phạm vi, thời gian, chi phí, chất lượng, nguồn
nhân lực và rủi ro.


<b>Nội dung chính: </b>
<b>2.1. Quản lý phạm vi </b>


Phạm vi (scope) là một danh sách tất cả những gì dự án phải làm (và cũng có thể là
một danh sách tất cả những điều mà dự án không phải làm). Dự án phải có một phạm vi
được viết ra rõ ràng, nếu không, dự án sẽ không bao giờ kết thúc.


Quản lý phạm vi: Là việc xác định phạm vi, giám sát việc thực hiện mục đích, mục
tiêu của dự án, xác định công việc nào thuộc về dự án và cần phải thực hiện, cơng việc nào
nằm ngồi phạm vi của dự án


Các kết quả chuyển giao (deliverables) là những sản phẩm của dự án sẽ chuyển giao:
như phần cứng, phần mềm, bảo hành, tài liệu, đào tạo và phương thức chuyển giao.



Nhóm dự án và các bên liên quan (stakeholders) phải cùng hiểu những sản phẩm
nào được tạo ra như là kết quả của dự án và chúng được tạo ra như thế nào.


<b>2.1.1. Bản kế hoạch phạm vi dự án </b>
Quy trình quản lý phạm vi


- Khởi thảo: bắt đầu một dự án hoặc chuyển tiếp sang giai đoạn tiếp theo.


- Lập kế hoạch phạm vi: phát triển các tài liệu nhằm cung cấp nền tảng cho các quyết
định về dự án trong tương lai.


</div>
<span class='text_page_counter'>(18)</span><div class='page_container' data-page=18>

- Kiểm tra phạm vi: hợp thức hóa việc chấp nhận phạm vi của dự án.


- Điều khiển thay đổi phạm vi: điểu khiển những thay đổi của phạm vi dự án.


Lập kế hoạch


Thảo quy định phạm vi dự án. Tập hợp thông tin phù hợp cho kết luận tuân theo các
nguyên tắc sau:


- Đảm bảo rằng loại dự án và quy mô dự án được xác định rõ:


- Xem xét việc sử dụng kế hoạch dự án tích hợp cho dự án thêm / chuyển / thay đổi
và các dự án vi mô


- Chuẩn bị cho quy định phạm vi phức tạp hơn và lớn hơn cho cả dự án vĩ mô.
- Đảm bảo rằng các phần có thể chuyển giao và ranh giới d án được xác định rõ:
- Tài liệu có xác định rõ cái sẽ được hồn thành và khơng được hồn thành như một


phần của dự án hay không?



- Các yêu cầu bắt buộc và khơng bắt buộc có xác định rõ hay khơng? Các tiêu chí
chấp thuận cho các kết quả chuyển giao đã được phác thảo chưa?


- Tài liệu có xác định rõ mỗi phần có thể chuyển giao nào sẽ bằng ngơn ngữ khơng
biệt ngữ hay khơng?


- Bạn có biết khi nào dự án hồn tất khơng?


- Tính đến ngày tháng bắt đầu và ngày tháng hồn tất theo mục tiêu trong đó có thời
đoạn tương đối với ngày tháng bắt đầu theo lý thuyết và / hoặc ngày tháng bắt đầu
/ kết thúc.


- Tính đến hậu quả của những ngày tháng bị trễ hạn theo toàn bộ dự án cũng như các
mốc quan trọng cụ thể.


- Đảm bảo rằng trách nhiệm được xác lập rõ:


- Đảm bảo rằng tất cả các bên liên quan hiểu vai trò và trách nhiệm của họ trong dự
án.


- Cân nhắc việc sử dụng ma trận trách nhiệm.


- Mọi người có hiểu chuỗi yêu cầu cho dự án hay không?


- Có một số quy định hay chuẩn của ngành ảnh hưởng tới các phần có thể chuyển
giao hay khơng? Giao cho ai đó nghiên cứu và chịu trách nhiệm về các phạm vi này.
- Đảm bảo rằng tam giác thép được đặt đúng chỗ:


- Cái nào là ưu tiên giữa chi phi, lịch trình và chất lượng?



</div>
<span class='text_page_counter'>(19)</span><div class='page_container' data-page=19>

- Bản đồ nguồn lực có ý nghĩa khơng? Các phần có thể chuyển giao có thể thực hiện
được hay không?


- Các mốc quan trọng đề ra có ý nghĩa khơng?
- Ước tính chi phí đề ra có ý nghĩa khơng?


- Đảm bảo rằng quy định phạm vi phác thảo rõ rủi ro liên quan tới dự án:


- Cẩn thận các rủi ro nghiệp vụ đó như các điều kiện thị trường xấu không trở thành
bộ phận của quy định rủi ro cho dự án.


- Cân nhắc việc sử dụng ma trận rủi ro để tránh hàng loạt những điều xấu có thể xảy
ra.


Thảo tôn chỉ dự án


Dự án bạn đang thực hiện có địi hỏi thời gian, nguồn lực hay tiền bạc không? Nếu
câu trả lời là có thì khi đó bạn cần xây dựng tơn chỉ dự án


Tôn chỉ dự án là một tài liệu dự án cấp phép hay phê chuẩn một dự án. Sự cấp phép
này quy định từ một mức quản lý thích hợp trở lên và nên thực hiện tối thiểu ba điều:


- Tôn chỉ dự án nên đặt tên dự án và bổ nhiệm giám đốc dự án.
- Tôn chỉ dự án nên phác thảo các yêu cầu nghiệp vụ cho dự án.
- Tôn chỉ dự án nên mô tả các yêu cầu chức năng sẽ được đưa ra


Xây dựng tôn chỉ dự án tuân theo các nguyên tắc sau:


- Đảm bảo rằng bên ký kết hay người ký/ cấp phép cho tài liệu quyết định này phải


đúng chức năng, có thẩm quyền:


 Bên ký kết có thể cho phép bổ nhiệm lại nhân sự có liên quan hay khơng?


 Bên ký kết có thể cho phép giải phóng nguyên vật liệu có liên quan hay khơng?


 Bên ký kết có thể cho phép tiêu dùng tiền bạc cần thiết hay không?
- Đảm bảo rằng tôn chỉ dự án rõ ràng:


 Tôn chỉ dự án có đặt tên dự án rõ ràng hay khơng?


 Tơn chỉ dự án có chỉ định rõ giám đốc dự án hay không?


 Tôn chỉ dự án có chỉ rõ thời gian thực hiện và kinh phí dự án hay khơng?


 Tơn chỉ dự án có phác thảo yêu cầu nghiệp vụ chứng minh cho dự án hay
không?


</div>
<span class='text_page_counter'>(20)</span><div class='page_container' data-page=20>

- Đảm bảo rằng tôn chỉ dự án được phân phát hợp lý:


 Các đối tượng liên quan dự án có bản sao hay khơng?


 Đội ngũ thành viên dự án có bản sao hay khơng?


 Bộ phận kế tốn hay tài chính có bản sao hay khơng?


 Các nhà quản lý nguồn lực liên quan trong dự án có bản sao hay khơng?


<b>2.1.2. Bản kế hoạch chi tiết phạm vi dự án </b>



Bảng kê công việc là tài liệu kiểm sốt dự án có thể được sử dụng như một hợp đồng
pháp lý, tài liệu phạm vi hay tài liệu kiểm sốt nhưng thơng thường nên phác thảo một số
chi tiết quan trọng:


- Công việc được thực hiện.


- Ngày tháng, thời gian và địa điểm công việc được thực hiện.
- Ai chịu trách nhiệm thực hiện công việc.


- Nguyên vật liệu và kỹ thuật được dùng để thực hiện công việc.
- Chi phí thực hiện cơng việc.


- Tiêu chí chấp thuận cơng việc.


Một số tổ chức dùng bảng kê công việc như một hợp đồng pháp lý với một nhà cung
cấp đang cung cấp một hay nhiều phần có thể chuyển giao cho dự án. Trong những trường
hợp này, bảng kê công việc sẽ tính đến điều kiện thanh tốn, thưởng và phạt hiệu quả và
các tiêu chí chấp nhận hay từ chối công việc.


Một số tổ chức dùng bảng kê cơng việc như một tài liệu kiểm sốt cho các phần có
thể chuyển giao của dự án được xây dựng trong các bộ phận khác. Trong các trường hợp
này bảng kê cơng việc có thể rất giống với trình tự cơng việc giữa các bộ phận. Mục đích
đầu tiên của bảng kê cơng việc trong những trường hợp này là thu mua nguồn lực thông
qua các đường chức năng.


</div>
<span class='text_page_counter'>(21)</span><div class='page_container' data-page=21>

Thảo bảng kê cơng việc


Bảng kê cơng việc có thể là một tài liệu kiểm soát tốt nhưng bạn cần phải hiểu tổ
chức của bạn sử dụng bảng kê cơng việc để làm nó hiệu quả như thế nào. Xây dựng bảng
kê công việc hiệu quả tuân theo các nguyên tắc sau:



- Đảm bảo rằng bạn hiểu về loại dự án:


 Cân nhắc cẩn thận các phần có thể chuyển giao liên quan để xác định xem dự
án là vĩ mô, vi mô hay thêm/ chuyển/ thay đổi.


 Đảm bảo rằng bạn hiểu rõ mối quan hệ giữa loại dự án và kỳ vọng cho tài liệu
dự án trong tổ chức của bạn.


- Đảm bảo rằng bạn hiểu tổ chức của mình sử dụng bảng kê cơng việc như thế nào:


 Tổ chức có mẫu bảng kê công việc hay không?


 Xem xét các tệp dự án khác để xem họ sử dụng bảng kê công việc như thế nào.
- Đi vào cụ thể để tránh những nhầm lẫn và hiểu lầm:


 Đảm bảo rằng bạn tính đến tất cả các thơng tin cần thiết (Đó là ai, cái gì, ở
đâu, khi nào và như thế nào).


 Nên tránh các thuật ngữ kỹ thuật, các từ thông dụng, các từ viết tắt, hoặc định
nghĩa để đảm bảo rằng mọi người đang tiến hành công việc từ định nghĩa dùng
chung.


- Lấy chữ ký nếu bạn muốn nó mang tính pháp lý hoặc ràng buộc:


 Nếu bạn đang dùng bảng kê công việc như một hợp đồng với các bộ phận khác
nhau thì bạn cần chữ ký để làm cho hợp đồng có giá trị.


Cấu trúc bảng kê công việc



Một bảng kê công việc có chiều hướng trên xuống. Bắt đầu từ sản phẩm tồn bộ và
chia nó ra thành những yếu tố nhỏ hơn. Do đó, người ta có thể so sánh xây dựng BKCV
giống như công tác chuẩn bị dàn bài cho một bài văn. Mỗi chủ đề đều được chia thành
những chủ đề con, và mỗi chủ đề con lại được chia thêm nữa thành các phần nhỏ. Tuy
nhiên, cũng cần chú ý tới quan hệ giữa mô tả công việc và mô tả sản phẩm. Trong đó, sản
phẩm: danh từ (bao gồm: đầu vào, đầu ra, động tác xử lý); công việc: Động từ, mô tả một
quá trình hoạt động, xử lý.


BKCV có thể được phân thành nhiều mức. Khơng phải tất cả "nhánh" của BKCV
đều cần chi tiết cùng số mức. Mỗi mức cho phép tạo ra lịch biểu và báo cáo tóm tắt thơng
tin tại từng mức đó. BKCV chỉ viết "cái gì", chứ khơng viết "như thế nào";


</div>
<span class='text_page_counter'>(22)</span><div class='page_container' data-page=22>

BKCV bao gồm hai thành phần chính.


- Danh sách sản phẩm: DSSP (Product Breakdown Structure)


 DSSP: mô tả theo trình tự từ trên xuống


 Mức độ phân cấp tuỳ theo độ phức tạp của sản phẩm. Nói chung, sản phẩm
càng phức tạp thì số các mức càng lớn hơn. Sản phẩm toàn bộ và từng sản
phẩm con được mơ tả bằng danh từ.


<b>Hình 2.1: BKCV theo sản phẩm </b>


- Danh sách công việc: DSCV (Task Breakdown Structure)


Xác định các công việc cần thực hiện để xây dựng từng sản phẩm con và từ đó hình
thành nên sản phẩm tồn bộ. DSCV được chia làm nhiều mức và mô tả từ trên xuống dưới.
Mỗi công việc đều được mô tả bằng động từ (hành động) và bổ ngữ.



</div>
<span class='text_page_counter'>(23)</span><div class='page_container' data-page=23>

Kết hợp cả 2 danh sách sản phẩm và danh sách cơng việc, ta có bảng kê cơng việc
chi tiết


<b>Hình 2.3: Bảng kê cơng việc chi tiết </b>


Cả phần DSSP và DSCV đều được đánh mã duy nhất. Mã số xác định vị trí, hay
mức, của phần tử trong BKCV.


Lưu ý: Nửa trên của BKCV bao gồm các mô tả sản phẩm, Nửa dưới của BKCV bao
gồm các mô tả công việc (để ra được sản phẩm).


Việc xây dựng một BKCV tốt, phải mất nhiều giờ- thậm chí hàng ngày – làm việc
cật lực và sửa chữa. Các bước xây dựng BKCV


Bước 1.


- Viết ra sản phẩm chung nhất. Dùng danh từ hay thuật ngữ mô tả trực tiếp 1 cách vắn
tắt (ví dụ: Hệ thống phần mềm quản lí nhân sự, Bệnh viện đa khoa, Cầu mới, ....).
Thông tin lấy từ tài liệu "Phác thảo dự án"


Bước 2.


</div>
<span class='text_page_counter'>(24)</span><div class='page_container' data-page=24>

Bước 3.


- Tạo lập Danh sách công việc Mô tả các công việc ở dưới mỗi sản phẩm ở mức thấp
nhất. Sau đó phân rã từng công việc ra thành các mức thấp hơn.


- Nếu một công việc cần làm nhiều hơn 2 tuần (hoặc 80 giờ) thì nên phân rã tiếp.


Bước 4. Đãnh mã cho mỗi ô của Bảng kê công việc.


- Mức 0: đánh mã 0.0 cho sản phẩm chung nhất


- Mức 1: đánh các mã 1.0, .2.0, 3.0 cho các sản phẩm con


Đánh số tiếp mỗi ô trong BKCV một mã số duy nhất, theo cách sau: Từ trên
xuống dưới -- Từ trái sang phải không phân biệt nội dung trong 1 ô là sản phẩm hay công
việc.


- Nếu là 1.0. => đánh số tiếp là 1.1, 1.2, 1.3, ....
- Nếu là 1.1 => đánh tiếp là 1.1.1, 1.1.2, 1.1.3, ...
- Nếu là 1.2 => đánh tiếp 1.2.1, 1.2.2, ...


Bước 5. Xét duyệt lại BKCV


- Tất cả các ô thuộc danh sách sản phẩm đều có danh từ (và có thể tính từ đi kèm),
- Tất cả các ô thuộc danh sách công việc có động từ ra lệnh và bổ ngữ


- Tất cả các ô đều có mã duy nhất


<b>2.1.3. WBS (Work Breakdown Structure) </b>


WBS là bản thiết kế phân cấp các sản phẩm, sản phẩm phụ, nhiệm vụ và nhiệm vụ
con cần để hoàn thành dự án. Một WBS tốt cung cấp cơ sở cho việc xây dựng các ước
lượng thời gian và chi phí có ý nghĩa cũng như lịch biểu khả thi.


WBS là một danh sách chi tiết các bước cần để hoàn thánh một dự án. Nó cung cấp
nhiều lợi ích cho người quản lý dự án. Việc xây dựng WBS buộc người quản lý dự án phải
cố gắng tư duy để hiều những cái sẽ phải làm để kết thúc dự án. Nếu phân tích đúng đắn,
khoa học, nó cho phép xác định các bước chính xác để làm xong dự án.



</div>
<span class='text_page_counter'>(25)</span><div class='page_container' data-page=25>

Một WBS tốt cũng cho phép người quản lý dự án xây dựng việc giải trình giữa các
thành viên tổ dự án. Sau khi liệt kê tất cả các nhiệm vụ người quản lý dự án có thể phân
cơng cơng việc cho từng người. Điều này thể hiện khơng khí dân chủ, thẳng thắn, đầy trách
nhiệm và giải trình giữa các thành viên tổ.


Người quản lý dự án có thể dùng WBS để xây dựng lịch biểu hữu dụng. Một danh
sách cụ thể các nhiệm vụ, làm cơ sở cho các ước lượng hiện thực và việc xây dựng cuối
cùng về các lịch biểu. Bên cạnh đó, nó làm cho người quản lý dự án có khả năng phát triển
các lịch biểu, được biết đến như lịch biểu tầng.


Cuối cùng, việc xây dựng một WBS tốt buộc các vấn đề cơ bản sớm nảy sinh trong
dự án thay vì muộn ( Khi cịn khó khăn hơn để thay đổi tình huống ). Việc xây dựng WBS
địi hỏi những đóng góp đáng kể từ những người tham dự dự án ( Như: người quản lý dự
án, khách hàng, thành viên tổ, người tài trợ dự án và quản lý cấp cao).


<b>2.1.4. Các nguyên lý cơ bản tạo WBS </b>
Các đặc trưng của WBS


Đặc trưng chính của WBS là có khuynh hướng trên xuống. Người quản lý dự án bắt
đầu với sản phẩm cuối cùng và chia nó ra thành những yếu tố nhỏ hơn, các sản phẩm trung
gian hay sản phẩm con. Hình dưới chỉ ra việc tổ chức này của WBS.


Việc chia ra là rất giống với việc chuẩn bị dàn bài cho một bài văn. Mỗi chủ đề đều
được chia thành những chủ đề con, và mỗi chủ đề con lại được chia thêm nữa thành các
cấu phần.


Một đặc trưng khác của WBS là được tách thành nhiều mức. Không phải tất cả “
nhánh ” của WBS đều cần bung ra hết. Bản thân mức là khơng có ý nghĩa chính. Mỗi mức
đơn giản cho phép bạn tạo ra lịch biểu và báo cáo tóm tắt thơng tin tại từng mức đó.



</div>
<span class='text_page_counter'>(26)</span><div class='page_container' data-page=26>

<b>Hình 2.4. Cấu trúc phân sản phẩm </b>


Quá trình phân rã (Decomposition)


Cấu trúc chi tiết công việc WBS xác định phạm vi của dự án bằng cách liệt kê ra tất
cả những dự án nhỏ (sub-project) hoặc những kết quả chuyển giao trong một dự án. Công
tác phân tách cấu trúc chi tiết công việc là việc đội dự án phân tách những dự án nhỏ hoặc
những kết quả chuyển giao thành những công việc cấu thành và các gói cơng việc cần thiết
để thực hiện dự án.


Một cấu trúc chi tiết công việc được coi là đã phân tách khi:


Các công việc cấu thành (component tasks) hoặc các gói cơng việc phải là những
việc duy nhất có thể phân biệt được với các công việc khác và dễ xác định bởi những người
sẽ thực hiện cơng việc, ví dụ “nâng cấp Cửa hàng số 7” chứ không phải là “nâng cấp địa
điểm bán lẻ”.


Các công việc cấu thành hoặc các gói cơng việc phải có thời gian được xác định rõ
ràng hoặc một nỗ lực có thể lập lịch được.


Các công việc cấu thành và các gói cơng việc phải đủ cụ thể để thiết lập các giới
hạn chi phí và lịch trình bằng các metric chung như đơ la hoặc số giờ làm việc.


Trách nhiệm và thẩm quyền đối với các cơng việc cấu thành hoặc gói cơng việc có
thể được giao cho một người hoặc một nhóm.


</div>
<span class='text_page_counter'>(27)</span><div class='page_container' data-page=27>

Cấu phần của WBS


WBS bao gồm 2 cấu phần chính. Phần thứ nhất của WBS được gọi là cấu trúc sản
phẩm (PBS). PBS giống như WBS nói chung, địi hỏi lấy viễn cảnh trên xuống. Hình trên


minh họa cho cấu trúc phần sản phẩm.


Lần nữa việc chia ra này của PBS là tương tự với dàn bài của bài văn – mỗi chủ đề
được chia thành các chủ đề con và mỗi chủ đề con lại được chia nhỏ thêm thành các cấu
phần. Mức độ bung ra tùy theo mức độ phức tạp của sản phẩm. Nói chung sản phẩm càng
phức tạp thì số các mức càng lớn hơn.


PBS cũng chiếm phần trên của cấu trúc phân việc. Mỗi nhánh của PBS lại được
phân nhỏ hơn thành các mức khác nhau. Sản phẩm toàn bộ và từng sản phẩm con được mô
tả bằng danh từ hay chủ ngữ.


<b>Hình 2.5. Cấu trúc phân nhiệm vụ </b>


Phần thứ hai của WBS được gọi là cấu trúc phân nhiệm vụ, cũng còn được biết là
TBS. Nó bao gồm các nhiệm vụ, nhiệm vụ con để xây dựng từng sản phẩm con và chung
cuộc xây dựng nên sản phẩm toàn bộ.


TBS, cũng giống như PBS. Được chia thành nhiều mức và đòi hỏi viễn cảnh trên
xuống.


Số mức của việc bung ra tùy thuộc vào độ phức tạp của sản phẩm tồn bộ hay sản
phẩm con. Nói chung dự án càng phức tạp thì lại càng cần nhiều mức.


TBS khơng giống PBS, nó chiếm phần thấp hơn của WBS. Mỗi nhánh của TBS có
thể được chia thành các mức khác nhau. Mỗi nhiệm vụ và các yếu tố thấp hơn đều được
mô tả bằng động từ ra lệnh ( động từ hành động ) và một bổ ngữ. Do đó một TBS bao gồm
phần xác định ( động từ ra lệnh ) và phần xử lý ( bổ ngữ ). Nếu gộp cả 2 sẽ cho ta phần vị
ngữ trong một câu mà chủ ngữ là các PBS.


</div>
<span class='text_page_counter'>(28)</span><div class='page_container' data-page=28>

<b>Hình 2.6. Ví dụ về WBS đầy đủ </b>


Các bước xây dựng WBS


Bước 1:


Viết ra sản phẩm toàn bộ sẽ phải xây dựng. Dùng danh từ hay thuật ngữ mô tả tực
tiếp như hệ thống quản lý kho hay kế hoạch tiếp thị. Hãy mang tính mơ tả mà khơng bị dài
dịng. Cơ bản, mơ tả chính xác về sản phẩm nên bắt nguồn từ Phát biểu về công việc
(statement of work).


Bước 2:


Bung toàn bộ sản phẩm ra thành các mức biến thiên theo các sản phẩm con. Điều
này giúp cho việc xây dựng cấu trúc sản phẩm của WBS. Thông thường 2 hoặc 3 mức là
đủ.


Bước 3:


</div>
<span class='text_page_counter'>(29)</span><div class='page_container' data-page=29>

Câu hỏi thông thường hay được hỏi là nên bung một nhánh bao xa trên WBS? Cách
thông thường nhất để xác định mức thích hợp được biết tới xem như qui tắc là 2 tuần hay
80 giờ.


Điều này có nghĩa là nếu một phần tử TBS địi hỏi hơn 2 tuần làm việc (80h làm
việc) thì hãy bung phần tử TBS đó thành mức khác nữa. Qui tắc này sẽ đảm bảo nhận diện
chi tiết hơn các nhiệm vụ và sẽ trợ giúp cho việc theo dõi dấu vết các nhiệm vụ này.


Bước 4:


Đánh mã cho mỗi phần tử trong WBS bằng một mã số duy nhất. Thứ nhất cho phần
tử sản phẩm mã 0.0 ( Cách thực hành thông thường ), Thứ 2, tại mức tiếp của PBS cho mỗi
phần tử sản phẩm con một số duy nhất, về cơ bản là 1.0, 2.0,vv..vv. Dùng các số này và


bắt đầu đi xuống từng nhánh, viết ra mã WBS duy nhất. Mã này nên chỉ ra mức của nó lệ
thuộc vào phần tử mức cao hơn.


Bước 5:


Xét duyệt lại WBS, giám định để đảm bảo rằng:


- Tất cả các phần tử PBS đều có danh từ (có thể thêm tính từ đi kèm)
- Tất cả các phần tử TBS đều có động từ ra lệnh và bổ ngữ


- Tất cả các phần tử đều có mã WBS duy nhất.


Các cách khác nhau để bung WBS. Cấu trúc phân việc có thể được bung theo nhiều
cách:


Cách 1


</div>
<span class='text_page_counter'>(30)</span><div class='page_container' data-page=30>

<b>Hình 2.7. WBS theo sản phẩm </b>


Cách 2


</div>
<span class='text_page_counter'>(31)</span><div class='page_container' data-page=31>

<b>Hình 2.8. WBS theo trách nhiệm chia thành nhiều pha </b>
Cách 3:


</div>
<span class='text_page_counter'>(32)</span><div class='page_container' data-page=32>

<b>Hình 2.9: WBS theo miền trách nhiệm </b>


Đây là những cách thông dụng nhất để bung ra WBS. Tuy nhiên khơng có quy tắc
nhanh và cứng nhắc. Khi muốn xây dựng một WBS đáp ứng cho nhu cầu của mình – hãy
xây dựng một WBS giúp cho ta có thể lãnh đạo, xác định, lập kế hoạch, tổ chức, kiểm soát
và kết thúc dự án.



<b>2.2. Quản lý thời gian </b>


<b>2.2.1. Tầm quan trọng của lập lịch </b>


Kết thúc dự án đúng hạn là một trong những thách thức lớn nhất
Thời gian có độ linh hoạt bé nhất; nó trơi qua bất kể điều gì xảy ra


</div>
<span class='text_page_counter'>(33)</span><div class='page_container' data-page=33>

<b>2.2.2. Quản lý thời gian </b>


Quản lý thời gian: Là việc lập kế hoạch, phân phối và giám sát tiến độ thời gian
nhằm đảm bảo thời hạn hồn thành dự án. Nó chỉ rõ mỗi công việc phải kéo dài bao lâu,
khi nào thì bắt đầu, khi nào thì kết thúc và toàn bộ dự án kéo dài bao lâu, phải hồn thành
khi nào.


<b>2.2.3. Quy trình quản lý thời gian </b>


Quản lý thời gian dự án gồm những qui trình bảo đảm hồn tất dự án đúng hạn.
Những qui trình này gồm:


- Xác định các hành động


- Ước lượng thời gian cho mỗi hoạt động
- Triển khai lịch hành động


- Kiểm soát lịch hành động


<b>2.2.3.1. Xác định các hoạt động </b>
- Hành động theo nỗ lực hay thời đoạn



Nỗ lực là thước đo năng lượng hay lao động dùng để hoàn tất một nhiệm vụ cụ thể
hay gói cơng việc. Các chỉ số dùng để thể hiện điều này được tính bằng thời gian trên dạng
đơn vị. Ví dụ như ba giờ kỹ thuật hay năm ngày nghiên cứu.


Theo năng lực là thuật ngữ dùng để mô tả nhiệm vụ có thể hồn tất nhanh hơn thơng
qua việc áp dụng các nguồn lực lao động hay năng lượng phụ.


Thời đoạn là thước đo xem một gói cơng việc hay nhiệm vụ cụ thể sẽ mất bao lâu
để hoàn tất. Các chỉ số dùng để thể hiện điều này được tính bằng các đơn vị thời gian. Ví
dụ như trong xây dựng nhà dân dụng, sau mỗi lần đổ trần, người ta thường để 1 tuần để
trần ổn định trước khi tiếp tục xây các tầng tiếp theo.


Khoảng thời gian cố định là một thuật ngữ dùng để mô tả nhiệm vụ hay gói cơng
việc cần đến một lượng thời gian để hoàn tất. Việc áp dụng các nguồn lực phụ sẽ không
làm thay đổi thời gian yêu cầu.


- Xác lập các mốc quan trọng


- Các dự án theo lịch trình so với các dự án theo nguồn lực
- Thành lập các nguyên tắc ước lượng thời gian


</div>
<span class='text_page_counter'>(34)</span><div class='page_container' data-page=34>

Dự án hướng theo nguồn lực khi giá trị các nguồn lực, cụ thể là các nguồn lực kỹ
năng và chi phí ràng buộc quan trọng hơn cả mà nhà tài trợ hay khách hàng mong muốn.
Nó chi phối mọi quyết định trong dự án. Các dự án theo nguồn lực phải mở rộng thời gian
hoặc từ bỏ chất lượng để giữ lại các ràng buộc về nguồn lực.


Trong cả hai trường hợp thì thuật ngữ “hướng theo” được dùng để diễn tả ràng buộc
quan trọng hơn cả cho dự án đang được đưa ra.


<b>2.2.3.2. Sắp thứ tự các hoạt động </b>



Mốc quan trọng là các trường hợp điểm kiểm soát trong dự án, thường là việc hồn
tất phần có thể chuyển giao chính tạo ra yêu cầu báo cáo hoặc yêu cầu sự ủng hộ của khách
hàng hay nhà tài trợ trước khi tiếp tục dự án. Mốc quan trọng có thời đoạn bằng 0.


Các mốc quan trọng đóng vai trị như những mốc đánh dấu và được xác định bởi
giám đốc dự án và/hoặc khách hàng. Chúng phải được xác lập có chọn lựa sử dụng các
giác quan thơng thường.


Ví dụ như đối với một đánh giá thiết kế chính, thử nghiệm bản mẫu, nguồn vào cần
đến từ nguồn bên ngoài, xúc tiến quảng cáo. Các mốc quan trọng có ích trong việc chỉ ra
sự tiến triển tại các điểm chính nhưng chỉ số tiến triển thực sự là các gói cơng việc và ước
lượng nên được thực hiện sao cho phù hợp.


<b>2.2.3.3. Ước lượng thời gian cho mỗi hoạt động </b>
Xây dựng ước lượng thời gian theo nguyên tắc sau:


- Đánh giá các tài liệu yêu cầu với con mắt người phê bình những lỗi sai hay những
điều bỏ sót


- Các yêu cầu nghiệp vụ có rõ ràng và cụ thể hay không?


- Các yêu cầu chức năng có hỗ trợ các yêu cầu nghiệp vụ không?


- Quan trọng nhất là các yêu cầu kỹ thuật có được phác thảo rõ rằng và đầy đủ hay
không?


Đảm bảo rằng ước lượng chính quy của bạn gồm các thành phần chính sau:
- Danh sách các giả định dùng trong việc xây dựng ước lượng.



</div>
<span class='text_page_counter'>(35)</span><div class='page_container' data-page=35>

Đảm bảo rằng bạn hiểu đầy đủ mục đích dự định của ước lượng và đang sử dụng kỹ
thuật ước lượng đúng:


- Ước lượng được dùng để đánh giá tiềm lực dự án hay để quản lý dự án hay khác?
- Không sử dụng ước lượng trên xuống nếu dự án chưa từng được thực hiện trước


đây.


- Xác lập các mức độ ưu tiên từ các mục tiêu được xác định quan trọng, có ý nghĩa
nhất cho dự án hoặc được xác nhận bởi các yêu cầu nhà tài trợ hay khách hàng.


<b>2.2.3.4. Phát triển lịch biểu </b>


Đảm bảo rằng nhà tài trợ và các đối tượng liên quan dự án hiểu một cách rõ ràng
hoặc bản chất của các dự án nguồn lực và các dự án theo lịch trình. Thường có một mối
quan hệ cả hai/và giữa lịch trình và nguồn lực:


- Hỏi họ xem liệu thời hạn giao là chắc chắn và phải được hoàn tất với chi phí nào đó
hay khơng?


- Hỏi họ xem liệu thời hạn có thể lùi lại được nếu nguồn lực trở thành một vấn đề hay
không?


<b>2.2.3.5. Điều khiển lịch biểu </b>


Đảm bảo rằng thời đoạn ước tính của các dự án theo nguồn lực được chuyên gia về
nội dung chuyên ngành xét duyệt cẩn thận. Chuyên gia về nội dung chuyên ngành hiểu các
yêu cầu về nguồn lực và các kỹ thuật liên quan đến việc thực hiện công việc thực sự:


- Bạn có biết nhiệm vụ nào theo cơng việc khơng?



- Bạn có biết kỹ năng nào cần để thực hiện công việc không?


Quan sát các trường hợp khoảng thời gian cố định và phụ thuộc cơ sở vật chất:
- Tìm kiếm các trường hợp khoảng thời gian cố định bất kỳ trong luồng dự án, đặc


biệt chú ý tới sự phụ thuộc ngược dịng và xi dịng.


</div>
<span class='text_page_counter'>(36)</span><div class='page_container' data-page=36>

<b>2.3. Quản lý chi phí </b>
<b>2.3.1. Chi phí </b>


Chi phí là tài nguyên được đem vào sử dụng, tiêu hao, kết chuyển giá trị vào sản
phẩm mong đợi. Chi phí cần được tính tốn trước để đạt được một mục tiêu rõ ràng hay để
trao đổi cái gì đó. Chi phí thường được đo bằng đơn vị tiền tệ.


<b>2.3.2. Quản lý chi phí </b>


Quản lý chi phí: Là q trình dự tốn kinh phí, giám sát thực hiện chi phí theo tiến
độ cho từng cơng việc và tồn bộ dự án. Cụ thể là tổ chức, phân tích số liệu, báo cáo những
thơng tin về chi phí.


Quản lý chi phí dự án bao gồm những quy trình yêu cầu đảm bảo cho dự án được
hoàn tất trong sự cho phép của ngân sách.


<b>2.3.3. Quy trình quản lý chi phí </b>


Quản lý Chi phí dự án gồm những qui trình bảo đảm cho dự án được hoàn tất trong
sự cho phép của ngân sách. Những qui trình này gồm:


- Lập kế hoạch về nguồn tài nguyên: xác định nguồn tài nguyên cần thiết và số lượng


để thực hiện dự án.


- Ước lượng chi phí: ước tính chi phí về các nguồn tài nguyên để hoàn tất một dự án.
- Dự tốn chi phí: phân bổ tồn bộ chi phí ước tính vào từng hạng mục cơng việc để


thiết lập một đường mức (Base line) cho việc đo lường việc thực hiện
- Kiểm soát – Điều chỉnh chi phí: điều chỉnh thay đổi Chi phí dự án.


<b>2.3.3.1. Lập kế hoạch cho nguồn tài nguyên </b>
- Nguyên tắc ước lượng chi phí


Đánh giá các tài liệu yêu cầu với con mắt phê bình về những sai lầm và bỏ sót:


 Các yêu cầu nghiệp vụ có rõ ràng và cụ thể khơng?


 Các yêu cầu chức năng có hỗ trợ các yêu cầu nghiệp vụ không?


 Quan trọng nhất là các yêu cầu kỹ thuật có được phác thảo rõ ràng và đầy đủ
không?


 Đảm bảo rằng bạn hiểu đầy đủ về mục đích của ước tính và đang dùng kỹ thuật
ước lượng đúng hay không?


</div>
<span class='text_page_counter'>(37)</span><div class='page_container' data-page=37>

Không sử dụng ước lượng trên xuống nếu dự án chưa từng được thực hiện trước
đây.


Đảm bảo rằng ước lượng chính quy của bạn có các thành phần chính sau:


 Danh sách các giả định dùng trong xây dựng ước lượng.



 Phạm vi biến động cho ước lượng đề ra.


 Giai đoạn thời gian dự án có hiệu lực.


Đảm bảo rằng thời hạn ước tính của tất cả các dự án theo nguồn lực được chuyên
gia về nội dung chuyên ngành xét duyệt cẩn thận. Chuyên gia về nội dung chuyên ngành
hiểu các yêu cầu nguồn lực và các kỹ thuật liên quan tới việc thực hiện hoạt động thực sự:


 Bạn có biết những nhiệm vụ nào là theo năng lực khơng?


 Bạn có biết kỹ năng nào cần để thực hiện công việc không?


Đảm bảo rằng nỗ lực cần đến được trình bày bằng các thuật ngữ cụ thể:


 Trình bày ước tính bằng đơn vị đo lường phù hợp với những thứ đã được theo
dõi về phương diện lịch sử.


 Đừng quên tính cả chi phí nguồn lực bên trong q trình tính tốn tồn bộ nỗ
lực.


Đảm bảo rằng cơ sở vật chất, nguyên vật liệu cần đến được trình bày bằng các thuật
ngữ, trong đó sức mua sẽ được hiểu là:


 Lập chi phí theo đơn giá, định mức hoặc giá thị trường theo cách tính trên đơn
vị tính của nguyên vật liệu, cơ sở vật chất.


 Lập hoá đơn, chứng từ nguyên vật liệu cho dự án.


 Đảm bảo rằng yêu cầu cơ sở vật chất, nguyên vật liệu được trình bày bằng
thuật ngữ tài chính.



- Chi phí nguyên vật liệu


</div>
<span class='text_page_counter'>(38)</span><div class='page_container' data-page=38>

- Chi phí cơ sở vật chất


Chi phí cơ sở vật chất là loại chi phí dùng để chỉ các cơng cụ, thiết bị vật chất hay
cơ sở hạ tầng dùng trong suốt dự án khơng trở thành bộ phận của các phần có thể chuyển
giao. Trong nhiều tổ chức, mục này đơn thuần được xem như tổng chi phí hay chi phí cố
định.


<b>2.3.3.2. Ước lượng chi phí </b>
- Ước lượng chính quy


Ước lượng chính quy được dùng để chỉ ước lượng gần đúng. Trên thực tế chúng
thường tốt hơn chút so với một ước đốn khơng rõ ràng. Phương pháp không được chuẩn
bị trước này tạo ra kỳ vọng rằng một điều gì đó có thể được thực hiện với một loạt nguồn
lực cụ thể và trong một lượng thời gian đã định.


Ước lượng chính quy và khơng chính quy là các cơng cụ ta dùng để dự đoán thời
gian và nguồn lực cần thiết để thực hiện một dự án cụ thể. Ước lượng chính quy dựa trên
sự phân tích. Trong một thế giới lý tưởng, phân tích này sẽ được tiến hành theo chiều sâu.
Ít nhất là một phân tích mở đầu phải được tiến hành. Một ước lượng gồm có 3 thành phần
chính:


 Danh sách các giả định được sử dụng trong việc xây dựng ước lượng (Ví dụ
như các chi phí đầu vào về lao động và nguyên vật liệu).


 Phạm vi biến động cho ước lượng được đưa ra (Ví dụ +/- 50%).


 Khoảng thời gian ước lượng có hiệu lực (Ví dụ như ước lượng này có hiệu lực


trong vịng 60 ngày).


Ngược lại, ước lượng khơng chính quy là ước đốn dựa trên sự suy đoán, phỏng
đoán và bản năng.


- Ước tính sử dụng kết quả chào thầu


Ước tính là một tài liệu dự án dùng để dự đoán bao nhiêu thời gian và tổng số nguồn
lực mà dự án cần đến. Chào thầu là một tài liệu thương mại ghi rõ thời gian và tiền bạc cần
để hồn tất cơng việc dự án trong đó có lãi rịng cho dự án. Chào thầu có thể kết hợp chặt
chẽ các ước tính từ các một số nhà thầu phụ.


Độc giả dự kiến đưa ra sự khác biệt quan trọng giữa chào thầu và ước tính. Chào
thầu hầu như định hướng về khách hàng và nhà tài trợ và có sự tăng giá đồng thời trong đó
có tính đến lãi rịng cho dự án, trong khi đó ước tính thường được dùng bên trong hoặc
giữa các nhà thầu phụ với mục đích thể hiện chi phí thực.


</div>
<span class='text_page_counter'>(39)</span><div class='page_container' data-page=39>

khơng trả bất kỳ lãi rịng hay tăng giá nào cho việc sử dụng các nguồn lực bên trong. Tuy
nhiên nhiều bộ phận công nghệ thông tin hoạt động trong hệ thống khách hàng từ chối
thanh toán, nhưng họ khơng cho phép tăng giá dịch vụ của mình. Kết quả là tài liệu họ
cung cấp cho khách hàng của mình có chức năng giống như chào thầu nhưng chỉ thể hiện
những chi phí mà họ cho phép sửa lại. Nhiều khi các tài liệu này là trình tự cơng việc giữa
các bộ phận thay vì các ước tính và chào thầu.


- Thơng tin lịch sử hay cơ sở dữ liệu dự án


Nếu một dự án đã được thực hiện trước đây thì giám đốc dự án có thể thu được
nhiều kiến thức về tài liệu và dữ liệu liên quan tới dự án. Rõ ràng là mức độ thơng tin có
thể dùng trực tiếp sẽ phụ thuộc vào điểm tương đồng của hai dự án đang được giải quyết.
Thông tin lịch sử là các dữ liệu hay tài liệu có thể tồn tại từ dự án trước tương tự


như dự án hiện tại. Về lý tưởng thì thông tin này bao gồm các mục sau:


 Báo cáo sự cố.


 Yêu cầu kỹ thuật, chức năng và nghiệp vụ.


 Ước tính lịch trình và chi phí chi tiết.


 Kinh phí dự án.


 Cấu trúc chi tiết công việc.


 Chi phí thực và dữ liệu hiệu suất theo lịch trình, tốt nhất là ở mức gói cơng
việc.


 Bài học thu được.


Thông tin tương tự là dữ liệu từ tình huống khác rất giống nhưng khơng y hệt như
các tình trạng trước mắt. Nếu tình huống giống hệt thì khi đó thơng tin được xem như là
mang tính lịch sử. Thông tin tương tự xuất phát từ thành phần của các dự án khác tương tự
như các thành phần của dự án mới. Thơng tin tương tự cũng có thể xuất phát từ kinh nghiệm
điều hành.


- Ước lượng theo giai đoạn


Ước lượng theo giai đoạn là một kỹ thuật trong đó ước tính chi phí và lịch trình
được xây dựng riêng cho từng giai đoạn của dự án. Phương pháp này được sử dụng đầu
tiên khi không thật chắc chắn về những thứ thật sự liên quan đến dự án.


</div>
<span class='text_page_counter'>(40)</span><div class='page_container' data-page=40>

- Ước lượng theo tham số



Ước lượng theo tham số là kỹ thuật ưu tiên cho các dự án công nghệ thông tin chưa
từng được thực hiện trước đây và các dự án công nghệ thông tin khơng có dữ liệu lịch sử.
Cịn các dự án công nghệ thông tin tương tự như các dự án khác hoặc là sự kết hợp của các
dự án khác nhau khơng có dữ liệu lịch sử đúng ở mức độ nhiệm vụ thì sao? Khi các tình
huống chính xác có thể khơng phải đối mặt thì một ước tính đúng vẫn có thể được xây
dựng sử dụng kỹ thuật ước lượng theo tham số.


Ước lượng theo tham số lấy kiến thức thu được từ các dự án tương tự nhưng khơng
chính xác, đồng thời sử dụng các tham số như chi phí trên đơn vị để ước tính thơng tin lịch
trình và chi phí.


Ước lượng theo tham số có thể sử dụng cho các dự án lớn bằng cách phân chia
chúng thành các đơn vị công việc nhỏ và đưa vào một mơ hình tốn học. Phương pháp ước
lượng này có hiệu quả nhất khi dữ liệu lịch sử đúng có sẵn ở mức độ nhiệm vụ thậm chí
nếu sự sắp xếp thứ tự và sự kết hợp cụ thể các nhiệm vụ chưa từng được nỗ lực trước đây.
Ước lượng theo giai đoạn đòi hỏi bạn phải có 3 nguồn vào then chốt:


 Thông tin lịch sử bằng đơn vị công việc được sử dụng làm cơ sở tính tốn.


 Tập hợp các đặc tính, yêu cầu và kế hoạch chi tiết.


 Mơ hình tốn học được xây dựng cẩn thận được gọi là công thức theo tham số
trình bày mối quan hệ cơng việc liên quan.


Một số tổ chức sử dụng ước lượng theo tham số ở các mức độ cấu trúc chi tiết công
việc thấp hơn, ở đó họ có nhiều dữ liệu chính xác và chi tiết hơn và sau đó kết hợp kết quả
vào các mẫu đã được xây dựng trước hợp lại thành ước lượng chi tiết có độ chính xác cao.


Các phương pháp ước lượng theo tham số phổ biên hiện nay là:



 Phương pháp COCOMO dựa trên KLOC (Kilo Line Of Codes)


 Phương pháp điểm chức năng – Function Point


 Phương pháp điểm trường hợp sử dụng – UseCase Point


 Phương pháp COSMIC FFP: Full Function Point


Ngoài ra, trên thế giới hiện sử dụng nhiều phương pháp khác như điểm đối tượng,
điểm đặc tính (Feature Point)


- Ước lượng dưới lên


</div>
<span class='text_page_counter'>(41)</span><div class='page_container' data-page=41>

cơng việc khơng hồn thiện thì ước tính dự án cũng như vậy. Phương pháp này cần một
cấu trúc chi tiết công việc và dựa vào một số giả định:


 Khả năng. Người đang ước tính chi phí và lịch trình cho các gói cơng việc phải
biết công việc thực sự được tiến hành như thế nào.


 Tính chính trực. Nếu người đang thực hiện cơng việc tham gia vào ước tính
thì họ không thể đánh giá quá cao hoặc quá thấp về thời gian cần để hồn thành
cơng việc.


 Độ chính xác. Tưởng tượng xem điều gì sẽ xảy ra đối với các con số chi phí
và lịch trình của bạn nếu ai đó liên quan đến quy trình tổng hợp thêm một chút
“yêu tố gian lận” vào ước tính ở từng giai đoạn.


- Ước lượng trên xuống



Ước lượng từ trên xuống là một kỹ thuật bắt đầu bằng một ước tsnh cho toàn bộ dự
án và sau đó chia ra thành tỷ lệ phần trăm trong tổng số đối với mỗi giai đoạng hay loại
công việc dự án. Điều này được thực hiện dựa vào công thức thu được từ các dữ liệu lịch
sử do các dự án tương tự cung cấp.


Phương pháp này cần một cấu trúc chi tiết công việc và dựa vào một số giả định rất
nguy hiểm:


 Tính tương tự của dự án


 Độ chính xác cảu tồn bộ ước tính


Do ước lương từ trên xuống cần có thơng tin lịch sử nên không thể thực hiện ước
lượng trên xuống cho một dự án chưa từng được thực hiện trước đây.


<b>2.3.3.3. Dự thảo chi phí </b>


Dự tốn ngân sách cho các chi phí là một hoạt động nghiệp vụ theo dõi tất cả các
chi phí trực tiếp và gián tiếp cho cơng ty bằng dự án. Khi đó doanh thu cho dự án được so
sánh với tất cả các chi phí trực tiếp và gián tiếp để tính tốn lợi nhuận của từng dự án. Hoạt
động này rất phổ biến trong ngành xây dựng và đôi khi được xem như kế tốn cơng việc.


<b>2.3.3.4. Kiểm sốt, điều chỉnh chi phí </b>
- Theo dõi kinh phí qua các chỉ tiêu


</div>
<span class='text_page_counter'>(42)</span><div class='page_container' data-page=42>

thực của việc đã thực hiện (ACWP).Cơng thức tính Biến động chi phí là CV
= BCWP – ACWP. Nếu kết quả của Biến động chi phí


 (CV) là số dương (+), nghĩa là dự án chưa sử dụng hết kinh phí; ngược lại nếu
là số âm (), nghĩa là dự án đã sử dụng vượt quá kinh phí dự tốn.



 CPI (Hiệu suất chi phí) là tỉ số giữa chi phí dự tốn để thực hiện cơng việc với
chi phí thực để hồn thành cơng việc, hay nói cách khác là tỉ số giữa Chi phí
dự tốn của việc được thực hiện (BCWP) với Chi phí thực của cơng việc đã
thực hiện (ACWP). Cơng thức để tính Hiệu suất chi phí là CPI = BCWP /
ACWP. Nếu giá trị CPI lớn hơn 1, điều đó có nghĩa là chi phí dự án chưa được
sử dụng triệt để. Ngược lại, nếu giá trị CPI nhỏ hơn 1, nghĩa là chi phí thực
hiện dự án vượt q chi phí dự tốn. Nhờ các phương pháp tính Hiệu suất chi
phí (CPI) và Biến động chi phí (CV), các Giám đốc CNTT sẽ nắm được việc
chi tiêu đang tiến triển theo chiều hướng tích cực, tiêu cực, hay trung hịa so
với cơng việc được thực hiện, và để có các động thái kịp thời.


- Kiểm soát điều chỉnh chi phí


 Giám sát hoạt động chi phí.


 Bảo đảm rằng chỉ có sự thay đổi hợp lý đều được ghi nhận trong đường mức
(Base line)


 Thơng báo những thay đổi đến những người có thẩm quyền


<b>Khái niệm </b> <b>Công thức </b>


Giá trị thu được (EV) EV = PV * (% thời gian hồn thành)
Chi phí phát sinh (CV – Cost Variance) CV = EV - AC


Biến động lịch (SV = Schedule Variance) SV = EV - PV
Chỉ số thực hiện chi phí


(CPI = Cost Performance Index)



CPI = EV / AC


Chỉ số thực hiện lịch


(SPI = Schedule Performance Index)


SPI = EV / PV


Ước tính tại thời điểm hồn tất
(EAC = Estimate At Completion)


EAC = BAC / CPI


Ước tính thời gian hồn tất
(Estimate Time to Complete)


Ước tính thời gian ban đầu / SPI


</div>
<span class='text_page_counter'>(43)</span><div class='page_container' data-page=43>

Nhận xét


CV cho biết sự sai biệt giữa chi phí thật sự và giá trị thu được
SV cho biết sự sai biệt giữa hoàn thành theo lịch và giá trị thu được


CPI là tỷ số giữa giá trị thu được và chi phí thật sự. Nếu bằng 1 thì phù hợp và <1
vượt ngân sách.


SPI là tỷ số thực hiện theo lịch. Nếu >= 1 thì hồn thành trước lịch và < 1 là ngược
lại.



- Tiến hành cập nhật kinh phí


Để tiến hành cập nhật lịch trình dự án, thực hiện theo các bước sau:


 Tính tốn chi phí dự tốn của việc được thực hiện


 Tính tốn chi phí thực của cơng việc đã thực hiện


 Tính biến động chi phí (CV) để xác định xem dự án này chưa sử dụng triệt để
kinh phí (kết quả dương +) hoặc vượt quá kinh phí (kết quả âm -).


 Tính tốn hiệu suất chi phí (CPI) là tỷ số xác định xem dự án sử dụng kinh phí
chưa triệt để (tỷ số > 1) hay vượt quá chi phí dự tốn (tỷ số < 1)


 Xác định có nên lấn sang các khoản dự trữ dự phòng/ dự trữ cho quản lý dựa
trên kế hoạch quản lý rủi ro đã đưa ra.


<b>2.4. Quản lý chất lượng </b>


Quản lý chất lượng: Là quá trình triển khai giám sát những tiêu chuẩn chất lượng
cho việc thực hiện dự án, đảm bảo chất lượng kết quả của dự án phải đáp ứng mong muốn
của nhà tài trợ (chủ đầu tư).


<b>2.4.1. Chất lượng </b>


Tổ chức quốc tế về tiêu chuẩn hoá (ISO=International Standart Organisation)) xác
định chất lượng như tổng thể các chi tiết nhỏ của một sản phẩm mà nó phải thoả mãn những
quy định đã được đề ra.


Một số chuyên gia khác lại định nghĩa theo nguyên tắc cơ bản :


- Yêu cầu phù hợp: thoả mãn các yêu cầu đòi hỏi


</div>
<span class='text_page_counter'>(44)</span><div class='page_container' data-page=44>

<b>2.4.2. Quy trình quản lý chất lượng </b>


Chất lượng sản phẩm, dịch vụ thường được hiểu là khả năng đáp ứng được hoặc
vượt quá nhu cầu và kỳ vọng của khách hàng/nhà tài trợ với một mức phí hợp lý, trong một
khoảng thời gian cho phép. Do các dự án thường ở trong bối cảnh một công ty lớn hơn,
nên chính sách chất lượng cảu cơng ty mẹ thường là nơi khởi đầu hợp lý khi lập kế hoạch
chất lượng của dự án. Ví dụ, rất nhiều tổ chức đã áp dụng hệ thống chất lượng tiêu chuẩn
quốc tế ISO 9000 để quản lý chất lượng. Quản lý chất lượng có bao gồm một vài quy trình
như hình dưới đây:


<b>Hình 2.10. Quy trình quản lý chất lượng </b>


<b>2.4.2.1. Lập kế hoạch chất lượng </b>


Kế hoạch quản lý chất lượng (quality management plan) là một tài liệu dự án định
ra những tiêu chuẩn chất lượng áp dụng cho dự án và cách thức đạt được những tiêu chuẩn
này.


Kế hoạch quản lý chất lượng được hợp nhất trong kế hoạch tổng thể của dự án. Nó
được xây dựng trong q trình lập kế hoạch chất lượng và phải bao gồm các kế hoạch cho
đảm bảo chất lượng, kiểm soát chất lượng, nâng cao chất lương trong vòng đời của dự án.
Nó cũng cần phải bao gồm cả phương thức trao đổi thông tin được dùng để báo cáo ma
trận hiệu quả hoạt động cho nhà tài trợ, đội dự án, những người có liên quan và nhà cung
cấp. Kế hoạch quản lý chất lượng theo chiều sâu có vai trị rất quan trọng đối các dự án
phát triển ứng dụng. Cần phải duyệt và cập nhật kế hoạch quản lý chất lượng thường xuyên
nhằm đảm bảo kế hoạch phản ánh được yêu cầu của những người liên quan đến dự án.


Để xây dựng một bản kế hoạch quản lý chất lượng, cần làm theo các bước sau:


Lập kế hoạch


Thực hiện


</div>
<span class='text_page_counter'>(45)</span><div class='page_container' data-page=45>

- Kiểm duyệt các tài liệu về yêu cầu và hỏi lại nhà tài trợ nếu cần, nhằm đảm bảo tất
cả các yêu cầu của nhà tài trợ đã được định nghĩa rõ ràng.


- Xác định thước đo (metric) chất lượng dùng cho dự án, đặt ra những tiêu chuẩn chất
lượng và mục tiêu về hiệu quả tuân theo những tiêu chuẩn và quy tắc công nghiệp.
- Thiết lập lịch trình kiểm định kiểm thử dựa trên những phụ thuộc và đặc điểm kỹ


thuật của dự án.


- Thiết lập vai trò và trách nhiệm quản ký chất lượng, đưa các công việc vào lịch trình
dự án.


- Điều hịa báo cáo hiệu quả hoạt động và kết quả kiểm định thực tế với tiêu chuẩn
chất lượng và mục tiêu về hiệu quả hoạt động.


- Xây dựng vòng lặp cho hành động hiệu chỉnh trong việc xử lý biến động chất lượng.
- Xây dựng các phương pháp giải quyết bất đồng giữa các thành viên trong đội về sự


phù hợp của các kết quả chuyển giao.


- Lập kế hoạch báo cáo hiệu quả hoạt động bằng cách xác định cơ chế phản hồi cho
nhà tài trợ, người có liên quan đến dự án, và các nhà cung cấp về tiêu chuẩn chất
lượng và mục tiêu hiệu quả công việc.


- Bảo đảm kế hoạch tuân thủ yêu cầu của nhà tài trợ và định nghĩa được các tiêu chí,
bao gồm kiểm thử chấp nhận cho việc ký kết hoàn tất của nhà tài trợ khi dự án kết


thúc.


<b>2.4.2.2. Đảm bảo chất lượng </b>


Đảm bảo chất lượng (Quality Assurance) là hoạt động thường xuyên đánh giá một
cách có hệ thống chất lượng tổng thể của dự án trong quá trình thực hiện để các cổ đông
tin rằng dự án sẽ đạt được nhứng tiêu chuẩng chất lượng đã đề ra cũng như các tiêu chuẩn
ngành, tiêu chuẩn quốc gia. Đảm bảo chất lượng là hoạt động theo hướng phòng ngừa.


 Biến động về chất lượng


Một số biến động có thể phát hiện bằng quá trình kiểm định, nhưng nhiều loại biến
động khác thì phải qua một quá trình kiểm tra nghiêm ngặt.


 Tầm quan trọng của biến động


Tầm quan trọng là mức độ quan trọng được đặt cho các biến động để xác định được
các hành động hiệu chỉnh cần thiết mà Giám đốc dự án phải thực hiện.


</div>
<span class='text_page_counter'>(46)</span><div class='page_container' data-page=46>

liên quan đến tổng thể dự án và điểm cân bằng trong tam giác thép (iron triangle balance).
Giám đốc dự án phải xác định các ngưỡng giới hạn mà nhà tài trợ dự án đặt ra cho các biến
động trong phạm vi dự án, cũng như trong bối cảnh của tổ chức; và sử dụng nguồn lực hợp
lý.


<b>Hình 2.11: Biến động về chất lượng </b>


 Phân tích nguyên nhân sâu xa


Phân tích nguyên nhân sâu xa là kỹ thuật xác định nguyên nhân chính xác của vấn
đề, và khi loại bỏ được ngun nhân đó thì vấn đề sẽ không xảy ra lần nữa.



<b>2.4.2.3. Kiểm tra chất lượng </b>


Quản lý chất lượng dự án được thực hiện theo các bước sau:


- Tiến hành kiểm định các gói cơng việc đã hồn thành cũng như đang thực hiện để
đảm bảo đúng với kế hoạch chất lượng dự án.


- Tiến hành kiểm định chất lượng các gói cơng việc là các điểm phụ thuộc trên đường
tới hạn.


Lập kế hoạch


Thực hiện
Hiệu chỉnh các ngưởng


bị vượt qua


Kiểm tra


Thực hiện hành động
hiệu chỉnh


Kiểm tra
Đạt u cầu ?


Khơng





</div>
<span class='text_page_counter'>(47)</span><div class='page_container' data-page=47>

- Tiến hành kiểm định việc quản lý phiên bản và quy trình quản lý cấu hình nhằm
đảm bảo rằng tất cả các thành viên đang sử dụng cùng một phiên bản. Đảm bảo rằng
cấu hình ban đầu đã được ghi lại và các thay đổi về cấu hình phải được phê duyệt
và ghi chép lại. Cần phải kiểm tra cấu hình để đảm bảo phù hợp với yêu cầu của
khách hàng.


- Phân tích biến động về chất lượng để xác định nguyên nhân sâu xa của vấn đề. Nếu
một vấn đề lặp đi lặp lại nhiều lần, nghĩa là bạn đang đối phó với các triệu chứng
xảy ra chứ không phải là giải quyết tận gốc vấn đề. Trước khi thực hiện hành động
hiệu chỉnh, cần phải xác định nguyên nhân sâu xa của vấn đề.


- Phân tích tầm quan trọng của bất kỳ một biến động nào. Mức độ chấp nhận các rủi
ro của nhà tài trợ đã được xác định trong quá trình lập kế hoạch, và Giám đốc dự án
phải dựa vào đó để quản lý dự án. Tập trung quá nhiều vào một biến động không
quan trọng chính là sự lãng phí nguồn lực chung. Ngược lại, với các biến động quan
trọng, nếu không phản ứng nhanh thì có thể mang lại kết quả rất tồi tệ cho dự án và
cho tổ chức.


- Nhận biết khi nào bảng ký nhận của khách hàng (sign-off) là quan trọng cho việc
chấp thuận chất lượng sản phẩm làm ra:


 Nếu yêu cầu phải có ký nhận của khách hàng, thì phải đảm bảo rằng khách
hàng ký kết trước khi bắt đầu thực hiện dự án.


 Nếu giai đoạn đầu khơng u cầu ký nhận của khách hàng, thì hãy tiếp tục
thực hiện dự án, và sẽ thực hiện ký nhận khi kết thúc dự án.


- Kiểm định chất lượng



Hoạt động đầu tiên trong quá trình đảm bảo chất lượng là kiểm định chất lượng.
Kiểm định chất lượng là một cuộc kiểm tra độc lập do nhân sự có đủ trình độ chun mơn
thực hiện nhằm đảm bảo kế hoạch chất lượng được tuân thủ nghiêm ngặt.


- Kế hoạch kiểm thử (Testing plan)


Kế hoạch kiểm thử là một tài liệu mô tả phương thức kiểm thử theo cách: trường
hợp, tích hợp, hệ thống và chấp nhận.


Có nhiểu phương pháp kiểm thử. Các phương pháp thường được sử dụng trong các
dự án CNTT bao gồm:


 Kiểm thử biên dịch cho những dự án phát triển – Code hoạt động hay có lỗi?


</div>
<span class='text_page_counter'>(48)</span><div class='page_container' data-page=48>

 Kiểm thử vận hành hay còn gọi là kiểm thử hệ thống hoặc bàn giao (Release
to Production – RTP) – Phần mềm có chạy được trên mơi trường hệ thống hiện
tại khơng? Nó có tương thích và hoạt động tương tác được với các ứng dụng
chính khác khơng? Phần mềm có đáng tin cậy và có bảo trì được không?


Sau khi lựa chọn các phương pháp kiểm thử, cần thiết lập một môi trường kiểm thử
bằng cách xác định và mua những tài nguyên cần thiết để hồn thành q trình kiểm thử
đã được thiết lập.


Giai đoạn cuối cùng của quá trình kiểm thử là giai đoạn nhà tài trợ/khách hàng thực
hiện kiểm thử chấp nhận.


- Kiểm soát chất lượng dự án


Kiểm sốt chất lượng là q trình đánh giá các kết quả chất lượng cụ thể dựa trên
những tiêu chuẩn chất lượng và xác định cách nâng cao chất lượng, loại bỏ những nguyên


nhân làm chất lượng không đảm bảo, được thực hiện trong suốt qui trình kiểm sốt dự án.


Hiện nay, có rất nhiều cơng cụ được dùng trong kiểm soát chất lượng, bao gồm biểu
đồ (histogram), sơ đồ phân tán, và rất nhiều loại biểu đồ kiểm sốt khác nhau. Cơng cụ
thường dùng nhất là biểu đồ.


- Biểu đồ


Biểu đồ là công cụ quản lý chất lượng cho phép sắp xếp các giá trị đã được đo lường
riêng biệt thành một bộ dữ liệu theo tần suất thống kê(số lượng hoặc phần trăm) xuất hiện.
Chúng được dùng để theo dõi rất nhiều yếu tố ví dụ như tần suất thử nghiệm cho kết quả
lỗi. Biểu đồ này biểu diễn sự phân bố các giá trị như một biểu đồ thanh (bar chart), biểu đồ
cột (column bar). Chúng dễ dàng thể hiện phạm vi, giá trị trung bình và sự biến đổi của dữ
liệu.


Biểu đồ có thể được dùng để:


 Diễn tả sự phân bố dữ liệu


 Đành giá được cả dữ liệu thuộc tính (qua/khơng qua) và dữ liệu biến thiên (đo
lường)


 Xác định mức độ biến đổi của quá trình


</div>
<span class='text_page_counter'>(49)</span><div class='page_container' data-page=49>

- Phân tích Pareto (Pareto Analysis)


Lược đồ Pareto (Pareto diagram) là loại biểu đồ đặc biệt giúp xác định và đặt ưu
tiên cho những lãnh vực có thể xảy ra vấn đề của dự án theo mức độ nghiêm trọng của
chúng. Mức độ nghiêm trọng bao gồm:



 Tần suất xuất hiện của một vấn đề


 Chi phí cho vấn đề


 Mức giảm chất lượng do vấn đề gây ra


 Lượng thời gian bị mất do vấn đề gây ra


 Mức độ rủi ro do vấn đề gây ra (ví dụ như sức khỏe hoặc an toàn)


- Quy tắc Pareto (Pareto Rule)


Quy tắc Pareto còn được gọi la quy tắc 80-20 phát biểu rằng 80% số lỗi là do 20%
hạng mục gây ra. Phân tích Pareto giúp giám đốc dự án đương đầu với những lãnh vực hay
xảy ra vấn đề này một cách hiệu quả. Quy tắc này được rút ra từ kinh nghiệm, nghĩa là nó
khơng chính xác hồn tồn nhưng thay vào lại chuyển tải một thực tế rằng một số lượng
lớn các lỗi lại hay xảy ra ở một vài hạng mục.


Xây dựng một biểu đồ Pareto, cần làm theo các bước sau:


 Định nghĩa vấn đề


 Xác định các nguyên nhân có thể hoặc các hạng mục của nguyên nhân. Nhiều
đội dự án phải vận dụng trí tuệ để tìm ra nhiều ngun nhân nhất có thể.


 Xác định cách thức để định lượng cho mỗi nguyên nhân – chi phí, tần suất
xuất hiện, chất lượng ...


 Lập khoảng thời gian để nghiên cứu



 Thu thập dữ liệu cho mỗi nguyên nhân.


 Vẽ biểu đồ thanh biểu diễn các nguyên nhân. Mỗi thanh là một nguyên nhân
(hoặc hạng mục của nguyên nhân). Phía bên trái của biểu đồ là trục Y thể hiện
tổng số lần xuất hiện của mỗi nguyên nhân. Phía bên phải là trục X, thể hiện
số phần trăm theo xác suất xuất hiện của mỗi nguyên nhân. Các thanh được
sắp xếp trên trục X theo trật tự phần trăm giảm dần.


</div>
<span class='text_page_counter'>(50)</span><div class='page_container' data-page=50>

- Quản lý cấu hình


Quản lý cấu hình là một kỹ thuật kiểm sốt dùng để kiểm tra chính thức và phê
duyệt các thay đổi về cấu hình dựa vào đặc điểm của sản phẩm chuyển giao, cũng như các
thiết bị phần cứng, phần mềm để tạo ra sản phẩm và phiên bản. Những thay đổi về cấu hình
và phiên bản xảy ra thường xuyên trong môi trường CNTT, do vậy cần phải được kiểm tra
liên tục.


Mục đích chính của quản lý cấu hình là theo dõi và duy trì tính vẹn tồn của việc
tiến hóa các tài sản dự án. Trong suốt chu trình phát triển dự án, nhiều thành phẩm có giá
trị được tạo ra. Việc phát triển các thành phẩm này là kết quả lao động rất tích cực, nặng
nhọc, thể hiện một sự đầu tư nghiêm túc, đáng kể. Do đó, các thành phẩm cấu thành lên
các sản phẩm chuyển giao, hoặc là chính các sản phẩm chuyển giao là những tài sản quan
trọng cần được bảo vệ và sẵn sàng tái sử dụng.


Cụ thể, các thành phẩm quan trọng được đặt dưới kiểm sốt cấu hình. Khi một thành
phẩm xuất hiện, sẽ tồn tại nhiều phiên bản, cho nên cần phải nhận dạng thành phẩm, các
phiên bản của nó và cả lịch sử thay đổi của nó.


Các thành phẩm phụ thuộc lẫn nhau. Như một kết quả, mỗi thay đổi gây ra một hiệu
ứng lan truyền. Khi một thành phẩm bị thay đổi, các thành phẩm phụ thuộc cần được xem
lại, thay đổi hoặc làm lại. Từ đó cho thấy, phiên bản cuối cùng của một thành phẩm thường


là tốt nhất, đáp ứng được yêu cầu của nhà tài trợ, khách hàng.


- Định luật Parkinson


Định luật Parkinson phát biểu rằng công việc được dàn trải để sử dụng hết khoảng
thời gian dự tính hồn thành. Định luật này được ứng dụng vào nhiều lĩnh vực trong cuộc
sống, nhưng nó đặc biệt nhạy bén trong các ứng dụng CNTT với nhiều nhiệm vụ mới và
mất nhiều thời gian mới hoàn thành tốt được.


<b>2.5. Quản lý nguồn nhân lực </b>


Quản lý nhân lực: Là quá trình hướng dẫn, phối hợp những nỗ lực của mọi thành
viên tham gia dự án vào việc hoàn thành mục tiêu của dự án. Nó cho thấy việc sử dụng lực
lượng lao động của dự án hiệu quả đến đâu?


<b>2.5.1. Tầm quan trọng của quản lý nguồn nhân lực </b>


Con người quyết định sự thành công hay thất bại của tổ chức hay dự án


</div>
<span class='text_page_counter'>(51)</span><div class='page_container' data-page=51>

<b>2.5.2. Cơ cấu tổ chức nhân sự cho dự án </b>


Các dạng tổ chức là các cấu trúc mà thông qua đó một cơng ty tổ chức các hoạt động
hàng ngày để tối ưu hố hiệu quả. Có ba dạng tổ chức chính là theo chức năng, ma trận và
theo dự án. Chúng có những đặc điểm sau:


<b>Các dạng tổ chức Đặc điểm </b>


Cấu trúc chức năng Mỗi bộ phận chịu trách nhiệm thực hiện một tập hợp hoạt động cụ
thể, thường xuyên, và tương đối ổn định.



Nhiều người cùng thực hiện một dạng hoạt động.


Báo cáo theo thứ bậc, báo cáo của từng cá nhân với một nhà quản
lý riêng.


Chức năng của giám đốc dự án tương đối thấp so với chức năng
của các giám đốc chức năng.


Cấu trúc ma trận Các cá nhân vẫn báo cáo lên trên theo thứ bậc về chức năng,
nhưng họ cũng báo cáo theo chiều rộng với từ một giám đốc dự
án trở lên.


Trong một số tổ chức, sơ đồ báo cáo theo ma trận này có thể là
hình thức tồn tại lâu dài.


Trong một dự án có cấu trúc ma trận thì ma trận chỉ là tạm thời
Cấu trúc ma trận có thể được mô tả như hội tụ yếu, cân bằng hay
hội tụ mạnh phụ thuộc vào chức năng tương đối của giám đốc dự
án so với giám đốc chức năng


Cấu trúc theo dự
án


Hay “dự án thuần
tuý”


Giám đốc dự án và đội dự án nòng cốt hoạt động như một đơn vị
tổ chức hoàn toàn độc lập với tổ chức mẹ (tổ chức truyền thống)
Trong một số tổ chức, cấu trúc dự án thuần tuý có thể bao gồm
những hệ thống tự hỗ trợ, chẳng hạn như một phòng nhân sự hay


phòng thu mua riêng. Trong các tổ chức khác, cấu trúc dự án thuần
tuý lại chia sẻ hệ thống hỗ trợ này với tổ chức mẹ.


</div>
<span class='text_page_counter'>(52)</span><div class='page_container' data-page=52>

<b>Hình 2.12: Chức năng cơ bản của giám đốc dự án </b>


<b>2.5.3. Vai trò của từng thành viên </b>


Biểu đồ tổ chức minh họa cấu trúc tổ chức của dự án. Mục đích của nó là chỉ ra mối
quan hệ chỉ đạo, quản lý và báo cáo trong dự án và mối quan hệ của dự án đối với tổ chức
me.


Một vài tổ chức sử dụng một cấu trúc tổ chức phân cấp chi tiết (OBS) để minh họa
tổ chức theo chức năng chịu trách nhiệm đối với các dạng công việc khác nhau trong dự
án.Công bố cấu trúc OBS sớm trong dự án là rất có lợi. Thứ nhất, OBS chưa phù hợp sẽ
làm xuất hiện những mâu thuẩn hay lầm lẫn về những vai trò trong dự án. Thứ hai, tạo
động lực thúc đẩy tinh thần trách nhiệm của các thành viên dự án khi OBS phù hợp.


Các đối tượng liên quan dự án là người:


 Có lợi ích nghiệp vụ trong kết quả của dự án


 Liên quan trực tiếp tới dự án


 Hoặc đóng góp các nguồn lực cho dự án
Các đối tượng liên


quan dự án


Đặc điểm



Nhà tài trợ Chịu trách nhiệm cuối cùng đối với sự thành công của dự án
Ký kết hoàn tất các tài liệu lập kế hoạch và các yêu cầu thay đổi
Cho phép đội dự án sử dụng các nguồn lực


Giám đốc chức năng <sub>Giám đốc dự án </sub>


Cấu trúc
chức năng


Cấu trúc ma
trận yếu


Cấu trúc ma
trận cân bằng


Cấu trúc ma
trận mạnh


Cấu trúc
theo dự án


C


hức




ng


tươn



</div>
<span class='text_page_counter'>(53)</span><div class='page_container' data-page=53>

Bảo vệ và cố vấn cho đội quản lý dự án


Cắt băng khởi công, cũng như khánh thành dự án và và tiến hành
hoạt động


Ký và công bố tôn chỉ dự án.


Nếu nhà tài trợ không phải là người trong công ty, chẳng hạn như
là một khách hàng thì trách nhiệm của giám đốc dự án bao gồm
một số trách nhiệm khác.


Khách hàng Nhận đầu ra dự án


Thanh toán cho đầu ra dự án


Xác định nhu cầu đối với sản pharm kết quả của dự án


Có thể là nhiều cơng ty hay cá nhân với những đặc điểm và yêu
cầu trái ngược nhau.


Giám đốc chức
năng


Các nhà quản lý chịu ảnh hưởng bởi hoạt động hay kết quả của dự
án


Kiểm soát và các đóng góp nguồn lực cho dự án (con người, trang
thiết bị…)



Có thể có những yêu cầu trái ngược nhau về kết quả dự án
Có thể tính đến cả cấp trên của Giám đốc dự án


Giám đốc dự án Làm việc với các đối tượng liên quan dự án để định nghĩa dự án.
Lập kế hoạch, sắp xếp lịch trình và dự thảo ngân sách các hoạt
động của dự án với đội ngũ ban đầu.


Cùng làm việc với đội để thực thi kế hoạch


Giám sát hiệu quả hoạt động và thực hiện các hoạt động hiệu chính
Thường xuyên báo báo cho các nhà tài trợ và các đối tượng liên
quan dự án


Đưa ra yêu cầu và trình bày những thay đổi về phạm vi


Đóng vai trị như một người trung gian giữa đội dự án và các đối
tượng liêu quan dự án khác.


Đội ngũ thành viên
dự án


Phân công dựa trên năng lực điều chỉnh, kỹ năng theo các hoạt
động của dự án cụ thể của họ


Có thể tính đến các tài ngun bên trong và bên ngoài


</div>
<span class='text_page_counter'>(54)</span><div class='page_container' data-page=54>

<b>2.5.4. Tuyển đội ngũ nhân sự </b>


Để tổ chức đội dự án, hãy làm theo các bước sau:



- Xác định được cơ cấu đội dự án phù hợp với tổ chức và các phương pháp để tập hợp
được các thành viên dự án như mong muốn.


- Đánh giá được năng lực kỹ thuật và kỹ năng làm việc theo nhóm của các thành viên
nịng cốt của đội dự án, cũng như các thành viên cấp ủy nhiệm.


- Chọn và tuyển các thành viên dự án.


- Giải quyết các vấn đề và sự thiếu hụt về nguồn nhân lực có kỹ năng cần thiết bằng
cách đàm phán để có được nguồn nhân lực khan hiếm, dựa vào tình huống nghiệp
vụ và ưu tiên chiến lược của dự án:


 Xem nguồn nhân lực mà dự án yêu cầu có ảnh hưởng đến đường tới hạn (
đường găng ) hay không?


 Đàm phán với các đơn vị chức năng hoặc các Giám đốc dự án khác để có được
nguồn lực cần thiết.


 Chuẩn bị tinh thần để hủy dự án nếu khơng tìm được hoặc khơng đạt được
thỏa thuận để đảm bảo chi trả được cho các nguồn nhân lực có kỹ năng cần
thiết.


- Lập ma trận trách nhiệm ( Responsibility Matrix )


- Điều hòa giữa việc phân bổ nguồn lực với ngân sách và lịch trình dự án, đồng thời
phải phát hiện được tất cả những sự không nhất quán trong dự án


Giám đốc dự án phải thể hiện được cả kỹ năng quản lý và kỹ năng lãnh đạo.
- Lãnh đạo là nghệ thuật tác động đến người khác để họ có ý muốn làm một cơng việc



nào đó mà bạn nghĩ là nên làm. Giám đốc dự án thường hướng dẫn đội dự án làm
việc theo cách mà đội dự án có thể đạt được mục đích. Điều này bao gồm cả kỳ
vọng về kết quả cuối cùng, một lý do thuyết phục để dự án đạt được mục đích. Một
lịch trình rõ ràng, và những người có khả năng hồn thành tốt nhiệm vụ. Lãnh đạo
khơng có nghĩa là dựa vào quyền lực được ban hành, mà phải dựa trên khả năng tác
động người khác thực hiện công việc.


- Công tác quản lý bắt đầu từ việc lập kế hoạch cho đến tổ chức, vận hành, giám sát
và điều khiển để hồn thành cơng việc của dự án. Quyền quản lý bắt nguồn từ vị trí
chính thức trong đội dự án và trong tổ chức.


</div>
<span class='text_page_counter'>(55)</span><div class='page_container' data-page=55>

hiệu quả trên những nấc thang đi đến thành cơng, cịn kỹ năng lãnh đạo sẽ xác định xem
chiếc thang đó có được đặt ở đúng tường hay không?”


Hậu cần cho đội dự án:


- Công tác cung ứng cho đội dự án chính là việc cung cấp đồ dùng, trang thiết bị cần
thiết cho đội dự án hoàn thành nhiệm vụ. Bao gồm:


 Các đồ dùng cần thiết cho dự án và các kết quả bàn giao của dự án


 Trang thiết bị cho đội dự án chủ yếu là các trang thiết bị văn phịng bao gồm
khơng gian làm việc, bàn, điện thoại, máy vi tính, máy chủ, phần mềm và điện


 Thiết bị liên lạc cho các thành viên không làm việc ở một nơi cố định


 Thiết bị phần mềm và phần cứng để thiết lập môi trường kiểm thứ


 Những trang thiết bị cần thiết để phục vụ chuyến công tác, bao gồm cả việc di
chuyển, thuê phòng và các khoản khác



<b>2.6. Quản lý rủi ro </b>


<b>2.6.1. Khái niệm quản lý rủi ro </b>


Quản lý rủi ro: Là việc nhận diện các nhân tố rủi ro trong dự án, sử dụng các phương
pháp định tính, định lượng để xác đinh tính chất, mức độ rủi ro và có kế hoạch đối phó
cũng như quản lý từng loại rủi ro.


<b>2.6.2. Quy trình quản lý rủi ro </b>


Một từ điển đã định nghĩa về rủi ro là “sự mất mát hoặc sự bỏ lỡ một cơ hội”
Rủi ro dự án liên quan tới sự thấu hiểu những vấn đề tiềm tàng ở phía trước có thể
xuất hiện trong dự án mà chúng sẽ cản trở sự thành công của dự án.


Mục đích của việc quản lý rủi ro dự án là giảm tối thiểu khả năng rủi ro trong khi
đó tăng tối đa những cơ hội tiềm năng.


</div>
<span class='text_page_counter'>(56)</span><div class='page_container' data-page=56>

<b>2.6.2.1. Nhận biết rủi ro </b>
- Các tình huống rủi ro chung


 Nhân viên kỹ thuật khơng thích hợp.


Thiếu huấn luyện và kinh nghiệm về phần cứng, hệ điều hành, bộ trình phần mềm
hay lĩnh vực ứng dụng đều đặt ra rủi ro. Thiếu kinh nghiệm trong công việc của nhóm gây
ra vấn đề về trao đổi. Những yêu cầu của khách hàng về an toàn, pháp lý, quy tắc thanh
toán quá đáng cũng làm cho người của bạn khơng đáp ứng nổi.


Ví dụ: Có một dự án gặp phải khó khăn khi một người mới nhập cư được nhận làm
lập trình viên cho dự án Bộ Quốc phòng. Bởi lý do an ninh việc lập trình phải được thực


hiện tại máy của khách. Và việc lập trình bắt đầu, người ta mới phát hiện ra là anh ta không
được phép vào trụ sở của khách; anh ta chưa có đủ yêu cầu để được làm việc ở đó. Phải
mất một thời gian 6 tháng mới có thể hồn tất các thủ tục giấy tờ về an ninh.


 Môi trường làm việc không sát hợp.


Môi trường lập trình cần n tĩnh ấy và khơng bị quấy rối. Cần đặc biệt lưu ý nếu
việc lập trình phải thực hiện tại cơ quan khách. Nói chung cần có máy tính chạy nhanh,
trình biên dịch thích hợp và phần mềm phát triển tốt.


 Tài nguyên do bên thứ ba cung cấp.


Nếu có việc gì đó do một bên cung cấp mà ta khơng kiểm sốt được họ, thì ta đang
ở cạnh một rủi ro. Ta cố gắng thu được quyền kiểm soát đối với các bên đó. Điều này có
thể được thực hiện bằng các điều khoản phạt trong hợp đồngvới nhà cung cấp đưa thêm
các yêu cầu vào cuộc họp giam sát hiệu năng của các nhân viên.


 Rút ngắn dự án.


Ta có thể làm cho dự án được hoàn thành sớm hơn hoặc nếu ta có nhiều người, mọi
người đều làm thêm giờ và có máy tính lớn. Nhưng chi phí đó cũng phải lên gấp đơi!


 Việc thanh tốn ngân sách không xác định.


Nếu người dùng cần được chấp thuận ngân quỹ theo từng quý thì bạn đướng trước
khả năng bị cắt xén cho mỗi quý. Nếu người dùng thanh tốn theo cột mốc được bàn giao,
thì bạn phải tranh cãi về việc chấp nhận và thanh toán theo từng cột mốc. Nếu bạn đang
dùng tiến trình đề nghị hai bước thì việc phân tích có thể ngốn hết ngân quỹ của người
dùng.



- Tình huống rủi ro tài chính


</div>
<span class='text_page_counter'>(57)</span><div class='page_container' data-page=57>

Việc chấp nhận, đặc biệt việc cho chạy song song có thể tiếp diễn vơ hạn. Việc thiếu huấn
luyện nhóm, các yêu cầu về tài liệu quá mức hay các chuẩn bất thường cũng có thể gây ra
vấn đề.


 Việc quản lý dự án kiểu phân bố khơng có hiệu quả.


Tốt nhất là mọi thành viên của nhóm dự án, cũng như khách hàng đều trong cùng
miền địa lý, nếu không sẽ rất tốn kém cho đi lại.


 Quản lý q sốt sắng có thể lại “khơng quản lý kỹ” được dự án.


Hãy giữ các tài liệu ở mức tối thiểu. Mọi người có thể nghĩ cách tốt hơn để báo cáo
lại hoạt động của mình. Hãy xác định một tập nhỏ các tài liệu chuẩn rồi dùng chúng. Giữ
các cuộc họp ở mức tối thiểu. Bạn hãy dùng điện thoại và bản ghi nhớ để liên lạc mọi lúc
có thể. Đừng làm ảnh hưởng tới các nhân viên.


 Rủi ro còn xảy ra khi cả người dùng không thể và không có quyền trả lời các
câu hỏi nhanh chóng.


Có dự án (đối với một cơ quan lớn của chính phủ) mà câu trả lời cho những câu hỏi
có liên quan tới mọi yêu cầu phải do một uỷ ban của người dùng quyết định, mà uỷ ban
này mỗi tháng họp một lần. Người ta ước lượng để xác định yêu cầu cần ít nhất hai tuần
nhưng thực tế một tháng mới hồn tất.


- Tình huống rủi ro kỹ thuật


Cịn có các nhân tố kỹ thuật ảnh gây ra lỗi hay việc kém hiệu năng.



 Giải pháp sai.


Bạn có xây dựng hệ thống hướng dẫn tên lửa bằng cách dùng BASIC vì đó là ngơn
ngữ của bạn biết tường tận nhất khơng?. Bạn có định đưa một hệ thống quản lý kho lớn
vào trong một máy tính cá nhân nhỏ khơng? Máy tính của ban đã dùng hết 98% tài nguyên
mà bạn định đưa hệ thống kế toán cho 10 000 người bán hàng vào trong 2% cịn lại? Cần
phải đảm bảo máy tính phát triển và máy tính vận hành tương hợp nhau và đều có sẵn khi
cần đến, cả phần cứng lẫn phần mềm đều được sản xuất bảo đảm. Phải đặc biệt cẩn thận
trong mơi trường có nhiều nhà cung cấp.


 u cầu/đặc tả tồi.


Nếu có điều gì còn chưa rõ hay mơ hồ, hay nếu người dùng không thể trao cho bạn
các yêu cầu chắc chắn thì những thay đổi nhất đinh sẽ xuất hiện trong hoặc sau khi phát
triển. Thay đổi có thể rất tốn kém cho việc thực hiện và bạn không thể được thanh tốn để
làm việc đó. Cần phải làm việc phân tích dự án kỹ trong trường hợp này.


 Không hiểu biết về người dùng.


</div>
<span class='text_page_counter'>(58)</span><div class='page_container' data-page=58>

máy tính mà khách hàng xác định cho giao diện con người cần phải được biết rõ. Tính an
tồn, thủ tục, quy tắc và hướng dẫn kiểm tốn có thể buộc việc thiết kế cho một hệ thống
phải theo một kiểu đặc biệt.


 Độ dung sai mất mát dữ liệu sẽ xác định ra các thủ tục sao lưu.


Một số cửa hàng có thể khơi phục lại dữ liệu một tuần trước đó. Số khác khơng thể
dung thứ cho bất kỳ mất mát nào, cho nên việc ghi lại các giao dịch hay sao đúp các tệp
cần phải được thiết kế cho hệ thống.





Điều mang tính rủi ro rất cao là ghi rõ các con số về thời gian đáp ứng, khối lượng
dữ liệu và hiệu năng vào trong hợp đồng. Đã có tình huống một người hợp đồng hứa hẹn
mọi thời gian đáp ứng vượt quá 5 giây và anh ta từ chối thanh toán cho hệ thống. Nếu buộc
phải đề cập đến vấn đề thời gian đáp ứng trong hợp đồng (và phần lớn đều có điều khoản
này) thì hãy dùng những lời như “95% thời gian đáp ứng ..” , hay “Chúng tôi sẽ thiết kế
hướng theo không quá 5 giây”. Chúng ta làm hết sức mình nhưng chúng ta khơng đảm bảo.


Ngẫu nhiên, rủi ro kỹ thuật lại là ít nhất. Điều này khơng có gì đáng ngạc nhiên vì
chúng ta có khuynh hướng có nhiều nhà kỹ thuật giỏi trong lĩnh vực này. Thách đố rủi ro.
Hãy tự hỏi bạn các câu hỏi về rủi ro sau trả lời có hay thậm chí có phần nào đó, cho bất kỳ
câu hỏi nào thì tức nhận rủi ro. Danh sách được chia thành 3 phần: rủi ro thấp, rủi ro trung
bình, rủi ro cao.


<b>2.6.2.2. Phân tích rủi ro theo định tính </b>


Rủi ro là thước đo tình trạng khơng chắc chắn. Nó gồm 3 thành phần:
- Bản thân sự kiện rủi ro


- Thước đo khả năng có thể mà sự kiện rủi ro đó xẩy ra.


- Ảnh hưởng hay tính nghiêm trọng của sự kiện rủi ro đó vào dự án.


Phân tích định tính là việc mơ tả tác động của mỗi loại rủi ro và sắp xếp chúng vào
từng nhóm mức đọ: rủi ra cao, trung bình, thấp. Mục đích của phân tích định tính là nhằm
đánh giá tổng thể xem rủi ro tác động đến những bộ phận nào và mức độ ảnh hưởng của
nó đến từng bộ phận và toàn bộ dự án.


Đối với những dự án đơn gián có thể chỉ áp dụng phương pháp định tính để xác định
rủi ro.



</div>
<span class='text_page_counter'>(59)</span><div class='page_container' data-page=59>

<b>2.6.2.3. Phân tích định lượng rủi ro </b>


Phân tích định lượng là việc sử dụng các phương pháp toán, thống kê và tin học để
ước lượng rủi ro về chi phí, thời gian, nguồn lực và mức độ bất định. Một số công cụ
thường sử dụng để lượng hóa rủi ro như phân tích mạng, phân tích xác suất, phương pháp
đồ thị, phân tích quan hệ.


Phân tích rủi ro định lượng (QRA). Việc này có thể dự đốn, xác định và cuối cùng
có thể loại bỏ các nguy cơ liên quan đến sản phẩm.


Quy trình đánh giá rủi ro như một số lượng chính xác, đánh giá xác suất của biến cố
bất lợi xảy ra và mức độ nghiêm trọng bằng việc cân nhắc nguy cơ của sản phẩm. Lý tưởng
nhất, việc phân tích được thực hiện trước khi một sản phẩm mới được phép đưa vào sản
xuất.


Phân tích rủi ro định lượng (QRA) là một mơ hình thống kê mơ phỏng một rủi ro
như một biến cố.


Lợi ích từ việc Phân tích đánh giá định lượng (QRA)


- Ước tính rủi ro tiềm năng của một sản phẩm từ giai đoạn thiết kế
- Xác minh rằng thiết kế kết hợp với một mức độ an toàn cho phép


- Cung cấp một cơ sở vững chắc cho việc quản lý quyết đinh go/no-go đối với việc
phát triển và sản xuất.


Đánh giá rủi ro định lượng: bao gồm các bước sau:


- Xây dựng phương pháp luận và thiết lập các thông số giả định


- Nhận diện mối nguy


- Tai nạn / Sự cố lớn (Phát triển kịch bản) (nếu có)
- Ước tính tần số


- Mơ hình hóa hậu quả
- Ước tính tử vong (nếu có)
- Tổng kết và xếp hạng rủi ro
- Đánh giá rủi ro


- Gửi dự thảo báo cáo đánh giá rủi ro cho khách hàng (khi cần thiết)


<b>2.6.2.4. Kế hoạch đối phó rủi ro </b>


</div>
<span class='text_page_counter'>(60)</span><div class='page_container' data-page=60>

- Kế hoạch dự phịng (đối phó những bất ngờ) là những hoạt động xác định trước mà
thành viên của dự án sẽ thực hiện nếu một sự kiện rủi ro xuất hiện


- Kế hoạch rút lui được thực hiện cho những rủi ro có tác động lớn tới những yêu cầu
mục tiêu của dự án


- Quỹ dự phòng (bất ngờ) hay tiền trợ cấp được giữ bởi nhà tài trợ và có thể dùng
giảm nhẹ chi phí hay rủi ro lịch biểu nếu có những sự thay đổi về phạm vi hay chất
lượng.


Xây dựng kế hoạch quản lý rủi ro bao gồm một số bước sau:


- Xác định chiến lược và phương pháp quản lý rủi ro bằng các phương pháp định
lượng và định tính, cũng như các kế hoạch xếp loại.


- Lập kế hoạch dự phòng bằng cách xác định các phương pháp đối phó và các chiến


lược giảm thiểu, đồng thời xây dựng một bản kế hoạch dựa trên tình huống, tích hợp
các biện pháp đối phó và các chiến lược giảm thiểu thành một tổng thể toàn diện.
- Lập kế hoạch quản lý rủi ro trên đường tới hạn bằng cách xác định bản chất đặc


trưng và tầm quan trọng của các rủi ro đối với đường tới hạn.


- Định nghĩa các dấu hiệu rủi ro làm dấu hiệu cảnh báo sớm khi có thể và để nhận
biết rủi ro.


- Chỉ định người chịu trách nhiệm cho một rủi ro hoặc mối đe dọa nhất định. Định ra
những dấu hiệu rủi ro mà họ cần giám sát và các biện pháp đối phó mà họ cần thực
hiện.


- Lập quỹ dự phòng rủi ro (contingency reserve) nhằm hỗ trợ cho kế hoạch.
- Lập quy trình cập nhật kế hoạch trong suốt vòng đời của dự án


<b>2.6.2.5. Giám sát và kiểm soát rủi ro </b>


- Giám sát và kiểm sốt rủi ro liên quan tới việc hiểu biết tình trạng của chúng.
- Kiểm soát rủi ro liên quan đến việc thực hiện kế hoạch quản lý rủi ro khi chúng xảy


ra


- Kết quả chính của việc giám sát và kiểm sốt rủi ro là điều chỉnh hoạt động, yêu cầu
thay đổi dự án, cập nhật những kế hoạch mới.


- Kiểm sốt đối phó rủi ro liên quan đến việc chấp hành những quy trình quản lý rủi
ro và kế hoạch rủi ro để đối phó với những sự kiện rủi ro.


</div>
<span class='text_page_counter'>(61)</span><div class='page_container' data-page=61>

<b>2.6.3. Kỹ thuật để quản lý rủi ro </b>


7 bước trong quy trình quản trị rủi ro
- Thiết lập bối cảnh


Bây giờ, đây là bước đầu tiên và quan trọng nhất của quy trình quản trị rủi ro. Trong
bước này, việc thiết lập bối cảnh được thực hiện. Điều này bao gồm những thứ như lập kế
hoạch cho phần cịn lại của q trình.


Tiếp theo là việc xác định các mục tiêu của các bên liên quan. Trên cơ sở này, các
rủi ro sẽ được đánh giá. Sau đó, một khung được xác định cho tồn bộ q trình và sau đó
sẽ thiết lập một chương trình nghị sự cho cả quảng cáo nhận dạng để phân tích kế hoạch.


- Xác định các rủi ro hoặc các mối đe dọa


Khi bối cảnh được thiết lập, bước tiếp theo của quy trình quản trị rủi ro để có thể
xác định được các rủi ro tiềm ẩn. Rủi ro là những sự kiện khơng lường trước có thể gây ra
một số vấn đề khi chúng được kích hoạt. Do đó, cách tiếp cận cơ bản để bắt đầu xác định
rủi ro là xác định nguồn chính của vấn đề.


Điều cơ bản nhất cần có để xác định rủi ro là kiến thức về tổ chức mà quy trình quản
trị rủi ro đang được thực hiện. Chúng ta nên biết thực tế là các loại môi trường mà thị
trường thường thực hiện là gì và cũng như cách nó hoạt động trong các môi trường khác
nhau này.


Những mơi trường này có thể là pháp lý xã hội, kinh tế, khí hậu, chính trị, v.v. họ
cũng nên nhận thức rõ về những điểm mạnh và điểm yếu khác nhau của tổ chức.


Cùng với đó, họ nên biết về lỗ hổng có tổn thất ngồi dự kiến, quy trình sản xuất,
hệ thống quản lý và cơ chế kinh doanh mà nó hoạt động. Người ta phải rất chính xác trong
khi phân tích rủi ro ở đây; nếu khơng, nó có thể gây ra tổn thất đáng kể cho tổ chức.



Theo cách này, nền tảng của quản trị rủi ro được xây dựng trên cơ sở xác định rủi
ro.


- Đánh giá rủi ro


Khi các rủi ro được xác định, chúng được đánh giá dựa trên mức độ nghiêm trọng
tiềm tàng của tổn thất và số lần chúng xảy ra, đó là xác suất xảy ra. Trong quá trình này,
phỏng đốn được thực hiện theo cách tốt nhất có thể.


Khó khăn chính trong đánh giá rủi ro là khơng có thơng tin thống kê về tỷ lệ xảy ra
rủi ro trong tất cả các loại sự cố trong quá khứ. Đánh giá rủi ro có thể tạo ra loại dữ liệu đó
để dễ hiểu các rủi ro chính.


- Xử lý rủi ro tiềm năng


</div>
<span class='text_page_counter'>(62)</span><div class='page_container' data-page=62>

- Chuyển giao rủi ro


Trong trường hợp này, bên dự kiến sẽ chuyển toàn bộ hoặc một phần tổn thất của
rủi ro rủi ro sang một phần khác với chi phí xác định. Ở đây những điều liên quan đến hợp
đồng cá nhân là những rủi ro chuyển giao. Ngồi ra, có nhiều kỹ thuật khác mà việc chuyển
rủi ro có thể diễn ra.


- Tránh rủi ro


Tránh các rủi ro hoặc bỏ qua các trường hợp có thể dẫn đến một loại tổn thất
khác. Điều này có thể bao gồm các khía cạnh như không thực hiện một hoạt động cụ thể
có thể mang lại rủi ro nhất định. Bây giờ trong khi tránh rủi ro nhìn chung khá an tồn,
nhưng đôi khi, điều này cũng có thể có nghĩa là người ta đang mất đi lợi nhuận tiềm
năng. Vì vậy, những người chọn không tham gia kinh doanh chỉ để họ không phải đối mặt
với bất kỳ rủi ro nào có nghĩa là họ cũng đang tránh các cơ hội kiếm được nhiều lợi nhuận


từ nó.


- Duy trì rủi ro


Điều này ngụ ý rằng những tổn thất đã tăng do rủi ro phải được giữ lại. Hoặc họ
cũng có thể được giả định bởi tổ chức hoặc thực thể kinh doanh. Nó thường được gọi là
một quyết định có chủ ý cho bất kỳ thực thể nào có một loại đặc điểm cụ thể. Về cơ bản có
hai phương pháp khác nhau được sử dụng để duy trì; đây là những bảo hiểm bị giam cầm
và thứ hai là tự bảo hiểm.


- Kiểm soát rủi ro


Kiểm soát rủi ro có thể được thực hiện theo nhiều cách. Người ta có thể tránh các
rủi ro hoặc có thể cố gắng kiểm sốt tổn thất nhiều nhất có thể.


- Tạo kế hoạch


Để tạo một kế hoạch, điều đầu tiên người ta cần làm là quyết định sự kết hợp các
phương pháp khác nhau có thể được sử dụng cho mọi rủi ro riêng lẻ. Mỗi quyết định được
thực hiện với mục tiêu quản trị rủi ro cần được ghi lại chính xác và hết sức cẩn thận. Sau
đó, nó sẽ nhận được sự chấp thuận từ cấp độ thích hợp của ban quản lý.


Một kế hoạch tốt nên có kiểm sốt an ninh có thể áp dụng cũng như hiệu quả. Nó
nên chứa một lịch trình để thực hiện kế hoạch và những người chịu trách nhiệm thực hiện
một phần cụ thể của kế hoạch. Người ta phải đảm bảo rằng kế hoạch quản trị rủi ro được
đo lường hiệu quả.


- Thực hiện kế hoạch quản trị rủi ro


</div>
<span class='text_page_counter'>(63)</span><div class='page_container' data-page=63>

Bằng cách này, hầu như tất cả các rủi ro có thể tránh được mà không cần phải hy sinh bất


kỳ mục tiêu nào của thực thể hoặc giảm bớt các mục tiêu của người khác.


- Xem xét và đánh giá kế hoạch


Hiếm khi thấy rằng các kế hoạch quản trị rủi ro là hoàn hảo. Trong khi kế hoạch
đang được thực hiện, ln có thể thực hiện các thay đổi cần thiết trong kế hoạch trên cơ sở
thực tiễn, tổn thất và kinh nghiệm.


Ngồi ra, thơng tin thu được giúp đưa ra nhiều quyết định khác để trong tương lai
rủi ro có thể được xử lý theo những cách tốt hơn nhiều.


Người ta phải đảm bảo rằng tất cả các quy trình này được thực hiện chính xác nhất
để có kết quả tốt nhất và sau đó đưa ra quyết định có thể bảo vệ họ khỏi mọi rủi ro hoặc
mối đe dọa đối với tổ chức hoặc tổ chức kinh doanh.


<b>2.6.4. Phần mềm quản lý rủi ro </b>


Enforce Risk Management là phần mềm tự động chủ động xác định, phân loại và
xử lý các dữ liệu cá nhân, nhạy cảm trong toàn doanh nghiệp. Đây là giải pháp đưa ra cái
nhìn sâu sắc và kiểm sốt tồn bộ các dữ liệu đi qua các thiết bị Endpoint bao gồm cả có
cấu trúc và phi cấu trúc. Điều này cho phép doanh nghiệp quản lý dữ liệu một cách thông
minh, đảm bảo tuân thủ bảo mật và giảm thiểu rủi ro về dữ liệu.


5 phần mềm quản lý công việc và dự án phổ biến nhất hiện nay:


- Trello là phần mềm quản lý dự án được xây dựng dựa trên phương pháp Kanban.
Giao diện của Trello là một bảng thông tin, trực quan hố cơng việc với các cột
tương ứng với trạng thái (ví dụ: To do, Doing và Done). Với thiết kế tối giản và
cách sử dụng đơn giản, bạn có thể dễ dàng theo dõi luồng cơng việc, phân công
nhiệm vụ, cộng tác trên Trello, chỉ với thao tác kéo và thả đơn giản.



- Asana là phần mềm quản lý dự án cơ bản giúp theo dõi dự án, công việc, thời gian,
nguồn lực, tất cả chỉ với một giao diện đơn giản. Có thể xem tổng quan hoặc chi tiết
dự án, hoặc theo dõi công việc linh hoạt thông qua bảng Kanban hoặc
To-do-list... Asana là một phần mềm đáp ứng khá đầy đủ nhu cầu của một nhà quản lý
muốn kiểm soát khối lượng công việc đồ sộ của công ty.


- Wrike cũng là một giải pháp quản lý dự án mạnh mẽ. Nếu như Asana giúp bạn làm
việc khơng cần email, thì Wrike thay thế khơng chỉ email mà cịn hầu hết cơng cụ
làm việc khác. Theo đánh giá của Business News Daily, Wrike được bình chọn là
lựa chọn hàng đầu cho giải pháp quản lý dự án miễn phí. Đây là một giải pháp tuyệt
vời cho những team nhỏ hoặc các start-up khơng có nhiều kinh phí.


</div>
<span class='text_page_counter'>(64)</span><div class='page_container' data-page=64>

bản sản phẩm nâng cấp được phát hành liên tục dựa theo phản hồi của khách hàng).
Các nhóm phần mềm có thể sử dụng Jira để lên kế hoạch, theo dõi, phát hành, báo
cáo phần mềm mới hoặc phần mềm nâng cấp. Họ cũng có thể sử dụng Jira để theo
dõi bất kỳ vấn đề nào trong quá trình phát triển và hoàn thiện sản phẩm.


- Wework là một phần mềm quản lý công việc được phát triển tại Việt Nam, với các
tính năng cộng tác, lập kế hoạch, báo cáo khá đầy đủ, khơng thua kém gì các giải
pháp quản lý dự án quốc tế.


<b>Bài tập </b>


Sinh viên trong lớp chia thành nhiều nhóm. Mỗi nhóm tự chọn đề tài cho nhóm. Các
đề tài không được giống nhau. Yêu cầu:


Hãy xây dựng tôn chỉ của dự án
Hãy xây dựng WBS cho dự án



Hãy xác định danh sách các hoạt động
Hãy xây dựng quy trình kiểm sốt thời gian
Hãy ước lượng chi phí cho dự án


</div>
<span class='text_page_counter'>(65)</span><div class='page_container' data-page=65>

<b>CHƯƠNG 3: THỰC HIỆN VÀ KẾT THÚC DỰ ÁN </b>


<b>Giới thiệu: </b>


Nội dung bài này trình bày những vấn đề cơ bản về điều khiển và giám sát dự án,
làm sao để phát hiện các vấn đề, hiệu chỉnh nó và thực hiện kết thúc dự án.


<b>Mục tiêu: </b>


Triển khai dự án và quản lý việc đóng dự án.
<b>Nội dung chính: </b>


<b>3.1. Điều khiển và kiểm sốt dự án </b>
Giám sát và duy trì


Các kỹ năng quan trọng để quản lý quá trình thực hiện dự án chính là chủ động giám
sát các thành phần cơ bản của dự án và quản lý thời gian thật chặt chẽ. Thông tin về các
thành phần cơ bản của dự án rất khó tưởng tượng khi ngồi một chỗ mà bạn phải đi, quan
sát, hỏi han và kiểm tra.


</div>
<span class='text_page_counter'>(66)</span><div class='page_container' data-page=66>

<b>Hình. 3.1: Giám sát và duy trì dự án </b>


































Hình 2-8. Giám sát và duy trì d ự án



V ạ ch ra ph ư ng h ướ ng
hành độ ng
Xác đị nh các d ấ u hi ệ u


r ủ i ro


Ti ế n hành
L ậ p l ạ i k ế
ho ạ ch d ự án


B ắ t đầ u các hành độ ng
hi ệ u ch ỉ nh để l ậ p l ạ i


k ế ho ạ ch


Các ng ưỡ ng gi ớ i h ạ n b ị
v ượ t


Đặt ra các tiêu chí
đánh giá và giám sát


Xác định các dấu
hiệu rủi ro


Các ngưỡng giới
hạn bị vượt


Lập lại
KH dự án



Vạch ra phương
hướng hành động
Bắt đầu các hành


động hiệu chỉnh để
lập lại kế hoạch


</div>
<span class='text_page_counter'>(67)</span><div class='page_container' data-page=67>

Giám sát một cách đều đặn


Để giám sát dự án, hãy thực hiện các bước sau:
Luôn chủ động giám sát dự án


Vạch ra chiến lược duy trì và giám sát sự hỗ trợ của các cổ đông và nhà tài trợ để
đảm bảo rằng nhà tài trợ và các cổ đông vẫn đang chia sẻ trách nhiệm của dự án.


Vạch ra chiến lược duy trì và theo dõi các kênh truyền thông để chắc chắn rằng phần
nội dung, các kênh và tần suất được đặt ra trước đó vẫn đang hoạt động.


Vạch ra chiến lược duy trì và giám sát các quy trình kiểm sốt để đảm bảo phạm vi
dự án không bị mở rộng so với lịch trình, cũng như kinh phí.


Vạch ra chiến lược duy trì và giám sát các phưng pháp và tiêu chuẩn đưa ra trong
kế hoạch chất lượng của dự án để đảm bảo rằng dự án vẫn đang tuân thủ các phưng pháp
và tiêu chuẩn đặt ra. Phân công cho các thành viên dự án chịu trách nhiệm về từng phương
pháp và tiêu chuẩn, sau đó kiểm tra sự tuân thủ các phương pháp và tiêu chuẩn đó.


Vạch ra chiến lược duy trì và giám sát việc tuân thủ các nguyên tắc và tiêu chuẩn
của ngành. Nếu cần thiết, hay nhờ sự trợ giúp của ban pháp luật. Các nhóm chuyên môn
thường đưa ra nguồn thông tin khác về các tiêu chuẩn của ngành.



<b>3.1.1. Giám sát dự án </b>


<b>3.1.1.1. Giám sát từ ban chỉ đạo dự án </b>


Ban chỉ đạo dự án thường có ít nhất Trưởng ban phụ trách chung và Phó ban phụ
trách điều hành.


PGĐ điều hành theo dõi từng ngày tiến độ các cơng đoạn thiết kế, lập trình và thử
nghiệm hệ thống. Cần trực tiếp giám sát các cán bộ chuyên môn tham gia thực hiện dự án
chứ không phải thông qua các báo cáo “tôi đã làm xong 90 % cơng việc”. Bởi vì, để làm
10% cịn lại có thể mất nhiều thời gian như 90% công việc kia. Đối với việc viết một
chương trình, chỉ có hai số 0 và 100 là có thể dùng để đo tiến độ thực hiện. Vì vậy, PGĐ
điều hành khơng có cách nào khác là đi sát nhân viên và phản ứng kịp thời đối với mọi tình
huống có thể dẫn đến sự chậm trễ.


PGĐ điều hành cần tiến hành giám sát đến mức nào? Điều này phụ thuộc vào trình
độ của các lập trình viên kỹ thuật: một lập trình viên mới ra trường thường phải được quan
tâm sát sao hơn . Cũng cần tăng cường giám sát trong trường hợp có sự trao đổi giữa các
chương trình. Đối với mỗi cơng đoạn hoặc mỗi cơng việc lớn, lúc bắt đầu là lúc địi hỏi
phải theo dõi nhiều hơn cả.


</div>
<span class='text_page_counter'>(68)</span><div class='page_container' data-page=68>

ghé thăm, uống chén trà hay ly cà phê và trị chuyện với họ .Đương nhiên cũng có nhưng
biện pháp giám sát chính thức, chẳng hạn qua các cuộc họp hay hội ý thường kỳ hàng tuần.


PGĐ điều hành cần quan tâm theo dõi để làm sao:


- Các cán bộ lập trình để tạo ra sản phẩm đã hứa với khách hàng. Từng cơng việc
được hồn thành đúng thời hạn, các chức năng phù hợp với các yêu cầu kỹ thuật đã
đặt ra.



- Các cán bộ lập trình tn thủ đúng các chuẩn đã được mơ tả đối với các thiết kế
modules, lập trình cấu trúc và hướng dẫn sử dụng.


- Các công việc tiến triển theo kế hoạch. Mọi vấn đề có thể gây ra chậm giải quyết
- Mọi người đều vui vẻ, thoả mãn. ai cũng thấy mình trưởng thành lên trong công


việc, thời gian phải làm ngồi giờ khơng nhiều, khơng có ai q mết mỏi, các vấn
đề về nhân sự được báo cáo với Ban chỉ đạo và được giải quyết.


Ban chỉ đạo cũng cần theo dõi tiến độ dự án, nhưng là những nét chính như thời
gian và kinh phí sử dụng, chất lượng, tình hình cán bộ cơng nhân viên. GĐ dự án có thể đi
thăm để nắm tình hình và để có được các thơng tin khơng chính tức từ phía PGĐ và cán bộ
lập trình. Tuy nhiên, phần lớn thông tin dự án cho GĐ là do các nhóm làm việc cung cấp,
thơng qua các cuộc họp chính thức và các báo cáo. GĐ dự án cần giám sát nhất là trong
các trường hợp sau:


- Dự án phát triển chậm hơn so với kế hoạch


- Chi phí sử dụng vượt quá ngân sách. Có thể như vậy khơng đáng ngại, nếu phần
việc đã hồn thành vượt kế hoạch dự kiến


- Vấn đề con người. Mặc dù là mối tiếp xúc thường xuyên với các thành viên trong
nhóm làm việc nhưng do là “người trong cuộc”, PGĐ điều hành có thể khơng phải
là người tinh nhất đối với các vấn đề về nhân sự. Mặt khác, có những vấn đề mà các
thành viên tổ muốn trực tiếp phản ánh với GĐ dự án. Vì vậy, GĐ dự án cần giữ liên
hệ với đội ngũ nhân viên là người nhậy bén, bằng trực cảm kịp thời phát hiện các
vấn đề này.


- Các vấn đề về giao tiếp với lãnh đạo cấp trên với khách hàng.



<b>3.1.1.2. Giám sát từ các cấp quản lý cao hơn </b>


Các cấp quản lý cao hơn (so với ban chỉ đạo) của dự án giám sát trên những phương
tiện sau:


- Các kết quả cuối cùng của dự án; Dự án có sẽ hồn thành đúng thời hạn hay khơng?
Dự án sẽ có đem lại lợi ích như dự tính hay khơng?


</div>
<span class='text_page_counter'>(69)</span><div class='page_container' data-page=69>

khách hàng. Các cấp quản lý cao nhất của hai bên cần phải gặp gỡ nhau để sao cho
các yêu cầu đưa ra đều được đáp ứng một cách thoả đáng


- Các vấn đề về con người trong ê- kíp của chính GĐ dự án. các cấp lãnh đạo phía
trên cần phải giúp đỡ trong những vấn đề mà giám đốc dự án không thể tự mình giải
quyết được. Và nếu bản thân GĐ dự án có vấn đề.


<b>3.1.1.3. Giám sát từ phía khách hàng </b>


Mặc dù cơ quan quản lý dự án có thể khơng đồng ý, khách hàng có quyền được biết
tiến độ dự án, vì nếu dự án thất bại, khách hàng là người bị ảnh hường nhiều nhất.


Khách hàng muốn kiểm tra ngay từ trước xem sản phẩm liệu sẽ có được giao nộp
đúng thời hạn hay khơng, giá cuối cùng phải trả có giữ đúng như đã quy định hay không
và chất lượng sản phẩm có đảm bảo như đã hứa hay khơng.


Khách hàng cũng có thể giám sát dự án theo đường chính thức; yêu cầu cung cấp
các báo cáo định kỳ để nắm được tiến độ dự án cũng như các khuynh hướng dự báo, tham
dự phiên họp của ban chỉ đạo dự án hoặc nhân dịp kết thúc các giai đoạn lớn. Tiến độ dự
án còn được thể hiện qua các biên bản kiểm tra kỹ thuật ở từng cơng đoạn trong q trình
triển khai thực hiện dự án, với cả chữ ký đại diện khách hàng.



Ngồi ra, khách hàng có thể thường xun gặp gỡ Ban chỉ đạo dự án để nắm tình
hình.


<b>3.1.2. Phát hiện và giải quyết các vấn đề </b>


Thống kê một số nước cho thấy vấn đề sau đây thường hay gặp nhất trong quản lý
dự án:


Các vấn đề về nhân sự 1-5% (nhưng được ưu tiên cao nhất)
- Các vấn đề về kinh phí 10-20%


- Các vấn đề về lịch biểu 90-95%


Ngoài ra, tuỳ thuộc vào mỗi nước, mỗi tổ chức quốc tế .., ở một số dự án kinh phí
được coi là quan trọng hơn, thời hạn có thể linh hoạt ít nhiều, trong khi ở một số dự án
khác (ví dụ đối với các nước Bắc Mỹ trong đó có Canada) thời hạn lại là quan trọng hơn.


<b>3.1.2.1. Vấn đề lịch biểu </b>


Vấn đề hay gặp nhất đối với người làm quản lý dự án là vấn đề kéo dài thời hạn .
Trong số các nguyên nhân thường dẫn đến kéo dài thời hạn dự án có thể kể:


</div>
<span class='text_page_counter'>(70)</span><div class='page_container' data-page=70>

- Ước lượng sai nhiều


Khi thấy một công việc phải kéo dài (người thực hiện cơng việc đó báo cáo khơng
thể hồn thành kịp, hoặc đến thời hạn rồi mà cơng việc vẫn dở dang), trước hết cần xem
công việc đó nằm trên đường găng hay khơng. Nếu đó khơng phải là một công việc găng
và thời gian kéo dài khơng nhiều hơn so với khoảng thả nổi, thì sẽ khơng có vấn đề gì. Trái
lại nếu thời gian kéo dài nhiều so với khoảng thả nổi hoặc cơng việc đã cho nằm trên đường
găng, thì thời hạn hoàn thành dự án cũng sẽ phải kéo dài theo. Phản ứng thường gặp trong


trường hợp này là “Thôi được, ta sẽ (bằng cách nào đấy) đẩy nhanh các công việc để bù
lại” . Nhưng phải chăng đây là một hình thức lảng tránh vấn đề, vì trên thực tế rất hiếm khi
bạn có thể kết thúc nhanh các công việc sau để bù lại như bạn thường an ủi.


Khi có một cơng việc kéo dài hãy sử thế như sau:


- Nếu đó là cơng việc đang thực hiện dở, bạn có thể thử khắc phục bằng cách tăng
cường các biện pháp quản lý. Nếu nguyên nhân của sự chậm trễ là các vấn đề thuộc
về kỹ thuật, hãy huy động sự giúp đỡ của các chuyên gia. Nếu là do cá nhân lập
trình viên kỹ thuật gây ra, hãy tìm hiểu xem hồn cảnh, cuộc sống riêng tư của người
đó có gặp khó khăn gì khơng. Hãy trị chuyện cở mở, khuyến khích động viên, áp
dụng các biện pháp thưởng phạt cần thiết. Người làm quản lý dự án cần cố gắng giải
quyết các vấn đề nhân sự bằng cách gặp gỡ, nói chuyện trực tiếp với nhân viên, chứ
không chỉ thông qua các nhóm trưởng.


- Nếu các nỗ lực về quản lý không đem lại kết quả, hãy xem xét phương án bổ sung
nguồn lực, phương tện để thức đẩy nhanh cơng việc. Có thể bạn sẽ may mắn tìm
thấy một cơng việc nào đó khơng sử dụng hết nguồn lực được phân bổ, và phần dư
thừa chuyển được sang cơng việc đang gặp khó khăn. Bạn có thể huy động làm thêm
giờ, song cẩn thận; trong lập trình bổ sung thêm nhân lực khơng có nghĩa là thức
đẩy nhanh cơng việc, thậm chí có khi ngược lại. Nên tham khảo trước ý kiến của
những người trong nhóm và chỉ quyết định bổ sung thêm người nếu họ đồng ý.
- Xét xem các cơng việc cịn phải làm, những cơng việc nào chính ra có thể thực hiện


song song, nhưng khi lập lịch biểu ta đã để nối tiếp chỉ vì thiếu nguồn lực, phương
tiện này. Có thể tình hình ở đó đã thay đổi người ta có thể tăng cường thêm cho
chúng ta


- Nếu có một cơng việc chưa làm nhưng chắc là sẽ phải kéo dài, và không liên quan
đến sự trậm trễ có thể xảy ra ở các cơng việc đang tiến hành, thì thường là do khơng


được cung cấp nguồn lực, phương tiện theo đúng yêu cầu và thời hạn. Hãy dùng
biện pháp quản lý, nói khéo hoặc ngược lại, làm găng, thậm chí đe dọa nếu cần thiết.
- Nếu tất cả các giải pháp trên đều khơng có hiệu quả, hãy dũng cảm chấp nhận và


</div>
<span class='text_page_counter'>(71)</span><div class='page_container' data-page=71>

<b>3.1.2.2. Vấn đề kinh phí </b>


Vấn đề thứ hai thường gặp trong quản lý dự án là kinh phí sử dụng vượt qúa ngân
sách dự kiến. Để xác định xem trong trường hợp này thực sự có vấn đề hay khơng, và trên
cơ sở đó dự báo tổng chi phí cho dự án cũng như thời hạn kết thúc, ta cần xác định được
giá trị phần việc đã thực hiện.


<b>3.1.3. Kiểm soát dự án </b>


Tổ dự án cần phải giao tiếp với nhau và thế giới bên ngoài. Các cuộc họp và các báo
cáo chính là nhằm mục đích này


Trong một dự án CNTT, các cuộc họp có thể được phân ra làm ba loại: Loại thứ
nhất là các cuộc họp định kỳ để thảo luận tình hình triển khai dự án. Loại thứ hai bao gồm
các cuộc họp nhằm xem xét tổng quan sản phẩm, phát hiện và chỉnh sửa các vấn đề thuộc
về kỹ thuật. Và loại thứ ba là các cuộc họp về quản lý, báo cáo với các cấp có liên quan về
tiến độ dự án. Các cuộc họp quản lý này cũng có thể là các cuộc họp định kỳ, như phiên
họp của Ban chỉ đạo, hoặc mỗi đợt sơ kết sau mỗi cơng đoạn chính.


Hình thức giao tiếp thứ hai là qua các báo cáo. Chẳng hạn những người ít có dịp
gặp gỡ trực tiếp với tổ dự án có thể nắm tình hình thơng qua các báo cáo định kỳ hàng tuần
hoặc hàng tháng


<b>3.1.3.1. Thông qua họp định kỳ và báo cáo </b>
- Mục đích và thành phần



Đối với các dự án CNTT vừa và nhỏ, cần phải có các cuộc họp định kỳ hàng tuần
với sựu tham gia của tất cả các thành viên tổ dự án. Các cuộc họp này là dịp để các bộ phận
báo cáo với Ban chỉ đạo về tiến độ dự án và những vấn đề nảy sinh. Đối với các dự án lớn,
bao gồm nhiều đơn vị, nhiều nhóm làm việc, các cuộc họp định kỳ nên chia thành hai hay
ba phần (hai hay ba cuộc họp nhỏ). Trong phần đầu tiên ngắn gọn quảng 30 phút đến 60
phút, nhất là trong tuần nhóm trưởng đã theo sát các khâu. Cuối cùng có thể phần thứ ba,
các nhóm trưởng lại họp với Ban chỉ đạo. Thơng thường các nhóm trưởng chỉ cần báo cáo
miệng, nhưng Ban chỉ đạo có thể yêu cầu báo cáo bằng văn bản.




- Nên bố trí họp định kỳ vào ngày nào trong tuần?


</div>
<span class='text_page_counter'>(72)</span><div class='page_container' data-page=72>



- Các báo cáo định kỳ :Mục đích và số trang


Hình thức giao tiếp chủ yếu của dự án với bên ngoài là các báo cáo định kỳ, ngắn
gọn và theo mẫu quy định sẵn, do Ban chỉ đạo ra. Báo cáo định kỳ là vấn đề cần phải bàn
tới không chỉ với các dự án cơng nghệ phần mềm, mà cịn với cả các dự án trong lĩnh vực
khác nữa; báo cáo thường quá dài và đòi hỏi quá nhiều thời gian để chuẩn bị. Ai cũng biết
rằng, khi nhận được một tài liệu nào đó, trước hết người ta thường lướt qua mấy dịng đầu
tiên xem có gì đáng giá hay khơng. Nếu thấy hay, có thể người ta mới đọc tiếp trang đầu,
để rồi sau đó chuyển ngay xuống đoạn kết của tài liệu. Một báo cáo tuần chỉ nêu dài không
quá hai ba trang giấy A4: phần tường thuật tối đa một trang đầu, tiếp đến một hoặc hai
trang do máy tính in ra. Mỗi báo cáo như vậy GĐ dự án chỉ cần không q 30 phút là có
thể chuẩn bị xong. Khơng nên kể lể nhiều về các việc đã qua, lý giải dòng hoặc `thuyết
giáo tràn lan về các vấn đề sắp tới. Hãy dành chuyện đó cho các cuộc bàn luận khơng chính
thức.



- Định kỳ ra báo cáo


Để có được những bước tiến đáng kể, việc quyết định ra báo cáo hàng tuần, hai tuần
hay hàng tháng .. là tuỳ thuộc vào thời gian cần thiết để hoàn thành một khối lượng cơng
việc trung bình trong dự án. Đối với những dự án vừa và nhỏ, có thể phân ra thành những
công việc với thời gian thực hiện không quá một tuần, báo cáo tuần là thích hợp hơn cả.
Nếu phần lớn các công việc phải cần một tháng mới hồn thành xong, có thể ra báo cáo
tháng, cũng có thể ra các báo cáo ngắn ngày hơn, nếu khách hàng yêu cầu như vậy cho họ
thường xuyên nắm được tiến độ, hoặc trong trường hợp dự án phụ thuộc nhiều vào các
nguồn lực ở bên ngoài.




- Nội dung báo cáo định kỳ


Báo cáo định kỳ cần bao gồm những phần sau đây:


 Các hoạt động và kết quả thu được từ báo cáo trước: Kê khai các công việc
đang thực hiện, tiến độ của từng cơng việc, các cơng việc hồn thành.


 Các vấn đề nảy sinh: Giải thích các trở ngại mới xuất hiện, do ai hoặc cái gì
gây ra, ai chịu trách nhiệm theo dõi và hiện xử lý đến đâu. Quan trọng nhất là
xác định ảnh hưởng của nó tới dự án.


 Các vấn đề đã giải quyết: Giải thích tóm tắt (hoặc dẫn chiếu đến báo cáo kỳ
trước), vấn đề đã được giải quyết như thế nào, do ai giải quyết và tác động của
nó lên dự án.


</div>
<span class='text_page_counter'>(73)</span><div class='page_container' data-page=73>

Chỉ cần một hay hai câu là đủ. Không cần mô tả lại những vấn đề ở các báo
cáo trước.



 Lịch biểu mới đối chiếu với kế hoạch: Trang hai của báo cáo tốt nhất nên dành
cho sơ đồ Gantt do máy tính in ra. Ứng với mỗi cơng việc sẽ có hai đường: đối
với các cơng việc đã hồn thành-thời gian dự tính theo kế hoạch và thời gian
thực tế sử dụng để làm công việc đó, đối với các cơng việc cịn phải làm-thời
gian dự tính theo kế hoạch và thời gian theo lịch biểu mới. Giải thích tất cả
các thay đổi so với sơ đồ Gantt tuần trước, đặc biệt nếu thời hạn giao hàng đã
khác. Gạch dưới để nhấn mạnh các thông báo kéo dài thời hạn.


 Đối chiếu chi phí thực tế với dự tính ngân sách. Có thể sử dụng MS Project để
có ngay sơ đồ chiếu giữa Chi phí thực tế, Dự tính ngân sách (kế hoạch)và Giá
trị phần việc đã thực hiện. Tóm tắt những khoản mới phải chi kể từ lần báo
cáo trước


 Kế hoạch tuần sau: Liệt kê các công việc theo kế hoạch và các sự kiện mốc
của tuần tới


<b>3.1.3.2. Thông qua họp kỹ thuật </b>


Một số các cuộc họp tổng quan là tốn kém và mất thời gian. Vì vậy, cần biết tổ chức
sao cho có hiệu quả


- Lên lịch họp, phân chia rõ thời gian để thảo luận từng phần.


 Gửi sớm lịch họp và các tài liệu cần thiết cho các thành viên tham dự có thời
gian nghiên cứu trước.


 Bố trí địa điểm họp sao cho khơng bị quấy nhiễu. Điều khiển phiên họp theo
chương trình đã đề ra, khống chế thời gian đã phân cho từng mục, nhưng không
quá cứng nhắc, nhất là khi gặp một vấn đề quan trọng cần thảo luận lâu hơn


một chút.


 Dành đủ thời gian để bàn các công việc đã ký kết; kiên quyết yêu cầu giữ đúng
tiến độ.


- Họp xét duyệt kỹ thuật (Kế hoạch, Thiết kế, Mã, Thử nghiệm, Tài liệu)


</div>
<span class='text_page_counter'>(74)</span><div class='page_container' data-page=74>

<b>3.1.3.3. Thông qua họp quản lý </b>
- Họp ban chỉ đạo.


Ở mỗi dự án quan trọng thường có một Ban chỉ đạo, thành phần Ban chỉ đạo bao
gồm Trưởng-Phó ban, người phụ trách dự án của bên khách hàng, một hoặc hai đại diện
của các bộ phận (Viện, Phòng, Ban ..) chuyên mơn có người tham gia dự án, và ít nhất một
thủ trưởng cấp trên, có đủ thẩm quyền đối với tất cả các bộ phận liên quan theo nghĩa là
những đơn vị cung cấp nguồn lực cho dự án.


Ban chỉ đạo họp thường kỳ vào những thời gian định sẵn-trung bình từ 6 đến 8 tuần
một lần đối với một dự án từ 6 đến 24 tháng. Mục đích họp là để thu nhận thơng tin về tình
hình triển khai dự án và xác định các vấn đề. Người ta nhận thấy một điều lý thú là đường
dây quan hệ của các nhà quản lý cấp cao nhiều khi có sức mạnh kéo được dự án ra khỏi
tình trạng bế tắc hoặc trì trệ. Các cuộc họp này cũng giúp cho các cấp quản lý nắm sát hơn
tiến độ dự án, trở nên gần gũi hơn với tổ dự án, và điều đó có tác dụng động viên tất cả mọi
người.


- Họp nhân dịp các sự kiện mốc.


Mỗi khi kết thúc các cơng việc chính nên có họp. Các cuộc họp này cần có hai phần:
Phần thứ nhất để các nhóm kỹ thuật trao đổi về những gì đã làm được, các vấn đề nảy sinh
ở giai đoạn vừa qua, và lập kế hoạch làm việc cho giao đoạn tới. Phần thứ hai dành cho tất
cả các thành viên tham gia dự án bao gồm cả khách hàng và các cấp quản lý có liên quan.


Trưởng ban chỉ đạo chủ trì phiên họp và sau đó có thể có bia và bánh ngọt.. Trước khi mở
bia cần bàn xong các kết quả đã đạt được, những vấn đề đặt ra và nguồn lực cần thiết cho
giai đoạn tiếp theo. Các cuộc họp này tăng cường sự gắn bó và hăng hái của mọi người.
Dưới đây ta sẽ đề cập một số sự kiện mốc trong dự án.


<b>3.1.3.4. Thông qua họp đặc biệt </b>


Những sự kiện mấu chốt trong chu trình dự án địi hỏi sự tham gia ý kiến không chỉ
của một người. Đối với mỗi sự kiện như vậy, có thể bố trí một cuộc họp riêng để thảo luận.


- Họp đánh giá rủi ro và quyết định có theo đuổi dự án hay không.


Để đánh giá rủi ro, nên mời những người đã có kinh nghiệm với các dự án cùng
loại. Cuộc họp này phải tiến hành trước khi đưa ra đề xuất dự án, để bảo đảm là tất cả các
rủi ro đã được đánh giá và tính vào giá thành dự án, trên cơ sở đó quyết định có nên bỏ
cơng sức viết dự án hay khơng. Thành phần họp là Trưởng-Phó ban chỉ đạo dự án (tương
lai) và các chuyên gia.


- Khai trương dự án.


</div>
<span class='text_page_counter'>(75)</span><div class='page_container' data-page=75>

Mời tham dự phần đầu tất cả những ai liên quan đến dự án; Khách hàng, người cung cấp
thiết bị, thành viên Ban chỉ đạo, các cấp quản lý, đội ngũ kỹ thuật viên ..


Mục đích đề giới thiệu các bên với nhau, đặt quan hệ giao tiếp, nêu rõ nguồn gốc và
mục tiêu dự án. Phiên họp này cũng nhằm tạo ra bầu không khí phấn khởi và hăng hái bước
vào dự án. Phần thứ hai chỉ dành cho các cán bộ kỹ thuật, nhằm đề ra các hướng chỉ đạo,
quy định các thủ tục, .. Phải nắm được chính xác trình độ của mỗi người và lên kế hoạch
đào tạo nếu cần.


- Họp lập kế hoạch (ước lượng) dự án.



Sẽ rất tốt nếu để một nhóm nhỏ, ba hoặc bốn người, tiến hành các ước lượng cần
thiết. Nhóm này có thể đảm nhiệm ln khâu phân rã công việc, xác định các nguồn lực,
phương tiện cần có và sắp xếp cơng việc theo thứ tự trước sau.


- Thông qua các đặc tả chức năng.


Trước hết họp đội ngũ kỹ thuật viên xem xét các vấn đề của giai đoạn cuối, ước
lượng và lịch biểu, nhất là nếu có sự thay đổi về đặc tả chức năng. Sau đó tiến hành họp
chung với đông đủ các bên như đã mô tả ở trên. Thông báo về mọi thay đổi trong kế hoạch
như lùi thời hạn giao sản phẩm hoặc nâng giá. Cần có sự cam kết từ phía các bộ phận thiết
kế và lập trình.


- Thảo luận chi tiết thiết kế mức cao nhất.


Phó ban chỉ đạo điều hành phiên họp. Nhiều nhất chỉ nên không quá 5 người tham
dự bao gồm các cán bộ thiết kế, chuyên gia ngoài hoặc lập trình viên có kinh nghiệm. Tác
giả thiết kế trình bày các phương án TLD khác nhau, nói rõ ưu điểm và nhược điểm của
từng phương án. Những người tham dự bổ xung ý kiến và đề nghị các phương án khác của
họ. Cuối cùng, TLD tốt nhất sẽ được chọn . Cuộc thảo luận chi tiết này kéo dài từ 2 đến 4
giờ.


- Thảo luận chi tiết thiết kế mức trung.


Đối với các dự án lớn, cần tiến hành thảo luận chi tiết và lựa chọn thiết kế từng mức,
và tất nhiên là cho thiết kế hoàn chỉnh. Mục đích các buổi thảo luận này nhằm phát hiện
tất cả các vấn đề còn cần phải làm rõ trong thiết kế. Tuỳ thuộc vào số lượng module trong
thiết kế, có thể phân ra một số buổi, nhưng khơng nên quá 5 người tham gia và mỗi buổi
kéo dài quá từ 3 đến 5 giờ.



- Thơng qua thiết kế hệ thống.


Mục đích và cách tiến hành giống như họp thông qua các đặc tả chức năng. Xem
xét lại một lần nữa các ước lượng, đề nghị cam kết về các điều khoản khác nhau như bàn
giao phần cứng, đội ngũ cán bộ lập trình, khâu chấp nhận, tài liệu hướng dẫn sử dụng.


- Thảo luận chi tiết và thiết kế module, tài liệu và kế hoạch thử nghiệm.


</div>
<span class='text_page_counter'>(76)</span><div class='page_container' data-page=76>

họp phải khẳng định thiết kế đã chọn là tốt nhất, và xem còn vấn đề gì nữa khơng. Có thể
thảo luận liền mấy module, nhưng mỗi module không quá từ 1 đến 2 giờ, và mỗi buổi
không quá 4 giờ. Tác giả module trình bày, ghi lại các ý kiến đề xuất, để suy nghĩ, tìm cách
giải quyết và sẽ báo lại với Ban chỉ đạo sau.


- Thảo luận mã tài liệu cho người dùng.


Tất cả những điều trình bày ở phần thảo luận module cũng sẽ đúng ở đây. Tuy nhiên
cuộc thảo luận này chi tiết và có thể có nhiều người tham dự.


- Họp kết thúc chấp nhận thử nghiệm (sự kiện mốc).


Đúng ra đây không thật sự là sự kiện mốc như một số sự kiện mốc khác. Vì vậy
khơng nên phơ trương ầm ĩ, Chỉ coi như một cuộc gặp mặt giữa khách hàng và Trưởng ban
chỉ đạo dự án.


- Họp kết thúc giai đoạn vận hành (sự kiện mốc)


Đây thực ra không phải là một cuộc họp, mà là một bữa tiệc và tất cả mọi người đều
được mời, một dịp để xả hơi và chuyển sang giai đoạn hậu dự án.


- Họp rút kinh nghiệm sau dự án.



Đây là một việc hay bị quên, mặc dù rất quan trọng. Cần phải có hai phiên họp -
phiên họp với khách hàng và họp nội bộ. Họp với khách hàng có thể mời cả tổ dự án và
các cấp quản lý cao hơn. Không để phiên họp này trở thành qua quýt. Mục đích là phân
tích các trục trặc xảy ra với người sử dụng và bàn cách khắc phục những sự kiện đó trong
tương lai. Trong trường hợp khách hàng khơng thoả mãn, đây có thể là dịp để chứng tỏ với
anh ta rằng vấn đề không nằm trong tầm kiểm soát của chúng ta. Trong trường hợp khách
hàng thoả mãn, có thể đề nghị anh ta giới thiệu với các khách hàng khác.


Phiên họp thứ hai là giữa tổ dự án với các cấp quản lý có liên quan. Phải làm sao
đây thật sự là phiên họp phê bình xây dựng. Phân tích những thiếu sót sai lầm, làm thế nào
để tránh được những thiếu sót sai lầm đó trong tương lai, ghi lại các đề xuất tương ứng.


- Báo cáo sau dự án.


Kết quả cuộc họp rút kinh nghiêm sau dự án được ban chỉ đạo trình bày trong mơt
báo cáo chính thức. Báo cáo này sẽ là một tài liệu tổng kết sẽ được lưu hành cho nhiều dự
án khác cũng như có thể sẽ được nhiều người ngoài dự án xem. Báo cáo sau dự án cần bao
gồm những phần sau đây:


 Dự án đã được hình thành như thế nào, mục tiêu ban đầu, các giải pháp đề xuất


 Phương pháp và tổ chức dự án, các kiến nghị cải tiến nếu có


 So sánh kế hoạch đề ra với kết quả đạt được trên thực tế. Nếu có sự khác nhau
đáng kể – giải thích vì sao.


 Cập nhật các cơng thức và tỷ số dùng để ước lượng.


</div>
<span class='text_page_counter'>(77)</span><div class='page_container' data-page=77>

 Các rủi ro đã gặp phải, đề xuất để tránh những rủi ro đó trong tương lại. Cập


nhật tài liệu lưu về rủi ro.


 Các phần của sản phẩm có thể tái sử dụng.


 Trả lời các câu hỏi “Ta có nêu ở lại trong lĩnh vực ứng dụng đã cho hay không”,
hoặc chung hơn nữa, “Ta có nên tiếp tục làm quản lý dự án nữa hay không”.
- Họp thảo luận các vấn đề ngay cấn.


Có trường hợp Trưởng ban chỉ đạo một mình khơng thể giải quyết được khó khăn
đặt ra. Ví dụ như tình trạng nhiều cán bộ làm cho dự án xin thơi việc và do đó phải tìm
người thay thế, các nguồn lực, phương tiện quan trọng không được cung cấp, nhiều cán bộ
quá mệt mỏi hoặc mâu thuẩn lẫn nhau, liên hệ giữa dự án và người sử dụng bị gián đoạn..
Trưởng ban chỉ đạo dự án cần mời họp để tham khảo ý kiến tất cả các bên liên quan cũng
như ai có thể đưa ra giải pháp. Thơng thường cần có cấp đại diện quản lý cao của hai bên,
bên dự án và bên người sử dụng, tham gia.


<b>3.2. Kết thúc dự án </b>


<b>3.2.1. Đánh giá tài chính </b>


Khi chúng ta dự định đầu tư thực hiện dự án xây dựng một hệ thống thông tin, ta
cần cân nhắc xem có nên thực hiện dự án đó hay khơng, và trong trường hợp nên thực hiện
thì trong số nhiều phương án triển khai dự án nên chọn phương án nào. Để trả lời các câu
hỏi này, mối quan tâm của các nhà đầu tư là đo hiệu quả do việc thực hiện dự án mang lại
và các quyết định sẽ dựa trên việc so sánh các hiệu quả này. Như vậy điều quan trọng là
phải so sánh mối quan hệ giữa chi phí dự án và lợi ích do dự án mang lại. Song cần chú ý
là trong khi chi phí dự án được tính bằng tiền thì hầu như các hiệu quả do dự án CNTT
mang lại đều khó có thể đo được bằng tiền. Để khắc phục khó khăn này, khi so sánh các
phương án thực hiện dự án chúng ta có thể sự dụng phương pháp hai bước:



- Đầu tiên dùng đánh giá tài chính so sánh chi phí các dự án


- Trong số các phương án được đánh giá tốt ở bước 1, so sánh tiếp một số chỉ tiêu
chất lượng không được thể hiện bằng tiền để chọn phương án thích hợp nhất.


<b>3.2.1.1. Xác định chi phí </b>


Chi phí xây dựng hệ thống thông tin thường bao gồm các loại chi phí sau đây:
- Chi phí xây dựng hệ thống: Chi phí xây dựng hệ thống được tập chung chi trong


một vài năm đầu. Đây là chi phí trong thời gian phát triển hệ thống mới bao gồm
các chi phí:


 Mua trang thiết bị phần cứng


</div>
<span class='text_page_counter'>(78)</span><div class='page_container' data-page=78>

 Cơng phân tích, thiết kế, lập trình, kiểm tra, cài đặt


 Chuẩn bị chỗ đặt máy


 Huấn luyện


 Chuyển từ hệ thống cũ sang hệ thống mới


- Chi phí tác nghiệp: Sau khi hệ thống được xây dựng và đi vào hoạt động, chi phí tác
nghiệp là các chi phí phục vụ cho hoạt động hàng ngày của hệ thống bao gồm:


 Thuê phần cứng và phần mềm


 Hợp đồng bảo dưỡng phần cứng và phần mềm



 Chi phí cho nhân lực hàng ngày: vào dữ liệu, quản lý mạng, ..


 Thuê chỗ đặt máy tính
- Các chi phí gián tiếp khác


 Các chi phí tác nghiệp và chi phí gián tiếp xuất hiện khi hệ thống bắt đầu đi
vào hoạt động.


 Trong trường hợp dự án đem lại các lợi ích đo được bằng tiền, thì lợi ích đó
được tính là chi phí với dấu âm và tính gộp trong tổng chi phí. Như vậy đối
với mỗi phương án ta có bảng chi phí tính theo từng năm.


<b>3.2.1.2. So sách các phương án </b>


Để đánh giá tài chính các dự án, ta tìm cách so sánh chi phí dự án. ở đây ta giả định
có một hệ thống cũ đang hoạt động, và hệ thống đã suy thối nên chi phí cho hoạt động
của hệ thống này hàng năm tăng dần. Hệ thống mới được đem so sánh với hệ thống cũ bao
gồm các chi phí xây dựng, chi phí tác nghiệp và chi phí gián tiếp.


<b>3.2.1.3. Điểm hịa vốn </b>


</div>
<span class='text_page_counter'>(79)</span><div class='page_container' data-page=79>



<b>Hình 3.2. Đánh giá tài chính </b>


<b>3.2.2. Đánh giá hiệu quả dự án </b>
<b>3.2.2.1. Thu hồi vốn đơn giản </b>


Để so sánh hai hệ thống cũ và mới theo phương pháp thời hạn thu hồi vốn đơn giản,
ta lập bảng so sánh chi phí như sau:



Chênh lệch chi phí gộp lại từng năm được tính bằng cách tính tổng chênh lệch chi
phí từ năm thứ nhất tới năm đó.


Trong bảng này chúng ta có một số giả thiết sau:


- Thời gian cần thiết để xây dựng hệ thống mới la 1,5 năm. Trong thời gian đó hệ
thống cũ vẫn phải hoạt động , do đó trong chi phí xây dựng hệ thống mới, trong 1,5


Chi phí

















N ă m
Chi phí xây



d ự ng


Đ i ể m hoà


</div>
<span class='text_page_counter'>(80)</span><div class='page_container' data-page=80>

năm đầu tiên vẫn phải cộng chi phí vận hành hệ thống cũ và chi phí đó ở năm thứ
hai chỉ tính nửa năm


- Bắt đầu từ giữa năm thứ hai, hệ thống mới được đưa vào khai thác, hệ thống cũ
không làm việc nữa và ta bắt đầu phải chi phí cho vận hành hệ thống mới.




Khi đó thời hạn thu hồi vốn giản đơn được tính theo công thức:


Nếu gọi là chỉ số năm mà e<0, e>0 thì
e


Thời hạn thu hồi vốn giản đơn = i + ---
e+e


<b>3.2.2.2. Thu hồi vốn có chiết khấu </b>


Về cơ bản, phương pháp tính thời hạn thu hồi vốn có chiết khấu giống như phương
pháp tính thời hạn thu hồi vốn đơn giản, điều khác là tại mỗi năm có tính triết khấu theo
mức lãi suất của thị trường vốn. Cách tính mới này phức tạp hơn, song chính xác hơn vì có
chú ý đến giá trị của tiền tệ theo thời gian.


<b>3.2.2.3. Đánh giá các chỉ tiêu chất lượng </b>


Sau khi dùng đánh giá tài chính để so sánh chi phí của các phương án thực hiện dự


án, ta chọn được hai, ba phương án tốt. Tiếp theo ta có thể sử dụng một vài chỉ tiêu chất
lượng để tiếp tục so sánh chọn ra phương án tốt nhất. Các chỉ tiêu chất lượng đó có thể là:


- Tăng độ chính xác của thơng tin (giảm sai sót)
- Giảm thời gian sửa sai


- Cung cấp thông tin tốt hơn, nhanh hơn
- Tăng mức độ an toàn hệ thống


- Tăng khả năng cập nhật thông tin
- Tăng hiệu quả sử dụng của người dùng
Thời hạn thu


hồi vốn giản
đơn


</div>
<span class='text_page_counter'>(81)</span><div class='page_container' data-page=81>

<b>Bài tập </b>


Các nhóm trên cơ sở đề tài của nhóm đã thực hiện ở chương 2, hãy:
- Lâp kế hoạch giám sát và kiểm soát dự án


</div>
<span class='text_page_counter'>(82)</span><div class='page_container' data-page=82>

<b>MỤC LỤC HÌNH ẢNH </b>


<b>TRANG </b>


Hình 1.1: Minh họa quyền lãnh đạo dự án ... 8


Hình 1.2: Những người có trách nhiệm với dự án ... 13


Hình 2.1. Bảng kê công việc theo sản phẩm ... 19



<i>Hình 2.2. Danh sách cơng việc ... 19 </i>


Hình 2.3. Bảng kê cơng việc chi tiết ... 20


Hình 2.4. Cấu trúc phân sản phẩm ... 23


Hình 2.5. Cấu trúc phân nhiệm vụ ... 24


Hình 2.6. Ví dụ về WBS đầy đủ ... 25


Hình 2.7. WBS theo sản phẩm ... 27


Hình 2.8. WBS theo trách nhiệm chia thành nhiều pha ... 28


Hình 2.9. WBS ra theo miền trách nhiệm ... 29


Hình 2.10. Quy trình quản lý chất lượng ... 41


Hình 2.11. Biến động về chất lượng ... 43


Hình 2.12. Chức năng cơ bản của giám đốc dự án ... 49


Hình 3.1. Giám sát và duy trì dự án ... 63


</div>
<span class='text_page_counter'>(83)</span><div class='page_container' data-page=83>

<b>MỤC LỤC BẢNG </b>


</div>
<span class='text_page_counter'>(84)</span><div class='page_container' data-page=84>

<b>TÀI LIỆU THAM KHẢO </b>


1. Pankaj Jalote (Dịch: Nguyễn Công Danh - Trần Cao Đệ), Software Project


Management in Practice (Quản lý dự án phần mềm trong thực tiễn),
Addison-Wesley (Dịch: ĐH Cần Thơ), 2002 (Dịch: 2013)


2. Kathy Schwalbe, Information Technology Project Management – Revided 6e,
Cengage Learning, 2011


3. Giáo trình Quản lý Dự án, Ngô Trung Việt, ĐH. Quốc gia Tp.HCM, 2008
4. Hidenori Shibamoto (Châm Blue dịch), Quản lý dự án hiệu quả theo phong cách


</div>

<!--links-->
Quản lý dự án Công nghệ thông tin
  • 39
  • 1
  • 7
  • ×