NGUYỄN ĐĂNG KHOA

QUẢN LÝ DỰ ÁN
CÔNG NGHỆ THÔNG TIN

HÀ NỘI 2020
1
MỤC LỤC
BẢNG VIẾT TẮT......................................................................................................................................3

Lời mở đầu.................................................................................................................................................5

Chương 1:Tổng quan về quản lý dự án ƯDCNTT..................................................................................6

1. Những vấn đề chung về quản lý dự án và quản lý dự án ứng dụng CNTT................................................6

1.1 Khái niệm về dự án và dự án ứng dụng CNTT:................................................................................6

1.1.1 Khái niệm dự án........................................................................................................................6
1.1.2-Khái niệm dự án ứng dụng CNTT:.........................................................................................6
1.2 Đặc trưng của một dự án.....................................................................................................................7
1.2.1 Mục tiêu của dự án...................................................................................................................7
1.2.2 Thời gian dự án.........................................................................................................................7
1.2.3 Kinh phí của dự án...................................................................................................................8
1.2.4 Nguồn nhân lực.........................................................................................................................8
1.2.5 Kết quả chuyển giao của dự án................................................................................................8
1.3. Phân loại dự án ứng dụng CNTT:.....................................................................................................8
1.3.1- Theo tầm cỡ dự án:..................................................................................................................8
1.3.2 Theo nội dung của dự án:.........................................................................................................9
1.3.3 Dự án một người hay dự án nhiều người................................................................................9
1.3.4 Dự án nội bộ hay bên ngoài....................................................................................................10
1.4 Các nhân tố liên đến dự quan đến dự án (Stackholders)..................................................................10
1.5. Các lĩnh vực quản lý trong dự án (Knowledge areas)....................................................................11
1.6 Vai trò của người quản lý dự án.......................................................................................................12
1.7 Các giai đoạn của dự án (Project phases)................................................................................13
1.8 Những vấn đề quản lý dự án ứng dụng CNTT:...............................................................................15
1.8.1 Mục đích của quản lý dự án ứng dụng CNTT......................................................................15
1.8.2 Các bước quản lý dự án ứng dụng CNTT.............................................................................16
1.8.3 Nguyên nhân khiến dự án ứng dụng CNTT thất bại:..........................................................17
1.9 Các giai đoạn thực hiện dự án ứng dụng CNTT.............................................................................18
1.10 Nhân sự của các bên liên quan tham gia thực hiện dự án ứng dụng CNTT:...............................21
Chương 2: Các nội dung cơ bản của quản lý dự án ứng dụng CNTT.................................................22

2.1. Quản lý phạm vi dự án ứng dụng CNTT:.......................................................................................24

2.1.1 Xác định phạm vi dự án.........................................................................................................24
2.1.2 Qui trình quản lý phạm vi........................................................................................................28
2.2.Xác định phương án lựa chọn ứng dụng CNTT..............................................................................29

2
2.3. Quản lý thời gian dự án ứng dụng CNTT:......................................................................................33
2.4 Quản lý nguồn lực của dự án ứng dụng CNTT:..............................................................................43
2.5. Giám sát dự án ứng dụng CNTT:....................................................................................................45
2.5.1 Giám sát dự án........................................................................................................................45
2.5.2 Giám sát dự án từ phía các cấp quản lý cao hơn..................................................................47
2.5.3  Giám sát dự án từ phía khách hàng......................................................................................47
2.6- Một số rủi ro trong thực hiện dự án ứng dụng CNTT:.................................................................53
2.6- Các biện pháp đảm bảo chất lượng thực hiện dự án ứng dụng CNTT........................................59
2.6.1-Tầm quan trọng của quản lý chất lượng...............................................................................59
2.6.2. Lập kế hoạch chất lượng (Planning quality)........................................................................59
2.6.3. Thực hiện đảm bảo chất lượng (Quality assurance)............................................................61
Chương 3:.................................................................................................................................................61

Giải quyết sự cố trong quá trình thực hiện đầu tư, bảo hành và vận hành dự án ứng dụng CNTT. 61

3.1. Nguyên tắc giải quyết sự cố:.............................................................................................................61

3.1.1 Phát hiện và giải quyết các vấn đề ngay từ trước khi chúng xảy ra....................................61
3.1.2 Phát hiện và giải quyết các vấn đề trong khi triển khai.....................................................62
3.1.3 Phát hiện và giải quyết các vấn đề ở giai đoạn cuối...........................................................63
3.2 Phát hiện và giải quyết các vấn đề sự cố..........................................................................................63
3.3. Trách nhiệm các tổ chức, cá nhân liên quan:.................................................................................65
3.3.1 Trách nhiệm của chủ đầu tư hoặc đơn vị thụ hưởng đầu tư khi xảy ra sự cố....................68
3.3.2 Trách nhiệm của các nhà thầu tham gia dự án khi xảy ra sự cố.........................................69
3.3.3 Kinh phí thực hiện..................................................................................................................69
3.4 Nội dung giải quyết sự cố:.................................................................................................................69
3.4.1 Xử lý nhanh khi có sự cố........................................................................................................70
3.4.2 Lập hồ sơ sự cố........................................................................................................................70
3.4.4 Thu dọn hiện trường sự cố.....................................................................................................70
3.4.5 Giải quyết sự cố.......................................................................................................................71
Tài liệu tham khảo:..................................................................................................................................72

CÁC PHỤ LỤC........................................................................................................................................72

3
 BẢNG VIẾT TẮT
CNTT Công nghệ thông tin
DA Dự án
DA ƯDCNTT Dự án ứng dụng CNTT
THH Tin học hóa
UBND Ủy ban nhân dân
BKCV Bảng kê công việc
DSSP Danh sách sản phẩm
DSCV Danh sách công việc
TQM Hệ thống quản lý chất lượng tổng thể
Total Quality Management

4
Lời mở đầu
Với sự phát triển vô cùng mạnh mẽ của Công nghệ thông tin (CNTT), nhu cầu phát
triển phần mềm ngày càng tăng, đặc biệt là những phần mềm lớn, có phạm vi ứng dụng
rộng rãi, xây dựng trong nhiều năm, huy động một đội ngũ đông đảo những chuyên gia
phần mềm khác nhau. Các phần mềm được thiết kế và xây dựng trong khuôn khổ những
dự án CNTT. Rất nhiều bài học thực tế ở Việt Nam và trên thế giới đã cho thấy rằng dự án
càng lớn thì khả năng thành công càng ít. Việc quản lý dự CNTT ngày càng chứng tỏ vai
trò đặc biệt quan trọng của nó, góp phần đảm bảo thành công cho dự án. Quản lý dự án, từ
chỗ là một nghệ thuật, đã được nghiên cứu, tổng kết và phát triển thành một môn khoa
học.
Giáo trình này thường được giảng dạy ở năm cuối của các bậc đào tạo. Nội dung
chính của cuốn sách này gồm 3 chương và được sắp xếp theo thứ tự các giai đoạn phát
triển hệ thống:

Chương 1. Tổng quan về quản lý dự án ƯDCNTT, trình bày những kiến thức tổng
quan về dự án, dự án ứng dụng CNTT, đặc trưng, các cách phân loại dự án ứng dụng
CNTT, các nhân tố ảnh hưởng đến dự án, vai trò của người quản lý dự án và các lĩnh vực
trong quản lý dự án ứng dụng CNTT.

Chương 2: Các nội dung cơ bản của quản lý dự án ứng dụng CNTT nội dung
chương này bao gồm: Quản lý phạm vi dự án ứng dụng CNTT, xác định phương án lựa
chọn ứng dụng CNTT, quản lý thời gian dự án ứng dụng CNTT, quản lý nguồn lực của dự
án ứng dụng CNTT, Giám sát dự án ứng dụng CNTT , một số rủi ro trong thực hiện dự án
ứng dụng CNTT, các biện pháp đảm bảo chất lượng thực hiện dự án ứng dụng CNTT
Chương 3: Giải quyết sự cố trong quá trình thực hiện đầu tư, bảo hành và vận
hành dự án ứng dụng CNTT, nội dung chính của chương này bao gồm: nguyên tắc giải
quyết sự cố, phát hiện và giải quyết các vấn đề sự cố, trách nhiệm các tổ chức, cá nhân liên
quan, nội dung giải quyết sự cố.
Để cho sinh viên có thể tự kiểm tra đánh giá sự tiếp thu bài giảng ngoài các ví dụ
trong các phần bài giảng, chúng tôi đã đưa vào các câu hỏi, bài tập ngay cuối mỗi chương
nhằm cô đọng các kiến thức đã trình bày

Liên quan đến môn học đòi hỏi người đọc cần có các kiến thức về: tin học, công nghệ
thông tin, phân tích thiết kế hệ thống, phần mềm và quy trình làm phần mềm

Với kinh nghiệm giảng dạy nhiều năm môn tin học, hệ thống thông tin quản lý cũng
như qua làm thực tế các dự án tin học nói chung, mặc dầu có rất nhiều cố gắng, nhưng
không tránh khỏi những thiếu sót, tác giả rất mong nhận được sự đóng góp ý kiến của độc
giả để giáo trình được hoàn thiện hơn.

5
Chương 1:Tổng quan về quản lý dự án ƯDCNTT
1. Những vấn đề chung về quản lý dự án và quản lý dự án ứng dụng CNTT
1.1 Khái niệm về dự án và dự án ứng dụng CNTT:
1.1.1 Khái niệm dự án
Dự án là một hoạt động tạo ra - một cách có phương pháp và định tiến, với các
phương tiện và nguồn lực đã cho - một sản phẩm mới hoặc một thực tế mới.
Theo cách hiểu này, thì dự án phải có tính cụ thể và mục tiêu xác định, nhằm đáp
ứng một nhu cầu chuyên biệt (của người dùng). Dự án cũng không phải là một nghiên cứu
trừu tượng mà phải cấu trúc nên một thực tế mới chưa tồn tại trước đó. Mặc dù việc
nghiên cứu, thử nghiệm và phát triển có thể là một phần nhất định trong dự án, nhưng
cũng chỉ đóng vai trò hỗ trợ trong quá trình thực hiện mục tiêu cuối cùng của dự án mà
thôi. Do vậy cần phân biệt rõ sự khác nhau giữa dự án và các đề tài nghiên cứu triển khai
mà các cơ quan, đơn vị nghiên cứu vẫn thường làm.
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ý.
1.1.2-Khái niệm dự án ứng dụng CNTT:
Mục tiêu cơ bản của Nghị quyết 49/CP ngày 4/8/1996 nhằm "Xây dựng những nền
móng bước đầu vững chắc cho một kết cấu hạ tầng về thông tin trong xã hội có khả năng
đáp ứng các nhu cầu cơ bản về thông tin trong quản lý nhà nước và trong các hoạt động
kinh tế xã hội, đồng thời tích cực xây dựng ngành công nghiệp công nghệ thông tin
(CNTT) thành ngành công nghiệp mũi nhọn của đất nước, nhiều dự án CNTT đẫ được
phát triển”. Các dự án CNTT tập trung chủ yếu vào các nội dung sau:
Ứng dụng CNTT trong các hoạt động quản lý và nghiệp vụ, trong đó trọng tâm là
Tin học hoá phục vụ điều hành và quản lý Nhà nước;
Xây dựng hệ thống các Cơ sở dữ liệu (CSDL) quốc gia và chuyên ngành;
Phát triển tiềm lực và cơ sở hạ tầng về CNTT...
Nội dung cơ bản của các dự án đó đề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 ứng dụng 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ự
6
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ý hoá 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ý hoá 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...
Từ đây, khái niệm dự án trong giáo trình này sẽ được hiểu là các dự án ứng dụng
CNTT, với sự tuân thủ các khái niệm, định nghĩa chung về dự án, với những nội dung đặc
thù về CNTT như đã nêu ở trên.
- CNTT = Phần cứng + Phần mềm, sự tích hợp phần cứng, phần mềm và con người
- Dự án ứng dụng CNTT = dự án liên quan đến phần cứng, phần mềm, và mạng
Ví dụ: Dự án xây dựng hệ thống tính cước và chăm sóc khách hàng tại các Bưu điện
Tỉnh/Thành, phục vụ hoạt động sản xuất kinh doanh.
1.2 Đặc trưng của một dự án
1.2.1 Mục tiêu của dự án
Mọi dự án đều bắt đầu khi có một vấn đề được đặt ra trong thực tế. Kèm theo đó
phải là những yêu cầu cần được giải quyết. Mục tiêu của dự án là giải quyết được vấn đề
này. Các mục tiêu của dự án nhất thiết phải được viết ra một cách rõ ràng ngay từ đầu, nếu
không khó có thể hoàn thành được
Từ các mục tiêu chung của việc phát triển CNTT như đã nêu ở trên, mỗi dự án
CNTT cần phải cụ thể hoá các mục tiêu của mình cả về mặt định tính và định lượng. Trên
thực tế hiện nay, điều này không đơn giản vì muốn có mục tiêu cụ thể, phải xác định được
yêu cầu thật cụ thể. Trong khi đó, có lẽ vì ứng dụng CNTT là công việc tương đối mới mẻ
ở nước ta, nên nhiều khi người dùng cũng khó nêu rõ yêu cầu của mình, và do đó các mục
tiêu được nêu lên hết sức chung chung. Điều này sẽ ảnh hưởng không ít tới sự thành bại
của dự án mà chúng ta sẽ phân tích kỹ về sau này.
1.2.2 Thời gian dự án
Đối với mỗi dự án phải xác định được một thời hạn tối đa phải hoàn thành, cụ thể
hơn là phải có thời điểm bắt đầu và thời điểm kết thúc. Thời điểm bắt đầu là khi vấn đề
giải quyết được đặt ra. Thời điểm kết thúc là hạn cuối cùng mà dự án phải hoàn thành.
Thời điểm này phải được xác định rõ ràng, nếu không dự án có thể sẽ không bao giờ kết
thúc. Trong thực tế, dự án luôn gặp phải những yêu cầu thay đổi khi đã ở gần giai đoạn
cuối cùng. Nếu các thay đổi đó được coi như là một phần của dự án, thì dự án khó mà
hoàn thành đúng hạn được. Vì vậy phải rất rõ ràng về thời điểm kết thúc, và hãy đưa
những yêu cầu thay đổi này vào một dự án mới.
Các dự án CNTT nằm trong khuôn khổ tổng thể của việc phát triển CNTT thường là
những dự án trung hạn, kéo dài một vài ba năm. Tuy nhiên, để thực hiện từng bước, ta có
thể phân các dự án đó thành các dự án nhỏ và hoàn thành trong thời gian từ vai ba tháng
đến một năm để đáp ứng từng mục tiêu cụ thể trong mục tiêu chung của một dự án lớn.

7
1.2.3 Kinh phí của dự án
Tương tự như trên, mọi dự án đều phải xác định một kinh phí tối đa, hay nói khác đi
là một khoản tiền tối đa mà dự án có thể sử dụng.
Mỗi dự án trong sự phát triển CNTT đều phải xác định tổng dự toán kinh phí cho
toàn bộ quá trình thực hiện, phân bổ theo từng năm thực hiện. Cho đến hiện nay, với các
dự án CNTT lấy kinh phí từ ngân sách Nhà nước cuối năm đều có việc xem xét lại các kết
qủa đã đạt được và trên cơ sở đó dự trù kế hoạch tài chính cho năm sau. Tuy nhiên, để đạt
được hiệu quả cao, đồng bộ và tạo ra được những thay đổi cơ bản trong hoạt động quản lý,
kinh tế xã hội, các dự án ứng dụng CNTT ở các Bộ ngành địa phương thường đòi hỏi
những đầu tư khá lớn mà ngân sách Nhà nước khó có thể đáp ứng cân đối hoàn toàn được.
Do vậy, các dự án đều được xác định nguồn vốn khác nhau có thể huy động được để đảm
bảo được kinh phí cần thiết thực hiện dự án.
1.2.4 Nguồn nhân lực
Là tất cả những người tham gia vào dự án. Mỗi dự án phải xác định danh sách
những người tham gia, từ mức quản lý dự án đến những người thực hiện, triển khai.
Nhân lực có thể huy động từ bên trong hoặc bên ngoài đơn vị, tuỳ theo nội dung
từng công việc trong dự án. Các dự án ứng dụng CNTT thường luôn đòi hỏi phải có sự
phối hợp chặt chẽ giữa các chuyên gia nghiệp vụ và chuyên gia tin học. Trong tình hình
triển khai dự án Tin học hoá quản lý nhà nước năm nay, do lực lượng cán bộ tin học tại
các đơn vị cơ sở còn thiếu, nên sự phối hợp với các chuyên gia bên ngoài là rất cần thiết.
1.2.5 Kết quả chuyển giao của dự án
Là kết quả của dự án hay nói khác đi là sản phẩm cuối cùng của dự án. Mục tiêu của
dự án thông thường là giải quyết vấn đề bằng việc tạo ra các kết quả này. Các kết quả và
các mục tiêu nhất thiết phải được viết ra rõ ràng, nếu không mục đích của dự án sẽ không
đạt được; sẽ tạo ra những kết quả sai khác đi và sẽ không ai hài lòng cả.
 1.3. Phân loại dự án ứng dụng CNTT:
Dự án trong thực tế rất đa dạng, có thể phân loại theo nhiều cách khác nhau:
1.3.1. Theo tầm cỡ dự án:
Dự án lớn: được đặc trưng bởi tổng kinh phí huy động lớn, số lượng các bên tham
gia đông, thời gian dàn trải, qui mô rộng lớn. Chúng đòi hỏi phải thiết lập các cấu trúc tổ
chức riêng biệt, với mức phân cấp trách nhiệm khác nhau, đề ra quy chế hoạt động và các
phương pháp kiểm tra chặt chẽ. Người quản lý các dự án này khó có thể đi sâu vào từng
chi tiết trong quá trình thực hiện. Nhiệm vụ chủ yếu của họ là, một mặt thiết lập hệ thống
quản lý và tổ chức, phân chia dự án thành các dự án bộ phận và phối kết các dự án bộ phận
đó, cho phép mỗi mức thực hiện tốt trách nhiệm của mình; mặt khác đảm nhận các mối
quan hệ giữa dự án với bên ngoài.
Việc xây dựng cả một hệ thống tin học lớn là một ví dụ. Dự án về Tin học hoá các
hoạt động điều hành và quản lý nhà nước tại các Bộ ngành và địa phương (gọi tắt là dự án
THH) có thể xem như là dứ án lớn đối với mỗi nơi. Người quản lý chính của dự án này

8
phải là một nhà tổ chức tốt, xác định được rõ mục tiêu đặt ra, cũng như các dự án nhánh
cần phải thực hiện và theo dõi phối hợp, thúc đẩy quá trình thực hiện toàn bộ dự án. Vai
trò này ở các địa phương đang là cấp UBND tỉnh, thành.
Dự án trung bình và nhỏ: không dòi hỏi kinh phí nhiều, thời gian ấn định ngắn,
không quá phức tạp...Ví dụ, viết tài liệu nghiên cứu khả thi hay lập trình cho một modul
đơn nào đó có thể coi như là một dự án nhỏ; việc tin học hoá điều hành và quản lý tại một
VP UBND là dự án ở mức trung bình... Người chủ dự án thường kiêm luôn cả việc quản lý
dự án (đối nội) lẫn việc quan hệ với các chuyên gia bên ngoài.
Kinh nghiệm các nước cho thấy những dự án trung bình hoặc nhỏ là những dự án cỡ
ít hơn 15 người trong một năm. Đó có thể là dự án mà 5 người làm trong 3 năm, hoặc 15
người làm trong một năm. Dĩ nhiên, càng ít người tham gia thì việc quản lý dự án càng đỡ
phức tạp hơn.
Về lý thuyết, quản lý dự án lớn hay nhỏ cũng đều theo những phương pháp luận
như nhau cả. Dự án lớn có thể gọi là chương trình; chương trình thường được phân thành
nhiều dự án nhỏ hơn. Trong trường hợp đó sẽ tồn tại nhiều mức quản lý dự án khác nhau,
và để phân biệt có thể gọi những người quản lý bằng những tên khác nhau như người quản
lý chương trình, người quản lý dự án, người điều hành dự án, nhóm trưởng,...Thậm chí,
mỗi một người tham gia vào dự án cũng phải biết cách tổ chức và quản lý công việc mà
mình được giao.
1.3.2 Theo nội dung của dự án:
Dự án trong sự phát triển ứng dụng CNTT có thể phân làm 3 loại chính:
Dự án ứng dụng CNTT trong công tác quản lý và hoạt động nghiệp vụ. Ví dụ, như
dự án Tin học hoá hoạt động quản lý nhà nước tại các Bộ ngành và địa phương.
Dự án xây dựng cơ sở hạ tầng về CNTT trong đó có xây dựng cơ sở hạ tầng về kỹ
thuật là dự án Mạng truyền thông dữ liệu quốc gia; xây dựng cơ sở hạ tầng về thông tin
như dự án các CSDL quốc gia; phát triển tiềm năng nhân lực như dự án xây dựng các khoa
CNTT tại các trường đại học chính của cả nước...
Các dự án nhằm thực hiện nhiệm vụ đã phân công cho các Bộ ngành như phát
triển nền Công nghiệp Công nghệ thông tin; đảm bảo đủ cán bộ tin học cho đất nước...
Nội dung của mỗi dự án có thể bao gồm nhiều vấn đề khác nhau, nhưng liên quan
rất chặt chẽ, hỗ trợ lẫn nhau. Ví dụ như các hạng mục trong dự án THH văn phòng, như
xây dựng hệ thống thông tin, xây dựng mạng máy tính, đào tạo phục vụ cho dự án...
1.3.3 Dự án một người hay dự án nhiều người
Môt dự án có thể được thực hiện bởi một người hoặc nhiều người. Việc quản lý dự
án sẽ khó khăn hơn khi có từ hai người trở lên. Nên sử dụng số người tối thiểu (và vẫn có
những thời hạn nhất định cho họ).
Như đã nêu trên, các dự án CNTT có tầm cỡ khó có thể do một người thực hiện mà
xong được. Do vậy vấn đề quản lý dự án một cách nghiêm túc là hết sức cần thiết và

9
không phải là dễ dàng; đặc biệt vai trò phối hợp của những người quản lý ở mức trên trong
những dự án như vậy rất quyết định cho sự thành bại của toàn bộ dự án.
1.3.4 Dự án nội bộ hay bên ngoài
Dự án nội bộ là dự án của một đơn vị tổ chức thực hiện nhằm phục vụ cho yêu cầu
của chính tổ chức đó. Dự án bên ngoài là dự án được thực hiện để đáp ứng yêu cầu cho
một đơn vị nơi khác. Ví dụ như một người ký hợp đồng thực hiện một dự án cho đơn vị
nào đó.
Như vậy, dự án THH Văn phòng UBND tỉnh nếu do VP chủ trì thực hiện thì sẽ là
dự án nội bộ của Văn phòng nhằm nâng cao hiệu quả hoạt động của mình. Nhưng nếu
cũng dự án này mà do Sở KHCN & MT chủ trì thì đối với Sở đây lại là dự án bên ngoài.
1.4 Các nhân tố liên đến dự quan đến dự án (Stackholders)
Các bên tham gia là tất cả những ai có liên quan hoặc bị ảnh hưởng bởi các hoạt
động của dự án, cụ thể:
- Có lợi ích nghiệp vụ trong kết quả dự án
- Liên quan trức tiếp tới dự án
- Đóng góp các nguồn lực cho dự án
Các bên liên quan dự án có những lợi ích, nhu cầu và ưu tiên khác nhau. Họ có thể
có những quan điểm khác nhau về việc dự án cố gắng hoàn thành những gì. Do đó, việc
xác định được các bên liên quan trong dự án càng sớm càng tốt, đặc biệt trong giai đoạn
xây dựng ý tưởng. Xem qua các bên liên quan còn chưa lộ diện sẽ là một rủi ro rất lớn đến
việc tổ chức thực hiện dự án. Thông thường, trong một dự án, các bên tham gia bao gồ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. Nhà tài trợ có trách
nhiệm 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.
 Đồng thời cho phép nhóm quản lý dự án sử dụng các nguồn lực, bảo vệ và cố vấn
cho nhóm quản lý dự án.
 Trong quá trình thực hiện dự án, nhà tài trợ có thêm các trách nhiệm xem xét lại các
tiến trình và chất lượng, cắt băng khai trương, khánh thành, ký và công bố tôn chỉ
dự án.
- Nhà quản lý dự án (giám đốc dự án):
 Làm việc với các đối tượng liên quan để đị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; chi huy nhóm dự án 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 thông báo cho 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ò là người trung gian giữa nhóm dự án và các đối tượng liên quan
- Nhà quản lý chức năng: Các nhà quản lý này chịu ảnh hưởng bởi các hoạt động
hay kết quả của dự án.
 Kiểm soát và đóng góp nguồn lực cho dự án (con người, trang thiết bị..)
10
  Có thể có những yêu cầu trái ngược với kết quả dự án
 Trong một số trường hợp là cấp trên của nhà quản lý dự án
- Khách hàng: Trong trường hợp nhà tài trợ không phải là đơn vị triển khai sản phẩm của
dự án thì nhà tài trợ chính là khách hàng. Đối tượng này có nhiệm vụ như sau:
 Nhận đầu ra của dự án
 Thanh toán cho đầu ra dự án
 Xác định nhu cầu cho đầu ra 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
- Nhà cung cấp: một dự án thường bao gồm nhiều hạng mục khác nhau, trong đó có
những hạng mục khi xem xét yêu tố khả thi, nhà tài trợ quyết định mua. Nhà cung cấp có
trách nhiệm cung cấp các thiết bị, sản phẩm hay dịch vụ cần thiết phục vụ cho hoạt đông
của dự án thông qua hình thức hợp đồng, để đảm bảo dự án đạt được mục tiêu đã đề ra.
1.5. Các lĩnh vực quản lý trong dự án (Knowledge areas)
Theo đối tượng quản lý, quản lý dự án bao gồm 9 lĩnh vực chính cần được xem xét,
nghiên cứu là:
- Lập kế hoạch tổng thể: lập kế hoạch cho dự án là quá trình tổ chức dự án theo
một trình tự lô gích, chi tiết hoá các mục tiêu của dự án thành những công việc cụ thể và
hoạch định một chương trình thực hiện những công việc đó nhằm đảm bảo các lĩnh vực
quản lý khác nhau của dự án đã được kết hợp một cách chính xác và đầy đủ.
- 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 ngoài phạm vi của dự án.
- 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 hoà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 hoàn thành
khi nào.
- Quản lý chi phí: Là quá trình dự toán kinh phí, giám sát thực hiện chi phí theo
tiến độ cho từng công việc và toà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ý 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ư).
- 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?
- Quản lý thông tin (truyền thông): Là quá trình bảo đảm các dòng thông tin
thông suốt, nhanh chóng và chính xác giữa các thành viên dự án và với các cấp quản lý,
giữa các tổ nhóm quản lý dự án. Thông qua quản lý thông tin có thể trả lời các câu hỏi: ai

11
cần thong tin về dự án? mức độ chi tiết? các nhà quản lý dự án cần báo cáo cho họ bằng
cách nào?
- 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.
- Quản lý hợp đồng và các hoạt động mua sắm: Là quá trình lựa chọn nhà cung
cấp hàng hoá và dịch vụ; thương lượng với họ, quản lý các hợp đồng và điều hành việc
mua bán nguyên vật liệu, trang thiết bị, dịch vụ nhằm giải quyết cácvấn đề: bằng cách nào
cung cấp các hàng hoá, vật liệu cần thiết cho dự án? tiến độ cung cấp, chất lượng cung cấp
đến đâu?
1.6 Vai trò của người quản lý dự án
Phần lớn kiến thức cần thiết để quản lý dự án là kiến thức riêng của ngành QLDA.
Ngoài ra, người quản trị dự án còn phải có kiến thức và kinh nghiệm trong:
- Quản lý tổng quát
- Lãnh vực ứng dụng của dự án
Các kỹ năng cần thiết của nhà quản lý dự án:
- Kỹ năng lãnh đạo: Lãnh đạo là kỹ năng cơ bản để nhà quản lý dự án chỉ đạo, định
hướng, khuyến khích và phối hợp các thành viên trong nhóm cùng thực hiện dự án. Đây là
kỹ năng quan trọng nhất. Nó đòi hỏi các nhà quản lý dự án có những phẩm chất cần thiết,
có quyền lực nhất định để thực hiện thành công mục tiêu dự án.
- Kỹ năng lập kế hoạch và kiểm soát dự án: Nhà quản lý dự án phải là người chịu
trách nhiệm về kế hoạch tổng thể trước nhà tài trợ và khách hàng. Vì vậy, nhà quản lý dự
án phải có kỹ năng lập lịch trình dự án và xác định các tiêu chí để đánh giá công việc hoàn
thành. Đồng thời, nhà quản lý dự án phải biết thiết lập các quy trình hệ thống để đánh giá
và kiểm soát mức độ thành công của bảng kế hoạch.
- Kỹ năng giao tiếp và thông tin trong quản lý dự án: Nhà quản lý dự án có trách
nhiệm phối hợp, thống nhất các hoạt động giữa các bộ phận chức năng và những cơ quan
liên quan để thực hiện các công việc của dự án nên bắt buộc phải thành thạo kỹ năng giao
tiếp. Nhà quản lý dự án phải có kiến thức, hiểu biết các công việc của các phòng chức
năng, có kiến thức rộng về một số lĩnh vực kỹ thuật. Nhà quản lý dự án cũng cần giỏi kỹ
năng thông tin, truyền thông, kỹ năng chia sẻ thông tin giữa các thành viên dự án và những
người liên quan trong quá trình triển khai dự án.
- Kỹ năng thương lượng và giải quyết khó khăn vướng mắc: Nhà quản lý dự án
trong quá trình thực hiện trọng trách của mình có quan hệ với rất nhiều nhóm. Đồng thời,
cùng với sự phát triển tổ chức của dự án, trách nhiệm của nhà quản lý dự án ngày càng
tăng nhưng quyền lực của họ được cấp không tương xứng. Do thiếu quyền lực, bắt buộc
các nhà quản lý phải có kỹ năng thương lượng giỏi với các nhà quản lý cấp trên và những
người đứng đầu các bộ phận chức năng chuyên môn nhằm tranh thủ tối đa sự quan tâm,

12
ủng hộ của cấp trên, người đứng đầu trong việc giành đủ nguồn lực cần thiết cho hoạt
động của dự án.
- Kỹ năng tiếp thị và quan hệ khách hàng: Một trong những nhiệm vụ quan trọng
nhất của nhà quản lý dự án là trợ giúp các đơn vị, doanh nghiệp trong hoạt động
Marketing. Làm tốt công tác tiếp thị sẽ giúp đơn vị giữ được khách hàng hiện tại, tăng
thêm khách hàng tiền năng.
- Kỹ năng ra quyết định: Lựa chọn phương án và cách thức thực hiện các công
việc dự án là những quyết định rất quan trọng, đặc biệt trong những điều kiện thiếu thông
tin và có nhiều thay đổi, biến động. Để ra được quyết định đúng và kịp thời cần nhiều kỹ
năng tổng hợp của nhà quản lý như: kỹ năng tổ chức bao gồm lập kế hoạch, xác định mục
tiêu, phân tích; kỹ năng xây dựng nhóm như thấu hiểu, thúc đẩy, tinh thần đồng đội và kỹ
năng công nghệ liên quan đến kinh nghiệm, kiến thức về dự án.
1.7 Các giai đoạn của dự án (Project phases)
Dự án là một thực thể thống nhất, thời gian thực hiện xác định và có độ bất định
nhất định nên các tổ chức, đơn vị thường chia dự án thành một số giai đoạn để quản lý
thực hiện. Mỗi gian đoạn được đánh dấu bằng việc thực hiện một hay nhiều công việc.
Tổng hợp các giai đoạn này được gọi là chu kỳ hay vòng đời của dự án. Chu kỳ của dự án
xác định thời điểm bắt đầu, thời điểm kết thúc và thời gian thực hiện dự án. Chu kỳ dự án
xác định những công việc nào sẽ được thực hiện trong từng giai đoạn và ai sẽ tham gia
thực hiện. Nó cũng chỉ ra những công việc nào còn lại ở giai đoạn cuối sẽ thuộc về hoặc
không thuộc về phạm vi của dự án. Thông qua chu kỳ dự án có thể nhận thấy một số đặc
điểm:
- Mức chi phí và yêu cầu nhân lực thường là thấp khi mới bắt đầu dự án, tăng cao
hơn vào thời kỳ phát triển, nhưng giảm nhanh khi dự án bước vào giai đoạn kết thúc.
- Xác suất hoàn thành dự án thành công thấp nhất và do đó mức độ rủi ro là cao nhất
khi dự án bắt đầu thực hiện. Xác suất thành công sẽ tăng lên khi dự án bước qua các giai
đoạn sau.
- Khả năng ảnh hưởng của nhà tài trợ tới đặc tính cuối cùng của sản phẩm dự án và
do đó tới chi phí là cao nhất vào thời kỳ bắt đầu và giảm mạnh khi dự án tiếp tục trong các
giai đoạn sau.
Vòng đời dự án xác định các giai đoạn mà một dự án phải trải qua tính từ lúc bắt
đầu cho tới khi kết thúc dự án. Các giai đoạn thường có cơ chế tự hoàn thiện kiểm soát
quản lý thông qua các công việc giám sát, đánh giá. Điển hình, sự chuyển tiếp giữa các
giai đoạn thường có điểm mốc đánh dấu và một kết quả chuyển giao cụ thể, kèm theo
những phê duyệt, tán thành của nhà tài trợ trước khi bước sang giai đoạn tiếp theo.
Vòng đời phát triển dự án (Systems Development Life Cycle - SDLC) là khung làm
việc dùng để mô tả các giai đoạn trong quá trình phát triển và duy trì hệ thống. SDLC cơ
bản là nhóm các giai đoạn của dự án. Các giai đoạn của dự án thay đổi tùy theo dự án, tổ
chức hoặc lãnh vực kinh doanh, thường được chia thành 4 giai đoạn như sau:

13
 - Giai đoạn xây dựng ý tưởng: Xây dựng ý tưởng là việc xác định bức tranh toàn
cảnh về mục tiêu, kết quả cuối cùng của dự án và phương pháp thực hiện dẫn tới kết quả
đó. Xây dựng ý tưởng dự án bắt đầu ngay khi hình thành dự án. Khảo sát-tập hợp số liệu,
xác định yêu cầu, đánh giá rủi ro, dự tính nguồn lực, so sánh lựa chọn dự án, … là những
công việc triển khai và cần được quản lý trong gian đoạn này. Quyết định lựa chọn dự án
là những quyết định chiến lược dựa trên mục đích, nhu cầu và các mục tiêu lâu dài của tổ
chức, doanh nghiệp. Trong giai đoạn này những nội dung được xét đến là mục đích yêu
cầu của dự án, tính khả thi, lợi nhuận tiềm năng, mức độ chi phí, mực độ rủi ro và ước
lượng các nguồn lực cần thiết. Đồng thời cũng cần làm rõ hơn nữa ý tưởng dự án bằng
cách phác thảo những kết quả và phương pháp thực hiện trong điều kiện hạn chế về nguồn
lực. Phát triển ý tưởng dự án không cần thiết phải lượng hoá hết bẳng các chỉ tiêu nhưng
nó phải ngắn gọn, được diễn đạt trên cơ sở thực tế. Đối với các dự án CNTT, tính hệ thống
và khả năng tương hợp có vai trò quan trọng, dựa trên nền tảng một kiến trúc CNTT do
nhà nước quy định. Kiến trúc này có vai trò hướng dẫn việc xây dựng các dự án sao cho
chúng có thể kết nối, tương hợp với nhau, tạo ra một mạng quốc gia liên thông, thống nhất
cơ chế kết nối, chia sẻ và cung cấp dịch vụ. Kết thúc giai đoạn này là sự phê duyệt về chủ
trương thực hiện dự án (ý tưởng).
- Giai đoạn phát triển: Là giai đoạn chi tiết xem dự án cần được thực hiện như thế
nào, nội dung chủ yếu của giai đoạn này tập trung vào công tác thiết kế và lập kế hoạch.
Đây là giai đoạn chứa đựng những công việc phức tạp nhất của dự án. Nội dung chủ yếu
bao gồm:
+ Thành lập nhóm dự án, xác định cấu trúc tổ chức.
+ Lập kế hoạch tổng thể
+ Phân tích, lập bảng chi tiết công việc – WBS
+ Lập kế hoạch tiến độ thời gian
+ Lập kế hoạch ngân sách
+ Lập kế hoạch nguồn lực cần thiết
+ Lập kế hoạch chi phí
+ Xin phê chuẩn thực hiện tiếp
Kết thúc giai đoạn này, tiến trình dự án có thể bắt đầu. Thành công của dự án phụ
thuộc rất lớn vào chất lượng và sự chuẩn bị kỹ lưỡng của các kế hoạch trong giai đoạn
này.
- Giai đoạn thực hiện: Là giai đoạn quản lý tổ chức triển khai các nguồn lực bao
gồm các công việc cần thiết như xây dựng phòng ốc, hệ thống, lựa chọn công cụ, mua sắm
trang thiết bị, lắp đặt … Đây là giai đoạn chiếm nhiều thời gian và nỗ lực nhất. Những vấn
đề cần xem xét trong giai đoạn này là những yêu cầu kỹ thuật cụ thể nhằm so sánh, đánh
giá lựa chọn công cụ thiết bị, kỹ thuật lắp ráp, mua thiết bị chính, phát triển hệ thống. Kết
thúc giai đoạn này, các hệ thống được xây dựng và kiểm định, hệ thống có thể chuyển
sang giai đoạn vận hành, đưa vào khai thác thử nghiệm.

14
 - Giai đoạn kết thúc: Trong giai đoạn kết thúc của chu kỳ dự án, cần thực hiện
những công việc còn lại như hoàn thành sản phẩm, bàn giao hệ thống, công trình và những
tài liệu liên quan; đánh giá dự án, giải phóng các nguồn lực. Dưới đây là một số các việc
cụ thể:
+ Hoàn chỉnh và lập kế hoạch lưu trữ hồ sơ liên quan đến dự án
+ Kiểm tra lại sổ sách kế toán, tiến hành bàn giao và báo cáo
+ Thanh quyết toán
+ Đối với phát triển, xây dựng hệ thống cần chuẩn bị và bàn giao sổ tay hướng dẫn
lắp đặt, quản trị và sử dụng
+ Bàn giao dự án, lấy chữ ký của khách hàng về việc hoàn thành
+ Bố trí lao động, giải quyết công ăn việc làm cho những người từng tham gia dự án
+ Giải phóng và bố trí lại thiết bị
Các dự án thường bao gồm một số quy trình liên kết với nhau. Các quy trình này lặp
đi lặp lại và diễn ra trong từng giai đoạn của vòng đời dự án và tác động lẫn nhau. Cả 5
quy trình quản lý dự án đều hoạt động tại từng giai đoạn vòng đời dự án, nhưng mỗi quy
trình hoạt động có mức độ khác nhau tuỳ theo mỗi giai đoạn. Chẳng hạn như sự lặp lại của
quá trình khởi tạo tiến hành ở phần đầu của mỗi gian đoạn nhằm tập trung vào các yêu cầu
và mục tiêu nghiệp vụ trong giai đoạn đó. Các quy trình này là:
- Khởi tạo: Sự cấp phép cho dự án hay giai đoạn nào đó
- Lập kế hoạch: Sàng lọc các mục tiêu của dự án và lựa chọn phương án hành động
tốt nhất để đạt được các mục tiêu đó
- Thực thi kế hoạch: Quản lý, phân bổ các nguồn lực để thực hiện kế hoạch
- Kiểm soát: Là giai đoạn giám sát và xem xét mức độ tiến hành trên cơ sở nguyên
tắc nhằm xác định những điểm khác biệt so với kế hoạch đã đề ra để thực hiện các hoạt
động cần thiết nhằm hiệu chỉnh, đảm bảo dự án đang đi đúng hướng, đáp ứng các mục tiêu
của dự án ban đầu.
- Kết thúc: Đạt được ký kết hoàn tất từ nhà tài trợ và đưa dự án hoặc giai đoạn đó
đến một kết thúc theo thứ tự
1.8 Những vấn đề quản lý dự án ứng dụng CNTT:
1.8.1 Mục đích của quản lý dự án ứng dụng CNTT
Mục đích cuối cùng của việc quản lý dự án là nhằm đảm bảo cho dự án được thực
hiện thành công. Một dự án được đánh giá là thành công nếu như đáp ứng được 4 vấn đề
cơ bản sau:
Sản phẩm cuối cùng của dự án thực sự đáp ứng các yêu cầu của người dùng, đảm
bảo thời gian và kinh phí không vượt quá 10-20% dự tính ban đầu;
Người dùng hài lòng với quá trình thực hiện dự án, thực sự tham dự và góp phần
công sức của mình trong các hoạt động của dự án. Đặ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;

15
 Các cấp quản lý phía trên của dự án (BCĐ CNTT, Bộ Tài chính...) được cung cấp
đầy đủ thông tin về tình hình thực hiện dự án.
Những người thực hiện dự án cũng phấn khởi, không bị quá gò bó, tích luỹ được
kinh nghiệm, tăng thêm thu nhập...

1.8.2 Các bước quản lý dự án ứng dụng CNTT

Lập kế hoạch:
Định ra mục tiêu của dự án: kết quả cuối cùng cần đạt được, thời gian phải hoàn
thành, các tiêu chuẩn về kỹ thuật ...
Xác định các phương tiện cần huy động (nhân lực, thông tin, thiết bị,...) tất cả
những gì cần được tính vào kinh phí của dự án
Xác định cách thức tổ chức quản lý và thực hiện.
Quản lý các rủi ro
Rủi ro là những điều xảy ra và làm cho dự án phải kéo dài hơn hoặc phải chi phí
nhiều hơn so với kế hoạch đã định. Vấn đề là nếu lường trước được các vấn đề có thể xảy
ra để đề xuất các biện pháp theo dõi và hành động kịp thời thì tốt hơn nhiều so với việc
chờ chịu một cách bị động.
Quản lý nhân sự:
Động viên những người tham gia, kết phối hoạt động của họ, tạo điều kiện khuyến
khích họ làm việc tích cực hơn, hiệu quả hơn.
Theo dõi dự án:
Người quản lý dự án phải theo dõi để đảm bảo mọi việc xảy ra theo đúng kế hoạch.
Việc theo dõi có thể được xác định gồm 3 vấn đề chính:
1. Giám sát - có các hệ thống có thể cho biết rõ dự án đang tiến triển thế nào so với
kế hoạch. Hệ thống tốt nhất là hệ thống có thể báo động trước cho người quản lý dự án
biết về các vấn đề nảy sinh, có thể dẫn đến sự thay đổi chương trình hay mục tiêu của dự
án về thời hạn, kinh phí và kết quả.
2. Biết được có vấn đề thực sự nảy sinh hay không. Có thể, dự án không được thực
hiện theo sát kế hoạch đề ra một cách chính sác, nhưng điều đó không có ý nghĩa là sẽ gây
ra rắc rối. Ví dụ một công việc (không thuộc đường Gant) không được hoàn thành đúng
thời hạn đã định, thì không thể coi là một vấn đề.
3.Phản ứng đối với vấn đề: có thể là khắc phục các nguyên nhân gây ra vấn đề, hoặc
là thay đổi kế hoạch. Nếu kế hoạch bị thay đổi phải thông báo cho những người có liên
quan tới sự thay đổi này.
Tóm lại, quản lý dự án không chỉ đơn thuần là thực hiện một khối công việc đã
được vạch định sẵn, mà bao gồm cả chính việc hình thành nên khối công việc đó. Hơn thế
nữa, trong giai đoạn xác lập dự án, người quản lý phải tập trung nhiều công sức hơn so với
giai đoạn thực hiện - khi đã có thể giao nhiệm vụ cụ thể cho các cán bộ kỹ thuật được rồi.

16
1.8.3 Nguyên nhân khiến dự án ứng dụng CNTT thất bại:
Theo thống kê chung trên thế giới :
33% các dự án bị huỷ bời vì
Vượt qua giới hạn về thời gian hoặc kinh phí;
Công nghệ đã bị thay đổi quá nhiều so với hiệu quả mà dự án sẽ mang lại;
Người dùng hoặc khách hàng không cần tới nó nữa;
Những lý do chính trị.
50 - 100% quá tải
Một dự án mà chi phí của nó vượt quá 50% kinh phí cho phép
hoặc kéo dài quá 50% thời gian dự định thì coi như là đã thất bại.
Không được sử dụng:
Nhiều dự án không bao giờ đưa vào sử dụng được. Lý do có thể là:
Dự án không giải quyết được vấn đề đặt ra;
Quá khó sử dụng,
Không có đào tạo.
Nguyên nhân sâu xa của việc thất bại có thể xuất phát:
Ngay từ khi bắt đầu dự án, do thiếu một kế hoạch tốt:
Đa số dự án không thể triển khai được vì không xuất phát từ thực tế cụ thể. Người ta
bắt tay vào việc lập chương trình mà không hiểu rõ tại sao lại có dự án đó và chính xác là
cần phải hoàn thành cái gì; nói cách khác, không có kế hoạch gì cả. Nếu không đánh giá
xem là sẽ cần phải tốn bao nhiêu công sức để làm việc đó, ta sẽ không thể hình dung được
số lượng nhân công cần thiết, mà đó chính là chi phí chính của dự án.
Nếu không thống nhất rõ ràng trước với người dùng về những gì họ yêu cầu dự án
phải đạt được, thì sau này sẽ rất khó khăn để người dùng chấp nhận các kết quả của dự án.
Người ta có thể hứa hẹn với nhau nhiều điều, nhưng tất cả những cam kết đó đều phải
được ghi nhớ lại dưới dạng các văn bản.
Việc đặt ra những thời hạn và kinh phí không sát thực tế thường khiến cho những
nhóm thực hiện không thể nào thực hiện được lời hứa của mình.
Trong các bước phát triển tiếp:
Dự án có thể mắc sai lầm trong giai đoạn phân tích và thiết kế. Ví dụ, nếu các kết
quả phân tích và thiết kế không được tư liệu hoá lại một cách chính xác, rõ ràng, thì sẽ gây
ra những cách hiểu khác nhau về sau này.
Nếu người quản lý dự án không phân công rõ nhiệm vụ của từng người một, thì ai
cũng nghĩ rằng đó không phải là trách nhiệm, mà là trách nhiệm của người khác, rồi cuối
cùng sẽ chẳng có gì hoàn thành xong cả.
Thiếu hoặc không hiểu rõ các công cụ hỗ trợ cho việc phát triển hệ thống cũng như
cho việc quản lý - theo dõi dự án, sẽ làm ảnh hưởng đến thời gian và kết quả của dự án.
Không làm rõ lịch điều phối nhân sự và thông báo trước cho các đối tượng liên
quan, thì sẽ rất khó khăn khi cần huy động nhân lực cần thiết để hoàn thành công việc.

17
 Việc bắt đầu viết chương trình trước khi bản thiết kế được hoàn thành (mà trước đây
đã trở thành thói quen của không ít lập trình viên) sẽ khiến cho dự án khó mà thành công
một cách tốt đẹp (vì không tính hết mọi vấn đề), hoặc sẽ tốn thêm nhiều công sức để mà
điều chỉnh về sau này.
Không kịp thời phát hiện ra các vấn đề chính nảy sinh trước và sau giai đoạn phát
triển. Đó là do thiếu sự rà soát chi tiết về mặt kỹ thuật (thiết kế, chương trình, tài liệu...) và
xem xét lại về mặt quản lý (đề cương, kinh phí, lịch trình...) một cách khách quan từ bên
ngoài.
Sự thay đổi công tác của các thành viên tham gia dự án cũng là một nguyên nhân
phải tính đến. Ví dụ, nếu như ta luôn chỉ phụ thuộc vào một người lập trình duy nhất, thì
khi người đó không tham gia được nữa vào dự án, thì dự án có nguy cơ bị bế tắc nếu như
ta chưa kịp chuẩn bị người thay thế.
Thiếu các chuẩn mực, qui định trong quá trình phát triển cũng làm cho dự án bị thất
bại ở một mức độ nào đó. Ngay cả trong việc quản lý dự án CNTT, chúng ta cũng cần phải
thống nhất với nhau về một phương pháp luận chung - đó cũng là một loại chuẩn.
Và cuối cùng là quá nhiều người tham gia dự án chưa chắc đã đẩy nhanh tốc độ mà
có khi còn làm cho dự án chậm đi vì phải thêm việc đào tạo, huấn luyện, thêm việc giao
tiếp giữa mọi người...tức là thêm thời gian và kinh phí.
Trong giai đoạn kết thúc:
Khi đã đến thời hạn cuối cùng, hoặc khi đã hết kinh phí mà mọi chuyện vẫn chưa
xong, thì yêu cầu đối với dự án thường bị thoả hiệp. Người ta nghĩ rằng một phần (lớn)
công việc đã hoàn thành rồi thế là được, vẫn còn hơn là không có gì. Thế nhưng, đối với
nhiều người dùng thì phải giải pháp toàn bộ mới đáp ứng yêu cầu của họ, chứ chỉ có một
phần thì ít khi chấp nhận được.
Một số ứng dụng được tạo ra mà không có sự rà lỗi cẩn thận. Điều đó gây nên ấn
tượng ban đầu không hay và gây khó khăn cho việc đưa vào sử dụng.
Một số hệ thống đưa ra không đáp ứng được đúng các chỉ tiêu kỹ thuật đã đề ra.
Nếu chi phí cho việc bảo trì quá lớn thì hệ thống cũng có thể bị ngừng hoạt động.
Trong nhiều trường hợp, nếu ở thời điểm nào đó mà chứng minh được rằng không
có ích lợi gì mà tiếp tục dự án nữa thì cũng nên mạnh dạnh xem xét đến việc phải ngừng
dự án lại.

1.9 Các giai đoạn thực hiện dự án ứng dụng CNTT

Bảy giai đoạn của dự án CNTT
Quá trình thực hiện dự án CNTT thành bảy giai đoạn chính sau: Xác định, phân
tích, thiết kế, thực hiện, kiểm thử hệ thống, kiểm thử chấp nhận và vận hành. Có thể nói
cách phân đoạn như vậy tương đối hợp lý và phù hợp chung với những phương pháp luận
về thực hiện một dự án CNTT mà chúng ta đã có dịp làm quen.

18
 Mục đích của giai đoạn này là có được một sự hiểu biết đầy đủ về các vấn đề, các
yêu cầu của người dùng có thể hình dung được đầy đủ về các vấn đề của dự án, ước lượng
được giá thành và thời gian thực hiện.
*Giai đoạn xác định:
Các hoạt động chính cần làm trong giai đoạn này là:
Tìm hiểu thấu đáo về các vấn đề của người dùng và những gì cần thiết để giải quyết
vấn đề đó.
Cần phải quyết định có thực hiện hay không thực hiện dự án. Ta cần phải biết chắc
rằng dự án là khả thi và có nhiều cơ hội để mà thành công.
Nếu dự án có thể thực hiện được, cần phân tích đánh giá các rủi ro có thể xảy ra và
chi tiết hoá tất cả các kết quả cần đạt được, khi nào và với giá thành bao nhiêu.
Cũng từ giai đoạn này, ta phải bắt đầu ngay các hoạt động về quản lý dự án, xem
xét, báo cáo và tư liệu hoá; và tiệp tục tiến hành các hoạt động đó cho đến khi kết thúc dự
án.
* Giai đoạn phân tích
 Mục tiêu
Giai đoạn phân tích nhằm mục tiêu xác định chính xác hệ thống thông tin dự định
xây dựng sẽ “làm gì" cho người sử dụng, và nó sẽ hoà nhập vào môi trường của người sử
dụng như thế nào, nói cách khác, trong giai đoạn này phải xác định mọi yêu cầu, mọi vấn
đề đặt ra mà hệ thống thông tin phải đáp ứng. Mặc dù theo lý thuyết thì trong giai đoạn
phân tích chỉ cần xác định được xem hệ thống sẽ phải làm những gì. Tuy nhiên trên thực
tế, kết thúc giai đoạn này người quản lý dự án phải hình dung ra được hệ thống sẽ thực
hiện các chức năng chính đó như thế nào?
Trong nhiều trường hợp, ta không thể chuyển sang giai đoạn thiết kế sâu được nếu
như chưa hoàn thành xong cơ bản giai đoạn phân tích này.
Các công việc phải thực hiện
Các công việc của giai đoạn phân tích bao gồm:
Công việc chính là viết tài liệu xác định mọi chức năng, mọi hành vi của hệ thống.
Tài liệu này được gọi là tài liệu đặc tả chức năng (Functional Specifications - FS).
Sau khi viết xong Đặc tả chức năng, chúng ta đã có hiểu biết đầy đủ hơn về hệ
thống thông tin cần phải xây dựng so với giai đoạn xác định, do đó cần xem xét lại kế
hoạch dự án ban đầu. Trên cơ sở xem lại viết Kế hoạch dự án cuối cùng (Final Project
Plan FPP).
Trong trường hợp dự án được thực hiện theo phương pháp hai bước thì kết thúc giai
đoạn phân tích chính là kết thúc bước 1, ta cần đề xuất và đánh giá thực hiện bước hai. Đề
xuất này được thể hiện qua việc viết Tài liệu để xuất phát triển (Development Proposal -
DP).
Trong giai đoạn phân tích, ta cũng thực hiện một phần công việc của giai đoạn thiết
kế. Đó là Thiết kế tổng thể (thiết kế mức tổng quát - Top level design - TLD). Như vậy ở

19
giai đoạn này không phải chúng ta chỉ xem xét hệ thống sẽ thực hiện các chức năng như
thế nào.
Toàn bộ các công việc vừa được môt tả thực chất tương ứng với giai đoạn viết các
dự án CNTT của các Bộ, ngành, các Tỉnh, Thành phố vừa qua.
* Giai đoạn thực hiện
 Mục đích: Thiết kế chi tiết và cài đặt, ráp nối các thành phần, các module trong hệ
thống bao gồm cả phần cứng và phần mềm.
Các công việc chính:
Thiết kế chi tiết các module và lập trình
Chế tạo các phần trong hệ thống
Dự toán và tổ chức mua thiết bị phần cứng/phần mềm
Chỉnh sản phẩm cho phù hợp với yêu cầu thực tế
Kiểm thử từng phần các module, phân hệ
Biên soạn tài liệu
*Giai đoạn kiểm thử hệ thống
 Mục đích:
Tính hợp tất cả các phần cùng hoạt động và kiểm tra căn kẽ tất cả các phần, các
mođun theo các chức năng đã ghi trong bản thiết kế bao gồm cả phần cứng và phần mềm.
Các công việc chính:
Tích hợp và kiểm thử từng phân hệ ứng và các dự án con
Tích hợp và kiểm thử đối với toàn bộ hệ thống lớn.
*Giai đoạn kiểm thử chấp nhận
 
Mục đích: Các công việc trong giai đoạn này chỉ để nhằm có được một xác nhận
bằng văn bản từ phía người sử dụng rằng ê kíp dự án đã giao nộp sản phẩm như đã giao
kèo.
Các công việc chính: - Trình diễn cho khách hàng, người sử dụng các chức năng
cơ bản của hệ thống.
Ký nhận của người sử dụng
Thực hiện các kiểm thử đã đưa ra trong kế hoạch kiểm thử chấp nhận đã xây dựng
trong giai đoạn kiểm thử hệ thống
* Giai đoạn vận hành và khai thác hệ thống
  Mục đích
Chuyển giao toàn bộ hệ thống trên diện rộng cho tất cả các mối và cho từng người
sử dụng.
Khai thác hệ thống giải các bài toán thực tế.
Các công việc chính
Cài đặt hệ thống
Đào tạo người sử dụng
20
 Giúp đỡ tổ chức khai thác hệ thống
Bảo hành
Kiểm toán sau khi hoàn thành dự án.
1.10 Nhân sự của các bên liên quan tham gia thực hiện dự án ứng dụng CNTT:
Trong các dự án ứng dụng CNTT lớn thông thường các đơn vị và nhân sự có liên
quan đến một dự án về tin học hoá phục vụ điều hành và quản lý nhà nước trong sự phát
triển ứng dụng CNTT. Tình hình tiến độ và kết quả thực hiện của dự án là điều mà những
nơi (người) đó cần phải quan tâm đến.
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ỹ
Nhân viên kỹ thuật trong mỗi thuật
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. Đây là những đối tượng sẽ được tập trung phân tích kỹ trong phần liên
quan đến nhân sự của dự án trong cuốn sách này.
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 ngoà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.

21
 Câu hỏi chương 1: Những đặc điểm cơ bản của dự án ứng dụng CNTT, sự khác biệt của
dự án ứng dụng CNTT và những dự án thông thường?

Chương 2: Các nội dung cơ bản của quản lý dự án

ứng dụng CNTT

Quy trình quản lý dự án ứng dụng CNTT là việc thực hiện một dự án với hàng trăm
công việc (tasks) phải được phải thực hiện, nhiều công việc trong số chúng phụ thuộc lẫn
nhau. Quản lý một cách hiệu quả quy trình này là cực kỳ quan trọng để dẫn đến thành
công. Tập hợp các hoạt động được thực hiện bởi người quản lý dự án được xác định cụ thể
trong quy trình quản lý dự án. Điều này khá chuẩn, có ba giai đoạn chính:
- Hoạch định dự án
- Thực hiện dự án
- Kết thúc dự án
Trong giai đoạn lập kế hoạch cho dự án (project planning), người quản lý dự án xem
xét lại các cam kết trong hợp đồng và tạo ra một kế hoạch để đáp ứng chúng. Việc tạo một
kế hoạch cho dự án liên quan đến việc định nghĩa một quy trình vòng đời (chu kỳ
sống/lifecycle process) để được thực hiện theo, ước lượng nỗ lực (effort) và thời gian hoàn
thành (schedule), chuẩn bị thời gian biểu chi tiết cho các công việc, v.v. Nó cũng bao gồm
các kế hoạch về chất lượng và quản lý cấu hình cũng như quản lý rủi ro. Trong giai đoạn
này, các hoạt động chính của người quản lý dự án như sau:
- Thực hiện các công việc khởi động và quản lý.
- Tạo một kế hoạch cho dự án và ước lượng thời gian hoàn thành (schedule).
- Xác định các mục tiêu của dự án.
-Xác định một quy trình chuẩn phù hợp để thực hiện dự án.
-Thay đổi quy trình chuẩn để đáp ứng được các yêu cầu (requirements) của dự án.
-Định nghĩa một quy trình để quản lý các thay đổi yêu cầu.
-Ước lượng các nỗ lực (effort).
-Lập kế hoạch cho nguồn nhân lực và tổ chức nhóm.
- Xác định các cột mốc (milestones) của dự án và ước lượng thời gian hoàn thành.
-Xác định các mục tiêu chất lượng và kế hoạch chất lượng để đạt được chúng.
- Lập kế hoạch để phòng ngừa lỗi.
- Xác định rủi ro và lập kế hoạch để giảm thiểu chúng.
- Xác định một kế hoạch đo lường đối với dự án.
- Xác định một kế hoạch đào tạo (training plan) cho dự án.
- Xác định các thủ tục theo dõi dự án.
22
 - Thực hiện xem xét lại các kế hoạch và thời gian hoàn thành dự án.
- Có được ủy quyền từ người quản lý cấp cao.
- Xác định và xem xét lại kế hoạch quản lý cấu hình.
- Nhắc nhở nhóm dự án thực hiện theo kế hoạch quản lý dự án.
Ngoài người quản lý dự án, giai đoạn này liên quan đến các khách hàng, một đại
diện của SEPG, và người quản lý kinh doanh của dự án. Tiêu chuẩn nhập là hợp đồng
hoặc uỷ quyền dự án đã có. Tiêu chuẩn xuất là kế hoạch dự án đã được lập tài liệu và
nhóm đã xem xét lại.
Giai đoạn thứ hai, thực hiện dự án (project execution), liên quan đến việc thực
hiện kế hoạch dự án, theo dõi tình trạng của dự án, và làm các hiệu chỉnh bất cứ khi nào
hiệu suất của dự án đi chệch với kế hoạch. Nói cách khác, nó liên quan đến việc theo dõi
và kiểm soát việc thực hiện theo quy trình của dự án. Giai đoạn này là dài nhất trong quy
trình quản lý dự án, kết hợp với các công việc định kỳ như giám sát tình trạng dự án và
chất lượng và thực hiện bất cứ hiệu chỉnh nào nếu cần thiết. Trong giai đoạn này, người
quản lý dự án thực hiện các hoạt động chính sau:
- Thực hiện dự án theo kế hoạch dự án.
- Theo dõi tình trạng dự án.
- Xem xét lại tình trạng dự án với người quản lý cấp cao. - Giám sát xem có tuân
theo quy trình dự án đã được xác định.
- Phân tích các lỗi và thực hiện các hoạt động ngăn chặn lỗi.
- Giám sát hiệu suất ở mức chương trình (program level).
- Tiến hành xem xét lại tại các cột mốc và hoạch định lại nếu cần thiết. Các thành
viên khác trong nhóm cũng tham gia trong giai đoạn này. Tiêu chuẩn nhập là kế hoạch dự
án được hoàn thành và phê duyệt và tiêu chuẩn xuất là tất cả các sản phẩm công việc
(work products) được chấp nhận bởi khách hàng.
Giai đoạn cuối cùng của quy trình quản lý dự án, kết thúc dự án (project closure),
liên quan đến việc kết thúc dự án một cách có hệ thống sau khi khách hàng chấp nhận.
Mục tiêu chính ở đây là để học hỏi từ kinh nghiệm để mà quy trình có thể được cải tiến.
Phân tích dữ liệu của các dự án đã hoàn thành cấu thành các hoạt động chính; số đo được
phân tích, các sản phẩm của quy trình (process assets) (nhiều tài liệu, như các bản mẫu
(templates) và hướng dẫn (guidelines) được sử dụng để hỗ trợ trong việc quản lý quy
trình) được thu thập để sử dụng trong tương lai, và các bài học được ghi nhận. Bởi vì học
từ dự án là mục tiêu chính, đây là một nhóm các hoạt động có liên quan đến người quản lý
dự án, SEPG, và các thành viên khác của nhóm. Tiêu chuẩn nhập là các khách hàng đã
chấp nhận sản phẩm. Tiêu chuẩn xuất là một cuộc họp hậu dự án (postproject) đã được 20
tiến hành. Các kết quả đầu ra chính của giai đoạn này là báo cáo kết thúc dự án và các sản
phẩm của quy trình (process assets) được thu thập. Toàn bộ những nội dung trên sẽ được
trình bày chi tiết như sau:

23
2.1. Quản lý phạm vi dự án ứng dụng CNTT:
2.1.1 Xác định phạm vi dự án
Tầm quan trọng của quản lý phạm vi dự án (Project scope)
- 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.
- Các kết quả chuyển giao (Deliverables) là những sản phẩm của dự án mà sẽ
chuyển giao: như là phần cứng, phần mềm (mua hoặc phát triển), 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.
Qui 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
- Xác định phạm vi: chia nhỏ các sản phẩm trung gian của dự án thành các thành
phần nhỏ hơn, dễ quản lý hơn
- 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.
Tạo bảng phân rã chi tiết công việc (Work Breakdown Structure- WBS)
Bảng kê công việc phục vụ các mục đích khác nhau trong các tổ chức khác nhau
phụ thuộc vào phương pháp luận quản lý dự án thông dụng. Tuy nhiên trong bất kỳ trường
hợp sử dụng nào thì bảng kê công việc là bước sống còn trong việc lập kế hoạch dự án.
Trong phần này này ta sẽ xem xét các yếu tố của bảng kê công việc và các cách thức khác
nhau mà nó được triển khai trong các tổ chức khác nhau.
Bảng kê công việc sẽ giúp kiềm chế sự căng thẳng khi trả lời các câu hỏi ai, cái gì,
khi nào, ở đâu, như thế nào và bao lâu bằng cách tập hợp tất cả các chi tiết khó khăn về
công việc yêu cầu để tạo ra phần có thể chuyển giao trong dự án.
a) Định nghĩa:
Bảng kê công việc là tài liệu kiểm soá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 soá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.

24
 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 toá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 soá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.
Một số tổ chức dùng bảng kê công việc như một tài liệu phạm vi cho các dự án
thêm/chuyển/ thay đổi và dự án vi mô. Phạm vi dự án chỉ được xác định khi các kết quả
chuyển giao đó được ghi rõ một cách cụ thể trong bảng kê công việc. Tất cả các công việc
theo yêu cầu không được chi tiết hoá trong bảng kê công việc là do định nghĩa ngoài phạm
vi và cũng không được thực hiện hoặc được thực hiện trong một bảng kê công việc sửa
đổi.
b) 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 cần phải hiểu tổ chức
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 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 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.
- Đảm bảo rằng 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 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 muốn nó mang tính pháp lý hoặc ràng buộc:
 Nếu đ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ì cần chữ ký để làm cho hợp đồng có giá trị.
c) 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 toà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

25
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";
Trình tự của từng công việc là không quan trọng cho dù quen đọc từ trái sang phải.
Xác định trình tự nằm trong giai đoạn lập lịch trình
BKCV bao gồm hai thành phần chính.
- Danh sách sản phẩm: DSSP (Product Breakdown Structure)
- Danh sách công việc: DSCV (Task Breakdown Structure)
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)
d) Các bước xây dựng BKCV
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.
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. Tạo danh sách sản phẩm: Phân rã sản phẩm chung nhất thành các sản phẩm
con ở các mức thấp hơn. Nói chung, khoảng 2-3 mức dưới là đủ.
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.
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
- 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, .....
- Không phân biệt nội dung trong 1 ô là sản phẩm hay công việc
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.
Xét duyệt và điều khiển phạm vi

26
 Một kế hoạch quản lý thay đổi được tuân thủ tốt và chặt chẽ sẽ ngăn ngừa việc mở
rộng phạm vi ảnh hưởng đến tiến độ, chất lượng dự án.
Nguyên tắc
Để quản lý hiệu quả việc mở rộng phạm vi, hãy tuân theo nguyên tắc sau:
- Giám sát thay đổi không được kiểm soát bằng cách phân tích các gói công việc để
tìm ra công việc không được phép:
+ Giám sát các báo cáo hiệu suất, các đánh giá hiệu suất, và các cuộc họp báo cáo
hiện trạng để tìm các dấu hiệu của việc mở rộng phạmvi tiềm năng.
+ Kiểm tra- thực hiện kiểm định công việc đang tiến triển.
+ Giám sát lịch biểu và ngân sách.
- Đảm bảo mọi yêu cầu thay đổi được ghi lại và sàng lọc để chấp thuận hoặc từ
chối.
- Lọc các yêu cầu thay đổi:
+ Loại bỏ những thay đổi ngoài phạm vi trừ khi chúng quan trọng cho dự án.
+ Đối với những thay đổi có khả năng được chấp thuận, đánh giá ảnh hưởng của
việc sửa lại kế hoạch và liệt kê các vấn đề có thể có.
+ Nếu ảnh hưởng nhỏ, giám đốc dự án và đội có thể xử lý thay đổi.
+ Nếu ảnh hưởng vừa phải, hãy chuẩn bị một báo cáo về ảnh hưởng và tìm sự đồng
ý của các đối tượng liên quan đến dự án.
+ Nếu ảnh hưởng lớn, hãy cố đàm phán về những thay đổi khác có thể hạn chế ảnh
hưởng. Hãy chuẩn bị một báo cáo về ảnh hưởng cho nhà tài trợ và nhận được sự phê duyệt
chính thức trước khi tiến hành.
- Nếu thay đổi được chấp thuận, hãy thực hiện những điều chỉnh cần thiết cho kế
hoạch dự án để bổ sung thay đổi.
- Nếu yêu cầu thay đổi bị từ chối, hãy đảm bảo rằng quyết định này được thông báo
tới người yêu cầu.
- Nếu thay đổi được chấp nhận, hãy thông báo về sự chấp nhận đó cho đội dự án,
đối tượng có liên quan và các nhà cung cấp, theo đúng nguyên tắc kế hoạch truyền thông.
Quy định phạm vi dùng để thử mức độ gay go cho mỗi yêu cầu thay đổi mà dự án
nhận được. Quy định phạm vi là chỉ dẫn duy nhất của dự án khi ai đó hỏi liệu điều gì sẽ
xảy ra và liệu lỗi đó có được sửa chữa hay không, liệu đặc tính đó có được xây dựng hay
không, liệu giao diện đó có thay đổi hay không hay liệu họ có được đào tạo hay không ?
Thảo quy định phạm vi là công việc khó khăn nhưng rất cần thiết. Quy định phạm
vi phải có tài liệu yêu cầu được nghiên cứu cẩn thận và nghiêm túc.
Nguyên tắc xác đị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ô.

27
 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 hoàn thành và không được hoà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?
 Có biết khi nào dự án hoàn tất không?
 Tính đến ngày tháng bắt đầu và ngày tháng hoà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.
 Cái nào là ưu tiên giữa chi phí, lịch trình và chất lượng?
 Tính năng, lịch trình hay kinh phí có thể thương lượng lại được để giữ cho dự án theo
đúng lịch trình hay đúng kinh phí nếu cần thiết?.
 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.

2.1.2 Qui 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
- Xác định phạm vi: chia nhỏ các sản phẩm trung gian của dự án thành các thành
phần nhỏ hơn, dễ quản lý hơn
- 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.

28
2.2.Xác định phương án lựa chọn ứng dụng CNTT
Đầu tư ứng dụng công nghệ thông tin phải là một phần của chiến lược hoạt động và
chiến lược này phải là một phần của toàn bộ chiến lược chung của cơ quan. Việc đầu tư
CNTT không phù hợp sẽ chỉ dẫn cơ quan đến chỗ sai lầm nhanh chóng hơn.
Đầu tư ứng dụng CNTT phải dựa trên nhu cầu về:
-Hỗ trợ chương trình cung cấp dịch vụ thiết thực và hiệu quả;
-Nâng cao dịch vụ khách hàng
-Giảm chi phí ;
-Hỗ trợ các ưu tiên nghiệp vụ
-Thực hiện một chương trình mới hoặc một sự thay đổi
Các nhà quản lý có nhiệm vụ đánh giá, lựa chọn và tài chợ cho các dự án CNTT dựa
trên cơ sở cách tiếp cận đề xuất dự án. Đề xuất dự án phải chỉ ra được cách thức công nghệ
này đưa đến nâng cao giá trị hoặc cải tiến dịch vụ. Các nhà quản lý cũng phải cần kiểm tra
các đề xuất của dự án mới để xác định các cơ cấu chia sẻ thông tin, công nghệ, các ứng
dụng và các phương tiện thuận lợi hiện có.
Việc lập kế hoạch đóng vai trò then chốt dẫn đến thành công của mỗi dự án CNTT.
Đề xuất dự án là yếu tố chủ chốt cho toàn bộ việc lập kế hoạch và nó thiết lập phạm vi
hoạt động quản lý dự án cũng như đạt được các lợi ích dự tính.
Cần lưu ý rằng đối với vấn đề bất kỳ nào cũng không có lời giải đơn gian. Chỉ cho
đến khi nhìn ra được tất cả các phương án và mọi khả năng lựa chọn mới có thể tìm ra
được cách giải quyết tốt nhất tình huống đang phải đối phó. Phần này mô tả cách làm thế
nào để xác định và khảo sát các khả năng lựa chọn, phải kiểm tra kỹ trước khi đưa ra một
quyết định đầu tư CNTT, và làm thế nào để chuẩn bị phân tích để đưa ra đề xuất dự án.
*Xác định vấn đề hoặc cơ hội
Bước đầu tiên trong quá trình đề xuất dự án là đưa ra một bản trình bày vấn đề,
trong dó xác định rõ các hoàn cảnh dẫn đến xem xét vấn đề đầu tư. Đây là một bước quan
trọng vì nó nhận dạng những vấn đề cần được phân tích giải quyết và các giới hạn của việc
nghiên cứu. Bản trình bày phải xác định các nhu cầu cần đáp ứng, vấn đề cần giải quyết,
hoặc cơ hội phải được khai thác.
Bản trình bày vấn đề phải đề cập đến.
-Những mục tiêu chương trình của cơ quan và những mục tiêu khác chịu tác động
của đầu tư đang được đề nghị.
-Mô tả vấn đề cần giải quyết, nhu cầu, hoặc cơ hội, và
-Chỉ dẫn chung phạm vi những hoạt động có thể.
Nếu quyết định đầu tư cho CNTT, việc đầu tư đó phải xuất phát từ các nhu cầu nảy
sinh từ những công việc cần được ưu tiên của cơ quan. Việc đánh giá phải tập trung vào
tính cách tốt nhất để đáp ứng các nhu cầu này. Đề xuất dự án phải chỉ ra cách mà các mục
tiêu chương trình của cơ quan và các mục tiêu khác có thể phát triển. Các mục tiêu này cần
được xác định trong kế hoạch nghiệp vụ và kế hoạch đầu tư dài hạn của cơ quan. Hải tham

29
khảo các bản kế hoạch này để có hướng dẫn giúp xác định các lợi ích mong muốn đạt
được.
Trước mắt có thể kiểm tra những nhu cầu của chỉ một bộ phận nghiệp vụ, tuy thế
phải cân nhắc đến những mục tiêu tổng thể của cả cơ quan. Một giải pháp nghiệp vụ
không tính đến những ưu tiên chung và những chiến lược nghiệp vụ thì có thể sẽ không
bao giờ dưa ra được những lợi ích mong muốn, do những thay đổi bất ngờ trong tổ chức
hoặc trong quá trình thực hiện.
Mỗi cơ quan, tổ chức nhà nước phải có một chiến lược tổng thể quản lý thông tin và
có một kế hoạch quản lý thông tin để xác định phương hướng CNTT cho đơn vị mình.
Định hướng CNTT có quan hệ mật thiết với các phương án CNTT đang phải đối phó với
các chi phí và các rủi ro. Đưa ra những quyết định đầu tư CNTT mà không tham chiếu kế
hoạch thông tin có thể sẽ dẫn đến các hệ thống không tương thích, không thể chia sẽ được
thông tin, do đó phải nhập nhiều lần dữ liệu đầu vào một cách vô ích và dẫn tới việc tốn
kém để duy trì hệ thống.
*Xác định các phương án.
Sẽ mô tả như thế nào các giải quyết hoặc các cơ hội định hướng cho các phân tích
tiếp theo? Hãy đừng vối tập trung vào các công nghệ, sản phẩm, hoặc phương pháp cụ thể,
vì khi làm như vậy chúng ta có thể loại bỏ những phương án khác có thể tạo ra lợi ích cao
hơn với cùng một chi phí. Thay vào đó, phải nhận biết tất cả những giải quyết có thể đáp
ứng các mục tiêu nghiệp vụ được mô tả trong bản trình bày vấn đề. Với cách này các
phương án được xây dựng và phân tích sẽ có quan hệ rõ ràng đối với những nhu cầu thực
sự của cơ quan. Nếu mối quan hệ này không rõ ràng, có thể bị lôi kéo v ào việc đầu tư vào
công nghệ vì mục đích công nghệ.
Các phương án phải bao gồm một phương án cơ sở cùng với hàng loại giải pháp
tiềm năng khác.
Phương án cơ sở phải chỉ ra được cách thức mà tổ chức sẽ hoạt động nếu giả định
cơ quan không thực hiện theo bản đề xuất đầu tư ứng dụng CNTT, hoặc không thay đổi
phương thức vận hành cơ quan. Thực ra phương án cơ sở này có thể chỉ là một phương án
chấp nhận được, song điều quan trọng là nó có tính hiện thực.
Sẽ là không thích hợp nếu khẳng định rằng phương án cơ sở đơn giản chỉ là tiếp tục
tình trạng hiện tại. Phương án cơ sở phải tính đến những sự phát triển tương lai trong một
thời gian đủ dài để có thể làm cơ sở so sánh với một hệ thống mới. Ví dụ, một cơ quan sử
dụng một hệ thống đã lâu năm sẽ phải trả chi phí bảo dưỡng nhiều lần khi hệ thống trở nên
già cỗi hơn. Tần suất các lỗi hệ thống có thể tăng hơn và thời gian máy hỏng sẽ dài hơn.
Các chi phí bảo trì có thể trở nên cao tới mức không chấp nhận được, nhưng sự chậm trể
về dịch vụ có thể trở lên không thể chịu nổi, khối lượng công việc phải làm trở nên không
thể quản lý nổi.
Phương án cơ sở phải dự toán những chi phí và lợi ích dài hạn của việc duy trì
phương pháp vận hành hiện tại, cần kiểm tra những sức ép đã biết từ bên ngoài đòi hỏi

30
thay đổi như những thay đổi được dự đoán về nhu cầu dịch vụ, kinh phí, bố trí nhân sụ,
hoặc định hướng nghiệp vụ.
Các phương án khác
Các vấn đề có thể được giải quyết theo các cách khác nhau và với các qui mô khác
nhau. Trong rất nhiều trường hợp, các phương án có thể tập trung vào việc sử dụng tối ưu
các hệ thống hiện có hoặc sửa đổi các thủ tục hiện hành. Các phương án này có thể đòi hỏi
một chút đầu tư hoặc không cần đầu tư mới.
Một số phương án, đặc biệt phương án CNTT, có thể sẽ được thực hiện nhờ sử dụng
một số chiến lược khác nhau. Việc kết hợp các chiến lược lựa chọn làm tăng phạm vi hiệu
quả của các phương án. Ví dụ, một yêu cầu về ứng dụng CNTT có thể được đáp ứng bởi
một hoặc một số trong các phương án sau:
-Xác định lại các quá trình nghiệp vụ để đạt được kết quả mong muốn mà không cần
đầu tư về CNTT.
-Sử dụng lại hoặc thích nghi một ứng dụng đã được phát triển bởi một bộ phận
nghiệp vụ khác hoặc một đơn vị khác.
-Xây dựng lại hệ thống hiện có (nếu đang có một ) để cung cấp những chức năng
theo yêu cầu.
-Mua sản phẩm thương mại đang có sẵn trên thị trường hoặc.
-Xây dựng theo đặt hàng một ứng dụng mới.
CÁc chiến lược xây dựng, thích nghi hoặc xây dựng lại một ứng dụng bao gồm việc
tự thực hiện những công việc này hoặc ký hợp đồng với bên ngoài, thực hiện chúng theo
từng giai đoạn hoặc thực hiện tất cả cùng một lúc.
Các phương án để có được phần cứng về CNTT có thể là:
-Mua
-Thuê dài hạn
-Thuê định kỳ
-Thuê dài hạn có nâng cấp thường xuyên
Chiến lược để thực hiện các phương án này có thể bao gồm những khung thời gian
thực hiện khác nhau, chẳng hạn như trì hoãn đầu tư cho đến khi có công nghệ tốt hơn hoặc
công nghệ được đề xuất đã được sử dụng rộng rãi hơn. Cần kiểm tra xem các chiến lược
có phạm vi đủ rộng để nắm bắt toàn bộ hiệu quả và chi phí của việc đầu tư vào cơ quan
hay không. Trong phạm vi một phương án hoặc chiến lược đơn lẻ, hãy tránh tạo ra những
quyết định hấp tấp đối với những vấn đề quan trọng. Bất kể khi nào còn nghi ngờ, cần phải
xác định và giải quyết lại các vấn đề này thông qua quá trình đánh giá.
Đối với từng phương án, nên lập danh sách tất cả những giả định về tình trạng công
nghệ, điều kiện môi trường, hoặc những ràng buộc về tổ chức liên quan đến việc thực hiện
đầu tư. Về sau, có thể kiểm tra những thay đổi các giả định này khi phân tích độ nhạy. Khi
việc đánh giá hoàn thành, việc quyết định giữa các phương án sẽ dựa trên cơ sở về chi phí
– lợi ích.

31
 Nhờ phân tích các phương án, có thể thấy rõ những lợi ích so sánh và lợi ích về mức
dịch vụ của đầu tư CNTT đang được đề nghị. Việc đưa các phương án lựa chọn vào phân
tích tạo khả năng xác định được giải pháp hứa hẹn nhất đối với những vấn đề liên quan
đến CNTT của tổ chức. Các phương án nên đủ rộng để nắm bắt được những tác động tổ
chức của đề xuất CNTT và các hiệu quả phục vụ khách hàng của nó.
*Sàng lọc các phương án.
Tất nhiên, không thể và cũng không cần thiết phân tích đầy đủ tất cả các phương án.
Quá trình sáng lọc là các tốt nhất để đảm bảo rằng việc phân tích tiếp tục chỉ với những
phương án hứa hẹn nhất. Sàng lọc cho phép hàng loạt phương án ban đầu được kiểm tra
với công sức hợp lý. Việc thiết lập quá trình sàng lọc các phương án còn có ưu điểm bổ
sung là đưa ra khuôn khổ đánh giá những lý do để lựa chọn, hay loại bỏ các phương án đặc
biệt.
Nên loại trừ ngay các phương án khi đã rõ ràng các lựa chọn khác là tốt hơn xem về
khía cạnh chi phí – lợi ích có thể nhanh chóng xác định xác định những đặc tính quan
trọng để phân biệt giữa các phương án. Việc nhóm các phương án có đặc tính chủ chốt
tương tự như nhau có thể giúp xác định những sự khác nhau liên quan đến nhưng yếu
điểm về chi phí, hoặc những ưu điểm về lợi ích, mà những sự khác biệt này vẫn tồn tại
ngay cả khi các phương án được đưa ra phân tích một cách khắt khe hơn.
Các phương án có thể bị loại trừ khi sự thành công của chúng phụ thuộc quá nặng
nề vào một công nghệ chưa được thử thách, hoặc chỉ đơn giản do chúng không hoạt động.
Cần chú ý không nhầm lẫn các phương án không hoạt động với các phương án ta ít mong
muốn. Các phương án không được mong muốn sẽ bị loại ra khi bắt đầu tính các chi phí và
lợi ích.
Mục đích đã đưa ra các phương án để tiếp tục quá trình phân tích khắt khe hơn. Một
kinh nghiệm tốt là khi còn nghi ngờ về giá trị kinh tế của một phương án cụ thể. Thì nhà
phân tích nên giữ nó lại cho các vòng đánh giá chi tiết hơn về sau.
*Chuẩn bị đánh giá
Khi đã xác định được các phương án, cần phải thiết lập một cơ sở để so sánh. Giai
đoạn tiếp theo là phác thảo cách thức để nhận biết và định lượng các chi phí, lợi ích và rủi
ro liên quan tới từng phương án, cần phải thiết lập một cơ sở để so sánh. Giai đoạn tiếp
theo là pháp thảo cách thức để nhận biết và định lượng các chi phí, lợi ích, lợi ích và rủi ro
liên quan đến từng phương án. Trả lời các câu hỏi sau hy vọng sẽ giúp chúng ta chuẩn bị
cho những công việc này.
-Phương án có liên quan như thế nào đến các mục đích và ưu tiên của cơ quan?
-Phương án sẽ nâng cao dịch vụ đối với dân chúng, cải tiến chương trình phân phối,
hoặc nâng cao tính cạnh tranh như thế nào?
-Phương án sẽ thu được kết quả gì khi thực hiện toàn bộ chương trình? Cái gì có thể
xảy ra nếu phương án này không được lựa chọn?

32
 -Nếu phương án được lựa chọn thì các kết quả có thể phát huy và các lợi ích tiếp
theo sẽ là những gì?
-Ai sẽ là những nhà đầu tư? Những điều họ quan tâm và trách nhiệm của họ là gì?
Phương án có những ảnh hưởng gì đến họ?
-Những tác động đến nguồn nhân lực của tổ chức là những gì? Sẽ quản lý những tác
động của phương án đó đến giáo dục, đào tạo, hỗ trợ, điều chỉnh lực lượng lao động như
thế nào?
-Phương án này có tạo khả năng tót cho các nhà quản lý và đội ngũ cán bộ hay
không?
-Khi nào một cuộc trao đổi theo yêu cầu trong nội bộ của cơ quan được tiến hành?
Chúng ta đã xem xét đến vấn đề công tác với các cơ quan khác chưa?
-Đã kiểm tra tất cả các phương án “tự làm hoặc mua” chưa? Đã kiểm tra việc sử
dụng các hệ thống và các dịch vụ chung chưa?
-Những cải tiến theo dự án mang tính chất kịp thời, năng suất, tiết kiệm chi phí,
tránh chi phí, chất lượng và dịch vụ là những gì?
-Phải chi phí bao nhiêu để nhận được CNTT?
-Phải chi phí bao nhiêu để xây dựng ứng dụng?
-Kế hoạch mua sắm những gì?
-Phương án đó có liên quan đến việc sử dụng công nghệ mới không? Nếu có thì các
rủi ro liên quan sẽ là những gì?
Tóm lại, những đầu tư về ứng dụng CNTT thường hỗ trợ dịch vụ đầy đủ hơn, đễ sử
dụng hơn và linh hoạt hơn. Các đầu tư về CNTT phải phản ánh các chiến lược và các ưu
tiên để đảm bảo rằng những đầu tư này sẽ sử dụng tốt nhất các nguồn tài nguyên hạn chế
của tổ chức. Trước khi xây dựng một đề xuất dự án nên:
-Xác định vấn đề hoặc cơ hội để nhận biết rõ ràng các yêu cầu.
-Xác định cơ quan sẽ như thế nào nếu không được đầu tư CNTT (phương án cơ sở)
-Nhận dạng hoàng loạt các phương án và các chiến lược
-Sàng lọc các phương án đó để tìm ra những phương án hứa hẹn nhất.
Cuối cùng, nên cân nhắc một loạt rộng rãi những câu hỏi để chuẩn bị cho đánh giá.
2.3. Quản lý thời gian dự án ứng dụng CNTT:

Tầm quan trọng của lịch trình dự án (Project schedules)

- 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
- Các vấn đề lịch biểu là lý do chính dẫn đến xung đột trong dự án, đặc biệt là trong
nửa sau của dự án, sức ép tiến độ gây căng thẳng, phá vỡ những quy định của dự án …
Các hoạt động của dự án (Activities)

33
 a) Hành động theo nỗ lực hay thời đoạn
Sự nhầm lẫn xung quanh nỗ lực và thời đoạn đã tồn tại từ lâu và rất phổ biến. Có
một ý kiến sai lầm tồn tại trong một thời gian dài là quản lý càng nhiều nguồn lực cùng
thực hiện một nhiệm vụ cụ thể thì nhiệm vụ thực hiện càng nhanh. Điều này có thể đúng
hoạc không đúng. Cách hiểu rõ ràng về nỗ lực và thời đoạn có thể mất rất lâu để cải thiện
ước tính và kế hoạch làm việc được xây dựng cho các dự án công nghệ thông tin.
Định nghĩa.
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ể hoà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.
Ví dụ.
Một việc sẽ mất bao lâu để hoàn tất có thể hay không thể phụ thuộc vào vào việc nỗ
lực được áp dụng bao nhiêu. Hãy nói rằng ta muốn tạo ra một chai rượu. Nhiều người
tham gia sẽ làm cho việc hái nho trong vườn trở nên nhanh hơn nhưng khi rượu đã được
đặt vào trong thùng thì không có lượng nỗ lực nào có thể làm cho rượu lên men nhanh
hơn. Công việc hái nho là theo năng lực, trong khi đó ủ và lên men rượu là trường hợp
khoảng thời gian cố định.
b) Xác lập các mốc quan trọng
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 hoà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.
Ví dụ:
Một công ty tư vấn xây dựng ước lượng thời gian cho dự án khách hàng và có các
mốc quan trọng tại thời điểm bất đầu và kết thúc dự án và ở mỗi giai đoạn của hợp đồng

34
có các phần có thể chuyển giao do sự đồng thuận của khách hàng đã được yêu cầu trước
khi họ có thể tiếp tục từng phần một và bằng sự đồng thuận, họ cũng có thể triển khai quy
trình quảng cáo. Sơ đồ mốc quan trọng cho dự án này được chỉ ra trong hình sau:
Tháng 3 Tháng 4 Tháng 5 Tháng 6 Tháng 7 Tháng 8
Hoàn tất 
hành động A
Hoàn tất 
hành động B
Hoàn tất 
hành động C
Hoàn tất 
hành động D
Hoàn tất 
hành động E

Bảng 1: Sơ đồ mốc quan trọng

c) Các dự án theo lịch trình so với các dự án theo nguồn lực.
Trong nhiều trường hợp, thống kê kỹ năng cần để hoàn tất các dự án công nghệ
thông tin hoặc không tồn tại hoặc luôn trong tình trạng thiếu hụt thời gian. Kết quả là hầu
hết các dự án công nghệ thông tin đều đối mặt với các ràng buộc nguồn lực và kế hoạch
làm việc chặt chẽ. Tìm hiểu về mức độ chiếm ưu thế trong cuộc đấu tranh này có thể đóng
vai trò quyết định để xây dựng một ước lượng đúng.
Định nghĩa:
Dự án hướng theo lịch trình khi thời hạn chuyển giao cuối cùng là 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 lịch trình sẽ dùng hết bất cứ nguồn lực nào cần để đảm bảo chuyển
giao trong thời hạn đã được xác lập.
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.
Ví dụ:
Có lẽ ví dụ tốt nhất về các dự án theo lịch trình trong công nghệ thông tin là các dự
án có tính chất như các chương trình Y2K vừa qua. Mỗi giám đốc dự án có một thời hạn
cuối cùng không thể thương lượng được, chính xác là 12giờ trưa ngày 31 tháng 12 năm
1999. Các công ty bắt buộc phải dùng hết các nguồn lực khổng lồ để nâng cấp hoặc thay
thế các hệ thống không thể thực hiện các mệnh lệnh đúng giờ.
Hầu hết các dự án mạng nội bộ đều theo nguồn lực. Trong nhiều trường hợp, các dự
án có được sự truy cập các nguồn lực phát triển Web rất hạn chế, điển hình là phải đảm
nhận các dự án thương mại điện tử và Web site tập trung theo bề ngoài.
35
 Ước lượng thời gian thực hiện (Duration)
a) Các kỹ thuật ước lượng thời gian
Ước lượng phi khoa học:
- Dựa trên kinh nghiệm chủ quan, cảm tính.
- Nhanh và dễ dàng.
- Kết quả thiếu tin cậy.
Chỉ nên dùng trong các trường hợp
- Đội ngũ chuyên môn rất có kinh nghiệm, có kỹ năng cao, đội hình cố định.
- Dự án đã quy định, bắt buộc phải theo.
Ước lượng PERT:
Thích hợp đối với những dự án.
- Đòi hỏi tính sáng tạo.
- Coi trọng chất lượng kết quả công việc hơn là thời gian hoàn thành dự án.
Công thức PERT.
- Cần làm 3 ước lượng thời gian cho mỗi công việc.
- Kết hợp lại để có con số cuối cùng.
Ước lượng khả dĩ nhất (ML-Most Likely): Thời gian cần để hoàn thành công việc
trong điều kiện “bình thường” hay “hợp lý”.
Ước lượng lạc quan nhất (MO-Most Optimistic): Thời gian cần để hoàn thành
công việc trong điều kiện “tốt nhất” hay “lý tưởng” (không có trở ngại nào).
Ước lượng bi quan nhất (MP-Most Pessimistic): Thời gian cần để hoàn thành
công việc một cách “tồi nhất” (đầy trở ngại).
Ước lượng cuối cùng tính theo công thức: (MO + 4(ML) + MP)/6
- Ví dụ: Ước lượng thời gian cho các công việc liên quan đến lắp mạng nội bộ cho
cơ quan. (EST: estimation - ước lượng thời gian để làm dự án)

Đơn vị tính: Ngày

Tên công việc MO ML MP EST
Vẽ sơ đồ và 2 3 5 3.2
khoan tường
Lắp các ống gen 1 2 4 2.2
Đi dây 1 2 4 2.2
Lắp các hộp nối 0.5 1 2 1
Lắp các máy 2 3 3 2.8
tính máy chủ
Kết nối các máy 1 2 4 2.2
tínhmáy chủ vào
hệ thống dây
mạng
Thử xem mạng 0.5 1 10 2.4
đã thông chưa
36
 Tổng thời gian 8 14 32 16

Bảng 2: Ước lượng thời gian cho các công việc liên quan đến lắp mạng nội bộ cho cơ quan.
Sau đó tăng thêm “một ít thời gian” cho mỗi công việc (thời gian lãng phí giữa
chừng). Thông thường tăng thêm 7% - 10%
Tên công việc EST % EST cuối cùng
Vẽ sơ đồ và khoan 3.2 10% 3.52
tường
Lắp các ống gen 2.2 10% 2.42
Đi dây 2.2 10% 2.42
Lắp các hộp nối 1 10% 1.1
Lắp các máy tính 2.8 10% 3.08
máy chủ
Kết nối các máy 2.2 10% 2.42
tính máy chủ
vào hệ thống dây
mạng
Thử xem mạng đã 2.4 10% 2.64
thông chưa
Tổng thời gian 16 10% 17.6

Trong thời gian Hải quân Mỹ phát triển biểu đồ PERT, Dupont cũng đang xây dựng
Phương pháp Đường tới hạn (Critical Path Method, viết tắt là CPM). Trong những năm
1960, Dupont nghiên cứu phát triển rất nhiều chất liệu mới đòi hỏi phải có các qui trình
sản xuất chi tiết. Nhu cầu của các doanh nghiệp tư nhân và quốc doanh về những vật liệu
mới đã vượt quá khả năng của Dupont trong việc xây dựng những thiết bị và qui trình cần
thiết để sản xuất hàng loạt, vì thế Dupont đã xây dựng CPM nhằm giúp xác định chính xác
hơn những ràng buộc về tài nguyên có ảnh hưởng thế nào đến thời gian đưa ra thị trường.
Ngày nay rất nhiều người coi CPM là phương thức tiếp cận mặc định trong việc vẽ sơ đồ
mạng cho những dự án có ràng buộc về tài nguyên.
Phương pháp đường tới hạn (Critical Path Method) là một kỹ thuật mạng dùng một
ước tính thời gian chính xác (không giống với PERT dùng đến 3 ước tính) để tính toán
thời lượng, thời gian dự trữ công việc hay thời gian trì hoãn, và đường tới hạn. Phương
pháp này có 4 đặc điểm tiêu biểu:
- Tất cả các gói công việc phải được đặt vào một sơ đồ mạng.
- Các gói công việc trên sơ đồ mạng phải được sắp xếp tuần tự sao cho thể hiện
được tất cả các phụ thuộc và đường đi đến kết thúc.
- CPM mang tính tiền định ở chỗ nó chỉ dùng một ước tính thời gian chính xác chứ
không dùng 3 ước tính để tính toán thời lượng, và do đó có khả năng theo dõi phần trăm
hoàn thành với một mức độ chính xác hợp lý.

37
 - Cuối cùng, cần phải tính toán thời gian dự trữ (float) hay thời gian trì hoãn (slack)
cho mỗi gói công việc và tính toán đường tới hạn.
Phương pháp đường tới hạn rất có ích cho những dự án đã từng làm trước đó, cho
phép ước lượng thời gian với độ chính xác hợp lý.
b) Một số hướng dẫn trợ giúp ước lượng thời gian cho dự án CNTT
Chi phí thời gian của lập trình viên:
Viết chương trình 13%
Đọc tài liệu hướng dẫn 16%
Thông báo, trao đổi, viết báo cáo 32%
Việc riêng 13%
Việc linh tinh khác 15%
Huấn luyện 6%
Gửi mail, chat 5%

Bảng3 chi phí thời gian của lập trình viên (Điều tra của Bell Labs)
Làm việc một mình 30%
Trao đổi công việc 50%
Làm những công việc 20%
khác,không phục vụ
trực tiếp cho công việc

Bảng 4 chi phí thời gian của lập trình viên (Điều tra của IBM))

Khó khăn trong việc ước lượng thời gian làm phần mềm:
- Phần mềm chưa làm bao giờ (khác với các dự án kỹ thuật khác)
- Khó dùng lại những kinh nghiệm của các dự án trước đây
- Công nghệ thay đổi
- Khó phân danh giới rõ ràng giữa các giai đoạn.
Ví dụ:
+ Kiểm thử có bao gồm việc gỡ rối hay không?
+ Thiết kế có bao gồm việc vẽ sơ đồ cấu trúc chương trình hay không? Công sức và
thời gian còn phụ thuộc vào một vài yếu tố khác
Loại dự án là cũ nếu đã có hơn 2 năm kinh nghiệm;
Môi trường áp dụng là cũ nếu đã có hơn 2 năm kinh nghiệm)
Công sức và thời gian còn phụ thuộc vào tay nghề của nhóm phát triển (nhóm lập
trình)
Số năm kinh Hệ số nhân
nghiệm
10 0.5

38
 8 0.6
6 0.8
4 1
2 1.4
1 2.6

Bảng 5: liên hệ số năm kinh nghiệm và hệ số công việc của người lập trình
Xây dựng lịch trình

+ Hoàn thành 100% = nhiệm vụ đã hoàn thành.Quy tắc này không mô tả chi tiết sự
tiến triển của hiệu suất như là 15%, và có thể thấy răng sự hoàn thành nhiệm vụ chỉ được
mô tả theo hai giai đoạn.
- Quy tắc hoàn thành theo phần trăm. Các con số phần trăm hoàn thành được đánh
giá tại các thời điểm báo cáo cụ thể. Mặc dù đây là một quy tắc mang lại hiệu quả cao khi
kiểm soát hiệu suất chi phí, nhưng điều quan trọng là phải nhận ra rằng phương pháp này
vẫn mang tính chủ quan, và chủ yếu là do các con số ước tính quá lạc quan. Vẫn có khả
năng, nhất là trong các dự án lớn, các chủ thầu gói công việc giấu các vấn đề xảy ra bằng
cách dự toán cao cho phần trăm công việc hoàn thành, và sau đó họ sẽ làm việc gấp rút
trong thời gian tới. Ví dụ “hoàn thành 95%”.
- Các mốc quan trọng. Phương pháp này được áp dụng thành công cho các gói công
việc có thời gian dài và nhiều hoạt động. Tổng giá trị gói công việc được chia ra và phân
thành các cột mốc quan trọng trong quá trình thực hiện gói công việc đó. Mỗi cột mốc đều
có một giá trị dự toán. Giá trị đó sẽ đạt được khi dự án hoàn thành được một cột mốc.
Biểu đồ theo dõi Gantt
Biểu đồ theo dõi Gantt là một biểu đồ Gantt được dùng để hiển thị hiệu suất thực tế so với
hiệu suất dự toán; đồng thời có thể hiển thị công việc đã được hoàn thành cùng với khoảng
trễ cho mỗi hoạt động. Mặc dù không hiển thị được một cách rõ ràng các mối quan hệ phụ
thuộc giữa các hoạt động hay đường tới hạn, biểu đồ Gantt lại là một công cụ rất hiệu quả
trong việc cung cấp thông tin tổng kết cập nhật và có thể rất có ích khi phân tích tổng hiệu
suất thời gian của dự án. Biểu đồ Gantt cũng có thể hiển thị thời gian của các cột mốc
quan trọng và cho biết liệu có theo kịp các thời hạn không.
d) Tính toán giá trị thu được
Tính chi phí dự toán của việc đã xếp lịch (BCWS) cho một giai đoạn nhất định. Các khoản
này đã được xác định trong quá trình triển khai kinh phí dự án và có trong Cấu trúc chi tiết
công việc (WBS) ở cấp độ gói công việc.
Ước tính phần trăm hoàn thành công việc dự toán trong khoản thời gian đó.
- Cần phải xem xét các nhân tố sau khi chọn phương pháp để tính phần trăm hoàn thành
công việc:
+ Lượng thời gian dành cho các gói công việc

39
+ Độ phức tạp của dự án
+ Khả năng chịu đựng sức ép của các thủ tục hành chính.
+ Phương pháp nào là phù hợp nhất để giảm thiểu tối đa sự chậm trễ.
Tính toán Chi phí dự toán của việc được thực hiện (BCWP), hay còn gọi là giá trị thu
được trong khoản thời gian đó, bằng cách lấy phần trăm hoàn thành công việc nhân với
Chi phí dự toán của việc đã xếp lịch (BCWS).
Tính toán Chi phí thực của công việc đã thực hiện (ACWP) trong khoảng thời gian đó
bằng cách xác định số lượng tiền thực tế được chi.
Điều khiển lịch trình

a)Sử dụng thông tin cập nhật về lịch trình dự án 26

Các thành phần của Hiệu suất theo lịch trình (SPI) và Biến động lịch trình (SV)
SV (Biến động lịch trình) SV = BCWP – BCWS
SPI (Hiệu suất theo lịch trình) SPI = BCWP / BCWS

Các dự án CNTT thường không theo sát lịch trình dự án, cho dù kế hoạch được lập
công phu chăng nữa. Một cuộc khảo sát các nhà lãnh đạo CNTT (CIO) gần đây cho thấy
chỉ 10% các sáng kiến CNTT được hoàn thành đúng kế hoạch và kinh phí, mặc dù các dự
án này đã theo sát lịch trình và thời gian suốt nửa chặng đầu. Dự án càng dài thì quyền ưu
tiên sẽ thay đổi và nguồn nhân lực cũng bị dịch chuyển qua dự án khác. Nhờ các phương
pháp tính Hiệu suất lịch trình (SPI) và Biến động lịch trình (SV), các Giám đốc CNTT sẽ
nắm được lịch trình đang tiến triển theo xu hướng tích cực, tiêu cực, hay trung hòa (Baker
and Field, 2001).
SV (Biến động lịch trình) là độ chênh lệch đo được giữa khoản thời gian dự toán
thực hiện hoạt động so với khoản thời gian thực để thực hiện hoạt động đó. Nói cách khác,
đó là chênh lệch giữa Chi phí dự toán của việc được thực hiện (BCWP) và Chi phí dự toán
của việc đã xếp lịch (BCWS). Công thức tính của Biến động lịch trình là SV = BCWP -
BCWS. Nếu kết quả của Biến động lịch trình (SV) là số dương (+), nghĩa là nhiệm vụ đó
đang vượt tiến độ. Còn nếu kết quả của Biến động lịch trình (SV) là số âm (-), nghĩa là
thời gian thực hiện nhiệm vụ đó đang bị tụt lùi so với lịch trình.
SPI (Hiệu suất tính theo lịch trình) là tỉ số giữa công việc hoàn thành với công việc
dự toán. Công thức tính Hiệu suất lịch trình là: SPI = BCWP / BCWS. Nếu giá trị SPI lớn
hơn 1, điều đó có nghĩa là công việc đang vượt tiến độ dự tính.
b) Cập nhật lịch trình
Để tiến hành cập nhật lịch trình dự án, hãy thực hiện các bước sau:
1. Sử dụng thông tin cập nhật về lịch trình dự án để xác định được khoản thời gian
được chia.
2. Tính toán Chi phí dự toán của việc đã xếp lịch (BCWS)
3. Tính toán Chi phí dự toán của việc được thực hiện (BCWP)

40
 4. Tính toán Biến động lịch trình (SV) để xác định xem dự án có theo kịp tiến độ (số
dương +) hay bị tụt lùi (số âm -) so với lịch trình.
5. Tính toán Hiệu suất tính theo lịch trình (SPI) để xác định xem dự án đang theo
đúng tiến độ (lớn hơn 1) hay tụt lùi (bé hơn 1) so với lịch trình.
Trong xây dựng dự án ứng dụng CNTT luôn có mối quan hệ giữa thời gian hoàn
thành dự án và nhân sự thực hiện dự án, thời gian hoàn thành chỉ được chấp nhận nếu
người đứng đầu của các đơn vị của đơn vị (mà dự án thuộc về) đồng ý để cung cấp đủ số
người cần thiết. Nếu số người cần thiết chưa có sẵn, thời gian hoàn thành dự án phải được
điều chỉnh. Các phụ thuộc (dependencies) của dự án cũng được kiểm tra trước khi thời
gian hoàn thành được chấp nhận. Nếu việc thực hiện dự án phụ thuộc vào các yếu tố bên
ngoài (chẳng hạn như phải hoàn thành một dự án khác hoặc chờ đợi sự có mặt của một
phần mềm nào đó), thời gian hoàn thành phải được điều chỉnh để thích ứng với những yếu
tố này. Một khi thời gian tổng thể của dự án được ấn định cố định, thời gian cho các cột
mốc chính phải được xác định. Để xác định các cột mốc, trước tiên ta phải hiểu đường kết
nối nhân lực thường diễn ra trong một dự án. Số lượng người trong một dự án phần mềm
có xu hướng theo đường cong Rayleigh. Ở lúc bắt đầu và kết thúc, ít người làm việc trong
dự án; nhóm đạt được kích thước tối đa (PTS - peak team size) ở một nơi nào đó gần giữa
dự án. Cách thức hoạt động này xảy ra bởi vì chỉ có vài người là cần thiết trong giai đoạn
đầu của phân tích yêu cầu và thiết kế. Yêu cầu nguồn nhân lực đạt mức tối đa trong suốt
thời gian cài đặt mã và kiểm thử đơn vị (unit testing). Một lần nữa, trong suốt thời gian
kiểm thử hệ thống và tích hợp hệ thống (system testing and integration), ít người hơn được
cần. Trong nhiều trường hợp, mức phân công nhân sự không thay đổi thường xuyên,
nhưng xấp xỉ của đường cong Rayleigh được sử dụng: phân công một vài người lúc bắt
đầu, nhóm có đông người nhất trong suốt giai đoạn xây dựng (build phase), và sau đó để
lại một vài người để làm tích hợp và kiểm thử hệ thống. Nếu ta xem xét thiết kế, xây dựng
(build) và kiểm thử nghiệm là ba giai đoạn chính để thực hiện các yêu cầu.
Tiếp cận này thường được áp dụng để phân công nhân sự. Ít người hơn được giao
nhiệm vụ vào các giai đoạn bắt đầu và kết thúc, nhưng sẽ phân công số người tối đa vào
suốt giai đoạn xây dựng. Trong suốt giai đoạn xây dựng, dự án thường đạt mức PTS. Để
dễ dàng lập kế hoạch, đặc biệt là đối với các dự án nhỏ hơn, tất cả mọi người thường được
phân công ngay để cung làm việc với nhau từ lúc bắt đầu của dự án. Cách tiếp cận này có
thể dẫn đến một số người sẽ rảnh ở đầu và cuối dự án. Thời gian rảnh này (slack time)
thường được sử dụng cho đào tạo. Đào tạo ở cấp dự án nói chung cần thiết về các công
nghệ sắp sửa được sử dụng và lĩnh vực nghiệp vụ (business domain) của dự án, và đào tạo
này cần khá nhiều nỗ lực (thời gian), như có thể nhìn thấy được qua phân phối nỗ lực được
cung cấp trong cơ sở dữ liệu về quy trình. Tương tự như vậy, thời gian rảnh xuất hiện ở
giai đoạn cuối có thể được sử dụng để viết tài liệu và các nhiệm vụ kết thúc khác. Phân
phối thời gian hoàn thành dự án thì khác với phân phối nỗ lực. Đối với ba giai đoạn chính,
tỷ lệ phần trăm của thời gian được dùng trong giai đoạn xây dựng thì nhỏ hơn so với tỷ lệ

41
phần trăm của nỗ lực được dùng bởi giai đoạn này bởi vì nó liên quan đến nhiều người
hơn. Tương tự như vậy, tỷ lệ phần trăm của thời gian được sử dụng trong giai đoạn thiết
kế và kiểm thử thì lớn hơn tỷ lệ phần trăm nỗ lực của chúng. Thời gian chính xác được sử
dụng phụ thuộc vào đường kết nối nhân lực đã được hoạch định. Khi biết nỗ lực ước
lượng cho một giai đoạn, có thể xác định thời gian của giai đoạn khi biết đường kết nối
nhân lực. Nói chung, thiết kế cần khoảng 40% thời gian (20% cho thiết kế mức cao và
20% cho thiết kế chi tiết), xây dựng cần khoảng 40%, và tích hợp và kiểm thử hệ thống
cần 20% còn lại. Thông thường thì đường kết nối nhân lực khoảng 01:02:01 cho thiết kế,
xây dựng, tích hợp và thử nghiệm (được biết phân phối nỗ lực của các giai đoạn này là
01:04:01). Các hướng dẫn kiểu này giúp ích trong việc kiểm tra các cột mốc đã được thiết
lập dựa trên các ràng buộc khác. Điều quan trọng cần được biết là ngay cả khi một người
được phân công toàn thời gian (full-time) cho một dự án, việc thực hiện các nhiệm vụ
khác cũng tiêu tốn thời gian nhưng không đóng góp cho dự án. Những nhiệm vụ này bao
gồm nghỉ phép, hoạt động đoàn thể, đào tạo nói chung (không phải cho dự án cụ thể), xem
xét lại (review) các dự án khác, v.v.
Một khi các cột mốc và số lượng nhân sự (người tham gia) đã được ấn định cố định,
đây là lúc đi xây dựng kế hoạch chi tiết. Người quản lý dự án phân nhỏ các công
việc/nhiệm vụ ra thành các công việc nhỏ (xếp lịch được) hơn theo thứ bậc kế thừa. Tại
mỗi công việc chi tiết, người quản lý dự án ước lượng thời gian cần thiết để hoàn thành nó
và phân công nhận sự thích hợp để có thể hoàn thành thời gian biểu tổng thể. Trong việc
phân công nhân sự, người quản lý dự án xem xét đến nhiều yếu tố khác nhau như kế hoạch
nghỉ phép của các thành viên trong nhóm, kế hoạch cá nhân của họ và con đường sự
nghiệp, các kỹ năng của họ và kinh nghiệm được cần, yêu cầu được đào tạo và tư vấn, 91
tính chất quan trọng của công việc/nhiệm vụ, và giá trị của kinh nghiệm sẽ đạt được từ
nhiệm vụ đó. Ở mỗi cấp độ tinh chỉnh lại, người quản lý dự án kiểm tra số nỗ lực được cần
cho toàn bộ các công việc trong kế hoạch chi tiết và so sánh với nỗ lực ước lượng. Nếu
cần thiết, điều chỉnh lại các ước lượng chi tiết. Ví dụ, người quản lý dự án sẽ phân chia
giai đoạn thiết kế chi tiết ra thành nhiều công việc/nhiệm vụ nhỏ khi đang phát triển các
thiết kế chi tiết cho từng mô-đun, xem xét lại thiết kế chi tiết, sửa chữa các lỗi được tìm
thấy, v.v., và người quản lý dự án có thể tiếp tục phân chia chi tiết hơn nữa. Sau đó, người
quản lý sẽ lập thời gian biểu cho những công việc này và phân công nhân sự cho một vài
khoảng thời gian. Nếu kế hoạch chi tiết này không phù hợp với thời gian biểu và nỗ lực
ước lượng tổng thể, người quản lý dự án phải thay đổi thời gian biểu chi tiết. Nếu người
quản lý dự án nhận thấy rằng thời gian biểu chi tiết được xem là tốt nhất cũng không thể
tương thích với nỗ lực và thời gian của các cột mốc, người quản lý dự án phải sửa đổi lại
các ước lượng trước đó. Do đó, lập kế hoạch là một quá trình lặp đi lặp lại. Nói chung,
người quản lý dự án tinh chỉnh lại các công việc/nhiệm vụ đến một mức độ để mà các hoạt
động ở mức thấp nhất có thể được lên kế hoạch để chiếm không nhiều hơn một vài ngày
cho một người đơn lẻ. Người quản lý dự án cũng thêm vào các hoạt động chung, chẳng

42
hạn như quản lý dự án, điều phối, quản lý cơ sở dữ liệu, và quản lý cấu hình. Những hoạt
động này ít có tác dụng trực tiếp đến thời gian biểu bởi chúng là những công việc đang
diễn ra chứ không phải là các hoạt động xếp lịch được. Tuy nhiên, tuy nhiên chúng tiêu
tốn nhân sự và do đó phải được ghi nhận trong thời gian biểu của dự án. Hiếm khi người
quản lý dự án tạo kế hoạch chi tiết cho toàn bộ dự án với chỉ một lần. Sau khi thời gian
biểu tổng thể được ấn định cố định, người quản lý dự án có thể chi tiết hóa mỗi giai đoạn
chỉ vào lúc bắt đầu của giai đoạn đó. Để lập kế hoạch chi tiết, người quản lý dự án thường
xuyên sử dụng Microsoft Project (MSP) hoặc một bảng tính. Đối với mỗi hoạt động cấp
thấp nhất, họ quy định nỗ lực, khoảng thời gian, ngày bắt đầu, ngày kết thúc, và các nhân
sự. Đối với mỗi hoạt động, họ cũng xác định mã hoạt động, mã chương trình, và mã mô-
đun. Họ cũng có thể xác định sự phụ thuộc giữa các hoạt động. Một thời gian biểu chi tiết
của dự án không bao giờ là tĩnh. Thay đổi có thể được cần vì tiến bộ thực tế của dự án có
thể khác như những gì đã được lên kế hoạch, bởi vì các công việc mới được thêm vào để
đáp ứng các thay đổi yêu cầu, hoặc do các tình huống bất khả kháng khác. Thay đổi nên
chỉ được thực hiện khi cần thiết. Thời gian biểu cuối cùng, như được ghi nhận trong
Microsoft Project hoặc một số công cụ khác, là một tài liệu lưu kế hoạch dự án "sống"
nhất. Trong suốt dự án, nếu kế hoạch này cần phải được thay đổi và các công việc bổ sung
phải được thực hiện, sau khi quyết định được đưa ra, bất kỳ thay đổi nào đều phải được
ghi nhận vào trong thời gian biểu chi tiết. Do đó, thời gian biểu chi tiết sẽ trở thành tài liệu
chính để theo dõi các hoạt động và thời gian hoàn thành. Thời gian biểu chi tiết cũng là
một đầu vào quan trọng cho việc giám sát dự án

2.4 Quản lý nguồn lực của dự án ứng dụng CNTT:

Xây dựng nhóm dự án (Project team)
Các hoạt động phát triển đội dự án là một yếu tố tất yếu khi tiến hành dự án. Chủ đề
này đưa ra các phương pháp để phát triển đội dự án một cách hiệu quả.
Là Giám đốc dự án CNTT, phải đối mặt với thách thức về phía nhân sự. Đội dự án
có thể được hình thành từ một nhóm người có năng lực và được xếp lịch trình khá dày đặc.
Những người này thường coi trọng kiến thức kỹ thuật hơn là vị trí. Nhiệm vụ của Giám
đốc dự án chính là tập hợp những con người khác nhau này thành một đội, đây không phải
là một nhiệm vụ dễ dàng thực hiện. Hiệu quả làm việc của đội dự án chính là trách nhiệm
mà Giám đốc dự án phải gánh vác. Chủ đề này sẽ giúp xác định các vấn đề để ảnh hưởng
đến hiệu quả làm việc của đội dự án.
Các giai đoạn phát triển đội dự án
Mỗi người không phải sinh ra đã là một cá nhân có đầy đủ các khả năng. Họ phải
trải qua các giai đoạn phát triển và học tập cần thiết cho đến khi trưởng thành. Tương tự
như vậy, đội dự án cũng phải trải qua các giai đoạn phát triển nhất định. Hiểu được vấn đề
đó, cũng như biết các chỉ tiêu cho từng giai đoạn phát triển. Giám đốc dự án sẽ chủ động
giúp đỡ đội dự án phấn đấu đạt năng suất làm việc cao nhất có thể.

43
 Giai đoạn Đặc điểm
Hình thành Thành viên đội dự án làm quen với
nhau, thảo ra các quy tắc và sự hợp tác
giữa các thành viên.
Mâu thuẫn Nảy sinh các xung đột giữa các thành
viên đội dự án về các vấn đề tranh luận.
Hòa giải Các vấn đề giữa các thành viên đội dự
án được giải quyết, tập trung vào các
vấn
đề về quy trình và năng xuất lao động.
Thực hiện Đội dự án làm việc với năng xuất cao
nhất.

Bảng 6 : Các giai đoạn phát triển đội dự án

Giai đoạn hình thành

Trong giai đoạn Hình thành, các thành viên đội dự án thường phân vân không biết
tham gia đội dự án có phải là quyết định sáng suốt không? Họ đưa ra những đánh giá ban
đầu về kỹ năng và chất lượng làm việc của các thành viên cùng làm trong đội, và họ cũng
lo lắng xem các thành viên còn lại trong đội đánh giá về họ như thế nào?. Khi một dự án
đang được hình thành thì các cuộc trao đổi thường mang tính chất lịch sự và không có gì
bó buộc, vì các thành viên vẫn ngần ngại thể hiện nhiều quan điểm cá nhân. Những buổi
họp dự án trong giai đoạn này thường khá lộn xộn, vì các thành viên đang cố gắng tìm
hiểu nhiệm vụ của những người khác trong dự án.
Một điều lưu ý rằng các hoạt động phát triển đội dự án được đưa ra để các thành
viên trong đội cùng nhau thực hiện, chứ không phải là sự áp đặt của cấp trên cho đội. Có
thể tổ chức các hoạt động này theo từng nhóm nhỏ, hoặc theo phạm vi toàn đội. Mục đích
chính là nhằm giúp các thành viên đội dự án dần cảm thấy thoải mái khi làm việc và trao
đổi với mọi người trong đội.
b) Giai đoạn nảy sinh mâu thuẫn
Trong giai đoạn mâu thuẫn, các thành viên dự án thường rất bảo thủ và vì thế nảy
sinh nhiều mâu thuẫn. Sự khác nhau về tính cách bắt đầu bộc lộ, hệ quả của các cuộc xung
đột là các thành viên muốn làm công việc dự án, hoặc đưa ra quyết định theo cách riêng
của mình. Trong giai đoạn này, Giám đốc dự án cần phải sử dụng các kỹ năng để giải
quyết xung đột và kỹ năng ủy thác để giúp đội dự án giải quyết được vấn đề.
c) Giai đoạn hòa giải
Ở giai đoạn Hòa giải, đội dự án bắt đầu làm việc một cách năng suất mà không phải
lo lắng gì về quan điểm cá nhân hoặc các vấn đề tranh cãi. Khi xung đột vẫn còn xảy ra thì

44
người ta chỉ tập trung vào các vấn đề liên quan đến quy trình hơn là liên quan đến cá nhân.
Đội dự án bắt đầu 40 hoạt động trên cơ sở tin tưởng và trông cậy lẫn nhau.
Trong giai đoạn hòa giải, Giám đốc dự án phải thêm vào các tiêu chí bằng cách tập
trung vào các vấn đề về hiệu quả làm việc của dự án. Chẳng hạn như Giám đốc dự án phải:
- Tập trung nâng cao năng suất của đội nhằm đạt được mục tiêu của dự án.
- Nếu đội dự án mắc phải những vẫn đề cơ bản thì hãy lập các nhóm chức năng để
giải quyết vấn đề.
- Xóa bỏ tất cả những rào cản gây tổn hại đến hiệu quả làm việc của đội.
- Tạo cơ hội để ban quản lý, khách hàng, cũng như các đội khác ghi nhận hiệu quả
làm việc của Đội dự án.
d) Giai đoạn thực hiện
Trong giai đoạn Thực hiện, đội dự án sẽ làm việc với năng suất cao nhất. Việc cộng
tác và trao đổi trở nên dễ dàng, các xung đột được giải quyết. Các thành viên trong đội
cảm thấy thoải mái khi trình bày được các vấn đề, tin tưởng vào đồng đội để tìm ra giải
pháp tốt nhất cho toàn đội dự án. Vai trò Giám đốc dự án trong giai đoạn thực hiện là phải
công nhận hiệu quả làm việc của đội, nhưng lại đứng ngoài như thể đội dự án tự giải quyết
vấn đề này.

2.5. Giám sát dự án ứng dụng CNTT:

Kiểm soát dự án bao gồm ba mảng công việc chính:
-Giám sát tiến độ dự án so với kế hoạch đề ra;
-Phát hiện và giải quyết các vấn đề nảy sinh;
-Trong trường hợp gặp vấn đề không giải quyết được, điều chỉnh lại kế hoạch và
thông báo tất cả các bên liên quan.
Kiểm soát dự án tập trung xử lý những khâu vướng mắc, và không để ý đến những
khâu công việc trôi chảy. Chính vì vậy có thể coi đây là một dạng quản lý theo ngoại lệ.
 2.5.1 Giám sát dự án
Ở mỗi cấp quản lý khác nhau, việc giám sát dự án đòi hỏi những yêu cầu riêng và có
thể tiến hành theo các cách khác nhau. Dưới đây, ta sẽ xét từ phía Ban chỉ đạo (Ban giám
đốc) dự án và tứ phía khách hàng (người sử dụng).
  Giám sát dự án từ phía Ban chỉ đạo dự án
Như đã trình bày ở phần mở đầu, trong 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ễ
45
 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ả.
PGĐ điều hành làm thế nào để giám sát được nhân viên mà không gây "nhiễu",
không cản trở công việc của họ? Có thể tiến hành giám sát một cách không chính thức như
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 hoà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 tuân 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 ngoài giờ không nhiều, không có ai quá 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 đã hoà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. Cần đặc biệt chú ý
với các cuộc nói chuyện điện thoại các công văn bắt đầu bằng câu “tại sao tôi lại không
hay biết gì về .." ở mục sau ta sẽ xem GĐ dự án có thể giải quyết những vấn đề này như
thế nào.

46
  2.5.2 Giám sát dự án từ phía các cấp quản lý cao hơn
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ẽ hoà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?
Khách hàng (người sử dụng) hoàn toàn thoả mãn. Cơ quan (công ty) quản lý dự án
cùng một lúc có thể có nhiều dự án đang trong giai đoạn triển khai với cùng một 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 đề..
2.5.3  Giám sát dự án từ phía khách hàng
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 quá trình
triển khai thực hiện dự án, với cả chữ ký đại diện khách hàng. Ngoài ra, khách hàng có thể
thường xuyên gặp gỡ Ban chỉ đạo dự án để nắm tình hình
2.5.4 Kiểm soát thông qua họp định kỳ, họp tổng quan kỹ thuật và các báo cáo
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
Điều tra ở Bắc Mỹ cho thấy các nhà quản lý cấp cao (chẳng hạn ta sẽ coi là cấp
bốn)- Trợ lý Bộ trưởng, Thứ trưởng.., dành tới 99% thời gian cho các cuộc họp. Tiếp theo
các nhà quản lý cấp ba- Trưởng ban chỉ đạo hay giám đốc các chương trình lớn bao gồm

47
nhiều dự án- 90%. Các nhà quản lý cấp hai – Trưởng ban chỉ đạo hay GĐ các dự án-75%.
Và ngay cả đối với các nhà quản lý cấp một- các trưởng nhóm kỹ thuật, con số này cũng là
50%. Người ta còn nhận thấy 50% thời gian dự họp là uổng phí, vì những lý do khác nhau:
số người dự quá đông, nội dung thảo luận không được báo cáo trước, cuộc họp thường
xuyên bị gián đoạn, bị nhiễu. Sau đây ta sẽ xét mức độ cần thiết của các cuộc họp trong
chu trình một dự án CNTT cũng như phương pháp tiến hành sao cho hiệu quả.
Các cuộc họp định kỳ
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?
Các chuyên gia về quản lý dự án cho rằng nên bố trí họp định kỳ vào cuối tuần- tốt
nhất vào chiều thứ 6 hay sáng thứ 7. Như thế, mọi người sẽ tập trung cố gắng làm việc
trong tuần, gạt sang bên những gì không liên quan đến dự án, để cuối tuần có kết quả báo
cáo. Nếu bố trí họp vào thứ hai, mọi người sẽ chỉ bắt đầu lo vào cuối tuần và sẽ làm việc
căng thẳng cả thứ bảy-chủ nhật để thứ hai kịp báo cáo. Như vậy sẽ không còn thời gian
nghỉ ngơi và đỡ bị mệt mỏi.
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 quá 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

48
 Để 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 hoà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:
1. 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
hoàn thành.
2. 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.
3. 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
4. Các vấn đề còn tồn tại
Nhắc lại để các bộ phận nhớ là với tư cách là người quản lý dự án, không hề quên
những vấn đề còn chưa được giải quyết. 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
5. 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 đã hoà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.
6. Đố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
7. 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
Các cuộc họp tổng quan kỹ thuật
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ả

49
 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)
Nội dung các cuộc họp này đã được nêu chi tiết khi trình bày các giai đoạn tương
ứng của dự án. Mục đích họp xét duyệt là xem xét một chương trình, một tài liệu, một kế
hoạch thử nghiệm.. là kiểm tra lại các sản phẩm đó, tìm lỗi và đề ra các giải pháp cải tiến
tốt hơn. Thành phần tham gia có thể chỉ bao gồm tác giải sản phẩm đưa ra xét và một hoặc
hai người nữa, và Phó ban chỉ đạo phụ trách điều hành. Ngoại lệ duy nhất là họp xét duyệt
thiết kế hệ thống có thể mời thêm ba hoặc bốn chuyên gia ngoài.
Họp về quản lý
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
Các cuộc họp đặc biệt nhân các dịp đặc biệt

50
 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. Giống như huấn luyện viên triệu tập toàn bộ đội bóng trước
khi vào trận đấu. Ban chỉ đạo dự án tổ chức họp khai trương ngay sau khi dự án được ký
kết. Cuộc họp này nên chia làm hai phần: phần long trọng, họp chung, và phần họp riêng,
giữa các nhóm kỹ thuật. 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.
Như ta đã thấy ở Chương 9, 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 luôn 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ờ

51
 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. Ba đề
mục này có thể thảo luận chung. Chỉ có Phó ban chỉ đạo phụ trách điều hành, cán bộ phụ
trách nhóm lập trình và có thể thêm một cán bộ lập trình nữa tham gia. Cuộc 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ó

52
 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
Các điểm thành công của dự án
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.
 
2.6- Một số rủi ro trong thực hiện dự án ứng dụng CNTT:
Bốn bước trong quản lý rủi ro
Mọi dự án đều phải đúng hạn trong khuôn khổ ngân sách nếu không có gì trục trặc
phải chú ý tới những gì không thích hợp và cố gắng tránh chúng. Điều này được gọi là
quản lý rủi ro. Quản lý rủi ro bao gồm bốn bước:
Bước 1: Dự đoán rủi ro
Bước 2: Khủ bỏ rủi ro ở một nơi có thể
Bước 3: Giảm bớt tác động của rủi ro
Bước 4: vẫn trong kiểm soát khi có điều trục trặc
Ta hãy tham khảo chi tiết các điểm trên
Bước 1: Dự đoán rủi ro
Công việc đầu tiên và quan trọng nhất trong quản lý rủi ro là nhận biết điều gì có thể
dẫn tới sai sót. Phương pháp tốt nhất để xác định các khoản mục có thể rủi ro là nhìn vào
lịch sử và rút ra một danh sách những gì có thể đưa tới sai sót. Nếu chưa có ghi chép lịch
sử để xem lại thì cần hiểu rõ khi nào đang trong tình huống rủi ro
Ta hãy xem một số tình huống có thể gây ra rủi ro trong dự án:
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. Tiế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 dự án
không đáp ứng nổi. Có một dự án gặp phải khó khăc khi một người mới nhập cư được
53
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áycủ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ể hoà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 yê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 soát được họ, thì ta đang ở cạnh một rủi ro. Phải 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, vân vân.
Rút ngắn dự án. có thể làm cho dự án được hoàn thành sớm hơn hoặc nếu 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 toá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ì đứng trước khả năng bị cắt xén cho mỗi quý. Nếu người
dùng thanh toán theo cột mốc được bàn giao, thì 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 đ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
Có những tình huống mà khi hệ thống kết thúc thì còn tốn kém hơn là dữ liệu. Việc
thiếu xác định vấn đề là khó khăc cho việc ước lượng, đặc biệt khi người dùng không biết
chính xác anh ta muốn gì hay không thể xác định được điều đó Thiết kế tồi (không có cấu
trúc) và phương pháp lập trình tồi sẽ làm cho việc kiểm thử mất nhiều thời gian hơ dự liệu.
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ý quá 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. 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

54
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 hoà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 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ữ biết tường tận nhất không?. 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à
ta đị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.
Yê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 ta 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à không thể
được thanh toá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. Taph ải biết cách thức anh ta làm việc. Các cửa
hàng thống nhất có thể có những quy tắc đặc biệt liên quan đến thao tác viên máy tính .
Khối lượng chi thức chuyên gia về 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 toàn, thủ tục, quy tắc và hướng dẫn kiểm toá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 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
Rủi ro thấp

55
 Lĩnh vực Câu hỏi

Kích cỡ nhóm Nhóm dự án có từ 3 đến 5 người? (chú ý điều này kéo

Phần mềm/phần cứng theo rằng nhóm một hay hai người không rủi ro!)
Người sử dụng Chúng ta có đang dùng một ngôn ngữ không thích ứng
Huấn luyện với ứng dụng không? (COBOL để xử lý bít hay hợp
Thành viên nhóm ngữ cho giao thức thương mại)
Liệu người sử dụng có là người biết máy vi tính
không?
(Điều đó sẽ làm tốn thời gian huấn luyện, rồi khi anh
ta biết hơn thì anh ta sẽ đòi có sự thay đổi)
Chúng ta có thật sự cần huấn luyện về phận cứng máy
khách, phần mềm hệ thống, ngôn ngữ không?
Chúng ta có làm việc được với nhau không? Liệu có
vấn đề cốt nhân nào không? (Sức khoẻ, hiệu năng, vấn
đề cá nhân)

Bảng 7: câu hỏi rủi ro thấp

Rủi ro vừa
Lĩnh vực Câu hỏi

Kích cỡ nhóm Nhóm dự án có trên 5 người

Phần mềm/ phần cứng Liệu có yêu cầu nào về thời gian đáp ứng/ hiệu xuất
Người sử dụng hay tính sẵn có là quá đáng không?
Thành viên nhóm Liệu ta có đưa vào một phần cứng quá yếu không? Liệu
có dính dáng gì đến hợp ngữ/ ngôn ngữ macro không
(Macro khó học, khó gỡ lỗi và cũng khó tìm được
người lập trình)
Ta có phẩi sửa đổi hệ điều hành không? Có dính tới
mạng hay không? Có sản phẩm phần cứng hay phần
mềm mới nào không
Có vấn đề khó khăn trong trao đổi với người dùng
không?
(Người dùng bất hợp tác hay ở xa)
Liệu có ai trong nhóm mà người dùng không có quyền
tác động tới hay không? (Thường nhóm có thành viên
người dùng. Điều này là chấp nhận được chừng nào
người quản lý dự án đánh giá được hiệu năng của
người đó)

56
 Bảng 8: câu hỏi rủi ro vừa

Rủi ro cao
 
Lĩnh vực Câu hỏi

Phân mềm/phần cứng Trong môi trường nhiều nhà cung cấp, liệu có nhà cung
cấp nào đưa ra các sản phẩm không tương hợp không?
Chúng ta có đang dùng phần cứng, phần mềm các
Thành viên nhóm phương pháp thiết kế hay lập trình chưa từng được sửa
Các bên thứ ba trước hay không? (Đừng làm người tiên phong. Người
Hạn chót tiên phong là một anh chàng với mũi tên cắm trên
Yêu cầu ngực)
Chúng ta có làm việc được với nhau không? Liệu có
vấn đề cá nhân nào không? (Sức khoẻ, hiệu năng, vấn
đề cá nhân)
Liệu có tài năng nào phụ thuộc vào các bên ngoài sự
kiểm soát của ta không?
Liệu dự án có phải rút ngắn không? Liệu ước lượng có
được công bố không
Tài liệu yêu cầu có chắc có không, hay một trong
chúng ta (người dùng, nhóm dự án )không hiểu nó?
Bảng 9: câu hỏi rủi ro cao

Để kết luận, có thể dự tính các rủi ro bằng cách tạo ra các danh sách như trên để
nhắc nhở mình về những rủi ro có thể có. Hãy dùng lịch sử các dự án trong công ty để tạo
ra các danh sách riêng của mình. Hãy nhớ danh sách rủi ro là động phải thay đổi chúng khi
môi trường thay đổi
Bước 2. Khử bỏ rủi ro ở mọi nơi có thể
Tại điểm này một ý tưởng tốt là lập mức ưu tiên cho các khoản mục rủi ro. Hãy lập
một bảng như trong hình sau:

Bảng rủi ro
Khoản mục rủi ro Xác suất Tác động ưu tiên
(1-10) (1-10) (XxT)

Người sử dụng không trao đổi – Yêu cầu sẽ trượt 8 8 56

57
 Trưởng lập trình nghỉ phép/việc lập trình trượt 2 8 16
Bảng 10 : Bảng tính rủi ro
Ta hãy đưa vào trong bảng từng khoản mục trong bản câu hỏi rui ro mà ta đã trả lời
có hay thậm chí có thể. Hãy dịch các khoản mục rủi này thành ảnh hưởng thực tế lên dự án
của ta-thường là tăng chi phí hay thời hạn. Hãy quyết định về xác suất của việc xuất hiện
khoản mục này và gán cho nó một số từ 1 tới 10, 10 là xác suất cao nhất. Rồi quyết định
về tác động lên dự án. Hãy gán cho Tác động một số trong khoản từ 1 tới 10, 1 là khoản
mục có thể xoay sở được, 10 là khoản mục sẽ làm dừng chết dự án. Các khoản mục tác
động cao là các khoản mục rủi ro Vừa hay Cao trong phần câu hỏi rủi ro, cũng như các
khoản mục nằm trên đường găng. Hãy nhận Xác suất với Tác động cho từng khoản mục
để thu được ưu tiên
Bảng rui ro trong hình trên sẽ cho một thứ tự theo đó giải quyết khử bỏ các rủi ro.
Hiển nhiên, số ưu tiên càng cao trong Bảng rủi ro thì khoản mục đó càng phải chú ý.
Trong thực tế cần giải quyết cho các khoản mục theo thứ tự giảm dần của số ưu tiên.
Đối với mỗi khoản mục rủi ro, đầu tiên hãy thử loại bỏ nguyên nhân rủi ro. Hãy
xem xét đến quyền kiểm soát, thay đổi nhân viên, tìm phần cứng/ phần mềm tốt hơn, đào
tạo chính ta và người dùng. Mọi khoản mục đều đòi hỏi một giải pháp
Bước 3: Giảm bớt tác động của rủi ro bằng lập kế hoạch và định giá cho việc
bất ngờ
Với những khoản mục ta không thể khử bỏ được rủi ro, thì hãy xác định kế hoạch
đối phó với điều bất ngờ. Liệu còn có máy tính nào khác trong toà nhà hay trong vùng mà
ta có thể dùng sau giờ làm việc thường lệ trong trường hợp máy của ta không dùng được
không? Liệu có phương pháp mô phỏng phần mềm hay phần cứng để kiểm thử nếu chưa
có sản phẩm về chúng? Liệu có người dự phòng nào sẵn sàng làm việc với dự án của ta
trong trường hợp khẩn cấp không? Với mọi khoản mục rủi ro có dính dáng tới tài nguyên,
hãy thử sử dụng tài nguyên dự phòng.
Nếu có xác suất cao về một khoản mục rủi ro có thể xuất hiện, thì ta phải điều chỉnh
của giá tương ứng. Có nhiều dự án thành công vì giá đã được cho nổi theo một số phần
trăm nào đó. Điều này đôi khi còn được gọi là "nhân tố hương vị"vì người ước lượng lấy
hú hoạ một số phần trăm nào đó và tăng toàn bộ giá lên theo
Số phần trăm này sẽ chính xác hơn nhiều nếu nó dựa trên việc tính tác động chi phí
của khoản mục rui ro hiện tại.
Có thể tóm tắt kế hoạch cho điều bất ngờ dùng trong bảng hình sau
Bảng bất ngờ
Khoản mục rủi ro Hành động Ai Chi phí
%

Có trao đổi với người Họp theo tuần Trưởng 5000$

58
 dùng Làm bản mẫu Qlda 25000,3th
Phó Qlda

Người lập trình nghỉ Người 1/tr dự Tập sự 20.000$

phép phòng
Bảng 11: Bất ngờ và bảng tập trung
Đặt kế hoạch cho điều bất ngờ vào cột hành động của bảng bất ngờ. Trong cột Ai
đặt tên của người sẽ chụi trách nhiệm thực hiện kế hoạch cho điều bất ngờ. Với những
khoản mục của ta cần có cảnh báo sớm, hãy đặt vào cột Ai tên của cá nhân coi sóc việc
này và báo cho toàn nhóm khi sự việc xảy ra. Trong cột chi phí hãy đặt chi phí tăng lên
hoặc thời gian mà khoản mục rủi ro gây ra
Bước 4. Kiểm soát khi có điều trục trặc
Và cuối cùng, mặc cho tất cả mọi nỗ lực của ta, vài điều nào đó vẫn cứ trục trặc.
Hãy tính đến việc mọi thứ có thể trục trặc. Đừng có hoang tưởng (ngay cả khi mọi người
chống lại) và vẫn giữ kiểm soát nhiều nhất có thể được . Hãy làm hết sức mình, công bố
việc trượt dự án nếu cần, và báo cáo cho mọi người biết nguyên nhân vấn đề, đặc biệt nếu
họ ở bên ngoài quyền hạn pháp lý của ta. Mọi việc cuối cùng sẽ được giải quyết và ta vẫn
được kính trọng bởi khả năng của mình vẫn giữ bình tĩnh dưới ức ép
 
2.6- Các biện pháp đảm bảo chất lượng thực hiện dự án ứng dụng CNTT
2.6.1-Tầm quan trọng của quản lý chất lượng
Là một giám đốc CNTT, nhiệm vụ là phải bàn giao sản phẩm đạt yêu cầu, tiêu
chuẩn đặt ra trước đó. Chủ đề này sẽ giới thiệu cho ta các kỹ thuật để quản lý chất lượng
của dự án mà không gây biến động lớn về tài nguyên.
Trong suốt quá trình thực hiện dự án, làm cách nào để biết được đang đi đúng
hướng của mục tiêu đề ra? Không thể dùng quá nhiều thời gian và tiền bạc, nhưng vẫn
phải bàn giao sản phẩm. Thách thức của một Giám đốc dự án CNTT là phải thường xuyên
cân bằng giữa chất lượng với lịch trình và chi phí. Việc cân bằng như thế không phải là
một việc dễ thực hiện. Chủ đề này sẽ giới thiệu các bước để giúp người lãnh đạo duy trì dự
án ổn định.
2.6.2. Lập kế hoạch chất lượng (Planning quality)
Trong vài thập kỷ gần đây, đã có một phong trào hướng tới nâng cao chất lượng và
thay đổi trọng tâm từ thanh tra kiểm soát chất lượng tại địa điểm sản xuất (phát hiện vấn
đề) sang đảm bảo chất lượng. Trong đó chất lượng là một phần không thể thiếu của quá
trình thiết kế (phòng tránh vấn đề). Nhiều tổ chức đã áp dụng các hệ thống quản lý chất
lượng tổng thể (Total Quality Management, viết tắt là TQM), trong đó coi chất lượng là
một quá trình phát triển liên tục chứ không phải là một sự kiện diễn ra một lần. Những hệ
thống chất lượng này không chỉ được dùng trong trong quá trình phát triển sản phẩm và
dịch vụ mà còn được dùng trong các qui trình quản lý dự án. Những người đóng góp quan
59
trọng cho thành công của phong trào chất lượng này là W.Edwwrds Deming, Joseph M,
Juran, Phillip B.Crosby, Genichi Taguchi.
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 quá 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:
1. 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.
2. 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.
3. 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.
4. 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.
5. Đ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.
6. 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.
7. 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.
8. 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.
9. 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.
2.6.3. Thực hiện đảm bảo chất lượng (Quality assurance)
Đả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

60
tin rằng dự án sẽ đạt được những tiêu chuẩn 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.
a) Biến động về chất lượng
Như đã được thảo luận ở các chủ đề trước, nhiều tổ chức đã áp dụng Hệ thống Quản
lý Chất lượng tổng thể (TQM) theo mô hình Phát triển Quy trình liên tục. Giám đốc dự án
là người chịu trách nhiệm cuối cùng trong khâu quản lý chất lượng; tuy nhiên, việc đánh
giá chất lượng lại là trách nhiệm của bộ phận bảo đảm chất lượng.
b) 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. Quản lý dự án
không phải là một môn khoa học chính xác, và các dự án đều có ràng buộc về nguồn lực.
Giám đốc dự án phải xác định tầm quan trọng của các biến động vì nó 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ý.
Ví dụ: Biến động chi phí
Giả sử trong một dự án trị giá 5 triệu đô la, biến động chi phí là 5.000 đô la, tầm
quan trọng của biến động sẽ rất thấp. Nhưng với biến động chi phí là 5.000 đô la trong một
dự án trị giá 50.000

Câu hỏi chương 2:

1-Nêu một số nguyên nhân dẫn đến các dự án ứng dụng CNTT thất bại
2-Trong các giai đoạn triển khai dự án ứng dụng CNTT theo anh (chị) giai đoạn nào
là quan trọng nhất, vì sao?

Chương 3:
Giải quyết sự cố trong quá trình thực hiện đầu tư, bảo
hành và vận hành dự án ứng dụng CNTT
3.1. Nguyên tắc giải quyết sự cố:
3.1.1 Phát hiện và giải quyết các vấn đề ngay từ trước khi chúng xảy ra
"Phòng bệnh hơn chữa bệnh": Dưới đây là một số dấu hiệu "báo động” dự án có vấn
đề:
Làm việc không có kế hoạch. Đừng tin vào những lời biện minh kiểu "dự án này
nhỏ như thế cần gì phải vạch kế hoạch", hoặc "cứ làm đi đã rồi kế hoạch tự nó sẽ hình
thành sau". Hãy kiên quyết yêu cầu phải lập kế hoạch thực hiện. Không có dự án nào quá
nhỏ để không cần phải lập kế hoạch cả, và nếu không xây dựng kế hoạch ngay từ đầu, thì
sau đó với tư cách là người quản lý dự án, chúng ta sẽ rất bận, không có thời gian để làm
việc đó nữa.
61
 Các yêu cầu về chức năng không rõ ràng hoặc hoàn toàn không được xác định.
Nếu thấy ai đó khẳng định “người sử dụng không biết anh ta muốn gì", hoặc "yêu cầu còn
sẽ thay đổi”, hoặc nếu thấy quá nhiều giả định đặt ra, hãy xem lại phần đặc tả chức năng.
Hãy để người sử dụng tham gia cho ý kiến, tạo mẫu thử giao diện, hoặc tiến hành đề
cương hai giai đoạn để xác định rõ các đặc tả chức năng.
Ước lượng đại khái hoặc tuỳ tiện, hoặc bị áp đặt. Nếu nhiều ý kiến cho rằng, sẽ
không thể hoàn thành dự án đúng thời hạn và /hoặc chỉ với ngần ấy kinh phí, chắc là đã có
một sự đại khái, tuỳ tiện hoặc áp đặt nào đó trong khi ước tính. Hãy kiểm tra và ước tính
lại cho chính xác, khách quan hơn và bảo vệ các ước tính đó.
3.1.2 Phát hiện và giải quyết các vấn đề trong khi triển khai
Trong quá trình triển khai các dự án ứng dụng CNTT thường gặp các vấn đề sau
đây:
Đề xuất hoặc đề nghị thay đổi hoặc đặc tả chức năng. Qua một thời gian làm vệc,
trong số các thành viên dự án có thể sẽ có đề nghị thay đổi hoặc đặc tả chức năng, vì thấy
nếu giữ như vậy thì sẽ không thể hoàn thành và giao nộp sản phẩm đúng thời hạn được.
Câu trả lời ở đây không phải là không, trừ khi được sự đồng ý của người sử dụng. Hãy gác
các đề nghị đó lại và chấp nhận kéo dài thêm thời hạn. Ngay cả khi khách hàng đề nghị
thay đổi đặc tả chức năng, nếu trong giai đoạn triển khai thì câu trả lời vẫn không. Cần
đàm phán để dành những yêu cầu mới cho giai đoạn tiếp theo
Tài liệu chưa biên soạn xong. Tài liệu, bao gồm cả hướng dẫn sử dụng, là sản
phẩm quan trọng nhất trong một dự án ứng dụng CNTT, hãy đảm bảo hoàn tất các tài liệu
cần thiết, thậm chí nếu có vì thế mà phải đẩy lùi công việc khác. Và thử nghiệm khi thiết
kế chưa kết thúc. Như ta đã thấy trước, các chương trình viết trước khi có thiết kế bao giờ
cũng phải viết lại. Nếu thấy cán bộ lập trình nào nhàn rỗi, hãy tranh thủ đi học thêm một
khoá đào tạo hoặc nâng cao
Các báo cáo định kỳ. Ban chỉ đạo dự án cần phải ra báo cáo hàng tuần về tình hình
triển khai thực hiện dự án. Nếu các báo cáo mỗi tuần lại thấy ra muộn hơn, hoặc ngừng bặt
không thấy ra báo cáo sau chả có gì mới so với báo cáo trước, thì chắc dự án.. Hãy đi tìm
hiểu xem vấn đề đó ở đâu và thử áp dụng các biện pháp nêu trên để giải quyết.
Các thay đổi về lịch biểu báo cáo trong định kỳ. Có thể đề ra kế hoạch chính xác
cho tất cả mọi hoạt động của một dự án lớn. Nếu thấy các báo cáo có các câu dạng “Chúng
tôi định công việc X sẽ phải kéo dài 1 tuần. Ngoài ra vì công việc tưởng đến công việc Y
và công việc Y cũng phải thêm 1 tuần mới xong, nên chúng tôi thông báo thời hạn hoàn
thành dự án sẽ là 2 tuần", điều đó chứng tỏ lịch trình thực hiện được giám sát nghiêm túc
Người có trách nhiệm lâu không thấy xuất hiện. Nếu không thấy người có trách
nhiệm trả lời điện thoại, thoái thác không muốn lảnh tránh mỗi khi nhìn thấy từ xa, thì
chắc có vấn đề. Kiên quyết yêu cầu tiếp xúc và xác định xem vấn đề ở đâu. Nếu người sử
dụng không thoả mãn -thông tin này có thể từ khách hàng phản ánh, hoặc từ phía các
thành viên dự án. Chắc hẳn hỏng khâu nào đó, dự án đã không làm cho khách hàng thoả

62
mãn: bị người dự án coi thường, không được mời dự các cuộc họp tổng hợp hoặc không
được báo cáo trung thực về tiến độ dự án. Trưởng ban dự án, với tư cách là người chịu
trách nhiệm chính giao cho khách hàng, phải áp dụng ngay các biện pháp cần thiết để
không được thoả mãn
3.1.3 Phát hiện và giải quyết các vấn đề ở giai đoạn cuối
Giai đoạn kết thúc của dự án là rất quan trọng, vì đến lúc đó mọi người ai cũng mệt
mỏi, “chùng", và tất cả mọi công việc đều nằm trên đường găng. Hãy đặc biệt chú ý đến
các vấn đề sau đây:
-Thiếu giờ máy. Nguyên nhân ở đây thường là do khâu thử nghiệm mất nhiều thời
gian hơn dự tính (nhiều lỗi kỹ thuật). Tuy nhiên, thà phải kéo thời gian dự án còn hơn là
bàn giao một sản phẩm kém chất lượng
-Làm ngoài giờ quá nhiều. Hiện tượng thường xuyên phải làm ngoài giờ là dấu
hiệu chắc chắn dẫn đến sự mệt mỏi, kiệt sức. Các cán bộ lập trình thường có khuynh
hướng muốn-thậm chí ham mê-ở lại cơ quan làm việc sau giờ hành chính. Trong một giới
hạn nào đó, làm ngoài giờ có thể có năng suất, nhưng nếu vượt quá, ta sẽ thấy hiệu quả rất
thấp, thậm chí hoàn toàn không có. Trong một tuần, nói chung không nên để nhân viên ở
lại làm ngoài giờ quá hai buổi chiều.
Các cấp quản lý phía trên "quan tâm". Càng về cuối dự án (nhất là nếu dự án kết
thúc muộn), các cấp trên càng tỏ ra lo lắng. Ta thấy mình bị gọi hỏi, chất vấn nhiều hơn,
yêu cầu nộp nhiều báo cáo hơn, liên tục được triệu tập lên gặp. Ta phải mất rất nhiều thời
gian để làm cho lãnh đạo yên tâm là mọi việc được kiểm soát chặt chẽ-nhưng như thế mới
chính là công việc của người quản lý dự án
Kết luận:
Người làm quản lý dự án cần luôn giữ tay theo dõi mạch đập của dự án, phản ứng
kịp thời với mọi vấn đề phát hiện ra, và bất kỳ trong tình huống nào cũng vẫn phải bình
tĩnh, vững vàng. Rút cục, nếu không có những vấn đề xảy ra như vậy, thì người ta đã
chẳng cần đến nhà quản lý dự án làm gì.

3.2 Phát hiện và giải quyết các vấn đề sự cố

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 ứng dụng CNTT:
-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.
Các vấn đề về lịch biểu

63
 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ể:
Thứ tự ưu tiên thay đổi (có chỉ thị, yêu cầu ngừng dự án để làm việc khác )
Hàng đặt được đưa đến đúng thời hạn
Ướ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ể hoà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 ta có thể kết thúc nhanh các công việc sau để bù lại như 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ở, ta 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 hoà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ể ta 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. Ta 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 doạ nếu cần thiết.

64
 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à
tuyên bố đẩy lùi thời hạn dự án. Đây là cách phổ biến nhất và trong chừng mực nào đó là
tốt nhất vì như vậy ít rủi ro nhất.
Nên công bố thời hạn dự án như thế nào?
Công bố về việc đẩy lùi thời hạn dự án thường gây ra 2 dạng phản ứng trái ngược
nhau. Đối với “người ngoài", điều này có nghĩa là Ban chỉ đạo không kiểm soát được tổ
dự án. Tuy nhiên, đúng ra là ngược lại Ban chỉ đạo dự án đã giám sát dự án rất chặt chẽ.
Vì việc công bố đẩy lùi thời hạn dự án dù nhiều hay ít, cũng đều gây ra những sáo chộn
nhất định, nên người ta không thông báo về vấn đề này vụn vặt hàng tuần, mà thường dồn
lại và chỉ công bố vào cuối mỗi tháng.
Chú ý: Không để dồn nếu dự án đã gần đến thời hạn kết thúc, vì khi đó liên quan
đến rất nhiều vấn đề khác. Nếu ta đang ở tháng thứ 10 trong một dự án 12 tháng hãy thông
báo ngay cho khách hàng cũng như cho các bộ phận quản lý khác về mọi sự chậm trễ xảy
ra.
Có thể thử cách sau đây khi thông báo với khách hàng về việc lùi thời hạn dự án:
"tôi cần chuyển tới anh chị một tin vừa vui vừa không vui. Không vui vì chúng tôi phải
kéo dài thời hạn dự án. Nhưng vui vì chúng tôi đã thông báo với anh chị ngay từ bây giờ"
Các vấn đề về kinh phí
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

3.3. Trách nhiệm các tổ chức, cá nhân liên quan:

*Trách nhiệm của Chủ đầu tư trong việc quản lý dự án

1. Chủ đầu tư chịu trách nhiệm về quản lý thực hiện dự án, thực hiện nhiệm vụ,
quyền hạn kể từ giai đoạn chuẩn bị đầu tư, thực hiện đầu tư cho đến khi kết thúc đầu tư,
nghiệm thu bàn giao đưa sản phẩm của dự án vào khai thác sử dụng đảm bảo tính hiệu
quả, tính khả thi của dự án và tuân thủ các quy định của pháp luật, kể cả những công việc
giao cho Ban quản lý dự án hoặc thuê tổ chức tư vấn quản lý dự án thực hiện.
2. Trường hợp trực tiếp quản lý dự án nhưng không thành lập Ban quản lý dự án,
Chủ đầu tư sử dụng pháp nhân của mình để trực tiếp quản lý thực hiện dự án. Chủ đầu tư
phải có quyết định cử người tham gia quản lý dự án và phân công nhiệm vụ cụ thể, trong
đó phải có người trực tiếp phụ trách công việc quản lý dự án. Những người được cử tham
gia quản lý dự án làm việc theo chế độ kiêm nhiệm hoặc chuyên trách.
3. Trường hợp trực tiếp quản lý dự án và  thành lập Ban quản lý dự  án, Chủ đầu tư
phải cử người có trách nhiệm để chỉ đạo, đôn đốc, kiểm tra Ban quản lý dự án thực hiện
các nhiệm vụ, quyền hạn để bảo đảm dự án được thực hiện đúng nội dung và tiến độ đã
được phê duyệt.
65
 4. Trường hợp thuê tổ chức tư vấn quản lý dự án, Chủ đầu tư phải phân công ít nhất
một cán bộ lãnh đạo cơ quan, đơn vị phụ trách việc quản lý thực hiện dự án và giao nhiệm
vụ cho các đơn vị chuyên môn thuộc bộ máy của cơ quan, đơn vị mình để tham mưu, giúp
việc cho lãnh đạo thực hiện các nhiệm vụ, quyền hạn của Chủ đầu tư và kiểm tra, theo dõi
việc thực hiện hợp đồng của tư vấn quản lý dự án nhằm bảo đảm dự án được thực hiện
đúng nội dung, tiến độ, chất lượng và hiệu quả.
*Nhiệm vụ, quyền hạn của Chủ đầu tư và Ban quản lý dự án trong trường hợp
Chủ đầu tư thành lập Ban quản lý dự án
1. Chủ đầu tư có nhiệm vụ, quyền hạn sau:
a) Giao nhiệm vụ, quyền hạn cho Ban quản lý dự  án theo nguyên tắc: Phù hợp
với điều kiện thực tế của Chủ đầu tư, yêu cầu của dự án; phân định rõ trách nhiệm của
Chủ đầu tư  và Ban quản lý dự án; phân cấp mạnh cho Ban quản lý dự án theo tinh thần
nhiệm vụ phải đi đôi với quyền hạn để giảm tối đa các thủ tục hành chính giữa Chủ đầu tư
và Ban quản lý dự án;
Việc giao nhiệm vụ và uỷ quyền cho Ban quản lý dự án phải được thể hiện trong
quyết định thành lập Ban quản lý dự án, các văn bản giao nhiệm vụ và ủy quyền của Chủ
đầu tư.
Chủ đầu tư phải trực tiếp thực hiện một số nhiệm vụ, quyền hạn: phê duyệt thiết kế 
thi công và dự toán; điều chỉnh thiết kế thi công, dự toán; trình phê duyệt thiết kế sơ bộ
điều chỉnh; kiểm tra, chấp thuận một số hợp đồng quan trọng trước khi giao cho Ban quản
lý dự án ký kết; tổ chức nghiệm thu sản phẩm của dự án để đưa vào khai thác, sử dụng.
Trường hợp đặc biệt, cần thiết phải uỷ quyền cho Ban quản lý dự án thực hiện các nhiệm
vụ, quyền hạn nêu trên thì Chủ đầu tư phải báo cáo Người có thẩm quyền quyết định đầu
tư xem xét, quyết định.
b) Chủ đầu tư có thể giao cho một Ban quản lý dự án quản lý nhiều dự án khi có đủ
điều kiện năng lực.
2. Ban quản lý dự án có các nhiệm vụ  và quyền hạn sau:
a) Thực hiện nhiệm vụ do Chủ đầu tư giao và quyền hạn do Chủ đầu tư uỷ quyền.
Ban quản lý dự án chịu trách nhiệm trước Chủ đầu tư và pháp luật theo nhiệm vụ được
giao và quyền hạn được uỷ quyền;
b) Thực hiện các thủ tục và các công việc phục vụ triển khai dự án;
c) Tổ chức lập, chuẩn bị hồ sơ thiết kế thi công và dự toán, trình Chủ đầu tư thẩm
định, phê duyệt theo quy định;
d) Tổ chức lập hồ sơ yêu cầu (hồ  sơ mời thầu), tổ chức lựa chọn nhà thầu;
đ) Đàm phán, ký kết hợp đồng với các nhà thầu theo uỷ quyền của Chủ đầu tư;
e) Quản lý chất lượng, khối lượng, tiến độ, chi phí triển khai, an toàn phòng, chống
cháy, nổ, an toàn vận hành và vệ sinh công nghiệp tại hiện trường;
g) Lập báo cáo giám sát đánh giá đầu tư, báo cáo quyết toán khi dự án hoàn thành
đưa vào khai thác, sử dụng;

66
 h) Ban quản lý dự án không được thành lập các Ban quản lý dự án trực thuộc hoặc
thành lập các đơn vị sự nghiệp có thu để thực hiện quản lý dự án;
i) Khi Ban quản lý dự án được giao quản lý nhiều dự án thì từng dự án phải được
quản lý, theo dõi, ghi chép riêng và quyết toán kịp thời sau khi kết thúc dự án theo đúng
quy định;
k) Trường hợp cần thiết, Ban quản lý dự án được phép thuê các tổ chức, cá nhân có
đủ điều kiện năng lực, kinh nghiệm để tham gia quản lý, giám sát một số phần việc Ban
quản lý dự án không có đủ điều kiện, năng lực chuyên môn thực hiện, nhưng phải được
Chủ đầu tư chấp thuận. Chi phí thuê các tổ chức, cá nhân trong trường hợp này được tính
vào chi phí tư vấn đầu tư trong tổng mức đầu tư, dự toán của dự án.
l) Ban quản lý dự án được ký hợp đồng thuê cá nhân, tổ chức tư vấn nước ngoài có
kinh nghiệm, năng lực để quản lý các công việc mà tư vấn trong nước chưa đủ năng lực
thực hiện hoặc khi có yêu cầu đặc biệt khác. Việc thuê tư vấn nước ngoài trong trường hợp
này phải được Người có thẩm quyền quyết định đầu tư cho phép.
3. Cơ cấu tổ chức của Ban quản lý dự án gồm có giám đốc (hoặc Trưởng ban), các
phó giám đốc (hoặc Phó Trưởng ban), các đơn vị chuyên môn, nghiệp vụ; những người
tham gia Ban quản lý dự án có thể làm việc theo chế độ chuyên trách hoặc kiêm nhiệm.
Giám đốc, các phó giám đốc và những người phụ trách về công nghệ thông tin, kinh
tế, tài chính phải có trình độ đại học thuộc chuyên ngành phù hợp với lĩnh vực phụ trách,
có kinh nghiệm làm việc chuyên môn tối thiểu 3 năm và đã được bồi dưỡng nghiệp vụ về
quản lý, đầu tư ứng dụng công nghệ thông tin (bộ môn lập và quản lý dự án). Riêng đối
với các dự án nhóm C ở vùng sâu, vùng xa thì các chức danh nêu trên có thể giao cho
những người có trình độ cao đẳng hoặc trung cấp thuộc các chuyên ngành phù hợp.
Chuyển đổi, tổ chức lại các Ban quản lý dự án thiếu việc hoặc hết việc
1. Các Bộ, cơ quan ngang bộ, Uỷ ban nhân dân các cấp căn cứ tình hình thực
tế về số  lượng các dự án ứng dụng công nghệ thông tin do mình đang quản lý và định
hướng, kế hoạch ứng dụng công nghệ thông tin của năm sau để quyết định việc chuyển đổi
hoặc tổ chức lại các Ban quản lý dự án theo một trong các phương án sau đây:
a) Trường hợp các bộ, ngành, địa phương có số  lượng dự án ít dẫn đến tình trạng
có  Ban quản lý dự án thiếu việc hoặc hết việc thì cần nghiên cứu sắp xếp, tổ chức lại các
Ban quản lý dự án cho phù hợp với yêu cầu thực tế; chỉ giữ lại các Ban quản lý dự án đang
quản lý các dự án dở dang hoặc các dự án đã được quyết định đầu tư trong trường hợp áp
dụng hình thức Chủ đầu tư trực tiếp quản lý dự án, không để tình trạng các Ban quản lý
phải chờ dự án;
Việc sắp xếp, tổ chức lại các Ban quản lý  dự án thực hiện theo hướng chuyển thành
doanh nghiệp tư vấn quản lý dự án chuyên nghiệp, giúp Chủ đầu tư thực hiện quản
lý dự án thông qua hợp đồng ký với Chủ đầu tư. Căn cứ điều kiện thực tế, các bộ, ngành,
địa phương chỉ đạo thành lập các doanh nghiệp tư vấn quản lý dự án trên cơ sở chuyển đổi

67
từ một Ban quản lý dự án hoặc ghép nhiều Ban quản lý dự án, bảo đảm điều kiện năng lực
để quản lý các dự án theo quy định.
Đối với các Ban quản lý dự án không thể sắp xếp, chuyển đổi theo các phương án
nêu trên thì bộ, ngành, địa phương ra quyết định giải thể và có trách nhiệm giải quyết dứt
điểm các tồn tại của các dự  án cũ và quyền lợi của cán bộ, nhân viên Ban quản lý dự án.
b) Trường hợp các Ban quản lý dự án có  nguyện vọng được chuyển đổi thành
doanh nghiệp tư vấn nhằm khai thác, phát huy hết năng lực chuyên môn, nghiệp
vụ và kinh nghiệm sẵn có của Ban quản lý dự án thì bộ, ngành, địa phương quyết định
và tạo điều kiện để các Ban quản lý dự án chuyển đổi thành doanh nghiệp tư vấn quản lý
dự án chuyên nghiệp, và phải bảo đảm không làm gián đoạn quá trình quản lý thực hiện
các dự án.
* Nhiệm vụ, quyền hạn của Chủ đầu tư và tổ chức tư vấn quản lý dự án trong
trường hợp Chủ đầu tư thuê tư vấn quản lý dự án
1. Chủ đầu tư lựa chọn và ký hợp  đồng với tổ chức tư vấn quản lý dự  án để giúp
Chủ đầu tư quản lý thực hiện dự án.
2. Tổ chức tư vấn quản lý dự án phải có đủ năng lực phù hợp với công việc đảm
nhận theo quy định tại Điều 69 Nghị định này.
3. Tổ chức tư vấn quản lý dự án thực hiện các nội dung quản lý thực hiện dự án theo
hợp đồng ký với Chủ đầu tư. Hợp đồng thuê tư vấn quản lý dự án phải nêu rõ phạm vi
công việc và nội dung quản lý; quyền hạn, trách nhiệm của tư vấn và của Chủ đầu tư.
4. Tổ chức tư vấn quản lý dự án có trách nhiệm tổ chức bộ máy và cử người phụ
trách để trực tiếp thực hiện nhiệm vụ quản lý thực hiện dự án theo hợp đồng đã ký với Chủ
đầu tư. Tư vấn quản lý dự án phải có văn bản thông báo về nhiệm vụ, quyền hạn của người
phụ trách và bộ máy của tư vấn trực tiếp thực hiện quản lý dự án cho Chủ đầu tư biết và
thông báo tới các nhà thầu khác và tổ chức, cá nhân có liên quan.
5. Tổ chức tư vấn quản lý dự án được thuê các tổ chức, cá nhân có đủ điều kiện
năng lực, kinh nghiệm để thực hiện một số phần việc quản lý dự án, nhưng phải được Chủ
đầu tư chấp thuận và phù hợp với nhiệm vụ, quyền hạn trong hợp đồng đã ký với Chủ đầu
tư.
6. Tổ chức tư vấn quản lý dự án phải chịu trách nhiệm trước pháp luật và Chủ đầu
tư về các nội dung đã cam kết trong hợp đồng và phải bồi thường thiệt hại do lỗi của mình
gây ra trong quá trình quản lý dự án.

3.3.1 Trách nhiệm của chủ đầu tư hoặc đơn vị thụ hưởng đầu tư khi xảy ra sự cố
Theo điều 9 thông tư 02/2011/TT-BTTTT ngày 4/1/2011 do thứ trưởng Nguyễn
Minh Hồng ký có nêu rõ:
Trong quá trình thực hiện đầu tư, bảo hành, vận hành, khai thác sử dụng đối với các
dự án ứng dụng công nghệ thông tin, nếu sự cố xảy ra, chủ đầu tư hoặc đơn vị thụ hưởng
đầu tư (chủ sở hữu hoặc chủ quản lý, sử dụng sản phẩm của dự án) có trách nhiệm:

68
 1. Thực hiện ngay các biện pháp xử lý nhanh khi xảy ra sự cố theo quy định:
2. Lập hồ sơ sự cố theo quy định.
3. Lập kế hoạch giải quyết sự cố quy định.
4. Phối hợp với nhà thầu tham gia dự án và các bên có liên quan để giải quyết sự cố.
5. Giám sát và nghiệm thu công tác giải quyết sự cố.
3.3.2 Trách nhiệm của các nhà thầu tham gia dự án khi xảy ra sự cố
Trong quá trình thực hiện đầu tư, bảo hành, vận hành, khai thác sử dụng đối với các
dự án ứng dụng công nghệ thông tin, nếu sự cố xảy ra nhà thầu có trách nhiệm:
1. Phối hợp với chủ đầu tư thực hiện ngay các biện pháp xử lý nhanh khi xảy ra sự
cố theo quy định.
2. Chỉ tiếp tục thi công sau khi đã giải quyết toàn bộ sự cố, được sự nhất trí của chủ
đầu tư hoặc đơn vị thụ hưởng đầu tư.
3. Phối hợp với chủ đầu tư hoặc đơn vị thụ hưởng đầu tư hoàn thiện hồ sơ sự cố và
kế hoạch giải quyết sự cố.
4. Chịu trách nhiệm giải quyết sự cố do lỗi của mình cho đến khi nghiệm thu công
tác giải quyết sự cố.
3.3.3 Kinh phí thực hiện
Kinh phí xử lý nhanh sự cố, lập hồ sơ sự cố và thu dọn hiện trường sự cố được tạm
trích từ kinh phí sự nghiệp thuộc các cơ quan hành chính sự nghiệp hoặc trích từ vốn ngân
sách nhà nước đã bố trí cho chủ đầu tư để thanh toán. Sau khi làm rõ trách nhiệm của tổ
chức, cá nhân gây ra sự cố, bên có lỗi phải chịu hoàn lại toàn bộ kinh phí liên quan đến
công tác xử lý nhanh, lập hồ sơ sự cố và thu dọn hiện trường sự cố.
Kinh phí giải quyết sự cố:
*Kinh phí giải quyết sự cố do các nguyên nhân sau do bên có lỗi chi trả:
-Do lỗi hệ thống: hệ thống không đáp ứng tiêu chuẩn, quy chuẩn kỹ thuật, quy trình

sản xuất.
-Do các trường hợp bất khả kháng (hỏa hoạn, thiên tai, chiến tranh, v.v…).
-Các nguyên nhân khác ngoài các nguyên nhân đã nêu trên.
*Kinh phí giải quyết sự cố do nguyên nhân bởi các trường hợp bất khả kháng như
(hỏa hoạn, thiên tai, chiến tranh, v.v…). được trích từ kinh phí sự nghiệp thuộc các cơ
quan hành chính sự nghiệp hoặc từ vốn ngân sách nhà nước đã được bố trí cho chủ đầu tư
để thanh toán.

3.4 Nội dung giải quyết sự cố:

Tong quá trình thực hiện các dự án ứng dụng CNTT nếu có sự cố cần xử lý các vấn
đề như sau:
3.4.1 Xử lý nhanh khi có sự cố
Trong quá trình thực hiện đầu tư, bảo hành, vận hành, khai thác sử dụng đối với các
dự án ứng dụng công nghệ thông tin, nếu sự cố xảy ra, nhà thầu, chủ đầu tư và đơn vị thụ

69
hưởng đầu tư (chủ sở hữu hoặc chủ quản lý, sử dụng sản phẩm của dự án) có trách nhiệm
sau:
1. Ngừng thi công, vận hành hoặc khai thác, sử dụng một phần hoặc toàn bộ hệ
thống công nghệ thông tin.
2. Thực hiện các biện pháp kỹ thuật cần thiết để ngăn ngừa các sự cố có thể tiếp tục
xảy ra và đảm bảo an toàn cho người và tài sản.
3. Thông báo kịp thời cho các tổ chức, cá nhân có thẩm quyền.
4. Cá nhân hoặc đơn vị tại địa điểm thi công lắp đặt, cài đặt, sử dụng, vận hành, khai
thác thiết bị phải lập báo cáo nhanh sự cố hệ thống công nghệ thông tin theo mẫu và gửi
báo cáo nhanh cho chủ đầu tư, đơn vị thụ hưởng đầu tư (chủ sở hữu hoặc chủ quản lý, sử
dụng sản phẩm của dự án).
5. Bảo vệ hiện trường, trừ trường hợp phải giải quyết khẩn cấp để hạn chế thiệt hại.
3.4.2 Lập hồ sơ sự cố
1. Hồ sơ sự cố bao gồm:
a) Biên bản kiểm tra hiện trường sự cố theo mẫu tại Phụ lục V Nghị định số
102/2009/NĐ-CP ngày 06 tháng 11 năm 2009 của Chính phủ về quản lý đầu tư ứng dụng
công nghệ thông tin sử dụng nguồn vốn ngân sách nhà nước (dưới đây gọi tắt là Nghị định
số 102/2009/NĐ-CP);
b) Mô tả diễn biến của sự cố;
c) Kết quả khảo sát, đánh giá, xác định mức độ và nguyên nhân sự cố;
d) Các tài liệu về thiết kế và thi công liên quan đến sự cố.
2. Tùy từng trường hợp, chủ đầu tư, đơn vị thụ hưởng (chủ sở hữu hoặc chủ quản lý,
sử dụng sản phẩm của dự án) có thể tự thực hiện (nếu đủ năng lực) hoặc thuê các cá nhân,
tổ chức có đủ điều kiện năng lực theo quy định tại Chương VI Nghị định số 102/2009/NĐ-
CP để thực hiện tư vấn khảo sát, đánh giá, xác định nguyên nhân sự cố, xác định thiệt hại
do sự cố gây ra và làm rõ trách nhiệm của tổ chức hoặc cá nhân gây ra sự cố để hoàn thiện
hồ sơ sự cố theo quy định.
3.4.4 Thu dọn hiện trường sự cố
Sau khi có đầy đủ hồ sơ sự cố đáp ứng cho việc nghiên cứu, phân tích và xác định
nguyên nhân gây nên sự cố, nhà thầu, chủ đầu tư hoặc đơn vị thụ hưởng đầu tư (chủ sở
hữu hoặc chủ quản lý, sử dụng sản phẩm của dự án) tiến hành các bước sau:
1. Chụp ảnh, quay phim hoặc ghi hình, thu thập, ghi chép thông tin cần thiết có liên
quan đến sự cố.
2. Tháo dỡ, thu dọn hiện trường xảy ra sự cố.
3. Tiến hành các biện pháp cần thiết ngăn ngừa sự cố tiếp theo.
3.4.5 Giải quyết sự cố
1. Chủ đầu tư, đơn vị thụ hưởng (chủ sở hữu hoặc chủ quản lý, sử dụng sản phẩm
của dự án) và các nhà thầu tham gia dự án có trách nhiệm lập kế hoạch giải quyết sự cố
bao gồm các nội dung cơ bản sau:

70
 a) Thông tin chung;
b) Nội dung, biện pháp giải quyết;
c) Nguồn lực thực hiện;
d) Tiến độ thực hiện.
2. Sau khi đã xác định trách nhiệm giải quyết sự cố, các bên liên quan phải lập biên
bản xác nhận việc giải quyết sự cố theo mẫu.
3. Thực hiện giải quyết sự cố theo nội dung đã nêu.
4. Nghiệm thu công tác giải quyết sự cố. Biên bản nghiệm thu khắc phục sự cố theo
mẫu.

Câu hỏi chương 3:

1- Trách nhiệm của các bên trong quá trình giải quyết các sự cố trong triển khai các
dự án ứng dụng CNTT
2- Quy trình giải quyết sự cố khi triển khai các ự án dứng dụng CNTT

Tài liệu tham khảo:

Tiếng Việt
1. Đề án Tin học hoá quản lý hành chính Nhà nước 2001-2005 trong hành động - NXB
Chính trị Quốc gia - Hà Nội - 2002

71
 2. Quản lý thông tin và Công nghệ Thông tin - Tài liệu cơ sở để xây dựng bài giảng ở các
học viện, trường đào tạo và bồi dưỡng cán bộ, công chức và cán bộ quản lý - Dự án
Công nghệ Thông tin Việt Nam - Canada - Hà Nội - 2000
3. Phương pháp luận quản lý dự án Công nghệ thông tin - Ngô Trung Việt - NXB KHKT -
Hà Nội - 2002
4. Hội thảo do IBM tổ chức "Quy trình thống nhất và mô hình trực quan trong nền kinh tế
phần mềm hiện đại" - Hà Nội - 5/2003
5. Bộ tài liệu Chương trình bồi dưỡng nghiệp vụ quản lý đầu tư ứng dụng công nghệ thông
tin của Cục ứng dụng CNTT, Bộ Thông tin và Truyền thông
6. Tạp chí Tin học và đời sống - Hội Tin học Việt Nam
7. Thế giới Vi tính, PC WORLD B - Tạp chí chuyên đề giải pháp cho tổ chức - doanh
nghiệp - Sở KH-CN- Tp HCM
Tiếng Anh
8. Project Management Methodology - Ralph L. Kliem, Irvin S. Ludin, Ken L. Robertson
- Marcel Dekker Inc., 1997
9. Software Project Management - Bob Hughes and Mike Cotterell - The McGraw Hill -
Third Edition - 2002
10. A Guide to the Project Management - Body of Knowledge - William R. Duncan - PMI
Standard Committee - 1996
11. Software Engineering - A Practitioner's approach - Roger S. Pressman - Fifth edition -
McGraw Hill - 2001
12. Managing Large Database Development Projects -Tài liệu giảng cho Workshop - Dự án
CNTT Việt Nam-Canada tổ chức tại Hà Nội - tháng 5/1998
13. Robert K. Wysocki Ph.D., Effective Software Project Management, Wiley, 2006
14. Một số Website
15. http://www.spmn.com/
16. http://www.projectmanagement.com/main.html
17. http://www.pmi.org/

CÁC PHỤ LỤC

1-Giới thiệu phần mềm Microsoft Project
Phần mềm hỗ trợ cho việc quản ý dự án có nhiều, từ đơn giản như bảng tính, soạn
thảo văn bản.. đến các phần mềm đặc trưng hỗ trợ cho từng công việc liên qua đến quản lý
dự án như lập lịch, theo dõi, lưu trữ thông tin.. Trong phần này, chúng tôi chỉ tập trung
giới thiệu các chức năng chính của MicroSofft Prọect- một trong những công cụ phần
mềm có thể hỗ trợ cho chúng ta trong việc phân chỉa các công việc, lập lịch, theo dõi tiến
độ, điều phối nhân lực..
Quản lý dự án bằng Microsoft Project
Microsoft Project giúp lập kế hoạch, quản lý và trao đổi thông tin về dự án một cách
hiệu quả bằng cách sự dụng sức mạnh của cách lập lịch theo phương pháp đường găng
một các dễ dàng trong môi trường đồ hoạ. Với Microsoft Project, có được sự mềm dẻo và
72
sự kiểm soát cần thiết để tạo lập và tổ chức các dự án của họ. Có thể dùng đặc tính đặt
thông số riêng của Microsoft Project để đáp ứng các yêu cầu đặc trưng của mình và theo
dõi chính xác các thông tin mong muốn
Với các khả năng lập báo cáo được đổi mới của Microsoft Project có thể trao đổi
thông tin một cách dễ dàng bằng cách tạo, sửa đổi và in ấn cáo báo cáo chất lượng cao.
Thêm vào đó có thể truyền dữ liệu dễ dàng giữa Microsoft Project và các chương trình ứng
dụng khác, bao gồm cả Microsoft Excel và Microsoft Word
Tài liệu này nhằm phục vụ cho các cán bộ tham gia công tác quản lý dự án muốn
tăng hiệu quả của công việc bằng cách sử dụng các thành quả của CNTT, cụ thể là phần
mềm Microsoft Project. Tài liệu này chỉ đề cập đến các chức năng chính của MP. Các
chức năng nâng cao có thể tìm thấy trong các tài liệu về MP phiên bản tiếng Anh
Yêu cầu cơ bản đồi hỏi là người dùng có thể sử dụng thành thạo các chức năng cơ
bản của hệ điều hành Windows. Cụ thể là các thao tác sử dụng bàn phím và chuột, các
thao tác thực hiện lệnh chương trình trong Windows, các thao tác chọn Font, Size và các
chức năng in ấn, ..
Cách học tốt nhất này là người sử dụng ngồi trước màn hình và thực hiện các thao
tác trên MP theo hướng dẫn trong tài liệu.

73
 2- Các phụ lục mẫu biểu khi thực hiện dự án và khi giải quyết các sự cố của dự án
ứng dụng CNTT
Phụ lục I
Mẫu Biên bản nghiệm thu vật tư, thiết bị công nghệ thông tin
(Ban hành kèm theo Thông tư số 28 /2010/TT-BTTTT ngày 13/12/2010
của Bộ trưởng Bộ Thông tin và Truyền thông)
CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
Độc lập - Tự do - Hạnh phúc

…, ngày ….. tháng…… năm 20…..

BIÊN BẢN NGHIỆM THU VẬT TƯ, THIẾT BỊ CÔNG NGHỆ THÔNG TIN
DỰ ÁN:...............................
Hạng mục:…………………………………………………………………
Đơn vị thi công…………………………………….....................................
Đơn vị cung cấp:…………………………………………………………...
Loại vật liệu:………………………………………………………………..
I. THÀNH PHẦN NGHIỆM THU:
1. Đại diện chủ đầu tư:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ:…………………
2. Đại diện tư vấn giám sát thi công:
- Ông (Bà):…………………….. Chức vụ: Cán bộ giám sát thi công
3. Đại diện đơn vị thi công:
- Ông (Bà):…………………….. Chức vụ: Cán bộ thi công
II. THỜI GIAN NGHIỆM THU:
Bắt đầu: ......giờ...... ngày.......... tháng......... năm..........
Kết thúc: .......giờ...... ngày.......... tháng......... năm..........
Tại: …………………
III. NỘI DUNG:
1. Về giấy chứng nhận chất lượng của nhà sản xuất.
2. Về kết quả kiểm thử, kiểm định chất lượng vật tư, thiết bị của các tổ chức được cơ quan
nhà nước có thẩm quyền công nhận đối với vật tư, thiết bị công nghệ thông tin lắp đặt
trong dự án được nêu trong hồ sơ dự thầu trước khi đưa vào thi công.
3. Về các thông số kỹ thuật đối với các vật tư, thiết bị công nghệ thông tin so với các
thông số kỹ thuật ghi trong hợp đồng và hồ sơ thiết kế thi công trước khi đưa vào thi công.

IV. KẾT LUẬN:

- Chấp nhận hay không chấp nhận nghiệm thu.
- Yêu cầu sửa chữa và các yêu cầu khác (nếu có).
74
Các bên trực tiếp nghiệm thu chịu trách nhiệm trước pháp luật về Quyết định nghiệm thu
này.
ĐẠI DIỆN TƯ VẤN GIÁM SÁT ĐẠI DIỆN CHỦ ĐẦU TƯ
(Ký, ghi rõ họ tên) (Ký, ghi rõ họ tên)

ĐẠI DIỆN ĐƠN VỊ THI CÔNG

(Ký, ghi rõ họ tên)

75
 Phụ lục II
Mẫu Biên bản nghiệm thu vận hành thử thiết bị công nghệ thông tin
(Ban hành kèm theo Thông tư số 28 /2010/TT-BTTTT ngày 13/12/2010
của Bộ trưởng Bộ Thông tin và Truyền thông)

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập - Tự do - Hạnh phúc

……….., ngày……tháng……năm 20…..

BIÊN BẢN NGHIỆM THU VẬN HÀNH THỬ THIẾT BỊ CÔNG

NGHỆ THÔNG TIN
DỰ ÁN:...............................

1. Hệ thống thiết bị công nghệ thông tin được nghiệm thu bao gồm:

Nêu rõ hệ thống thiết bị công nghệ thông tin và thời gian vận hành thử (bắt đầu, kết thúc)

2. Thành phần trực tiếp nghiệm thu:

1. Đại diện chủ đầu tư:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ:…………………
2. Đại diện tư vấn giám sát thi công:
- Ông (Bà):…………………….. Chức vụ: Cán bộ giám sát thi công
3. Đại diện đơn vị tư vấn thiết kế:
- Ông (Bà):…………………….. Chức vụ: Cán bộ thiết kế
4. Đại diện đơn vị thi công:
- Ông (Bà):…………………….. Chức vụ: Cán bộ thi công
3. Thời gian nghiệm thu:

Bắt đầu: ......giờ...... ngày.......... tháng......... năm..........

Kết thúc: .......giờ...... ngày.......... tháng......... năm..........
Tại: …………………
4. Đánh giá công tác chạy thử thiết bị đã thực hiện:
a) Tài liệu làm căn cứ nghiệm thu;
b) Về chất lượng kiểm thử, vận hành thử thiết bị công nghệ thông tin (đối chiếu với
thiết kế, tiêu chuẩn thi công, lắp đặt và các yêu cầu kỹ thuật của dự án);
c) Công suất đưa vào vận hành:
- Công suất theo thiết kế thi công đã được phê duyệt;
76
 - Công suất theo thực tế đạt được;
d) Các ý kiến khác (nếu có).
5. Kết luận:
- Chấp nhận hay không chấp nhận nghiệm thu.
- Yêu cầu sửa chữa, hoàn thiện dự án đã thực hiện và các yêu cầu khác (nếu có).
Các bên trực tiếp nghiệm thu chịu trách nhiệm trước pháp luật về Quyết định nghiệm
thu này.

ĐẠI DIỆN TƯ VẤN GIÁM SÁT ĐẠI DIỆN CHỦ ĐẦU TƯ

(Ký, ghi rõ họ tên) (Ký, ghi rõ họ tên)

ĐẠI DIỆN ĐƠN VỊ TƯ VẤN THIẾT KẾ ĐẠI DIỆN ĐƠN VỊ THI CÔNG
(Ký, ghi rõ họ tên) (Ký, ghi rõ họ tên)

77
 Phụ lục III
Mẫu Biên bản nghiệm thu lắp đặt thiết bị công nghệ thông tin
(Ban hành kèm theo Thông tư số 28 /2010/TT-BTTTT ngày 13/12/2010
của Bộ trưởng Bộ Thông tin và Truyền thông)

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập - Tự do - Hạnh phúc

……., ngày……tháng……năm 20…..

BIÊN BẢN NGHIỆM THU LẮP ĐẶT THIẾT BỊ CÔNG NGHỆ THÔNG TIN
DỰ ÁN:...............................

I. Thiết bị/Cụm thiết bị công nghệ thông tin được nghiệm thu:
- Nêu rõ tên thiết bị công nghệ thông tin, địa điểm lắp đặt.
II. Thành phần trực tiếp nghiệm thu:
1. Đại diện chủ đầu tư:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ:…………………
2. Đại diện tư vấn giám sát thi công:
- Ông (Bà):…………………….. Chức vụ: Cán bộ giám sát thi công
3. Đại diện đơn vị tư vấn thiết kế:
- Ông (Bà):…………………….. Chức vụ: Cán bộ thiết kế
4. Đại diện đơn vị thi công:
- Ông (Bà):…………………….. Chức vụ: Cán bộ thi công

III. Thời gian nghiệm thu:

Bắt đầu: ......giờ...... ngày.......... tháng......... năm..........

Kết thúc: .......giờ...... ngày.......... tháng......... năm..........
Tại: …………………

IV. Đánh giá công việc lắp đặt (xây lắp) đã thực hiện:

a) Tài liệu làm căn cứ nghiệm thu:

b) Về chất lượng lắp đặt thiết bị công nghệ thông tin (đối chiếu với thiết kế, tiêu chuẩn
thi công và yêu cầu kỹ thuật của dự án):
c) Ý kiến của người giám sát thi công các dự án của chủ đầu tư về công tác nghiệm thu
công việc thi công của tổng thầu đối với nhà thầu phụ.
78
 d) Các ý kiến khác (nếu có):
V. Kết luận:
- Chấp nhận hay không chấp nhận nghiệm thu, đồng ý cho triển khai thi công các
công việc tiếp theo.
- Yêu cầu sửa chữa, hoàn thiện những tồn tại trong quá trình thi công và các yêu cầu
khác (nếu có).
Các bên trực tiếp nghiệm thu chịu trách nhiệm trước pháp luật về Quyết định
nghiệm thu này.

ĐẠI DIỆN TƯ VẤN GIÁM SÁT ĐẠI DIỆN CHỦ ĐẦU TƯ

(Ký, ghi rõ họ tên) (Ký, ghi rõ họ tên)

ĐẠI DIỆN ĐƠN VỊ TƯ VẤN THIẾT KẾ ĐẠI DIỆN ĐƠN VỊ THI CÔNG
(Ký, ghi rõ họ tên) (Ký, ghi rõ họ tên)

79
 Phụ lục IV
Mẫu Biên bản nghiệm thu kiểm thử, vận hành thử
(Ban hành kèm theo Thông tư số 28 /2010/TT-BTTTT ngày 13/12/2010
của Bộ trưởng Bộ Thông tin và Truyền thông)

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập - Tự do - Hạnh phúc

……………., ngày …… tháng…..năm 20…..

BIÊN BẢN NGHIỆM THU KIỂM THỬ, VẬN HÀNH THỬ

DỰ ÁN:...............................

1. Phần mềm nội bộ, cơ sở dữ liệu được nghiệm thu:

Nêu rõ phần mềm nội bộ, cơ sở dữ liệu và thời gian kiểm thử, vận hành thử (bắt đầu, kết
thúc)

2. Thành phần trực tiếp nghiệm thu:

1. Đại diện chủ đầu tư:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ:…………………
2. Đại diện đơn vị được giao quản lý, sử dụng:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ:…………………
3. Đại diện tư vấn giám sát thi công:
- Ông (Bà):…………………….. Chức vụ: Cán bộ giám sát thi công
4. Đại diện đơn vị tư vấn thiết kế:
- Ông (Bà):…………………….. Chức vụ: Cán bộ thiết kế
5. Đại diện đơn vị thi công:
- Ông (Bà):…………………….. Chức vụ: Cán bộ thi công
3. Thời gian nghiệm thu:
Bắt đầu: ......giờ...... ngày.......... tháng......... năm..........
Kết thúc: .......giờ...... ngày.......... tháng......... năm..........
Tại: …………………
4. Đánh giá công tác kiểm thử, vận hành thử phần đã thực hiện:
a) Tài liệu làm căn cứ nghiệm thu:

80
 b) Về chất lượng kiểm thử, vận hành thử (đối chiếu với thiết kế, tiêu chuẩn thi công và
các chỉ tiêu kỹ thuật của dự án).
c) Các tính năng đưa vào vận hành:
- Các chức năng, thuộc tính theo thiết kế thi công đã được phê duyệt.
- Các chức năng, thuộc tính thực tế đạt được.
d) Các ý kiến khác (nếu có).
5. Kết luận:
- Chấp nhận hay không chấp nhận nghiệm thu.
- Yêu cầu sửa chữa, hoàn thiện các khuyết điểm phần mềm nội bộ, cơ sở dữ liệu dự án
đã thực hiện và các yêu cầu khác (nếu có).
Các bên trực tiếp nghiệm thu chịu trách nhiệm trước pháp luật về Quyết định
nghiệm thu này.

ĐẠI DIỆN TƯ VẤN GIÁM SÁT ĐẠI DIỆN CHỦ ĐẦU TƯ

(Ký, ghi rõ họ tên) (Ký, ghi rõ họ tên)

ĐẠI DIỆN ĐƠN VỊ TƯ VẤN THIẾT KẾ ĐẠI DIỆN ĐƠN VỊ ĐƯỢC GIAO
(Ký, ghi rõ họ tên) QUẢN LÝ, SỬ DỤNG
(Ký, ghi rõ họ tên)

81
 ĐẠI DIỆN ĐƠN VỊ THI CÔNG
(Ký, ghi rõ họ tên)
Phụ lục V
Mẫu Biên bản nghiệm thu bàn giao sản phẩm dự án ứng dụng
công nghệ thông tin
(Ban hành kèm theo Thông tư số 28 /2010/TT-BTTTT ngày 13/12/2010
của Bộ trưởng Bộ Thông tin và Truyền thông)

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập - Tự do - Hạnh phúc

………., ngày…..tháng…..năm 20….

BIÊN BẢN NGHIỆM THU BÀN GIAO SẢN PHẨM DỰ ÁN

ỨNG DỤNG CÔNG NGHỆ THÔNG TIN
DỰ ÁN:..............................
I. Đối tượng nghiệm thu: (ghi rõ tên sản phẩm được nghiệm thu)
II. Thành phần trực tiếp nghiệm thu:
1. Đại diện chủ đầu tư:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ:…………………
2. Đại diện đơn vị được giao quản lý, sử dụng:
- Ông (Bà):……………………. Chức vụ:…………………
- Ông (Bà):.....……………… … Chức vụ: …………………
3. Đại diện tư vấn giám sát thi công:
- Ông (Bà):……………………. Chức vụ:…………………
- Ông (Bà):.....……………… … Chức vụ: Cán bộ giám sát thi công
4. Đại diện đơn vị tư vấn thiết kế:
- Ông (Bà):……………………. Chức vụ:…………………
- Ông (Bà):……………………. Chức vụ: Cán bộ thiết kế
5. Đại diện đơn vị thi công:
- Ông (Bà):……………………. Chức vụ:…………………
- Ông (Bà):…………………… Chức vụ: Cán bộ thi công
III. Thời gian nghiệm thu:

Bắt đầu: .......... ngày.......... tháng......... năm ..........

Kết thúc: ........... ngày.......... tháng......... năm..........
Tại: …………………

82
IV. Đánh giá công việc thi công đã thực hiện:
a) Về tài liệu làm căn cứ nghiệm thu:
b) Về chất lượng thi công dự án (đối chiếu với thiết kế, tiêu chuẩn kỹ thuật và yêu cầu
của dự án):
c) Về khối lượng thi công:
d) Về tiến độ thi công:
đ) Các ý kiến khác (nếu có):
V. Kết luận:
- Chấp nhận hay không chấp nhận nghiệm thu, đồng ý cho triển khai các công việc thi
công tiếp theo.
- Yêu cầu sửa chữa, hoàn thiện công việc thi công đã thực hiện và các yêu cầu khác
(nếu có).
Các bên trực tiếp nghiệm thu chịu trách nhiệm trước pháp luật về Quyết định
nghiệm thu này.

ĐẠI DIỆN TƯ VẤN GIÁM SÁT ĐẠI DIỆN CHỦ ĐẦU TƯ

(Ký, ghi rõ họ tên, chức vụ (Ký, ghi rõ họ tên, chức vụ
và đóng dấu) và đóng dấu)

ĐẠI DIỆN ĐƠN VỊ TƯ VẤN THIẾT KẾ ĐẠI DIỆN ĐƠN VỊ ĐƯỢC GIAO
(Ký, ghi rõ họ và tên, chức vụ và đóng dấu) QUẢN LÝ, SỬ DỤNG
(Ký, ghi rõ họ tên, chức vụ và đóng dấu)

83
 ĐẠI DIỆN ĐƠN VỊ THI CÔNG
(Ký, ghi rõ họ tên, chức vụ và đóng dấu)

Phụ lục VI
Mẫu Biên bản tổng nghiệm thu bàn giao toàn bộ các sản phẩm của dự án
(Ban hành kèm theo Thông tư số 28 /2010/TT-BTTTT ngày 13/12/2010
của Bộ trưởng Bộ Thông tin và Truyền thông)

<Tên Chủ đầu tư> CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
….................... Độc lập – Tự do – Hạnh phúc
Số: ………………
……………, ngày…..tháng…..năm 20…..

BIÊN BẢN
TỔNG NGHIỆM THU BÀN GIAO TOÀN BỘ CÁC SẢN PHẨM CỦA DỰ ÁN

I. Tên Dự án:…………….………………..……………

II. Địa điểm thi công: ..….………………..………………….......................................

III. Thành phần tham gia nghiệm thu:

1. Đại diện chủ đầu tư:

- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ:…………………
2. Đại diện đơn vị được giao quản lý, sử dụng:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ: …………………
3. Đại diện tư vấn giám sát thi công:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ: Cán bộ giám sát thi công
4. Đại diện đơn vị thiết kế:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ: Cán bộ thiết kế
5. Đại diện đơn vị thi công:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ: Cán bộ thi công

84
IV. Thời gian tiến hành nghiệm thu:

Bắt đầu: ......giờ...... ngày.......... tháng......... năm..........

Kết thúc: .......giờ...... ngày.......... tháng......... năm..........
Tại: …………………

V. Đánh giá thi công dự án:

a) Tài liệu làm căn cứ để nghiệm thu:
b) Chất lượng thi công dự án (đối chiếu với hồ sơ thiết kế thi công được duyệt, các chỉ
tiêu kỹ thuật, chỉ dẫn kỹ thuật):
c) Về khối lượng thi công:
d) Về tiến độ thi công:
đ) Các ý kiến khác (nếu có):
VI. Kết luận:
- Chấp nhận nghiệm thu hoàn thành hạng mục thi công hoặc dự án thi công để đưa
vào sử dụng.
- Yêu cầu sửa chữa, hoàn thiện bổ sung và các ý kiến khác (nếu có).
Các bên trực tiếp nghiệm thu chịu trách nhiệm trước pháp luật về Quyết định
nghiệm thu này.

ĐẠI DIỆN TƯ VẤN GIÁM SÁT ĐẠI DIỆN CHỦ ĐẦU TƯ

(Ký, ghi rõ họ tên, chức vụ (Ký, ghi rõ họ tên, chức vụ
và đóng dấu) và đóng dấu)

ĐẠI DIỆN ĐƠN VỊ TƯ VẤN THIẾT KẾ ĐẠI DIỆN ĐƠN VỊ ĐƯỢC GIAO
(Ký, ghi rõ họ và tên, chức vụ và đóng dấu) QUẢN LÝ, SỬ DỤNG
(Ký, ghi rõ họ tên, chức vụ và đóng dấu)

85
 ĐẠI DIỆN ĐƠN VỊ THI CÔNG
(Ký, ghi rõ họ tên, chức vụ và đóng dấu)

Phụ lục VII

Mẫu Biên bản hiện trường
(Ban hành kèm theo Thông tư số 28 /2010/TT-BTTTT ngày 13/12/2010
của Bộ trưởng Bộ Thông tin và Truyền thông)

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập - Tự do - Hạnh phúc

……….., ngày……tháng…….năm 20….

BIÊN BẢN HIỆN TRƯỜNG

DỰ ÁN:..............................
Hạng mục:………………………………………… …………….
Địa điểm:………………………… .……………………………………………….........
Đơn vị thi công: ……………………………………………………………...
I. Thành phần:
1. Đại diện chủ đầu tư:
- Ông (Bà):…………………….. Chức vụ:…………………
- Ông (Bà):…………………….. Chức vụ:…………………
2. Đại diện tư vấn giám sát thi công:
- Ông (Bà):…………………….. Chức vụ: Cán bộ giám sát thi công
3. Đại diện đơn vị thiết kế:
- Ông (Bà):…………………….. Chức vụ: Cán bộ thiết kế
4. Đại diện đơn vị thi công:
- Ông (Bà):…………………….. Chức vụ: Cán bộ thi công
II. Nội dung:
- Những yếu tố bất hợp lý:
86
 - Xuất hiện những yếu tố mới:
- Những yếu tố bất khả kháng (nếu có):
III. Kết luận:
- Chấp nhận những yếu tố thay đổi so với thiết kế thi công được duyệt.
- Chấp nhận các yếu tố bất khả kháng (nếu có).
- Các yếu tố khác (nếu có).
Các bên trực tiếp lập biên bản chịu trách nhiệm trước pháp luật về nội dung biên bản
này

DIỆN TƯ VẤN GIÁM SÁT ĐẠI DIỆN CHỦ ĐẦU TƯ

(Ký, ghi rõ họ tên) (Ký, ghi rõ họ tên)

ĐẠI DIỆN ĐƠN VỊ TƯ VẤN THIẾT KẾ ĐẠI DIỆN ĐƠN VỊ THI CÔNG
(Ký, ghi rõ họ tên) (Ký, ghi rõ họ tên)

PHỤ LỤC 8
MẪU BÁO CÁO NHANH SỰ CỐ HỆ THỐNGCNTT
(Ban hành kèm theo Thông tư số 02/2011/TT-BTTTT ngày 04/01/2011 của Bộ trưởng Bộ
Thông tin và Truyền thông)
CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
Độc lập – Tự do – Hạnh phúc
--------------
….., ngày ….. tháng ….. năm 20……
BÁO CÁO NHANH SỰ CỐ 
HỆ THỐNG CÔNG NGHỆ THÔNG TIN
Kính gửi: …...................................……………………
1. Tên cá nhân/đơn vị............................................................................
2. Tên dự án............................................................................................
3. Thuộc dự án (nhóm A, B, C):............................................................
4. Địa điểm triển khai:....................................................................
5. Tổ chức tư vấn thiết kế:...........................................................
6. Tổ chức tư vấn giám sát thi công:........................................................
7. Nhà thầu:...............................................................................................

87
 8. Mô tả sơ bộ về sự cố, tình trạng khi xảy ra sự cố, thời điểm xảy ra sự
cố.......................................
9. Sơ bộ về tình hình thiệt hại:............................................................
10. Sơ bộ về nguyên nhân sự cố (nếu có):...................................
11. Biện pháp giải quyết (dự kiến):.............................
 
CÁ NHÂN/ĐƠN VỊ BÁO CÁO
Nơi nhận: (ký, ghi rõ họ tên, chức vụ và đóng
- Như trên; dấu)
- Lưu:
PHỤ LỤC 9
MẪU BIÊN BẢN XÁC NHẬN VIỆC GIẢI QUYẾT SỰ CỐ
(Ban hành kèm theo Thông tư số 02/2011/TT-BTTTT ngày 04/01/2011 của Bộ trưởng Bộ
Thông tin và Truyền thông)
CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
Độc lập – Tự do – Hạnh phúc
--------------
….., ngày ….. tháng ….. năm 20……
BIÊN BẢN XÁC NHẬN VIỆC GIẢI QUYẾT SỰ CỐ
Dự án………………………………….
Địa điểm:.........................................
I. THÀNH PHẦN:
1. Đại diện chủ đầu tư:
- Ông (Bà):                                                    Chức vụ:
2. Tư vấn giám sát (nếu có):
- Ông (Bà):                                                    Chức vụ: Cán bộ giám sát.
3. Tư vấn Thiết kế (nếu có):
- Ông (Bà):                                                    Chức vụ: Cán bộ Thiết kế.
4. Đơn vị thi công:
- Ông (Bà):                                                    Chức vụ: Phụ trách thi công
5. Đơn vị lập hồ sơ sự cố (nếu có):
- Ông (Bà):                                                    Chức vụ: Cán bộ lập hồ sơ
II. NỘI DUNG:
.......................................................................................................................................
.......................................................................................................................................
.......................................................................................................................................
III. KẾT LUẬN:
.......................................................................................................................................
.......................................................................................................................................

88
  
ĐẠI DIỆN CHỦ ĐẦU TƯ TƯ VẤN GIÁM SÁT
(Ký, ghi rõ họ tên) (Ký, ghi rõ họ tên)

TƯ VẤN THIẾT KẾ ĐƠN VỊ LẬP HỒ SƠ SỰ

(Ký, ghi rõ họ tên) CỐ 
(Ký, ghi rõ họ tên)
ĐƠN VỊ THI CÔNG
(Ký, ghi rõ họ tên)

PHỤ LỤC 10
MẪU BIÊN BẢN NGHIỆM THU KHẮC PHỤC SỰ CỐ
(Ban hành kèm theo Thông tư số 02/2011/TT-BTTTT ngày 04/01/2011 của Bộ trưởng Bộ
Thông tin và Truyền thông)
CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
Độc lập – Tự do – Hạnh phúc
--------------
….., ngày ….. tháng ….. năm 20……
BIÊN BẢN NGHIỆM THU KHẮC PHỤC SỰ CỐ
1. Hệ thống công nghệ thông tin được nghiệm thu:
(Nêu rõ hệ thống và địa điểm)
2. Thành phần trực tiếp nghiệm thu:
1. Đại diện chủ đầu tư/đơn vị thụ hưởng đầu tư:
- Ông (Bà):                                                    Chức vụ:
- Ông (Bà):                                                    Chức vụ: Cán bộ giám sát
2. Đơn vị tư vấn giám sát (nếu có):
- Ông (Bà):                                                    Chức vụ:
- Ông (Bà):                                                    Chức vụ: Cán bộ giám sát.
3. Đơn vị tư vấn thiết kế (nếu có):
- Ông (Bà):                                                    Chức vụ:
- Ông (Bà):                                                    Chức vụ: Chủ trì thiết kế.
4. Đơn vị lập hồ sơ sự cố (nếu có)
- Ông (Bà):                                                    Chức vụ:
- Ông (Bà):                                                    Chức vụ: Chủ trì lập hồ sơ
5. Đơn vị thi công:
- Ông (Bà):                                                    Chức vụ:
- Ông (Bà):                                                    Chức vụ: Phụ trách thi công
3. Thời gian nghiệm thu:

89
 Bắt đầu:………………… ngày ….. tháng ….. năm ………
Kết thúc:……………….. ngày ….. tháng ….. năm ………
Tại:............................................
4. Đánh giá công tác giải quyết sự cố đã thực hiện:
a) Tài liệu làm căn cứ nghiệm thu;
b) Các nội dung chính đã được giải quyết;
c) Về chất lượng hệ thống công nghệ thông tin sau khi giải quyết sự cố (đối chiếu
với thiết kế, tiêu chuẩn thi công, lắp đặt và các yêu cầu kỹ thuật);
d) Các ý kiến khác nếu có.
5. Kết luận:
Chấp nhận hay không chấp nhận nghiệm thu.
Các bên trực tiếp nghiệm thu chịu trách nhiệm trước pháp luật về quyết định nghiệm
thu này. 
CHỦ ĐẦU TƯ NHÀ THẦU GIÁM SÁT THI CÔNG
(Ký, ghi rõ họ tên, chức vụ và đóng (Ký, ghi rõ họ tên, chức vụ và đóng
dấu) dấu)

NHÀ THẦU TƯ VẤN THIẾT KẾ  ĐƠN VỊ LẬP HỒ SƠ SỰ CỐ 

(Ký, ghi rõ họ tên, chức vụ và đóng (Ký, ghi rõ họ tên, chức vụ và đóng
dấu) dấu)

NHÀ THẦU THI CÔNG

(Ký, ghi rõ họ tên, chức vụ và đóng dấu)
 
Hồ sơ nghiệm thu giải quyết sự cố gồm:
- Biên bản nghiệm thu giải quyết sự cố và các phụ lục kèm theo biên bản này (nếu
có);
- Các tài liệu làm căn cứ để nghiệm thu.

90