Ngân hàng đề — PMP Mock Exam Set
Tìm thấy 201 câu.
- A Negative
- B Pessimistic
- C Challenging
- D Confronting
Xem giải thích
Đáp án
A — Negative (bên liên quan tiêu cực).
Vì sao đúng
⚠ Dấu hiệu bên liên quan tiêu cực: | Dấu hiệu | Nội dung | |---|---| | ⚠ KHÔNG hài lòng về dự án | | | ⚠ CHẤT VẤN công việc và các quyết định của đội | | | ⚠ Chất vấn cả yêu cầu ĐÃ ĐƯỢC nhà tài trợ phê duyệt | ⚠ tức là chống lại quyết định chính thức | | ⚠ KHÔNG MUỐN dự án tiến triển | ⚠ câu quyết định | | ⚠ Lý do: dự án làm gián đoạn mảng kinh doanh của bà ấy | ⚠ lợi ích cá nhân/bộ phận xung đột với dự án | | ⚠ Kết luận | ⚠ đây là bên liên quan TIÊU CỰC — người muốn dự án thất bại hoặc không diễn ra |
Vì sao các phương án khác sai
- B (Pessimistic), C (Challenging), D (Confronting) — ⚠ cả ba đều KHÔNG phải phân loại bên liên quan của PMBOK; ⚠ chúng mô tả tính cách hoặc hành vi chứ không phải phân loại chuẩn.
Ghi nhớ
⚠ Phân loại bên liên quan theo mức tham gia (PMBOK): | Mức | Nghĩa | |---|---| | ⚠ Unaware — không biết | ⚠ chưa biết dự án tồn tại hoặc chưa biết tác động của nó | | ⚠ Resistant — phản đối | ⚠ biết dự án và CHỐNG lại thay đổi — Terry ở đây | | ⚠ Neutral — trung lập | ⚠ biết nhưng không ủng hộ cũng không phản đối | | ⚠ Supportive — ủng hộ | ⚠ biết và ủng hộ | | ⚠ Leading — dẫn dắt | ⚠ chủ động tham gia để dự án thành công | | ⚠ Công cụ | ⚠ stakeholder engagement assessment matrix — ghi mức HIỆN TẠI (C) và mức MONG MUỐN (D) |
Từ khoá nhận diện:
"không muốn dự án tiến triển" → ⚠ bên liên quan tiêu cực / resistant "chưa biết dự án tồn tại" → ⚠ unaware "chủ động đóng góp cho dự án thành công" → ⚠ leading "chất vấn quyết định đã được duyệt" → ⚠ dấu hiệu phản đối, không phải góp ý
| ⚠ Bạn nên làm gì với Terry | Bước |
|---|---|
| ⚠ 1. TÌM HIỂU lý do thật sự | ⚠ "gián đoạn mảng kinh doanh" là mối lo CHÍNH ĐÁNG, không phải cố tình gây khó |
| ⚠ 2. Gặp riêng, nghe trước khi thuyết phục | |
| ⚠ 3. Xem có thể GIẢM tác động lên bộ phận của Terry không | ⚠ điều chỉnh lịch triển khai, có kế hoạch chuyển đổi |
| ⚠ 4. Cập nhật sổ đăng ký bên liên quan và kế hoạch tham gia | |
| ⚠ 5. Nhờ nhà tài trợ can thiệp nếu vượt thẩm quyền | ⚠ bước SAU CÙNG, không phải bước đầu |
| ⚠ 6. Bảo vệ đội khỏi áp lực không chính đáng | ⚠ đội không nên phải một mình đối phó với Terry |
| ⚠ Đừng | ⚠ coi Terry là kẻ thù — mối lo của bà ấy có thể chỉ ra rủi ro thật của dự án |
| ⚠ Vì sao bên liên quan tiêu cực lại HỮU ÍCH | Lý do |
|---|---|
| ⚠ Họ chỉ ra những rủi ro người ủng hộ không muốn thấy | |
| ⚠ Mối lo về gián đoạn kinh doanh thường là RỦI RO THẬT | |
| ⚠ Thuyết phục được họ thì dự án vững hơn nhiều | |
| ⚠ Nguy hiểm thật sự | ⚠ bên liên quan tiêu cực mà bạn KHÔNG BIẾT là ai |
| ⚠ Bối cảnh ma trận mạnh có ý nghĩa gì | Ý nghĩa |
|---|---|
| ⚠ PM có quyền trung bình tới cao | |
| ⚠ Đội chủ yếu báo cáo cho PM | |
| ⚠ Terry là quản lý CHỨC NĂNG, không phải cấp trên của đội dự án | |
| ⚠ Vì thế | ⚠ PM có đủ vị thế để xử lý, không nhất thiết phải leo thang ngay |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết đủ các bên liên quan tiêu cực chưa | ⚠ người không nói ra mới đáng lo | | Mối lo của họ có phải rủi ro thật không | | | Kế hoạch tham gia bên liên quan có phần riêng cho họ chưa | |
Và cách nhìn chuyên nghiệp về Terry: bà ấy không sai khi lo cho mảng kinh doanh của mình. Việc của PM là biến mối lo đó thành yêu cầu hoặc rủi ro được quản lý, thay vì thành một cuộc đối đầu.
- A Activity name
- B Activity identifier
- C Predecessor activities
- D WBS ID
Xem giải thích
Đáp án
C — Predecessor activities (các hoạt động tiền nhiệm).
Vì sao đúng
⚠ Chi tiết quyết định nằm ở chữ "VỪA KHỞI ĐỘNG": | Chi tiết | Suy ra | |---|---| | ⚠ "A project has JUST LAUNCHED" | ⚠ → đang ở giai đoạn RẤT SỚM | | ⚠ Đội mới đang ĐỊNH NGHĨA danh sách hoạt động | ⚠ → quy trình Define Activities | | ⚠ Ở giai đoạn đầu, thuộc tính hoạt động chỉ gồm ba thứ | ⚠ mã hoạt động, mã WBS, tên hoạt động | | ⚠ Việc tiền nhiệm được xác định ở quy trình SAU | ⚠ Sequence Activities | | ⚠ Kết luận | ⚠ tại thời điểm này chưa có thông tin về hoạt động tiền nhiệm |
Vì sao các phương án khác sai
- A (Activity name), B (Activity identifier), D (WBS ID) — ⚠ cả ba ĐỀU là thuộc tính có ngay từ giai đoạn đầu, ⚠ đúng như PMBOK mô tả.
Ghi nhớ
Ghi nhớ về chất lượng câu hỏi: ⚠ Hoạt động tiền nhiệm THỰC SỰ LÀ một thuộc tính hoạt động theo PMBOK — ⚠ nó nằm trong danh sách đầy đủ. ⚠ Điểm mấu chốt khiến khoá C đúng là ⚠ THỜI ĐIỂM: ⚠ PMBOK nói rõ ⚠ "trong các giai đoạn ĐẦU của dự án, thuộc tính hoạt động gồm mã hoạt động, mã WBS và tên hoạt động; KHI HOÀN THIỆN thì mới có thêm mô tả, hoạt động tiền nhiệm, hoạt động kế nhiệm, quan hệ logic, lead và lag..." ⚠ Đề nhấn chữ "vừa khởi động" chính là để dẫn tới cách đọc này. Giữ nguyên khoá C, ⚠ nhưng người học cần nhớ: ⚠ nếu đề KHÔNG nói dự án đang ở giai đoạn đầu thì hoạt động tiền nhiệm LÀ một thuộc tính hợp lệ và câu trả lời sẽ khác.
⚠ Thuộc tính hoạt động — danh sách ĐẦY ĐỦ khi đã hoàn thiện: | Nhóm | Thuộc tính | |---|---| | ⚠ CÓ NGAY từ đầu | ⚠ mã hoạt động (activity ID) | | ⚠ CÓ NGAY từ đầu | ⚠ mã WBS (WBS ID) | | ⚠ CÓ NGAY từ đầu | ⚠ tên hoạt động (activity label/name) | | ⚠ Bổ sung SAU | ⚠ mô tả hoạt động | | ⚠ Bổ sung SAU | ⚠ hoạt động TIỀN NHIỆM và KẾ NHIỆM | | ⚠ Bổ sung SAU | ⚠ quan hệ logic, lead và lag | | ⚠ Bổ sung SAU | ⚠ yêu cầu nguồn lực | | ⚠ Bổ sung SAU | ⚠ ngày áp đặt, ràng buộc, giả định | | ⚠ Bổ sung SAU | ⚠ người chịu trách nhiệm, địa điểm thực hiện | | ⚠ Bổ sung SAU | ⚠ mức nỗ lực, loại hoạt động |
Từ khoá nhận diện:
"vừa khởi động, giai đoạn đầu" → ⚠ thuộc tính chỉ có ID, WBS ID, tên "xác định trình tự và phụ thuộc" → ⚠ Sequence Activities — lúc này mới có tiền nhiệm "phân rã gói công việc thành hoạt động" → ⚠ Define Activities "ước lượng thời lượng" → ⚠ Estimate Activity Durations
| ⚠ Sáu quy trình quản lý lịch trình theo thứ tự | Quy trình |
|---|---|
| ⚠ 1. Plan Schedule Management | |
| ⚠ 2. Define Activities | ⚠ BƯỚC CỦA CÂU NÀY — ra activity list và activity attributes |
| ⚠ 3. Sequence Activities | ⚠ ra network diagram, xác định tiền nhiệm và kế nhiệm |
| ⚠ 4. Estimate Activity Durations | |
| ⚠ 5. Develop Schedule | ⚠ ra đường găng và đường cơ sở lịch |
| ⚠ 6. Control Schedule |
| ⚠ Vì sao thuộc tính được bổ sung DẦN | Lý do |
|---|---|
| ⚠ Đây chính là progressive elaboration áp dụng cho lịch trình | |
| ⚠ Không thể biết tiền nhiệm trước khi biết đủ các hoạt động | |
| ⚠ Ép điền đủ ngay từ đầu là tạo dữ liệu giả | |
| ⚠ Đối chiếu | ⚠ câu #25683 ở lô này về rolling wave planning — cùng nguyên tắc |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang ở quy trình nào của chuỗi lập lịch | ⚠ quyết định thuộc tính nào đã có | | Mỗi hoạt động có mã WBS tương ứng chưa | ⚠ thiếu là hoạt động mồ côi, không thuộc phạm vi nào | | Tên hoạt động có phải ĐỘNG TỪ không | ⚠ "Viết chương 1" chứ không phải "Tài liệu" |
Và điểm cần khắc từ câu này: cùng một danh sách thuộc tính, câu trả lời khác nhau tuỳ THỜI ĐIỂM trong dự án. Đọc kỹ mốc thời gian đề cho trước khi chọn đáp án.
- A Communications management plan
- B Stakeholder engagement plan
- C Stakeholder directory
- D Stakeholder mapping
Xem giải thích
Đáp án
B — Stakeholder engagement plan (kế hoạch tham gia của bên liên quan).
Vì sao đúng
⚠ Yêu cầu của nhà tài trợ khớp với tài liệu nào: | Yêu cầu | Tài liệu đáp ứng | |---|---| | ⚠ Xác định mức tham gia HIỆN TẠI của bên liên quan | ⚠ stakeholder engagement plan | | ⚠ Cách DUY TRÌ hoặc NÂNG CAO mức tham gia đó | ⚠ stakeholder engagement plan | | ⚠ Là một CHIẾN LƯỢC, không phải danh sách | | | ⚠ Đây là | ⚠ kế hoạch con của kế hoạch quản lý dự án, đầu ra của Plan Stakeholder Engagement |
Vì sao các phương án khác sai
-
A (Communications management plan) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nó nói ⚠ AI nhận thông tin gì, qua kênh nào, tần suất nào; ⚠ đó là CÔNG CỤ để thực hiện chiến lược tham gia, ⚠ không phải bản thân chiến lược đó.
-
C (Stakeholder directory) và D (Stakeholder mapping) — ⚠ không phải tên tài liệu chuẩn của PMBOK; ⚠ "mapping" là một KỸ THUẬT phân loại, không phải tài liệu.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25699 ở lô này về sổ đăng ký bên liên quan và câu #25702 về bên liên quan tiêu cực. ⚠ Ba câu vẽ đủ chuỗi: nhận diện (register) → lập chiến lược (engagement plan) → xử lý người phản đối.
⚠ Bốn quy trình quản lý bên liên quan: | Quy trình | Nhóm | Đầu ra chính | |---|---|---| | ⚠ Identify Stakeholders | ⚠ Khởi tạo | ⚠ stakeholder register | | ⚠ Plan Stakeholder Engagement | ⚠ Lập kế hoạch | ⚠ stakeholder engagement plan — CÂU NÀY | | ⚠ Manage Stakeholder Engagement | ⚠ Thực hiện | ⚠ yêu cầu thay đổi, cập nhật tài liệu | | ⚠ Monitor Stakeholder Engagement | ⚠ Giám sát và kiểm soát | ⚠ thông tin hiệu suất công việc |
⚠ Ma trận đánh giá mức tham gia — công cụ chính: | Bên liên quan | Unaware | Resistant | Neutral | Supportive | Leading | |---|---|---|---|---|---| | ⚠ Ký hiệu | ⚠ C = mức HIỆN TẠI (current) | | | ⚠ D = mức MONG MUỐN (desired) | | | ⚠ Khoảng cách C → D | ⚠ chính là việc phải làm trong kế hoạch tham gia |
Từ khoá nhận diện:
"chiến lược nâng và duy trì mức tham gia" → ⚠ stakeholder engagement plan "ai nhận thông tin gì, kênh nào, tần suất nào" → ⚠ communications management plan "danh sách bên liên quan và đánh giá về họ" → ⚠ stakeholder register "mức hiện tại và mức mong muốn" → ⚠ engagement assessment matrix
| ⚠ Nội dung của kế hoạch tham gia bên liên quan | Nội dung |
|---|---|
| ⚠ Mức tham gia HIỆN TẠI và MONG MUỐN của từng bên | |
| ⚠ Phạm vi và tác động của thay đổi lên từng bên | |
| ⚠ Quan hệ và chồng lấn giữa các bên liên quan | |
| ⚠ Yêu cầu giao tiếp của từng bên | |
| ⚠ Thông tin cần phân phối: nội dung, ngôn ngữ, mức chi tiết | |
| ⚠ Lý do phân phối và tác động kỳ vọng | |
| ⚠ Thời gian và tần suất | |
| ⚠ Cách cập nhật kế hoạch khi tình hình đổi | |
| ⚠ Lưu ý bảo mật | ⚠ kế hoạch này chứa đánh giá nhạy cảm — cân nhắc kỹ ai được đọc |
| ⚠ Bối cảnh ma trận YẾU có ý nghĩa gì | Ý nghĩa |
|---|---|
| ⚠ Quyền của PM THẤP | |
| ⚠ Nhà tài trợ đồng thời là quản lý chức năng | ⚠ đề nói rõ điều này |
| ⚠ PM càng phải dựa vào ẢNH HƯỞNG thay vì thẩm quyền | |
| ⚠ Vì thế | ⚠ quản lý sự tham gia của bên liên quan càng quan trọng — đó gần như là công cụ duy nhất bạn có |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có ma trận C và D cho từng bên liên quan chưa | | | Với mỗi khoảng cách C → D có hành động cụ thể không | ⚠ kế hoạch không có hành động là danh sách mong ước | | Kế hoạch có được cập nhật khi thái độ thay đổi không | |
Và ranh giới cần thuộc: kế hoạch giao tiếp trả lời "gửi gì cho ai", kế hoạch tham gia trả lời "muốn họ thay đổi thái độ thế nào và bằng cách gì". Cái sau là chiến lược, cái trước là công cụ thực thi.
- A Reject the change
- B Changes will now flow through formal change control procedures
- C Allow the changes to be added to the scope as no work has yet been completed
- D Ask the customer to present the change for the project sponsor to approve
Xem giải thích
Đáp án
B — Từ nay các thay đổi sẽ đi qua thủ tục KIỂM SOÁT THAY ĐỔI CHÍNH THỨC.
Vì sao đúng
⚠ Chi tiết quyết định: | Chi tiết | Suy ra | |---|---| | ⚠ Đường cơ sở phạm vi ĐÃ ĐƯỢC nhà tài trợ PHÊ DUYỆT | ⚠ → từ giây phút đó, phạm vi đã được KHOÁ | | ⚠ Mọi thay đổi sau khi có đường cơ sở | ⚠ → BẮT BUỘC qua Perform Integrated Change Control | | ⚠ "Các hạng mục nhỏ" | ⚠ → KHÔNG quan trọng — nhỏ hay lớn đều phải qua quy trình | | ⚠ "Chưa làm gì cả" | ⚠ → cũng KHÔNG quan trọng — đường cơ sở đã tồn tại rồi | | ⚠ Kết luận | ⚠ có đường cơ sở là có kiểm soát thay đổi |
Vì sao các phương án khác sai
-
C (cho thêm vào phạm vi vì chưa làm gì) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ nghe rất hợp lý, ⚠ nhưng ⚠ thời điểm phê duyệt đường cơ sở mới là mốc, không phải thời điểm bắt đầu công việc; ⚠ bỏ qua quy trình chính là scope creep.
-
A (từ chối thay đổi) — ⚠ PM không có thẩm quyền từ chối đơn phương; ⚠ và thay đổi có thể hoàn toàn hợp lý.
-
D (bảo khách trình bày với nhà tài trợ) — ⚠ đẩy việc của mình sang người khác; ⚠ PM phải GHI NHẬN và ĐÁNH GIÁ trước, ⚠ rồi mới trình lên người có thẩm quyền phê duyệt.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25675 ở lô 178 — ⚠ khách xin đổi thiết bị và sẵn sàng trả tiền, ⚠ đáp án vẫn là nộp yêu cầu thay đổi. ⚠ Hai câu cùng một nguyên tắc, khác cái cớ: một bên lấy cớ "khách trả tiền", một bên lấy cớ "chưa làm gì và chỉ là việc nhỏ". ⚠ Và câu #25643 ở lô 178 về scope creep.
⚠ Đường cơ sở là gì và vì sao nó quan trọng: | Điều | Nội dung | |---|---| | ⚠ Baseline = phiên bản ĐÃ ĐƯỢC PHÊ DUYỆT của kế hoạch | | | ⚠ Ba đường cơ sở chính | ⚠ phạm vi, lịch trình, chi phí — gộp lại là performance measurement baseline | | ⚠ Chỉ đổi được qua thủ tục kiểm soát thay đổi CHÍNH THỨC | | | ⚠ Là căn cứ ĐO hiệu suất | ⚠ không có đường cơ sở thì không tính được CPI, SPI | | ⚠ Scope baseline gồm | ⚠ project scope statement + WBS + WBS dictionary |
Từ khoá nhận diện:
"đường cơ sở đã được phê duyệt" → ⚠ mọi thay đổi phải qua quy trình "chỉ là thay đổi nhỏ" → ⚠ vẫn phải qua quy trình "chưa làm gì mà" → ⚠ vẫn phải qua quy trình "khách sẵn sàng trả tiền" → ⚠ vẫn phải qua quy trình
| ⚠ Vì sao ngay cả thay đổi NHỎ cũng phải qua quy trình | Lý do |
|---|---|
| ⚠ "Nhỏ" là đánh giá CHỦ QUAN, phải đo mới biết | |
| ⚠ Ba thay đổi nhỏ cộng lại không còn nhỏ | |
| ⚠ Tạo TIỀN LỆ: lần sau khách lại xin thêm | |
| ⚠ Đường cơ sở không cập nhật thì mọi phép đo hiệu suất SAI | ⚠ làm thêm việc mà EV không tăng tương ứng |
| ⚠ Không có dấu vết để giải trình sau này | |
| ⚠ Quy trình có thể NHANH | ⚠ thay đổi nhỏ thì phê duyệt nhanh, nhưng vẫn phải có dấu vết |
| ⚠ Bạn nên làm gì cụ thể | Bước |
|---|---|
| ⚠ 1. Giải thích với khách hàng quy trình thay đổi | ⚠ không phải từ chối, mà là hướng dẫn |
| ⚠ 2. Ghi nhận ba hạng mục thành yêu cầu thay đổi | |
| ⚠ 3. Đánh giá tác động tới phạm vi, lịch, chi phí, rủi ro | |
| ⚠ 4. Trình CCB hoặc nhà tài trợ | |
| ⚠ 5. Nếu duyệt: cập nhật đường cơ sở phạm vi | |
| ⚠ 6. Thông báo cho đội và các bên liên quan |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn đã có đường cơ sở chưa | ⚠ chưa có thì thay đổi còn dễ; có rồi thì phải theo quy trình | | Khách hàng có biết quy trình thay đổi không | ⚠ nên phổ biến từ đầu dự án | | Thủ tục thay đổi có đủ nhanh cho việc nhỏ không | ⚠ quá nặng nề thì người ta sẽ tìm cách lách |
Và mốc duy nhất cần nhớ: kiểm soát thay đổi bắt đầu từ lúc PHÊ DUYỆT đường cơ sở, không phải từ lúc bắt đầu làm việc. Mọi cái cớ khác — nhỏ, gấp, khách trả tiền, chưa động tới — đều không thay đổi mốc đó.
- A Affiliation
- B Safety
- C Esteem
- D Social
Xem giải thích
Đáp án
A — Affiliation (nhu cầu liên kết). ⚠ Đây KHÔNG phải một bậc trong tháp Maslow.
Vì sao đúng
⚠ Năm bậc nhu cầu của Maslow, từ dưới lên: | Bậc | Tên | Nội dung | |---|---|---| | ⚠ 1 | ⚠ Physiological — SINH LÝ | ⚠ ăn, uống, ngủ, không khí — nhu cầu sống còn | | ⚠ 2 | ⚠ Safety — AN TOÀN | ⚠ an toàn thân thể, ổn định công việc, sức khoẻ, tài chính | | ⚠ 3 | ⚠ Social / Belonging — XÃ HỘI | ⚠ tình bạn, gia đình, cảm giác thuộc về một nhóm | | ⚠ 4 | ⚠ Esteem — ĐƯỢC TÔN TRỌNG | ⚠ được công nhận, có địa vị, tự trọng | | ⚠ 5 | ⚠ Self-actualization — TỰ THỂ HIỆN | ⚠ phát huy hết tiềm năng bản thân | | ⚠ "Affiliation" | ⚠ KHÔNG thuộc Maslow | ⚠ đó là một trong BA nhu cầu của MCCLELLAND |
Vì sao các phương án khác sai
- B (Safety), C (Esteem), D (Social) — ⚠ cả ba ĐỀU là bậc trong tháp Maslow.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25641 ở lô 178 hỏi nhu cầu nào KHÔNG thuộc McClelland (đáp án: "ambition"), ⚠ và câu #25659 về Herzberg. ⚠ Ba câu là bộ hoàn chỉnh về các thuyết động lực — và đây chính là cặp bẫy đối xứng: một câu lấy từ bịa ra, một câu lấy từ THUYẾT KHÁC để gây nhiễu.
⚠ Điểm dễ nhầm nhất giữa Maslow và McClelland: | Thuyết | Ba/năm thành phần | |---|---| | ⚠ Maslow | ⚠ sinh lý, an toàn, XÃ HỘI, được tôn trọng, tự thể hiện | | ⚠ McClelland | ⚠ thành tựu, quyền lực, LIÊN KẾT (affiliation) | | ⚠ Chỗ lẫn | ⚠ "xã hội" của Maslow và "liên kết" của McClelland NGHE giống nhau nhưng thuộc hai thuyết khác nhau | | ⚠ Mẹo phân biệt | ⚠ Maslow là THÁP có thứ bậc; McClelland là BA nhu cầu song song, không xếp bậc |
⚠ Bảng tổng hợp các thuyết động lực: | Thuyết | Nội dung cốt lõi | |---|---| | ⚠ Maslow | ⚠ tháp NĂM bậc, thoả mãn bậc dưới mới lên bậc trên | | ⚠ Herzberg | ⚠ HAI yếu tố: duy trì (chống bất mãn) và động viên (tạo động lực) | | ⚠ McGregor | ⚠ Thuyết X (người lười) và Thuyết Y (người tự giác) | | ⚠ McClelland | ⚠ BA nhu cầu: thành tựu, quyền lực, liên kết | | ⚠ Vroom | ⚠ thuyết kỳ vọng: động lực = kỳ vọng × phương tiện × giá trị | | ⚠ Ouchi | ⚠ Thuyết Z: việc làm trọn đời, quan tâm toàn diện |
Từ khoá nhận diện:
"tháp, năm bậc, thoả mãn dần từ dưới lên" → ⚠ Maslow "ba nhu cầu, bài kiểm tra kể chuyện qua ảnh" → ⚠ McClelland "lương chỉ chống bất mãn" → ⚠ Herzberg "người lười hay người tự giác" → ⚠ McGregor "affiliation" → ⚠ McClelland, KHÔNG phải Maslow
| ⚠ Ứng dụng Maslow cho quản lý dự án | Ứng dụng |
|---|---|
| ⚠ Bậc 1–2 chưa được đáp ứng thì đừng nói tới động lực | ⚠ người lo mất việc không quan tâm tới cơ hội phát triển |
| ⚠ Bậc 3: xây cảm giác thuộc về đội | ⚠ hoạt động gắn kết, hiến chương đội |
| ⚠ Bậc 4: ghi nhận công khai, trao trách nhiệm | |
| ⚠ Bậc 5: giao việc thử thách, cơ hội học hỏi | |
| ⚠ Lưu ý | ⚠ thuyết Maslow bị phê phán là quá cứng nhắc trong thực tế, nhưng vẫn hay ra thi |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ai đang lo về bậc 1–2 không | ⚠ hợp đồng sắp hết, lương chậm, môi trường làm việc tệ | | Bạn có nhầm nhu cầu "xã hội" với "liên kết" không | ⚠ hai thuyết khác nhau | | Cách ghi nhận của bạn nhắm vào bậc nào | |
Và mẹo làm bài chắc chắn nhất cho dạng "cái nào KHÔNG thuộc thuyết X": kiểm tra xem nó có thuộc thuyết KHÁC không. Đề thi rất hay lấy thành phần của một thuyết để làm nhiễu cho thuyết bên cạnh.
- A Confirmed materials
- B High-grade materials
- C Correct materials
- D Quality-accepted materials
Xem giải thích
Đáp án
B — High-grade materials (vật liệu CẤP CAO).
Vì sao đúng
⚠ Phân biệt QUALITY và GRADE — khái niệm PMBOK nhấn mạnh: | Khái niệm | Nghĩa | Thấp thì sao | |---|---|---| | ⚠ Quality — CHẤT LƯỢNG | ⚠ mức độ ĐÁP ỨNG YÊU CẦU đã đặt ra | ⚠ LUÔN là vấn đề — chất lượng thấp là lỗi | | ⚠ Grade — CẤP ĐỘ | ⚠ phân hạng theo ĐẶC TÍNH KỸ THUẬT: độ bền, tính năng, vật liệu | ⚠ có thể CHẤP NHẬN được — cấp thấp không phải lỗi |
⚠ Vì sao đội cần "grade" chứ không phải "quality": | Lý do | Nội dung | |---|---| | ⚠ Họ muốn vật liệu BỀN HƠN, TỐT HƠN về đặc tính kỹ thuật | ⚠ đó là yêu cầu về CẤP ĐỘ | | ⚠ Vật liệu cấp thấp vẫn có thể có CHẤT LƯỢNG CAO | ⚠ nếu nó đúng đặc tả và không có khuyết tật | | ⚠ Vật liệu cấp cao vẫn có thể có CHẤT LƯỢNG THẤP | ⚠ nếu nó có lỗi sản xuất | | ⚠ Kết luận | ⚠ cái đội thật sự cần là CẤP CAO, còn chất lượng cao thì mọi vật liệu đều phải đạt |
Vì sao các phương án khác sai
- A (Confirmed materials), C (Correct materials), D (Quality-accepted materials) — ⚠ cả ba đều KHÔNG phải thuật ngữ PMBOK.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25635 ở lô 178 về định nghĩa chất lượng — ⚠ ở đó phần Ghi nhớ đã nêu cặp quality/grade. ⚠ Câu này hỏi thẳng vào cặp khái niệm đó.
⚠ Bốn tổ hợp quality × grade: | Tổ hợp | Có chấp nhận được không | |---|---| | ⚠ Chất lượng CAO + cấp CAO | ⚠ tốt nhất, cũng đắt nhất | | ⚠ Chất lượng CAO + cấp THẤP | ⚠ CHẤP NHẬN ĐƯỢC — sản phẩm ít tính năng nhưng chạy không lỗi | | ⚠ Chất lượng THẤP + cấp CAO | ⚠ KHÔNG chấp nhận — nhiều tính năng nhưng đầy lỗi | | ⚠ Chất lượng THẤP + cấp THẤP | ⚠ KHÔNG chấp nhận | | ⚠ Nguyên tắc PMBOK | ⚠ cấp thấp CÓ THỂ không sao; chất lượng thấp LUÔN là vấn đề |
⚠ Ví dụ kinh điển: | Ví dụ | Giải thích | |---|---| | ⚠ Xe hạng phổ thông chạy bền, không hỏng vặt | ⚠ grade thấp, quality cao — hoàn toàn ổn | | ⚠ Xe hạng sang liên tục phải sửa | ⚠ grade cao, quality thấp — không chấp nhận được | | ⚠ Phần mềm đơn giản, ít tính năng, không lỗi | ⚠ grade thấp, quality cao | | ⚠ Phần mềm nhiều tính năng, hay treo | ⚠ grade cao, quality thấp |
Từ khoá nhận diện:
"vật liệu bền hơn, tính năng nhiều hơn" → ⚠ grade "đúng đặc tả, không khuyết tật" → ⚠ quality "cấp thấp có thể chấp nhận, chất lượng thấp thì không" → ⚠ câu chốt của PMBOK "giao đúng cái đã yêu cầu" → ⚠ định nghĩa chất lượng
| ⚠ PM nên hỏi lại đội thế nào | Câu hỏi |
|---|---|
| ⚠ "Cấp vật liệu nào đã được ghi trong đặc tả?" | |
| ⚠ "Cấp đã duyệt có đáp ứng được yêu cầu kỹ thuật không?" | |
| ⚠ "Nếu cần cấp cao hơn thì đó là YÊU CẦU THAY ĐỔI" | ⚠ ảnh hưởng chi phí, phải qua kiểm soát thay đổi |
| ⚠ Cạm bẫy | ⚠ tự nâng cấp vật liệu cho "chắc" chính là GOLD PLATING |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đặc tả có ghi rõ CẤP vật liệu không | ⚠ thiếu là nguồn tranh cãi | | Cấp đã duyệt có đủ đáp ứng yêu cầu không | | | Nâng cấp có qua kiểm soát thay đổi không | |
Và câu tổng kết cần thuộc nguyên văn: cấp độ thấp có thể chấp nhận được, chất lượng thấp thì không bao giờ. Nhầm hai khái niệm này dẫn tới việc chi thêm tiền cho thứ không ai yêu cầu.
- A $329,667
- B $1,318,667
- C ($68,017)
- D 1.19
Xem giải thích
Đáp án
A — 329.667.
Vì sao đúng
⚠ Bóc tách dữ liệu: | Đại lượng | Cách tính | Kết quả | |---|---|---| | ⚠ BAC | ⚠ đề cho | ⚠ 1.250.650 | | ⚠ EV | ⚠ BAC × 75% hoàn thành thực tế | ⚠ 937.987,5 | | ⚠ PV | ⚠ BAC × 80% đáng lẽ phải xong | ⚠ 1.000.520 | | ⚠ AC | ⚠ đề cho | ⚠ 989.000 |
⚠ Ba bước tính ETC: | Bước | Phép tính | |---|---| | ⚠ 1. CPI = EV / AC | ⚠ 937.987,5 / 989.000 = 0,9484 | | ⚠ 2. EAC = BAC / CPI | ⚠ 1.250.650 / 0,9484 = 1.318.667 | | ⚠ 3. ETC = EAC − AC | ⚠ 1.318.667 − 989.000 = 329.667 | | ⚠ Ý nghĩa | ⚠ từ hôm nay tới lúc xong còn phải chi thêm khoảng 329.667 |
Vì sao các phương án khác sai
-
B (1.318.667) — ⚠ là EAC — TỔNG chi phí dự báo khi hoàn thành, ⚠ không phải phần CÒN LẠI; ⚠ đây là phương án gây nhiễu mạnh nhất vì nó là kết quả của bước 2.
-
C (68.017) — ⚠ không khớp chỉ số nào của bài; ⚠ CV = −51.012,5 và SV = −62.532,5, ⚠ cả hai đều khác con số này.
-
D (1,19) — ⚠ là một TỶ SỐ, ⚠ trong khi ETC phải là một SỐ TIỀN.
Ghi nhớ
Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này dùng CÙNG KHUÔN với câu #25581 (lô 176) và #25685 (lô 179) — ⚠ cùng ngân sách ⚠ 1.250.650, ⚠ cùng cách diễn đạt "hoàn thành X% nhưng đáng lẽ phải Y%", ⚠ cùng lỗi ngữ pháp "you were supposed to 75 percent". ⚠ Khác nhau ở CON SỐ và ở CHỈ SỐ được hỏi: ⚠ #25581 hỏi CV với 65/75 và AC 847.500; ⚠ #25685 hỏi CPI với cùng bộ số đó; ⚠ câu này hỏi ETC với 75/80 và AC 989.000. ⚠ Ba khoá đáp án đều đúng và KHÔNG mâu thuẫn — chỉ là ba biến thể của một mẫu đề. ⚠ Người học nên ⚠ tính đủ bộ chỉ số một lần cho mỗi bộ số rồi mới chọn đáp án, ⚠ vì phương án nhiễu thường chính là chỉ số khác của cùng bộ số đó.
⚠ Toàn bộ chỉ số của bộ số này: | Chỉ số | Phép tính | Kết quả | |---|---|---| | ⚠ CV = EV − AC | ⚠ 937.987,5 − 989.000 | ⚠ −51.012,5 | | ⚠ SV = EV − PV | ⚠ 937.987,5 − 1.000.520 | ⚠ −62.532,5 | | ⚠ CPI = EV / AC | | ⚠ 0,948 — vượt chi nhẹ | | ⚠ SPI = EV / PV | | ⚠ 0,938 — chậm nhẹ | | ⚠ EAC = BAC / CPI | | ⚠ 1.318.667 | | ⚠ ETC = EAC − AC | | ⚠ 329.667 — ĐÁP ÁN | | ⚠ VAC = BAC − EAC | | ⚠ −68.017 — chính là phương án C! |
⚠ Phát hiện quan trọng: ⚠ phương án C (68.017) chính là VAC — chênh lệch khi hoàn thành. ⚠ Đề đã dùng một chỉ số THẬT khác của cùng bộ số để làm nhiễu. ⚠ Đây là bằng chứng rõ nhất cho lời khuyên ở trên: phải phân biệt được ETC, EAC, VAC mới chọn đúng.
⚠ Bốn chỉ số dự báo — phân biệt cho chắc: | Chỉ số | Nghĩa | Đơn vị | |---|---|---| | ⚠ EAC | ⚠ TỔNG chi phí dự báo khi dự án hoàn thành | ⚠ tiền | | ⚠ ETC | ⚠ CÒN PHẢI CHI THÊM bao nhiêu từ hôm nay | ⚠ tiền | | ⚠ VAC | ⚠ CHÊNH LỆCH giữa ngân sách và dự báo — âm là sẽ vượt | ⚠ tiền | | ⚠ TCPI | ⚠ hiệu suất CẦN ĐẠT để về đúng ngân sách | ⚠ tỷ số | | ⚠ Quan hệ | ⚠ EAC = AC + ETC, và VAC = BAC − EAC |
Từ khoá nhận diện:
"còn phải chi bao nhiêu nữa" → ⚠ ETC "tổng cộng sẽ tốn bao nhiêu" → ⚠ EAC "sẽ vượt ngân sách bao nhiêu" → ⚠ VAC "phải làm hiệu quả thế nào mới về đúng ngân sách" → ⚠ TCPI
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đề hỏi TỔNG hay hỏi PHẦN CÒN LẠI | ⚠ EAC hay ETC | | Đáp án phải là tiền hay tỷ số | ⚠ loại ngay phương án sai đơn vị | | Bạn đã kiểm tra EAC = AC + ETC chưa | ⚠ 989.000 + 329.667 = 1.318.667 ✓ |
Và phép tự kiểm nhanh nhất cho dạng câu này: cộng AC với đáp án của bạn, kết quả phải bằng EAC. Ở đây 989.000 + 329.667 = 1.318.667 — khớp, nên đáp án chắc chắn đúng.
- A Accepted
- B Non-conforming
- C Residual
- D Aggravated
Xem giải thích
Đáp án
C — Residual (rủi ro tồn dư).
Vì sao đúng
⚠ Chuỗi sự việc trong đề: | Bước | Nội dung | |---|---| | ⚠ Xác định một rủi ro quá nguy hiểm cho đội tự làm | | | ⚠ Chọn chiến lược CHUYỂN GIAO — transference | ⚠ giao cho nhà cung cấp làm | | ⚠ Rủi ro gốc đã được xử lý | | | ⚠ NHƯNG vẫn còn khả năng nhà cung cấp giao TRỄ | ⚠ dù hợp đồng có điều khoản phạt | | ⚠ Rủi ro còn sót lại này | ⚠ = RỦI RO TỒN DƯ (residual risk) | | ⚠ Đề nói rõ | ⚠ "xác suất và tác động nhỏ" và "đã ghi vào sổ đăng ký rủi ro" — đúng cách xử lý rủi ro tồn dư |
Vì sao các phương án khác sai
-
A (Accepted — đã chấp nhận) — ⚠ "chấp nhận" là một CHIẾN LƯỢC ứng phó, ⚠ không phải LOẠI rủi ro; ⚠ rủi ro tồn dư này có thể được chấp nhận, nhưng tên gọi của nó vẫn là "tồn dư".
-
B (Non-conforming) và D (Aggravated) — ⚠ không phải thuật ngữ rủi ro của PMBOK.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25688 ở lô này về chiến lược ứng phó rủi ro. ⚠ Câu kia hỏi CHỌN chiến lược, câu này hỏi cái CÒN LẠI sau khi đã áp dụng chiến lược.
⚠ Ba khái niệm rủi ro rất dễ lẫn: | Khái niệm | Nghĩa | |---|---| | ⚠ Residual risk — rủi ro TỒN DƯ | ⚠ phần rủi ro CÒN LẠI sau khi đã ứng phó — không bao giờ về 0 hoàn toàn | | ⚠ Secondary risk — rủi ro THỨ CẤP | ⚠ rủi ro MỚI SINH RA TRỰC TIẾP từ chính hành động ứng phó | | ⚠ Risk trigger — dấu hiệu kích hoạt | ⚠ tín hiệu cho biết rủi ro sắp hoặc đang xảy ra |
⚠ Phân biệt tồn dư và thứ cấp bằng ví dụ này: | Loại | Ví dụ trong tình huống | |---|---| | ⚠ Rủi ro tồn dư | ⚠ nhà cung cấp vẫn có thể giao trễ — vẫn là RỦI RO CŨ, chỉ nhỏ đi | | ⚠ Rủi ro thứ cấp | ⚠ nếu việc thuê ngoài làm lộ thông tin mật cho bên thứ ba — rủi ro HOÀN TOÀN MỚI do chính việc thuê tạo ra | | ⚠ Cách phân biệt | ⚠ hỏi: "đây là phần còn lại của rủi ro cũ hay là rủi ro mới do hành động của tôi sinh ra?" |
Từ khoá nhận diện:
"vẫn còn khả năng xảy ra sau khi đã ứng phó" → ⚠ residual risk "rủi ro mới do chính biện pháp ứng phó tạo ra" → ⚠ secondary risk "dấu hiệu cảnh báo rủi ro sắp xảy ra" → ⚠ trigger "chuyển hậu quả sang bên thứ ba" → ⚠ transference
| ⚠ Chuyển giao rủi ro — những điều cần biết | Nội dung |
|---|---|
| ⚠ Chuyển HẬU QUẢ, không xoá bỏ rủi ro | ⚠ rủi ro vẫn tồn tại, chỉ đổi người chịu |
| ⚠ Công cụ điển hình | ⚠ bảo hiểm, bảo lãnh, hợp đồng giá cố định, thư bảo đảm |
| ⚠ Luôn kèm PHÍ CHUYỂN GIAO | ⚠ phí bảo hiểm, giá hợp đồng cao hơn |
| ⚠ Luôn còn RỦI RO TỒN DƯ | ⚠ bên nhận có thể không thực hiện được |
| ⚠ Sai lầm phổ biến | ⚠ tưởng ký hợp đồng xong là hết rủi ro |
| ⚠ Vì sao điều khoản phạt KHÔNG xoá được rủi ro | Lý do |
|---|---|
| ⚠ Tiền phạt KHÔNG bù được thời gian đã mất | |
| ⚠ Dự án vẫn trễ dù bạn được đền bù | |
| ⚠ Đòi bồi thường có thể mất thời gian và tiền pháp lý | |
| ⚠ Vì thế | ⚠ Mary hoàn toàn đúng khi ghi nhận rủi ro này |
| ⚠ Cách quản lý rủi ro tồn dư | Cách |
|---|---|
| ⚠ GHI vào sổ đăng ký rủi ro | ⚠ đúng như đội đã làm |
| ⚠ Đánh giá lại xác suất và tác động SAU khi ứng phó | |
| ⚠ Nếu còn quá lớn thì cần ứng phó tiếp | |
| ⚠ Nếu nhỏ thì chấp nhận và theo dõi | ⚠ trường hợp này |
| ⚠ Lập dự phòng cho phần rủi ro chấp nhận |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sau mỗi biện pháp ứng phó bạn có đánh giá lại không | ⚠ rủi ro tồn dư hay bị bỏ quên nhất | | Biện pháp ứng phó có sinh ra rủi ro mới không | ⚠ secondary risk | | Rủi ro tồn dư còn lại có được chấp nhận chính thức không | |
Và nguyên tắc cần khắc: không có biện pháp ứng phó nào đưa rủi ro về 0. Việc của quản lý rủi ro là đưa nó xuống mức chấp nhận được rồi ghi nhận phần còn lại — chứ không phải tuyên bố đã xử lý xong.
- A McClelland’s Theory of Needs
- B Maslow’s Hierarchy of Needs
- C Halo Effect
- D Vroom’s Expectancy Theory
Xem giải thích
Đáp án
D — Vroom's Expectancy Theory (thuyết kỳ vọng của Vroom).
Vì sao đúng
⚠ Ba thành phần của thuyết kỳ vọng, áp vào tình huống: | Thành phần | Nghĩa | Trong tình huống | |---|---|---| | ⚠ Expectancy — KỲ VỌNG | ⚠ "nếu tôi cố gắng thì tôi làm được" | ⚠ đội tin rằng làm thêm thứ Bảy thì kịp mốc | | ⚠ Instrumentality — PHƯƠNG TIỆN | ⚠ "nếu tôi làm được thì tôi được thưởng" | ⚠ Jonathan hứa rõ: kịp mốc thì có nghỉ bốn ngày | | ⚠ Valence — GIÁ TRỊ | ⚠ "phần thưởng đó có ĐÁNG với tôi không" | ⚠ đội HÀO HỨNG — nghỉ dài là thứ họ thật sự muốn | | ⚠ Công thức | ⚠ Động lực = Kỳ vọng × Phương tiện × Giá trị | | ⚠ Lưu ý | ⚠ là phép NHÂN — một thành phần bằng 0 thì động lực bằng 0 |
Vì sao các phương án khác sai
-
B (Maslow's Hierarchy of Needs) — ⚠ là tháp NĂM BẬC nhu cầu, ⚠ không nói về cơ chế nỗ lực → phần thưởng.
-
A (McClelland's Theory of Needs) — ⚠ là BA nhu cầu: thành tựu, quyền lực, liên kết; ⚠ không phải mô hình phần thưởng.
-
C (Halo Effect — hiệu ứng hào quang) — ⚠ là THIÊN KIẾN nhận thức: ⚠ đánh giá tổng thể một người dựa trên MỘT đặc điểm nổi bật; ⚠ trong dự án hay thấy ở việc ⚠ thăng chức người giỏi kỹ thuật lên làm quản lý dự án chỉ vì họ giỏi kỹ thuật.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25641 ở lô 178 (McClelland), câu #25659 (Herzberg) và câu #25706 ở lô này (Maslow). ⚠ Bốn câu hợp thành bộ đầy đủ về các thuyết động lực hay ra thi.
⚠ Bảng tổng hợp các thuyết: | Thuyết | Nội dung cốt lõi | |---|---| | ⚠ Maslow | ⚠ tháp năm bậc: sinh lý, an toàn, xã hội, tôn trọng, tự thể hiện | | ⚠ Herzberg | ⚠ hai yếu tố: duy trì chống bất mãn, động viên tạo động lực | | ⚠ McGregor | ⚠ Thuyết X (lười, phải giám sát) và Y (tự giác) | | ⚠ McClelland | ⚠ ba nhu cầu: thành tựu, quyền lực, liên kết | | ⚠ Vroom | ⚠ kỳ vọng × phương tiện × giá trị — CÂU NÀY | | ⚠ Ouchi | ⚠ Thuyết Z: việc làm trọn đời, quan tâm toàn diện |
Từ khoá nhận diện:
"cố gắng → đạt được → được thưởng → phần thưởng đáng giá" → ⚠ Vroom "tháp năm bậc" → ⚠ Maslow "lương chỉ chống bất mãn" → ⚠ Herzberg "ba nhu cầu song song" → ⚠ McClelland "đánh giá cả người dựa trên một điểm mạnh" → ⚠ halo effect
| ⚠ Vì sao Jonathan làm ĐÚNG theo Vroom | Lý do |
|---|---|
| ⚠ Mục tiêu RÕ RÀNG và khả thi | ⚠ kỳ vọng cao — đội tin mình làm được |
| ⚠ Liên kết trực tiếp giữa kết quả và phần thưởng | ⚠ phương tiện cao — hứa rõ ràng |
| ⚠ Phần thưởng là thứ đội THẬT SỰ muốn | ⚠ giá trị cao — đội hào hứng |
| ⚠ Cả ba đều cao | ⚠ nên động lực cao — đúng công thức nhân |
| ⚠ Vì sao nhiều chương trình thưởng THẤT BẠI | Nguyên nhân theo Vroom |
|---|---|
| ⚠ Mục tiêu bất khả thi | ⚠ kỳ vọng = 0 → động lực = 0 |
| ⚠ Đã từng hứa mà không giữ lời | ⚠ phương tiện = 0 → động lực = 0 |
| ⚠ Phần thưởng không ai muốn | ⚠ giá trị = 0 → động lực = 0 |
| ⚠ Bài học | ⚠ hỏi đội muốn gì thay vì tự quyết phần thưởng |
| ⚠ Rủi ro cần lưu ý trong tình huống này | Rủi ro |
|---|---|
| ⚠ Làm thứ Bảy là làm THÊM GIỜ | ⚠ một lần thì được, thành thói quen thì hại |
| ⚠ Đề nói "chất lượng là tối quan trọng" | ⚠ ép tiến độ có thể làm giảm chất lượng — xem câu #25612 |
| ⚠ Jonathan PHẢI giữ lời hứa | ⚠ thất hứa một lần là mất phương tiện mãi mãi |
| ⚠ Tốt nhất | ⚠ coi đây là biện pháp NGẮN HẠN, không phải cách vận hành thường xuyên |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mục tiêu bạn đặt ra đội có tin là làm được không | | | Bạn đã từng hứa mà không giữ lời chưa | | | Phần thưởng có phải thứ đội thật sự muốn không | ⚠ hỏi họ, đừng đoán |
Và điều quý nhất mà thuyết Vroom dạy: động lực là phép NHÂN, không phải phép cộng. Một mắt xích bằng 0 thì cả chuỗi bằng 0 — dù hai mắt còn lại có mạnh tới đâu.
- A Move onto the next project.
- B Return to operations.
- C Nothing. The project is done.
- D Write a final project report.
Xem giải thích
Đáp án
D — Viết báo cáo dự án cuối cùng (final project report).
Vì sao đúng
⚠ Nguyên tắc cốt lõi: | Nguyên tắc | Nội dung | |---|---| | ⚠ MỌI dự án đều phải qua quy trình Close Project or Phase | | | ⚠ Kể cả dự án bị HUỶ GIỮA CHỪNG | ⚠ đây là điểm hay bị quên nhất | | ⚠ Báo cáo cuối cùng là ĐẦU RA của quy trình kết thúc | | | ⚠ Lý do huỷ cũng phải được ghi lại | ⚠ để tổ chức học được từ đó | | ⚠ Trong tình huống này | ⚠ dự án huỷ vì công nghệ thay đổi — một bài học rất giá trị cho các dự án sau |
Vì sao các phương án khác sai
-
C (không làm gì cả, dự án xong rồi) — ⚠ SAI hoàn toàn: ⚠ huỷ dự án KHÔNG có nghĩa là bỏ mặc.
-
A (chuyển sang dự án tiếp theo) và B (quay về vận hành) — ⚠ là việc sẽ làm SAU khi đã kết thúc dự án đúng thủ tục, ⚠ không phải việc TIẾP THEO.
Ghi nhớ
⚠ Close Project or Phase — làm gì khi dự án bị huỷ: | Việc | Nội dung | |---|---| | ⚠ Viết BÁO CÁO CUỐI CÙNG | ⚠ tóm tắt hiệu suất, lý do kết thúc, mức đạt mục tiêu | | ⚠ Thu thập BÀI HỌC KINH NGHIỆM | ⚠ quan trọng nhất khi dự án thất bại | | ⚠ ĐÓNG các hợp đồng còn mở | ⚠ thanh toán, nghiệm thu phần đã làm, giải quyết khiếu nại | | ⚠ GIẢI PHÓNG nguồn lực | ⚠ trả người về phòng ban hoặc chuyển dự án khác | | ⚠ LƯU TRỮ tài liệu dự án | ⚠ thành tài sản quy trình tổ chức | | ⚠ Bàn giao phần công việc đã hoàn thành | ⚠ nếu có phần dùng lại được | | ⚠ Cập nhật cơ sở dữ liệu tổ chức | ⚠ dữ liệu chi phí, năng suất, bài học | | ⚠ Đo mức độ hoàn thành | ⚠ với dự án bị huỷ: ghi rõ đã đạt tới đâu và vì sao dừng |
Từ khoá nhận diện:
"dự án bị huỷ" → ⚠ vẫn phải Close Project or Phase "việc tiếp theo là gì" → ⚠ kết thúc đúng thủ tục, không phải bỏ đi "báo cáo cuối cùng" → ⚠ đầu ra của quy trình kết thúc "bài học kinh nghiệm" → ⚠ lessons learned register, chuyển thành OPA
| ⚠ Vì sao dự án THẤT BẠI lại có bài học QUÝ nhất | Lý do |
|---|---|
| ⚠ Chỉ ra điểm yếu trong quy trình chọn dự án | ⚠ có nên đánh giá rủi ro công nghệ kỹ hơn không? |
| ⚠ Chỉ ra dấu hiệu cảnh báo bị bỏ qua | |
| ⚠ Giúp dự án sau nhận ra tình huống tương tự SỚM hơn | |
| ⚠ Tránh lặp lại cùng một sai lầm | |
| ⚠ Nếu bỏ qua bước này | ⚠ tổ chức trả tiền cho bài học mà không nhận được bài học |
| ⚠ Nội dung báo cáo cuối cùng của một dự án bị huỷ | Nội dung |
|---|---|
| ⚠ Tóm tắt dự án và mục tiêu ban đầu | |
| ⚠ Mức độ đạt mục tiêu tại thời điểm dừng | |
| ⚠ LÝ DO huỷ — nêu rõ và trung thực | |
| ⚠ Tổng chi phí đã bỏ ra | ⚠ chi phí chìm — xem câu #25697 |
| ⚠ Phần công việc có thể tái sử dụng | |
| ⚠ Bài học kinh nghiệm | |
| ⚠ Trạng thái các hợp đồng và cam kết |
⚠ Đối chiếu: ⚠ câu #25697 ở lô này về chi phí chìm khi cân nhắc huỷ dự án. ⚠ Câu kia là lúc quyết định huỷ, câu này là việc phải làm sau khi đã quyết.
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi hợp đồng đã được đóng chưa | ⚠ bỏ sót là rủi ro pháp lý | | Bài học đã được ghi và LƯU vào nơi người khác tìm được chưa | ⚠ ghi mà không ai đọc thì vô ích | | Đội đã được thông báo và ghi nhận đúng mực chưa | ⚠ dự án huỷ không phải lỗi của họ |
Và điều phân biệt một quản lý dự án chuyên nghiệp: họ kết thúc dự án thất bại cẩn thận không kém dự án thành công. Chính bản báo cáo đó là thứ duy nhất tổ chức còn giữ lại được từ số tiền đã bỏ ra.