Giáo trình mô đun Quản lý dự án công nghệ thông tin - Nghề: Ứng dụng phần mềm
Giới thiệu:
Nội dung bài này trình bày những vấn đề cơ bản về dự án, phân loại dự án theo cáo
tiêu chí thông dụng, ý nghĩa thực tiễn của việc quản lý dự án và quy trình cơ bản về quản
lý dự án.
Mục tiêu:
Giới thiệu quản lý dự án.
Nội dung chính:
1.1. Tại sao phải quản lý dự án
Quản lý dự án là một trong những lĩnh vực kiến thức mang tính kinh nghiệm, có ý
nghĩa quan trọng trong các nhiệm vụ hàng ngày của bất kỳ một nhà quản lý hay một cá
nhân có tham vọng trở thành nhà quản lý.
Theo quan điểm chung dự án là một lĩnh vực hoạt động đặc thù, một nhiệm vụ cần
phải thực hiện theo một phương pháp riêng, trong khuôn khổ nguồn lực riêng, kế hoạch
tiến độ cụ thể nhằm tạo ra một sản phẩm mới. Từ đó cho thấy, dự án có tính cụ thể, mục
tiêu rõ ràng xác định để tạo ra một sản phẩm mới.
Tóm lại có thể nói ta phải quản lý dự án vì cần phải quản lý một chuỗi các công việc
(nhiệm vụ, hoạt động), được thực hiện nhằm đạt được mục tiêu đề ra trong điều kiện ràng
buộc về phạm vi, thời gian và ngân sách.
Hiểu theo cách khác, quản lý dự án là ứng dụng kiến thức, kỹ năng, công cụ và kỹ
thuật vào các hoạt động dự án để thỏa mãn các yêu cầu của dự án.
Xét theo khía cạnh khác, quản lý dự án là một quá trình lập kế hoạch, điều phối thời
gian, nguồn lực và giám sát quá trình phát triển của dự án nhằm đảm bảo cho dự án hoàn
thành đúng thời hạn, trong phạm vi ngân sách được duyệt và đạt được các yêu cầu đã định
về kỹ thuật, chất lượng của sản phẩm, dịch vụ, bằng các phương pháp và điều kiện tốt nhất
cho phép.
1.2. Phương pháp luận quản lý dự án truyền thống và quản lý dự án thực hành
TPM (Total Productive Maintenance - Phương pháp quản lý dự án truyền thống)
Phương pháp quản lý dự án truyền thống (TPM) trong cuốn Hướng dẫn về những
kiến thức cốt lõi trong Quản lý dự án (PMBOK) do Viện Quản lý Dự án (PMI) công bố.
Trong khi PMI không đưa ra một tên gọi cụ thể nào cho phương pháp quản lý dự án truyền
thống, thì hầu hết các công ty vẫn thường gọi đó là waterfall (thác nước) – mỗi giai đoạn
của dự án sẽ được chuyển đến giai đoạn tiếp theo (sau khi đã kết thúc hoàn toàn thành công
công việc) giống như dòng chảy của thác nước và chỉ chảy theo một hướng, không thể
quay lui về giai đoạn trước hay nhảy vượt giai đoạn (rõ ràng thì trong một thác nước nước
không thể chảy ngược).
Phương pháp truyền thống chọn cách tiếp cận một kế hoạch theo định hướng và tập
trung vào hoạt động để quản lý dự án. Điều này dẫn đến một loạt các quá trình có đầu vào
và đầu ra khác nhau. Người quản lý phải đảm bảo rằng việc bàn giao dự án trung gian đều
phải được lập kế hoạch và thực hiện ở các giai đoạn khác nhau của dự án.
Đó là một trong nhiều lý do khiến nhiều công ty ào ạt chuyển sang áp dụng phương
pháp Agile – bởi với Agile, họ không thể chống lại được sự quyến rũ của kết quả công việc
nhanh hơn, chi phí thấp hơn, và sẽ không có biểu đồ Gantt nữa!
Trong suốt vòng đời của một dự án, Agile nhấn mạnh việc tạo ra những kết quả hữu
hình càng sớm, càng thường xuyên thì càng hiệu quả và chú trọng việc quản lý mối quan
hệ, tạo điều kiện tương tác giữa các thành viên trong nhóm quản lý dự án. Điều này có
nghĩa là vai trò của một người quản lý dự án Agile hoàn toàn không giống với một người
quản lý dự án TPM.
Trang 1
Trang 2
Trang 3
Trang 4
Trang 5
Trang 6
Trang 7
Trang 8
Trang 9
Trang 10
Tải về để xem bản đầy đủ
Tóm tắt nội dung tài liệu: Giáo trình mô đun Quản lý dự án công nghệ thông tin - Nghề: Ứng dụng phần mềm
ươ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. Chương 3: Thực hiện và kết thúc dự án KHOA CÔNG NGHỆ THÔNG TIN 72 Mời tham dự phần đầu tất cả những ai liên quan đến dự án; Khách hàng, người cung cấp thiết bị, thành viên Ban chỉ đạo, các cấp quản lý, đội ngũ kỹ thuật viên .. Mục đích đề giới thiệu các bên với nhau, đặt quan hệ giao tiếp, nêu rõ nguồn gốc và mục tiêu dự án. Phiên họp này cũng nhằm tạo ra bầu không khí phấn khởi và hăng hái bước vào dự án. Phần thứ hai chỉ dành cho các cán bộ kỹ thuật, nhằm đề ra các hướng chỉ đạo, quy định các thủ tục, .. Phải nắm được chính xác trình độ của mỗi người và lên kế hoạch đào tạo nếu cần. - Họp lập kế hoạch (ước lượng) dự án. Sẽ rất tốt nếu để một nhóm nhỏ, ba hoặc bốn người, tiến hành các ước lượng cần thiết. Nhóm này có thể đảm nhiệm 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ờ. - 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 Chương 3: Thực hiện và kết thúc dự án KHOA CÔNG NGHỆ THÔNG TIN 73 họp phải khẳng định thiết kế đã chọn là tốt nhất, và xem còn vấn đề gì nữa không. Có thể thảo luận liền mấy module, nhưng mỗi module không quá từ 1 đến 2 giờ, và mỗi buổi không quá 4 giờ. Tác giả module trình bày, ghi lại các ý kiến đề xuất, để suy nghĩ, tìm cách giải quyết và sẽ báo lại với Ban chỉ đạo sau. - Thảo luận mã tài liệu cho người dùng. Tất cả những điều trình bày ở phần thảo luận module cũng sẽ đúng ở đây. Tuy nhiên cuộc thảo luận này chi tiết và có thể có nhiều người tham dự. - Họp kết thúc chấp nhận thử nghiệm (sự kiện mốc). Đúng ra đây không thật sự là sự kiện mốc như một số sự kiện mốc khác. Vì vậy không nên phô trương ầm ĩ, Chỉ coi như một cuộc gặp mặt giữa khách hàng và Trưởng ban chỉ đạo dự án. - Họp kết thúc giai đoạn vận hành (sự kiện mốc) Đây thực ra không phải là một cuộc họp, mà là một bữa tiệc và tất cả mọi người đều được mời, một dịp để xả hơi và chuyển sang giai đoạn hậu dự án. - Họp rút kinh nghiệm sau dự án. Đây là một việc hay bị quên, mặc dù rất quan trọng. Cần phải có hai phiên họp - phiên họp với khách hàng và họp nội bộ. Họp với khách hàng có thể mời cả tổ dự án và các cấp quản lý cao hơn. Không để phiên họp này trở thành qua quýt. Mục đích là phân tích các trục trặc xảy ra với người sử dụng và bàn cách khắc phục những sự kiện đó trong tương lai. Trong trường hợp khách hàng không thoả mãn, đây có thể là dịp để chứng tỏ với anh ta rằng vấn đề không nằm trong tầm kiểm soát của chúng ta. Trong trường hợp khách hàng thoả mãn, có thể đề nghị anh ta giới thiệu với các khách hàng khác. Phiên họp thứ hai là giữa tổ dự án với các cấp quản lý có liên quan. Phải làm sao đây thật sự là phiên họp phê bình xây dựng. Phân tích những thiếu sót sai lầm, làm thế nào để tránh được những thiếu sót sai lầm đó trong tương lai, ghi lại các đề xuất tương ứng. - Báo cáo sau dự án. Kết quả cuộc họp rút kinh nghiêm sau dự án được ban chỉ đạo trình bày trong môt báo cáo chính thức. Báo cáo này sẽ là một tài liệu tổng kết sẽ được lưu hành cho nhiều dự án khác cũng như có thể sẽ được nhiều người ngoài dự án xem. Báo cáo sau dự án cần bao gồm những phần sau đây: Dự án đã được hình thành như thế nào, mục tiêu ban đầu, các giải pháp đề xuất Phương pháp và tổ chức dự án, các kiến nghị cải tiến nếu có So sánh kế hoạch đề ra với kết quả đạt được trên thực tế. Nếu có sự khác nhau đáng kể – giải thích vì sao. Cập nhật các công thức và tỷ số dùng để ước lượng. Các điểm thành công của dự án. Chương 3: Thực hiện và kết thúc dự án KHOA CÔNG NGHỆ THÔNG TIN 74 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. 3.2. Kết thúc dự án 3.2.1. Đánh giá tài chính Khi chúng ta dự định đầu tư thực hiện dự án xây dựng một hệ thống thông tin, ta cần cân nhắc xem có nên thực hiện dự án đó hay không, và trong trường hợp nên thực hiện thì trong số nhiều phương án triển khai dự án nên chọn phương án nào. Để trả lời các câu hỏi này, mối quan tâm của các nhà đầu tư là đo hiệu quả do việc thực hiện dự án mang lại và các quyết định sẽ dựa trên việc so sánh các hiệu quả này. Như vậy điều quan trọng là phải so sánh mối quan hệ giữa chi phí dự án và lợi ích do dự án mang lại. Song cần chú ý là trong khi chi phí dự án được tính bằng tiền thì hầu như các hiệu quả do dự án CNTT mang lại đều khó có thể đo được bằng tiền. Để khắc phục khó khăn này, khi so sánh các phương án thực hiện dự án chúng ta có thể sự dụng phương pháp hai bước: - Đầu tiên dùng đánh giá tài chính so sánh chi phí các dự án - Trong số các phương án được đánh giá tốt ở bước 1, so sánh tiếp một số chỉ tiêu chất lượng không được thể hiện bằng tiền để chọn phương án thích hợp nhất. 3.2.1.1. Xác định chi phí Chi phí xây dựng hệ thống thông tin thường bao gồm các loại chi phí sau đây: - Chi phí xây dựng hệ thống: Chi phí xây dựng hệ thống được tập chung chi trong một vài năm đầu. Đây là chi phí trong thời gian phát triển hệ thống mới bao gồm các chi phí: Mua trang thiết bị phần cứng Mua phần mềm Chương 3: Thực hiện và kết thúc dự án KHOA CÔNG NGHỆ THÔNG TIN 75 Công phân tích, thiết kế, lập trình, kiểm tra, cài đặt Chuẩn bị chỗ đặt máy Huấn luyện Chuyển từ hệ thống cũ sang hệ thống mới - Chi phí tác nghiệp: Sau khi hệ thống được xây dựng và đi vào hoạt động, chi phí tác nghiệp là các chi phí phục vụ cho hoạt động hàng ngày của hệ thống bao gồm: Thuê phần cứng và phần mềm Hợp đồng bảo dưỡng phần cứng và phần mềm Chi phí cho nhân lực hàng ngày: vào dữ liệu, quản lý mạng, .. Thuê chỗ đặt máy tính - Các chi phí gián tiếp khác Các chi phí tác nghiệp và chi phí gián tiếp xuất hiện khi hệ thống bắt đầu đi vào hoạt động. Trong trường hợp dự án đem lại các lợi ích đo được bằng tiền, thì lợi ích đó được tính là chi phí với dấu âm và tính gộp trong tổng chi phí. Như vậy đối với mỗi phương án ta có bảng chi phí tính theo từng năm. 3.2.1.2. So sách các phương án Để đánh giá tài chính các dự án, ta tìm cách so sánh chi phí dự án. ở đây ta giả định có một hệ thống cũ đang hoạt động, và hệ thống đã suy thoái nên chi phí cho hoạt động của hệ thống này hàng năm tăng dần. Hệ thống mới được đem so sánh với hệ thống cũ bao gồm các chi phí xây dựng, chi phí tác nghiệp và chi phí gián tiếp. 3.2.1.3. Điểm hòa vốn Phân tích điểm hoà vốn là dạng đơn giản nhất của so sánh chi phí. Điểm hoà vốn là điểm tại đó hai đường chi phí của hệ thống mới và hệ thống cũ cắt nhau. Điều đó có nghĩa là bắt đầu từ thời điểm đó trở đi, chi phí cho hệ thống mới ít hơn chi phí cho hệ thống cũ, và nếu ta sử dụng hệ thống mới ta bắt đầu tiết kiệm được kinh phí. Chương 3: Thực hiện và kết thúc dự án KHOA CÔNG NGHỆ THÔNG TIN 76 Hình 3.2. Đánh giá tài chính 3.2.2. Đánh giá hiệu quả dự án 3.2.2.1. Thu hồi vốn đơn giản Để so sánh hai hệ thống cũ và mới theo phương pháp thời hạn thu hồi vốn đơn giản, ta lập bảng so sánh chi phí như sau: Chênh lệch chi phí gộp lại từng năm được tính bằng cách tính tổng chênh lệch chi phí từ năm thứ nhất tới năm đó. Trong bảng này chúng ta có một số giả thiết sau: - Thời gian cần thiết để xây dựng hệ thống mới la 1,5 năm. Trong thời gian đó hệ thống cũ vẫn phải hoạt động , do đó trong chi phí xây dựng hệ thống mới, trong 1,5 Chi phí N ă m Chi phí xây d ự ng Đ i ể m hoà v ố n Chi phí tác nghi ệ p Chương 3: Thực hiện và kết thúc dự án KHOA CÔNG NGHỆ THÔNG TIN 77 năm đầu tiên vẫn phải cộng chi phí vận hành hệ thống cũ và chi phí đó ở năm thứ hai chỉ tính nửa năm - Bắt đầu từ giữa năm thứ hai, hệ thống mới được đưa vào khai thác, hệ thống cũ không làm việc nữa và ta bắt đầu phải chi phí cho vận hành hệ thống mới. Khi đó thời hạn thu hồi vốn giản đơn được tính theo công thức: Nếu gọi là chỉ số năm mà e0 thì e Thời hạn thu hồi vốn giản đơn = i + ---------- e+e 3.2.2.2. Thu hồi vốn có chiết khấu Về cơ bản, phương pháp tính thời hạn thu hồi vốn có chiết khấu giống như phương pháp tính thời hạn thu hồi vốn đơn giản, điều khác là tại mỗi năm có tính triết khấu theo mức lãi suất của thị trường vốn. Cách tính mới này phức tạp hơn, song chính xác hơn vì có chú ý đến giá trị của tiền tệ theo thời gian. 3.2.2.3. Đánh giá các chỉ tiêu chất lượng Sau khi dùng đánh giá tài chính để so sánh chi phí của các phương án thực hiện dự án, ta chọn được hai, ba phương án tốt. Tiếp theo ta có thể sử dụng một vài chỉ tiêu chất lượng để tiếp tục so sánh chọn ra phương án tốt nhất. Các chỉ tiêu chất lượng đó có thể là: - Tăng độ chính xác của thông tin (giảm sai sót) - Giảm thời gian sửa sai - Cung cấp thông tin tốt hơn, nhanh hơn - Tăng mức độ an toàn hệ thống - Tăng khả năng cập nhật thông tin - Tăng hiệu quả sử dụng của người dùng Thời hạn thu hồi vốn giản đơn = ------------------------------------------------------- Năm cuối cùng chênh lệch chi phí gộp âm + Chênh lệch chi phí gộp tại năm âm cuối cùng Trị tuyệt đối của chênh lệch gộp tại năm âm cuối cùng cộng với tại năm dương đầu tiên Chương 3: Thực hiện và kết thúc dự án KHOA CÔNG NGHỆ THÔNG TIN 78 Bài tập Các nhóm trên cơ sở đề tài của nhóm đã thực hiện ở chương 2, hãy: - Lâp kế hoạch giám sát và kiểm soát dự án - Thực hiện đánh giá chi phí dự án - Xác định điểm hòa vốn cho dự án - Đánh giá chất lượng của dự án. KHOA CÔNG NGHỆ THÔNG TIN 79 MỤC LỤC HÌNH ẢNH TRANG Hình 1.1: Minh họa quyền lãnh đạo dự án ..................................................................... 8 Hình 1.2: Những người có trách nhiệm với dự án ........................................................ 13 Hình 2.1. Bảng kê công việc theo sản phẩm ................................................................ 19 Hình 2.2. Danh sách công việc ..................................................................................... 19 Hình 2.3. Bảng kê công việc chi tiết ............................................................................ 20 Hình 2.4. Cấu trúc phân sản phẩm ............................................................................... 23 Hình 2.5. Cấu trúc phân nhiệm vụ ................................................................................ 24 Hình 2.6. Ví dụ về WBS đầy đủ ................................................................................... 25 Hình 2.7. WBS theo sản phẩm ..................................................................................... 27 Hình 2.8. WBS theo trách nhiệm chia thành nhiều pha ............................................... 28 Hình 2.9. WBS ra theo miền trách nhiệm .................................................................... 29 Hình 2.10. Quy trình quản lý chất lượng ...................................................................... 41 Hình 2.11. Biến động về chất lượng ............................................................................. 43 Hình 2.12. Chức năng cơ bản của giám đốc dự án ....................................................... 49 Hình 3.1. Giám sát và duy trì dự án .............................................................................. 63 Hình 3.2. Đánh giá tài chính ......................................................................................... 76 KHOA CÔNG NGHỆ THÔNG TIN 80 MỤC LỤC BẢNG TRANG Bảng 2.1. Các chỉ số chi phí và công thức ................................................................... 39 Bảng 2.2. Đặc điểm các dạng tổ chức nhân sự ............................................................. 48 Bảng 2.3. Đặc điểm các đối tượng liên quan dự án ...................................................... 50 KHOA CÔNG NGHỆ THÔNG TIN 81 TÀI LIỆU THAM KHẢO 1. Pankaj Jalote (Dịch: Nguyễn Công Danh - Trần Cao Đệ), Software Project Management in Practice (Quản lý dự án phần mềm trong thực tiễn), Addison- Wesley (Dịch: ĐH Cần Thơ), 2002 (Dịch: 2013) 2. Kathy Schwalbe, Information Technology Project Management – Revided 6e, Cengage Learning, 2011 3. Giáo trình Quản lý Dự án, Ngô Trung Việt, ĐH. Quốc gia Tp.HCM, 2008 4. Hidenori Shibamoto (Châm Blue dịch), Quản lý dự án hiệu quả theo phong cách người Nhật, Công Thương, 2019
File đính kèm:
- giao_trinh_mo_dun_quan_ly_du_an_cong_nghe_thong_tin.pdf