Category: quản lý dự án

project management

Đề xuất hệ thống (system proposal)

Đề xuất hệ thống là một tài liệu kết hợp các tư liệu được tạo ra từ quá trình hoạch định và phân tích hệ thống.

Một đề xuất hệ thống thường bao gồm tóm tắt mục tiêu của hệ thống (executive summary), các yêu cầu của hệ thống, kế hoạch triển khai, phân tích khả thi, định nghĩa các yêu cầu và các mô hình (sơ đồ) phân tích diễn tả hệ thống mới. Các mô hình phân tích bao gồm phân tích chức năng, phân tích cấu trúc và phân tích hành vi. Tùy thuộc vào từng tổ chức và khách hàng mà có thể có thêm những đặc tả chi tiết hơn kèm theo. Ví dụ Bộ Thông tin và Truyền thông của Việt Nam, Bộ Quốc phòng Mỹ, NASA, IEEE/ANSI đều có những mẫu rất chi tiết cần phải tuân thủ.

Phần tóm tắt mục tiêu của hệ thống cung cấp tất cả thông tin quan trọng theo một mẫu cô đọng. Nó có thể coi là tóm tắt của cả đề xuất hệ thống. Mục tiêu của tóm tắt này là để giúp cho những lãnh đạo cấp cao bận rộn có thể nhanh chóng đọc qua và xác định xem phần nào của đề xuất hệ thống họ cần lưu ý đọc kỹ hơn. Phần tóm tắt này thường không dài quá một trang giấy. Nó thường bao gồm một phần mô tả vấn đề mà hệ thống cần giải quyết, các thông tin nền tảng cần thiết để hiểu vấn đề đó và để hiểu giải pháp được đề xuất, một mô tả của các lựa chọn giải pháp khác đã được cân nhắc và loại bỏ, và các điểm chính của giải pháp được đề xuất.

Dưới đây là một mẫu tham khảo cho đề xuất hệ thống:

1. Mục lục

2. Tóm tắt mục tiêu

Bản tóm tắt các thông tin quan trọng nhất của bản đề xuất này để những lãnh đạo quản lý bận rộn có thể đọc nhanh chóng nắm được nội dung chính, đồng thời quyết định xem phần nào của bản đề xuất họ sẽ cần đọc kỹ hơn.

3. Yêu cầu nghiệp vụ

Kết quả của quá trình hoạch định hệ thống, bao gồm các ý tưởng chung cho hệ thống mới (nhu cầu về nghiệp vụ, hệ thống mới hỗ trợ các nhu cầu nghiệp vụ để tạo ra giá trị cho doanh nghiệp như thế nào), xác định phạm vi dự án, và kế hoạch triển khai ban đầu.

4. Kế hoạch triển khai

Bản kế hoạch triển khai: từ kế hoạch triển khai ban đầu được rà soát cập nhật sau khi hoàn thành quá trình phân tích.

5. Phân tích khả thi

Bản phân tích khả thi được rà soát bằng cách sử dụng các thông tin có được từ quá trình phân tích.

6. Định nghĩa yêu cầu

Danh sách những yêu cầu nghiệp vụ chức năng và phi chức năng cho hệ thống.

7. Phân tích chức năng

Các biểu đồ trường hợp sử dụng, các biểu đồ hoạt động, và các mô tả trường hợp sử dụng dùng để thể hiện những quy trình cơ bản hoặc chức năng bên ngoài mà hệ thống cần hỗ trợ.

8. Phân tích cấu trúc

Các biểu đồ lớp và các biểu đồ đối tượng để mô tả các khía cạnh cấu trúc của hệ thống cần xây dựng. Phần này cũng có thể bao gồm cả phân tích cấu trúc của hệ thống hiện tại cần được thay thế.

9. Phân tích hành vi

Các biểu đồ hoạt động, biểu đồ trình tự, biểu đồ hành vi-trạng thái, và ma trận CRUDE để mô tả hành vi nội bộ của hệ thống cần xây dựng. Phần này cũng có thể bao gồm cả phân tích hành vi của hệ thống hiện tại cần được thay thế.

10. Các phụ lục

Bao gồm các thông tin bổ sung liên quan đến bản đề xuất hệ thống, thường được sử dụng để củng cố thêm giải pháp đề xuất. Các phụ lục này có thể là kết quả của thăm dò hay phỏng vấn, các báo cáo và thống kê ngành…

Nguồn tham khảo: Alan Dennis, Barbara Wixom, David Tegarden (2020), Systems Analysis and Design: An Object-Oriented Approach with UML, 6th Edition, Wiley.

Nghiên cứu/ phân tích khả thi

Nghiên cứu khả thi là một cuộc điều tra sơ bộ giúp quản lý quyết định có nên tiếp tục phát triển hệ thống hay không.

Sau khi nhu cầu cho hệ thống và các yêu cầu nghiệp vụ đã được xác định, đây là lúc để tạo ra một đề xuất chi tiết hơn nhằm hiểu rõ hơn về các cơ hội và hạn chế liên quan đến dự án được đề xuất. Phân tích khả thi hướng dẫn tổ chức trong việc xác định liệu có nên tiếp tục với dự án hay không. Phân tích khả thi cũng xác định những rủi ro quan trọng liên quan đến dự án cần được giải quyết nếu dự án được phê duyệt. Cũng giống như yêu cầu hệ thống, mỗi tổ chức có quy trình và định dạng riêng cho việc phân tích khả thi, nhưng hầu hết bao gồm ba loại chính: khả thi kỹ thuật, khả thi kinh tế, và khả thi về tổ chức. Kết quả của các phân tích này được kết hợp thành một nghiên cứu khả thi, và được trình lên một ủy ban/ hội đồng phê duyệt.

Mặc dù chúng ta thảo luận về phân tích khả thi trong bối cảnh bắt đầu một dự án, hầu hết các nhóm dự án sẽ chỉnh sửa nghiên cứu khả thi của họ trong suốt quá trình phát triển và xem xét lại nội dung của nó tại nhiều điểm kiểm tra khác nhau trong dự án. Nếu tại bất kỳ thời điểm nào, rủi ro và hạn chế của dự án vượt quá lợi ích của nó, nhóm dự án có thể quyết định hủy dự án hoặc thực hiện các cải tiến cần thiết.

Mục tiêu:

  • Khả năng cải tiến: Xác định tiềm năng cải tiến hệ thống hiện có hoặc phát triển một hệ thống mới.
  • Phạm vi vấn đề: Tập trung vào việc hiểu vấn đề thay vì giải quyết ngay lập tức.
  • Tài liệu quyết định: Sản phẩm đầu ra của nghiên cứu khả thi là một đề xuất hệ thống chính thức, mô tả đầy đủ bản chất và phạm vi của hệ thống đề xuất.

Các bước trong Phân tích khả thi:

  1. Thành lập đội dự án và bổ nhiệm trưởng dự án.
  2. Phát triển sơ đồ luồng hệ thống.
  3. Xác định các khiếm khuyết của hệ thống hiện tại và đặt mục tiêu.
  4. Liệt kê các giải pháp thay thế để đạt được mục tiêu.
  5. Xác định tính khả thi của từng giải pháp thay thế (ví dụ: tính khả thi về kỹ thuật, vận hành).
  6. Đánh giá hiệu suất và hiệu quả chi phí của từng giải pháp thay thế.
  7. Xếp hạng các giải pháp thay thế và chọn giải pháp tốt nhất.
  8. Chuẩn bị đề xuất hệ thống cho sự phê duyệt của quản lý.

Các loại khả thi:

  • Khả thi về kinh tế: Đánh giá hiệu quả chi phí của hệ thống ứng viên bằng cách sử dụng phương pháp phân tích chi phí/lợi ích. Mục tiêu là tối đa hóa giá trị ròng của tổ chức thông qua lợi tức đầu tư cao nhất với rủi ro thấp nhất.
  • Khả thi về kỹ thuật: Điều tra xem công nghệ hiện có có thể hỗ trợ giải pháp đề xuất hay không và liệu các nguồn lực hiện tại có cần nâng cấp hay không.
  • Khả thi về vận hành: Đánh giá liệu hệ thống có hoạt động hiệu quả trong môi trường tổ chức hiện tại và liệu người dùng có chấp nhận nó hay không.
  • Khả thi về hành vi: Xem xét thái độ của người dùng đối với hệ thống mới và xác định xem có cần nỗ lực đặc biệt nào cho việc đào tạo lại, giáo dục hoặc thay đổi công việc hay không.
  • Khả thi về thời gian: Đảm bảo rằng dự án có thể hoàn thành trong khung thời gian được yêu cầu và xác minh xem các thời hạn có hợp lý hay không.

Những nguyên nhân chính dẫn đến thất bại dự án là gì?

Nguồn: https://projectmanagementreport.com/blog/project-management-statistics

Nghiên cứu ngành và khảo sát các chuyên gia quản lý dự án tiết lộ các nguyên nhân hàng đầu dẫn đến thất bại dự án là:

1. Thiếu mục tiêu và phạm vi rõ ràng (64%)

2. Lập kế hoạch và dự báo không đầy đủ (57%)

3. Giao tiếp kém/kết nối không đồng bộ với các bên liên quan (56%)

4. Phân bổ tài nguyên không đủ (52%)

5. Quy trình quản lý thay đổi yếu kém (49%)

6. Thiếu sự hỗ trợ từ lãnh đạo (48%)

7. Quản lý rủi ro không hiệu quả (47%)

8. Lịch trình không thực tế (45%)

9. Phạm vi dự án mở rộng không kiểm soát (45%)

Những yếu tố hàng đầu này nhấn mạnh cách các vấn đề liên quan đến sự liên kết, lập kế hoạch, tài nguyên và khả năng thích ứng làm trật đường ray kết quả dự án. Mục tiêu mơ hồ, các nhóm làm việc riêng lẻ, rủi ro bị bỏ qua, thời hạn chặt chẽ, thay đổi không kiểm soát và các nhà tài trợ không gắn kết đều tạo nền tảng cho thất bại.

Xem xét kỹ hơn các nguyên nhân gốc rễ:

1. Mục tiêu không rõ ràng: Mục tiêu mơ hồ khiến không thể định nghĩa thành công có thể đo lường được hoặc điều chỉnh nhiệm vụ và kỳ vọng. Kết quả chịu ảnh hưởng nếu không có mục tiêu cụ thể để đánh giá tiến độ và sự hoàn thành.

2. Lập kế hoạch không đầy đủ: Lập kế hoạch không đủ về tài nguyên, ngân sách, lịch trình, rủi ro và yêu cầu làm cho các nhóm không chuẩn bị sẵn sàng để thực hiện một cách dự đoán. Khoảng trống không thể tránh khỏi khi công việc bắt đầu.

3. Giao tiếp kém: Giới hạn sự hợp tác liên chức năng và minh bạch góp phần vào sự không đồng bộ. Mọi người bị ngắt kết nối với kết quả và thay đổi, gây ra hiệu ứng dây chuyền.

4. Tài nguyên không đủ: Kế hoạch tài nguyên không thực tế làm căng thẳng các nhóm và cản trở năng suất. Công việc kéo dài hơn hoặc chất lượng giảm do khối lượng công việc không nhất quán.

5. Quản lý thay đổi yếu kém: Các thay đổi phạm vi không được quản lý chủ động. Thay vào đó, phạm vi mở rộng không kiểm soát làm lệch ngân sách, lịch trình, tài nguyên và chất lượng.

6. Thiếu hỗ trợ từ lãnh đạo: Các lãnh đạo không gắn kết không ủng hộ các dự án quan trọng hoặc cung cấp bảo vệ, làm cho các nhóm thiếu hỗ trợ.

7. Quản lý rủi ro không hiệu quả: Các nhóm phản ứng thay vì chủ động đối với các vấn đề mới nổi. Rủi ro không được xác định trở thành mối đe dọa lớn.

8. Lịch trình không thực tế: Lịch trình gấp gáp làm quá tải các nhóm và không để lại chỗ cho các tình huống dự phòng khi các vấn đề không thể tránh khỏi xuất hiện.

Tập hợp lại, những sai sót này ngăn cản các tổ chức tối đa hóa tỷ lệ thành công của dự án. Nhưng dữ liệu cũng cung cấp một lộ trình rõ ràng để cải thiện. Định nghĩa mục tiêu, lập kế hoạch kỹ lưỡng, giao tiếp chủ động, đảm bảo tài nguyên, kiểm soát thay đổi, nhận được sự ủng hộ của lãnh đạo, giảm thiểu rủi ro và lên lịch thực tế đều nằm trong tầm kiểm soát của quản lý.

Nhắm vào những khu vực này thông qua đào tạo, quy trình tinh chỉnh và quản trị sẽ mở khóa tỷ lệ thành công cao hơn theo thời gian. Kết quả dự án được xác định trực tiếp bởi các thực tiễn và văn hóa được xây dựng bởi ban lãnh đạo.