Ngân hàng đề — PMP Mock Exam Set
Tìm thấy 201 câu.
- A Scatter diagram
- B Control chart
- C Flowchart
- D Pareto diagram
Xem giải thích
Đáp án
A — Scatter diagram (biểu đồ phân tán).
Vì sao đúng
⚠ Vì sao là biểu đồ phân tán: | Điều | Nội dung | |---|---| | ⚠ Có HAI biến số cần so | ⚠ mức bảo trì thiết bị và số khuyết tật | | ⚠ Muốn xem có TƯƠNG QUAN không | ⚠ đúng chữ "correlation" trong đề | | ⚠ Mỗi điểm trên biểu đồ là một cặp giá trị | | | ⚠ Nhìn hình dạng đám mây điểm để đoán quan hệ | | | ⚠ Còn gọi là | ⚠ correlation chart hoặc XY diagram |
Vì sao các phương án khác sai
-
B (Control chart — biểu đồ kiểm soát) — ⚠ theo dõi MỘT biến theo thời gian để xem quy trình có nằm trong tầm kiểm soát không; ⚠ không thể hiện quan hệ giữa hai biến.
-
D (Pareto diagram) — ⚠ XẾP HẠNG các loại khuyết tật theo tần suất, ⚠ không đo tương quan.
-
C (Flowchart — lưu đồ) — ⚠ vẽ các bước của quy trình, ⚠ không phải công cụ phân tích số liệu.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25609 ở lô trước cũng về scatter diagram, và câu #25626 cùng #25664 ở lô này về Pareto và Ishikawa. ⚠ Bốn câu cùng thuộc bộ bảy công cụ chất lượng cơ bản — nên học chung.
⚠ Bảy công cụ chất lượng cơ bản: | Công cụ | Trả lời câu hỏi | |---|---| | ⚠ Check sheet | ⚠ "mỗi loại lỗi xảy ra bao nhiêu lần?" | | ⚠ Pareto chart | ⚠ "nên sửa loại nào trước?" | | ⚠ Cause-and-effect (Ishikawa) | ⚠ "vì sao nó hỏng?" | | ⚠ Flowchart | ⚠ "quy trình chạy thế nào?" | | ⚠ Histogram | ⚠ "dữ liệu phân bố ra sao?" | | ⚠ Control chart | ⚠ "quy trình có ổn định không?" | | ⚠ Scatter diagram | ⚠ "hai thứ này có liên quan không?" |
⚠ Đọc một biểu đồ phân tán: | Hình dạng | Nghĩa | |---|---| | ⚠ Các điểm chụm quanh đường đi LÊN | ⚠ tương quan DƯƠNG — biến này tăng thì biến kia tăng | | ⚠ Các điểm chụm quanh đường đi XUỐNG | ⚠ tương quan ÂM — biến này tăng thì biến kia giảm | | ⚠ Các điểm rải rác không có hình dạng | ⚠ KHÔNG có tương quan | | ⚠ Càng chụm sát đường | ⚠ tương quan càng MẠNH | | ⚠ Kỳ vọng của tình huống này | ⚠ tương quan ÂM: bảo trì càng đều thì lỗi càng ít |
Từ khoá nhận diện:
"hai biến có liên quan không" → ⚠ scatter diagram "quy trình có ổn định không" → ⚠ control chart "loại lỗi nào nhiều nhất" → ⚠ Pareto "vì sao lỗi xảy ra" → ⚠ Ishikawa "bảy điểm liên tiếp cùng một phía" → ⚠ rule of seven trên control chart
| ⚠ Cảnh báo quan trọng khi dùng biểu đồ phân tán | Cảnh báo |
|---|---|
| ⚠ TƯƠNG QUAN KHÔNG PHẢI NHÂN QUẢ | ⚠ đây là điều dễ kết luận sai nhất |
| ⚠ Có thể có biến thứ ba gây ra cả hai | ⚠ ví dụ thiết bị cũ vừa hay hỏng vừa khó bảo trì |
| ⚠ Cần đủ số điểm dữ liệu | ⚠ vài điểm không kết luận được gì |
| ⚠ Bước tiếp theo đúng | ⚠ thấy tương quan thì dùng Ishikawa và 5 Whys để tìm cơ chế nhân quả thật |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đủ dữ liệu để vẽ không | ⚠ cần nhiều cặp quan sát | | Hai biến có được đo cùng điều kiện không | | | Bạn đang kết luận tương quan hay nhân quả | ⚠ hai chuyện rất khác nhau |
Và giá trị của công cụ này với tình huống của bạn: nó biến nghi ngờ thành giả thuyết kiểm chứng được. "Tôi nghi bảo trì ảnh hưởng chất lượng" là cảm tính; một đám mây điểm dốc xuống rõ ràng là cơ sở để đề xuất tăng tần suất bảo trì.
- A Deductive planning
- B Expressive planning
- C High-level planning
- D Rolling wave planning
Xem giải thích
Đáp án
D — Rolling wave planning (lập kế hoạch theo đợt sóng).
Vì sao đúng
⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Xác định CHI TIẾT công việc của tháng tới | ⚠ → phần GẦN được lập kế hoạch kỹ | | ⚠ Phần sau tháng này để "chi tiết hoá SAU" | ⚠ → phần XA để ở mức thô | | ⚠ Kết luận | ⚠ đúng định nghĩa rolling wave planning |
⚠ Rolling wave planning: | Đặc điểm | Nội dung | |---|---| | ⚠ Là một DẠNG cụ thể của progressive elaboration | | | ⚠ Lập kế hoạch chi tiết cho khoảng thời gian NGẮN sắp tới | | | ⚠ Để phần xa ở mức khái quát | ⚠ chính là planning package trong WBS | | ⚠ Chi tiết hoá dần khi tới gần | | | ⚠ Dùng khi | ⚠ dự án dài, môi trường thay đổi, thông tin chưa đủ cho toàn bộ vòng đời |
Vì sao các phương án khác sai
-
C (High-level planning) — ⚠ mô tả MỨC ĐỘ chi tiết, ⚠ không phải một phương pháp lập kế hoạch có tên; ⚠ và Wendy đang lập kế hoạch CHI TIẾT cho tháng tới chứ không phải chỉ ở mức cao.
-
A (Deductive planning) và B (Expressive planning) — ⚠ không phải thuật ngữ PMBOK.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25627 ở lô 177 về planning package và câu #25671 ở lô 178 về progressive elaboration. ⚠ Ba câu là ba mặt của cùng một ý tưởng: WBS có chỗ để phần chưa rõ (planning package), nguyên tắc chung là chi tiết hoá dần (progressive elaboration), và cách làm cụ thể là rolling wave.
⚠ Phân biệt ba khái niệm: | Khái niệm | Nghĩa | |---|---| | ⚠ Progressive elaboration | ⚠ NGUYÊN TẮC: làm rõ dần theo thời gian | | ⚠ Rolling wave planning | ⚠ KỸ THUẬT cụ thể: chi tiết phần gần, thô phần xa | | ⚠ Planning package | ⚠ THÀNH PHẦN trong WBS chứa phần chưa phân rã |
Từ khoá nhận diện:
"chi tiết phần sắp tới, phần sau tính sau" → ⚠ rolling wave planning "làm rõ dần khi có thêm thông tin" → ⚠ progressive elaboration "nút WBS chưa phân rã tới gói công việc" → ⚠ planning package "chia gói công việc thành hoạt động" → ⚠ decomposition
| ⚠ Ưu và nhược của rolling wave | Điều |
|---|---|
| ⚠ ƯU: không lãng phí công lập kế hoạch cho thứ sẽ đổi | |
| ⚠ ƯU: kế hoạch gần luôn sát thực tế | |
| ⚠ ƯU: phù hợp môi trường biến động | |
| ⚠ NHƯỢC: khó đưa ra cam kết dài hạn về chi phí và ngày | |
| ⚠ NHƯỢC: bên liên quan có thể tưởng đội chưa chuẩn bị gì | |
| ⚠ Cách bù nhược điểm | ⚠ giải thích rõ đây là phương pháp có chủ đích, và cam kết dài hạn ở mức DẢI chứ không phải con số đơn |
| ⚠ Chọn độ dài "đợt sóng" thế nào | Nguyên tắc |
|---|---|
| ⚠ Đủ dài để đội có tầm nhìn làm việc | |
| ⚠ Đủ ngắn để thông tin còn đáng tin | |
| ⚠ Thường một tới ba tháng ở dự án dự đoán | ⚠ Wendy chọn một tháng |
| ⚠ Trong agile: một vòng lặp | ⚠ thường 1–4 tuần |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đang ép chi tiết cho phần quá xa không | ⚠ đó là lãng phí và tạo cảm giác chắc chắn giả | | Đã có lịch chi tiết hoá các đợt sau chưa | ⚠ rolling wave cần nhịp rà soát định kỳ | | Bên liên quan có hiểu vì sao phần xa còn thô không | |
Và điều khiến kỹ thuật này khác với "lập kế hoạch cẩu thả": phần xa để thô là QUYẾT ĐỊNH CÓ CHỦ ĐÍCH, kèm lịch cụ thể để chi tiết hoá nó. Thiếu vế sau thì đúng là cẩu thả thật.
- A Technical review board
- B Project steering group
- C Business analysis
- D Murder board
Xem giải thích
Đáp án
D — Murder board (hội đồng chất vấn).
Vì sao đúng
⚠ Murder board là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Một hội đồng chất vấn NGƯỜI TRÌNH BÀY rất gay gắt | | | ⚠ Hỏi xoáy về chi phí, tính khả thi, khả năng thành công, rủi ro | ⚠ đúng những gì đề liệt kê | | ⚠ Mục đích: tìm ra mọi điểm yếu TRƯỚC khi cam kết nguồn lực | | | ⚠ Là một phương pháp CHỌN DỰ ÁN | ⚠ project selection method | | ⚠ Kết quả | ⚠ quyết định Go / No-Go về việc có ban hành điều lệ dự án hay không |
Vì sao các phương án khác sai
-
B (Project steering group — ban chỉ đạo dự án) — ⚠ là nhóm GIÁM SÁT dự án ĐANG chạy, ⚠ không phải hội đồng chất vấn để quyết định có khởi tạo dự án hay không.
-
A (Technical review board) — ⚠ rà soát khía cạnh KỸ THUẬT, ⚠ trong khi đề nói tới chi phí, khả thi và xác suất thành công — tức góc nhìn kinh doanh.
-
C (Business analysis) — ⚠ là một lĩnh vực công việc, ⚠ không phải một loại cuộc họp.
Ghi nhớ
Từ khoá nhận diện:
"chất vấn gay gắt, tìm điểm yếu, quyết định Go/No-Go" → ⚠ murder board "giám sát dự án đang chạy" → ⚠ steering committee "phê duyệt hoặc từ chối yêu cầu thay đổi" → ⚠ change control board (CCB) "rà soát cuối giai đoạn" → ⚠ phase gate / stage gate review
| ⚠ Các phương pháp chọn dự án | Phương pháp |
|---|---|
| ⚠ Benefit measurement — đo lợi ích | ⚠ so sánh, chấm điểm, mô hình kinh tế |
| ⚠ NPV, IRR, payback period, BCR | ⚠ mô hình kinh tế định lượng |
| ⚠ Scoring model | ⚠ chấm điểm nhiều tiêu chí có trọng số |
| ⚠ Murder board | ⚠ chất vấn để lộ điểm yếu |
| ⚠ Peer review | ⚠ đồng nghiệp rà soát |
| ⚠ Constrained optimization | ⚠ mô hình toán học, quy hoạch tuyến tính — dùng cho danh mục lớn |
| ⚠ Bốn hội đồng dễ lẫn nhau | Hội đồng |
|---|---|
| ⚠ Murder board | ⚠ TRƯỚC khi dự án tồn tại — có nên làm không |
| ⚠ Change Control Board (CCB) | ⚠ TRONG dự án — có duyệt thay đổi không |
| ⚠ Steering committee | ⚠ TRONG dự án — định hướng và gỡ vướng |
| ⚠ Phase gate review | ⚠ CUỐI giai đoạn — có đi tiếp không |
| ⚠ Vì sao murder board có giá trị | Lý do |
|---|---|
| ⚠ Người đề xuất luôn LẠC QUAN về dự án của mình | |
| ⚠ Điểm yếu lộ ra TRƯỚC khi tiêu tiền thì rẻ hơn nhiều | |
| ⚠ Ép người đề xuất chuẩn bị kỹ | |
| ⚠ Buộc phải trả lời câu hỏi khó thay vì né tránh | |
| ⚠ Rủi ro của phương pháp | ⚠ quá gay gắt có thể loại cả những ý tưởng tốt nhưng người trình bày kém tự tin |
| ⚠ Ned nên chuẩn bị gì | Chuẩn bị |
|---|---|
| ⚠ Business case đầy đủ với số liệu kiểm chứng được | |
| ⚠ Ước lượng chi phí KÈM dải sai số và giả định | |
| ⚠ Danh sách rủi ro lớn và cách ứng phó | |
| ⚠ Các phương án thay thế đã cân nhắc | |
| ⚠ Câu trả lời cho câu hỏi "nếu không làm dự án này thì sao?" |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn có cơ chế thử thách đề xuất trước khi duyệt không | | | Đề xuất của bạn đã tự chất vấn chưa | ⚠ tìm điểm yếu trước khi người khác tìm hộ | | Số liệu bạn đưa ra có nguồn không | |
Và tinh thần của phương pháp này: thà "giết" một đề xuất trên bàn họp còn hơn để nó chết giữa chừng sau khi đã tiêu vài tỷ. Cái tên nghe hung hãn nhưng mục đích là bảo vệ tổ chức khỏi dự án không đáng làm.
- A 1
- B 0.96
- C 1.1
- D 0.75
Xem giải thích
Đáp án
B — 0,96.
Vì sao đúng
⚠ Bóc tách dữ liệu: | Đại lượng | Cách tính | Kết quả | |---|---|---| | ⚠ BAC — ngân sách hoàn thành | ⚠ đề cho | ⚠ 1.250.650 | | ⚠ EV — giá trị thu được | ⚠ BAC × 65% hoàn thành THỰC TẾ | ⚠ 1.250.650 × 0,65 = 812.922,5 | | ⚠ PV — giá trị kế hoạch | ⚠ BAC × 75% đáng lẽ phải xong | ⚠ 1.250.650 × 0,75 = 937.987,5 | | ⚠ AC — chi phí thực tế | ⚠ đề cho | ⚠ 847.500 |
⚠ Tính CPI: | Bước | Phép tính | |---|---| | ⚠ CPI = EV / AC | | | ⚠ = 812.922,5 / 847.500 | | | ⚠ = 0,9592... | ⚠ ≈ 0,96 | | ⚠ Nghĩa là | ⚠ cứ 1 đồng chi ra chỉ đổi được 0,96 đồng giá trị — vượt chi khoảng 4% |
Vì sao các phương án khác sai
-
A (1) — ⚠ nghĩa là đúng ngân sách; ⚠ nhưng đề nói rõ "đã chi HƠI NHIỀU HƠN kế hoạch" nên CPI phải nhỏ hơn 1.
-
C (1,1) — ⚠ lớn hơn 1 nghĩa là TIẾT KIỆM, ⚠ trái với đề bài.
-
D (0,75) — ⚠ là con số 75% trong đề, ⚠ không phải kết quả phép chia nào.
Ghi nhớ
Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG với câu #25581 ở lô 176. ⚠ Hai đề bài ⚠ giống nhau TỪNG CHỮ ⚠ (cùng ngân sách 1.250.650, cùng 65% và 75%, cùng chi 847.500), ⚠ chỉ khác đúng câu hỏi cuối cùng: ⚠ câu #25581 hỏi ⚠ CHÊNH LỆCH CHI PHÍ (CV) ⚠ với đáp án ⚠ (34.578), ⚠ còn câu này hỏi ⚠ CHỈ SỐ HIỆU SUẤT CHI PHÍ (CPI) ⚠ với đáp án ⚠ 0,96. ⚠ Hàm băm MD5 không phát hiện được vì một câu chữ khác nhau. Cả hai khoá đáp án đều ĐÚNG và KHÔNG mâu thuẫn — chỉ là hai câu hỏi khác nhau trên cùng một bộ số. Giữ nguyên cả hai.
⚠ Toàn bộ chỉ số của bộ số này — tính một lần dùng cho cả hai câu: | Chỉ số | Phép tính | Kết quả | |---|---|---| | ⚠ EV | ⚠ 1.250.650 × 0,65 | ⚠ 812.922,5 | | ⚠ PV | ⚠ 1.250.650 × 0,75 | ⚠ 937.987,5 | | ⚠ AC | ⚠ đề cho | ⚠ 847.500 | | ⚠ CV = EV − AC | ⚠ 812.922,5 − 847.500 | ⚠ −34.577,5 ≈ (34.578) — đáp án câu #25581 | | ⚠ SV = EV − PV | ⚠ 812.922,5 − 937.987,5 | ⚠ −125.065 — chính là phương án D của câu #25581 | | ⚠ CPI = EV / AC | ⚠ 812.922,5 / 847.500 | ⚠ 0,959 ≈ 0,96 — ĐÁP ÁN CÂU NÀY | | ⚠ SPI = EV / PV | ⚠ 812.922,5 / 937.987,5 | ⚠ 0,867 | | ⚠ EAC = BAC / CPI | ⚠ 1.250.650 / 0,959 | ⚠ ≈ 1.303.849 | | ⚠ VAC = BAC − EAC | | ⚠ ≈ −53.199 — chính là phương án B của câu #25581 |
⚠ Nhận xét quan trọng: ⚠ các phương án nhiễu của hai câu này chính là các chỉ số KHÁC của cùng bộ số — ⚠ SV làm nhiễu cho CV, VAC làm nhiễu cho CV. ⚠ Đây là kiểu soạn đề rất hay gặp: mọi phương án đều là con số "đúng" nhưng của một chỉ số khác.
Từ khoá nhận diện:
"chỉ số hiệu suất" → ⚠ TỶ SỐ quanh 1, loại ngay phương án là số tiền "chênh lệch" → ⚠ SỐ TIỀN, có dấu âm hoặc dương "chi nhiều hơn kế hoạch" → ⚠ CPI < 1 và CV âm "làm được ít hơn kế hoạch" → ⚠ SPI < 1 và SV âm
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đề hỏi chỉ số hay chênh lệch | ⚠ quyết định đáp án là tỷ số hay số tiền | | Đề hỏi chi phí hay tiến độ | ⚠ CPI/CV dùng AC, SPI/SV dùng PV | | Kết quả có khớp mô tả định tính trong đề không | ⚠ "chi nhiều hơn" thì CPI phải < 1 |
Và mẹo tự kiểm nhanh nhất trong phòng thi: đọc mô tả định tính trước rồi mới tính. Đề đã nói "chi nhiều hơn kế hoạch" nên loại ngay hai phương án ≥ 1, chỉ còn phải chọn giữa 0,96 và 0,75.
- A Adaptive planning
- B Agile project management
- C Adaptive project management life cycle
- D Predictive project management lifecycle
Xem giải thích
Đáp án
D — Predictive project management lifecycle (vòng đời quản lý dự án dự đoán).
Vì sao đúng
⚠ Ba dấu hiệu quyết định trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Khách hàng đã ĐỊNH NGHĨA TOÀN BỘ yêu cầu | ⚠ → phạm vi đã chốt từ đầu | | ⚠ Có SOW mô tả CHÍNH XÁC điều được kỳ vọng | ⚠ → đầu ra đã rõ ràng | | ⚠ Lập kế hoạch cho TOÀN BỘ công việc, và CHỈ công việc cần thiết | ⚠ → lập kế hoạch trọn gói ngay từ đầu | | ⚠ Kết luận | ⚠ đúng đặc trưng của vòng đời dự đoán, còn gọi waterfall hoặc plan-driven |
Vì sao các phương án khác sai
⚠ Cả ba phương án còn lại đều mô tả cách tiếp cận THÍCH ỨNG — ngược hẳn tình huống:
-
A (Adaptive planning), C (Adaptive project management life cycle) — ⚠ phạm vi để MỞ, chi tiết hoá dần qua các vòng lặp; ⚠ ở đây phạm vi đã chốt đầy đủ.
-
B (Agile project management) — ⚠ cũng thuộc nhóm thích ứng, ⚠ dùng khi yêu cầu còn biến động và cần phản hồi sớm.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25674 ở lô 178 về vòng đời thích ứng — ⚠ ở đó Validate Scope và Control Scope lặp lại mỗi vòng. ⚠ Hai câu là cặp đối lập hoàn chỉnh giữa dự đoán và thích ứng.
⚠ Bốn loại vòng đời dự án theo PMBOK: | Vòng đời | Phạm vi | Bàn giao | Mục tiêu | |---|---|---|---| | ⚠ Predictive — dự đoán | ⚠ chốt SỚM | ⚠ một lần ở cuối | ⚠ quản lý CHI PHÍ | | ⚠ Iterative — lặp | ⚠ chốt sớm nhưng tinh chỉnh qua các vòng | ⚠ một lần ở cuối | ⚠ giải pháp ĐÚNG hơn | | ⚠ Incremental — tăng dần | ⚠ chốt sớm | ⚠ NHIỀU lần, mỗi lần thêm chức năng | ⚠ TỐC ĐỘ giao hàng | | ⚠ Adaptive / Agile | ⚠ MỞ, chi tiết hoá dần | ⚠ thường xuyên, mỗi vòng lặp | ⚠ PHẢN HỒI và thích ứng thay đổi | | ⚠ Hybrid | ⚠ kết hợp | ⚠ tuỳ phần của dự án | ⚠ thực tế nhất trong nhiều tổ chức |
Từ khoá nhận diện:
"yêu cầu chốt đầy đủ từ đầu" → ⚠ predictive "phạm vi mở, backlog sắp lại ưu tiên" → ⚠ adaptive / agile "giao từng phần chức năng dùng được" → ⚠ incremental "làm đi làm lại để tinh chỉnh giải pháp" → ⚠ iterative "chỉ làm công việc cần thiết, không hơn" → ⚠ nguyên tắc chống gold plating, áp dụng ở mọi vòng đời
| ⚠ Khi nào chọn vòng đời dự đoán | Điều kiện |
|---|---|
| ⚠ Yêu cầu ỔN ĐỊNH và đã hiểu rõ | |
| ⚠ Công nghệ quen thuộc, ít bất định | |
| ⚠ Đã làm loại dự án này nhiều lần | |
| ⚠ Có hợp đồng giá cố định với phạm vi rõ | ⚠ SOW của tình huống này |
| ⚠ Chi phí thay đổi giữa chừng RẤT CAO | ⚠ xây dựng, hạ tầng, sản xuất |
| ⚠ Rủi ro | ⚠ nếu yêu cầu thực ra CHƯA rõ thì chốt sớm sẽ rất đắt để sửa |
| ⚠ Đặc điểm quản trị của vòng đời dự đoán | Đặc điểm |
|---|---|
| ⚠ Có ĐƯỜNG CƠ SỞ phạm vi, lịch, chi phí | |
| ⚠ Thay đổi phải qua kiểm soát thay đổi CHÍNH THỨC | |
| ⚠ Đo hiệu suất bằng EVM | ⚠ CPI, SPI, EAC |
| ⚠ Nghiệm thu dồn về cuối giai đoạn | |
| ⚠ So với agile | ⚠ agile coi thay đổi là bình thường; dự đoán coi thay đổi là ngoại lệ cần kiểm soát |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu có thật sự ổn định không | ⚠ khách nói "đã đủ" chưa chắc là đã đủ | | Chi phí sửa đổi giữa chừng cao tới đâu | | | Tổ chức có kinh nghiệm với loại dự án này chưa | |
Và câu hỏi duy nhất để chọn vòng đời: "chúng ta biết rõ phải làm gì tới mức nào?". Biết rõ thì dự đoán; còn mơ hồ thì càng chốt sớm càng đắt.
- A Sole source
- B Single source
- C Preferred source
- D Oligopoly
Xem giải thích
Đáp án
B — Single source (một nguồn được chọn).
Vì sao đúng
⚠ Phân biệt hai thuật ngữ: | Thuật ngữ | Nghĩa | |---|---| | ⚠ Single source | ⚠ CÓ nhiều nhà cung cấp trên thị trường, nhưng ta CHỌN đúng một | | ⚠ Sole source | ⚠ CHỈ CÓ MỘT nhà cung cấp duy nhất bán được thứ này |
⚠ Đề nói gì: | Chi tiết | Suy ra | |---|---| | ⚠ "đắt hơn các ĐỐI THỦ một chút" | ⚠ → thị trường CÓ đối thủ, tức có lựa chọn khác | | ⚠ "bạn THÍCH làm việc với nhà cung cấp này" | ⚠ → đây là LỰA CHỌN, không phải bắt buộc | | ⚠ Lý do: giao đúng hạn, dễ làm việc, hỗ trợ tốt | | | ⚠ Kết luận | ⚠ có lựa chọn mà vẫn chỉ chọn một → single source |
Vì sao các phương án khác sai
-
A (Sole source) — ⚠ SAI vì đề nói rõ có đối thủ cạnh tranh.
-
C (Preferred source) — ⚠ không phải thuật ngữ PMBOK, ⚠ dù nghe rất hợp với "bạn ưa thích".
-
D (Oligopoly — độc quyền nhóm) — ⚠ là khái niệm về CẤU TRÚC THỊ TRƯỜNG: ⚠ một nhóm nhỏ người bán chi phối; ⚠ không mô tả lựa chọn của bạn.
Ghi nhớ
Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG với câu #25618 ở lô 177 ⚠ (John và công ty JH Goods). ⚠ Hai đề ⚠ khác bối cảnh và khác thứ tự phương án nhưng hỏi CHÍNH XÁC cùng một khái niệm và có CÙNG khoá đáp án "single source". ⚠ Hàm băm MD5 không bắt được vì lời văn khác nhau. ⚠ Hai khoá KHÔNG mâu thuẫn — giữ nguyên cả hai. ⚠ Điểm khác nhỏ: ⚠ câu #25618 có phương án nhiễu "Preferred vendor", câu này đổi thành "Preferred source" — ⚠ cả hai đều là phương án bịa. ⚠ Lưu ý thứ tự chữ cái đã bị xáo: ở #25618 đáp án là C, ở câu này là B.
Từ khoá nhận diện:
"chỉ có một nơi bán được" → ⚠ sole source "có nhiều nơi nhưng ta chọn một" → ⚠ single source "vài người bán chi phối thị trường" → ⚠ oligopoly "một người bán duy nhất, không thay thế được" → ⚠ monopoly "chỉ có một người mua" → ⚠ monopsony
| ⚠ Rủi ro của single source | Rủi ro |
|---|---|
| ⚠ Trả giá cao hơn thị trường | ⚠ đề nói rõ nhà cung cấp này đắt hơn |
| ⚠ Mất năng lực đàm phán | |
| ⚠ Phụ thuộc: nhà cung cấp gặp sự cố là dự án đứng | |
| ⚠ Có thể vi phạm quy định mua sắm nội bộ | ⚠ nhiều tổ chức bắt mời thầu cạnh tranh |
| ⚠ Cách giảm | ⚠ ghi rõ lý do bằng văn bản và xin phê duyệt của người có thẩm quyền |
| ⚠ Khi nào chọn single source là hợp lý | Trường hợp |
|---|---|
| ⚠ Rủi ro giao trễ quan trọng hơn chênh lệch giá | ⚠ lý do trong đề |
| ⚠ Chi phí chuyển đổi nhà cung cấp cao | |
| ⚠ Cần tương thích với thứ đã mua trước | |
| ⚠ Thời gian gấp, không kịp mời thầu | |
| ⚠ Luôn phải | ⚠ ghi lý do vào hồ sơ mua sắm để giải trình sau này |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thị trường còn ai bán thứ này không | ⚠ quyết định single hay sole | | Lý do chọn đã ghi thành văn bản chưa | | | Chênh lệch giá có được bù bởi giá trị thật không | ⚠ giao đúng hạn cũng là tiền |
Và mẹo nhớ hai từ dễ lẫn nhất: sole = duy nhất (không còn ai khác), single = đơn lẻ (ta chỉ chọn một). Có đối thủ trên thị trường thì luôn là single, không bao giờ là sole.
- A Avoidance
- B Accelerate
- C Withdrawal
- D Mitigation
Xem giải thích
Đáp án
A — Avoidance (né tránh).
Vì sao đúng
⚠ Vì sao né tránh là chiến lược phù hợp nhất ở đây: | Chi tiết trong đề | Suy ra | |---|---| | ⚠ Rủi ro có XÁC SUẤT XẢY RA CAO | | | ⚠ Hậu quả: dự án nhiều khả năng THẤT BẠI | ⚠ tác động ở mức nghiêm trọng nhất | | ⚠ Rủi ro xác suất cao + tác động huỷ diệt | ⚠ → không nên chỉ giảm nhẹ, phải LOẠI BỎ hẳn | | ⚠ Né tránh nghĩa là | ⚠ thay đổi kế hoạch dự án để rủi ro KHÔNG CÒN KHẢ NĂNG xảy ra |
⚠ Cách né tránh trong thực tế: | Cách | Ví dụ | |---|---| | ⚠ Đổi phương án kỹ thuật | ⚠ dùng công nghệ đã kiểm chứng thay vì công nghệ mới | | ⚠ Thu hẹp phạm vi | ⚠ bỏ phần chứa rủi ro | | ⚠ Kéo dài lịch trình | ⚠ bỏ áp lực thời gian gây rủi ro | | ⚠ Làm rõ yêu cầu để loại bất định | | | ⚠ Trường hợp cực đoan: HUỶ dự án | ⚠ cũng là một hình thức né tránh |
Vì sao các phương án khác sai
- B (Accelerate — tăng tốc) và C (Withdrawal — rút lui) — ⚠ KHÔNG phải chiến lược ứng phó rủi ro của PMBOK; ⚠ "withdrawal" là một kỹ thuật giải quyết XUNG ĐỘT, không phải ứng phó rủi ro.
Ghi nhớ
Ghi nhớ về chất lượng câu hỏi: ⚠ Phương án D ("Mitigation" — giảm nhẹ) CŨNG là một chiến lược ứng phó rủi ro hợp lệ của PMBOK, ⚠ và đề chỉ hỏi ⚠ "chiến lược nào CÓ THỂ xử lý rủi ro này" ⚠ chứ không hỏi "chiến lược TỐT NHẤT". ⚠ Theo cách đọc chặt chẽ thì cả A lẫn D đều đúng — ⚠ chỉ B và C là sai vì không phải chiến lược ứng phó rủi ro. ⚠ Giữ nguyên khoá A vì với rủi ro ⚠ xác suất cao + có thể làm dự án THẤT BẠI, ⚠ né tránh là lựa chọn mạnh và phù hợp nhất; ⚠ giảm nhẹ chỉ làm rủi ro nhỏ đi chứ không loại bỏ khả năng dự án sụp. ⚠ Khi thi, nếu đề có cả avoidance lẫn mitigation, hãy đọc mức độ nghiêm trọng: hậu quả huỷ diệt thì chọn né tránh, hậu quả chịu được thì chọn giảm nhẹ.
⚠ Chiến lược ứng phó với MỐI ĐE DOẠ (rủi ro tiêu cực): | Chiến lược | Nghĩa | Khi nào | |---|---|---| | ⚠ Avoid — né tránh | ⚠ LOẠI BỎ khả năng xảy ra | ⚠ rủi ro nghiêm trọng, không chấp nhận được | | ⚠ Transfer — chuyển giao | ⚠ chuyển hậu quả sang bên thứ ba | ⚠ bảo hiểm, hợp đồng giá cố định, bảo lãnh | | ⚠ Mitigate — giảm nhẹ | ⚠ giảm XÁC SUẤT hoặc giảm TÁC ĐỘNG | ⚠ rủi ro chịu được sau khi giảm | | ⚠ Accept — chấp nhận | ⚠ không hành động, hoặc lập dự phòng | ⚠ rủi ro nhỏ, hoặc chi phí xử lý quá cao | | ⚠ Escalate — leo thang | ⚠ chuyển lên cấp cao hơn vì vượt thẩm quyền dự án | ⚠ PMBOK 6 thêm vào |
⚠ Chiến lược với CƠ HỘI (rủi ro tích cực) — đối xứng: | Chiến lược | Nghĩa | |---|---| | ⚠ Exploit — khai thác | ⚠ đảm bảo cơ hội CHẮC CHẮN xảy ra — đối xứng với avoid | | ⚠ Share — chia sẻ | ⚠ hợp tác với bên có khả năng nắm bắt tốt hơn — đối xứng với transfer | | ⚠ Enhance — tăng cường | ⚠ tăng xác suất hoặc tác động — đối xứng với mitigate | | ⚠ Accept — chấp nhận | ⚠ không chủ động làm gì | | ⚠ Escalate — leo thang | |
Từ khoá nhận diện:
"loại bỏ hẳn khả năng xảy ra" → ⚠ avoid "mua bảo hiểm, ký hợp đồng giá cố định" → ⚠ transfer "giảm xác suất hoặc giảm mức thiệt hại" → ⚠ mitigate "lập dự phòng và theo dõi" → ⚠ accept chủ động "vượt thẩm quyền dự án" → ⚠ escalate
| ⚠ Ai quyết định né tránh | Điều |
|---|---|
| ⚠ Né tránh thường đòi ĐỔI phạm vi, lịch hoặc phương án | |
| ⚠ Nghĩa là phải qua kiểm soát thay đổi | |
| ⚠ Nhà tài trợ tham gia quyết định | ⚠ đúng như đề nói: bạn họp với nhà tài trợ |
| ⚠ PM một mình | ⚠ không tự đổi đường cơ sở được |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Rủi ro này ở ô nào của ma trận xác suất – tác động | ⚠ quyết định mức độ quyết liệt của phản ứng | | Né tránh có tạo ra rủi ro MỚI không | ⚠ secondary risk — phải đánh giá lại | | Sau khi ứng phó còn rủi ro tồn dư bao nhiêu | ⚠ residual risk — phải ghi nhận và theo dõi |
Và nguyên tắc chọn chiến lược: mức độ phản ứng phải tương xứng với mức độ rủi ro. Rủi ro có thể làm dự án thất bại thì giảm nhẹ là chưa đủ — phải làm cho nó không còn xảy ra được nữa.
- A Sideward
- B Inward
- C Upward
- D Downward
Xem giải thích
Đáp án
B — Inward (hướng vào trong). ⚠ Không có hướng này trong mô hình.
Vì sao đúng
⚠ Bốn hướng ảnh hưởng của bên liên quan theo PMBOK: | Hướng | Nghĩa | Ví dụ | |---|---|---| | ⚠ Upward — LÊN TRÊN | ⚠ lãnh đạo cấp cao của tổ chức và của khách hàng | ⚠ nhà tài trợ, ban điều hành | | ⚠ Downward — XUỐNG DƯỚI | ⚠ đội ngũ và chuyên gia đóng góp kiến thức, kỹ năng | ⚠ thành viên đội dự án | | ⚠ Outward — RA NGOÀI | ⚠ các nhóm bên ngoài đội dự án | ⚠ nhà cung cấp, cơ quan quản lý, người dùng cuối, cơ quan tài chính | | ⚠ Sideward — SANG NGANG | ⚠ đồng cấp của quản lý dự án | ⚠ các quản lý dự án khác cạnh tranh nguồn lực | | ⚠ "Inward" | ⚠ KHÔNG tồn tại — phương án bịa |
Vì sao các phương án khác sai
- A (Sideward), C (Upward), D (Downward) — ⚠ cả ba ĐỀU là hướng ảnh hưởng hợp lệ.
Ghi nhớ
⚠ Vì sao "sideward" quan trọng mà hay bị quên: | Điều | Nội dung | |---|---| | ⚠ Là các quản lý dự án ĐỒNG CẤP | | | ⚠ Họ CẠNH TRANH cùng nguồn lực với bạn | ⚠ cùng một nhân sự giỏi, cùng ngân sách, cùng sự chú ý của lãnh đạo | | ⚠ Cũng có thể là đối tác hoặc nguồn hỗ trợ | | | ⚠ Bỏ qua họ | ⚠ là nguồn xung đột nguồn lực phổ biến nhất trong tổ chức ma trận |
⚠ Các mô hình phân loại bên liên quan: | Mô hình | Trục phân loại | |---|---| | ⚠ Power/Interest grid | ⚠ quyền lực × mức quan tâm | | ⚠ Power/Influence grid | ⚠ quyền lực × mức ảnh hưởng | | ⚠ Impact/Influence grid | ⚠ khả năng tác động × mức ảnh hưởng | | ⚠ Salience model | ⚠ quyền lực × tính cấp bách × tính chính danh | | ⚠ Direction of influence | ⚠ lên, xuống, ngang, ra ngoài — MÔ HÌNH CỦA CÂU NÀY | | ⚠ Prioritization | ⚠ xếp ưu tiên khi số bên liên quan quá lớn |
Từ khoá nhận diện:
"bốn hướng ảnh hưởng" → ⚠ upward, downward, outward, sideward "quyền lực và mức quan tâm" → ⚠ power/interest grid "quyền lực, cấp bách, chính danh" → ⚠ salience model "dự án lớn, quá nhiều bên liên quan" → ⚠ cần phân loại và xếp ưu tiên
| ⚠ Vì sao mô hình bốn hướng hữu ích với dự án LỚN | Lý do |
|---|---|
| ⚠ Dễ hiểu, không cần chấm điểm phức tạp | |
| ⚠ Gợi ý ngay CÁCH giao tiếp cho từng nhóm | |
| ⚠ Nhắc PM đừng chỉ nhìn lên trên | ⚠ rất nhiều PM chỉ chăm chăm báo cáo cấp trên |
| ⚠ Đề nói rõ | ⚠ "dự án lớn này" — càng nhiều bên liên quan càng cần khung phân loại |
| ⚠ Cách giao tiếp phù hợp cho từng hướng | Cách |
|---|---|
| ⚠ Upward | ⚠ ngắn gọn, tập trung vào tác động kinh doanh và quyết định cần xin |
| ⚠ Downward | ⚠ chi tiết, rõ việc, rõ kỳ vọng |
| ⚠ Outward | ⚠ chính thức, có văn bản, tuân thủ hợp đồng và quy định |
| ⚠ Sideward | ⚠ thương lượng, xây quan hệ, minh bạch về nhu cầu nguồn lực |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có bỏ sót nhóm nào trong bốn hướng không | ⚠ sideward và outward hay bị quên nhất | | Kế hoạch giao tiếp có phân biệt theo nhóm không | | | Sổ đăng ký bên liên quan có cập nhật không | ⚠ bên liên quan thay đổi suốt vòng đời dự án |
Và giá trị thực dụng của mô hình này: nó buộc bạn ngẩng đầu nhìn quanh, không chỉ nhìn lên. Rất nhiều dự án hỏng không phải vì lãnh đạo phản đối mà vì một đồng nghiệp ngang cấp rút mất người vào phút chót.
- A Control chart
- B Pareto chart
- C Histogram
- D Cause-and-effect chart
Xem giải thích
Đáp án
B — Pareto chart (biểu đồ Pareto).
Vì sao đúng
⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Biểu đồ về các KHUYẾT TẬT theo LOẠI | | | ⚠ Xếp từ loại NHIỀU NHẤT tới loại ÍT NHẤT | ⚠ → đặc trưng riêng của Pareto | | ⚠ Mục đích: tấn công nhóm lỗi lớn nhất qua các đợt cải tiến | ⚠ → đúng tinh thần nguyên lý 80/20 | | ⚠ Kết luận | ⚠ biểu đồ Pareto — một dạng histogram có sắp xếp |
Vì sao các phương án khác sai
-
C (Histogram) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ Pareto ĐÚNG là một dạng histogram, ⚠ nhưng ⚠ histogram thường KHÔNG sắp xếp theo thứ tự giảm dần ⚠ và không có đường luỹ kế; ⚠ đề nhấn mạnh việc xếp hạng nên phải chọn Pareto.
-
D (Cause-and-effect chart) — ⚠ là biểu đồ xương cá tìm nguyên nhân gốc, ⚠ không xếp hạng theo tần suất.
-
A (Control chart) — ⚠ theo dõi một biến theo thời gian để xem quy trình có ổn định không.
Ghi nhớ
Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG với câu #25626 ở lô 177 ⚠ — cùng hỏi loại biểu đồ xếp hạng khuyết tật từ lớn tới nhỏ, ⚠ cùng khoá đáp án Pareto, ⚠ chỉ khác lời văn nên MD5 không bắt được. ⚠ Hai khoá KHÔNG mâu thuẫn — giữ nguyên cả hai. ⚠ Điểm khác đáng chú ý: ⚠ câu #25626 có LỖI SOẠN ĐỀ — nó đặt "Ishikawa chart" và "Cause-and-effect chart" thành HAI phương án riêng dù là cùng một công cụ. ⚠ Câu này đã sửa được lỗi đó, chỉ để một phương án "Cause-and-effect chart". ⚠ Lưu ý ⚠ thứ tự chữ cái đã xáo: ở #25626 đáp án là A, ở câu này là B.
⚠ Pareto chart: | Đặc điểm | Nội dung | |---|---| | ⚠ Là histogram có các cột SẮP XẾP GIẢM DẦN | | | ⚠ Thường kèm ĐƯỜNG LUỸ KẾ phần trăm | | | ⚠ Dựa trên nguyên lý 80/20 | ⚠ 80% vấn đề đến từ 20% nguyên nhân | | ⚠ Trả lời câu hỏi: nên sửa cái gì TRƯỚC | | | ⚠ Đầu vào | ⚠ dữ liệu từ check sheet / tally list |
Từ khoá nhận diện:
"xếp từ lớn tới nhỏ" → ⚠ Pareto "phân bố tần suất, không xếp hạng" → ⚠ histogram thường "vì sao lỗi xảy ra" → ⚠ Ishikawa / cause-and-effect "quy trình có ổn định không" → ⚠ control chart "hai biến có liên quan không" → ⚠ scatter diagram
| ⚠ Bộ ba công cụ dùng nối tiếp nhau | Bước |
|---|---|
| ⚠ 1. Check sheet | ⚠ ĐẾM số lần mỗi loại lỗi xảy ra |
| ⚠ 2. Pareto chart | ⚠ XẾP HẠNG để biết sửa cái nào trước |
| ⚠ 3. Ishikawa + 5 Whys | ⚠ TRUY nguyên nhân gốc của loại lỗi đứng đầu |
| ⚠ 4. Đề xuất và thực hiện cải tiến | |
| ⚠ 5. Vẽ lại Pareto sau một chu kỳ | ⚠ đúng ý "rounds of improvement" trong đề |
| ⚠ Lưu ý khi dùng Pareto | Lưu ý |
|---|---|
| ⚠ Đếm SỐ LƯỢNG lỗi hay đếm CHI PHÍ lỗi | ⚠ hai bảng xếp hạng có thể khác hẳn nhau |
| ⚠ Loại lỗi ít nhưng cực đắt có thể quan trọng hơn loại nhiều mà rẻ | |
| ⚠ Cần dữ liệu đủ nhiều mới có ý nghĩa | |
| ⚠ Sau mỗi vòng cải tiến | ⚠ thứ hạng sẽ đổi — cột cũ giảm, cột khác lên đầu |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đang xếp hạng theo số lượng hay theo chi phí | | | Dữ liệu đếm có đáng tin không | ⚠ phân loại lỗi phải nhất quán giữa những người ghi | | Đã vẽ lại sau vòng cải tiến chưa | ⚠ để đo hiệu quả thật |
Và cách dùng đúng của công cụ này trong nhiều vòng cải tiến: mỗi vòng hãy dồn sức vào một tới hai cột cao nhất, rồi vẽ lại. Cố sửa mọi loại lỗi cùng lúc là cách chắc chắn nhất để không sửa được gì.
- A You do not have a schedule.
- B You do not have a project charter.
- C You do not have permission to use her resources.
- D You do not a budget to pay for the resources.
Xem giải thích
Đáp án
B — Bạn KHÔNG có điều lệ dự án (project charter).
Vì sao đúng
⚠ Điều lệ dự án làm gì: | Chức năng | Nội dung | |---|---| | ⚠ CHÍNH THỨC cho phép dự án tồn tại | | | ⚠ Bổ nhiệm quản lý dự án và nêu rõ THẨM QUYỀN của họ | ⚠ bao gồm quyền huy động nguồn lực của tổ chức | | ⚠ Do người có thẩm quyền BÊN NGOÀI dự án ban hành | ⚠ nhà tài trợ hoặc người khởi xướng | | ⚠ Là căn cứ để yêu cầu các phòng ban hợp tác | | | ⚠ Không có điều lệ | ⚠ Nancy hoàn toàn có lý khi không nhả người — chẳng có văn bản nào nói bà ấy phải làm vậy |
Vì sao các phương án khác sai
-
C (bạn không được phép dùng nguồn lực của bà ấy) — ⚠ mô tả TRIỆU CHỨNG chứ không phải NGUYÊN NHÂN; ⚠ câu hỏi là "nguyên nhân KHẢ DĨ NHẤT của vấn đề", ⚠ và nguyên nhân gốc là thiếu văn bản uỷ quyền chính thức.
-
A (bạn không có lịch trình) — ⚠ lịch trình có thể giúp thương lượng thời điểm, ⚠ nhưng không tạo ra thẩm quyền.
-
D (bạn không có ngân sách trả cho nguồn lực) — ⚠ có thể là vấn đề phụ, ⚠ nhưng ngay cả khi có tiền mà không có điều lệ thì vẫn thiếu cơ sở chính thức.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #25662 ở lô 178 — ⚠ đội báo cáo cho quản lý chức năng nên quyền của PM thấp; ⚠ và câu #25586 ở lô 177 về việc ⚠ điều lệ không nhất thiết do nhà tài trợ soạn. ⚠ Ba câu cùng chủ đề thẩm quyền của quản lý dự án.
⚠ Nội dung của điều lệ dự án: | Mục | Nội dung | |---|---| | ⚠ Mục đích dự án và lý do tồn tại | | | ⚠ Mục tiêu đo được và tiêu chí thành công | | | ⚠ Yêu cầu ở mức cao | | | ⚠ Mô tả dự án, ranh giới, bàn giao chính | | | ⚠ Rủi ro tổng thể | | | ⚠ Lịch mốc tóm tắt | | | ⚠ Nguồn lực tài chính được duyệt sơ bộ | | | ⚠ Danh sách bên liên quan | | | ⚠ Tiêu chí phê duyệt và kết thúc dự án | | | ⚠ QUẢN LÝ DỰ ÁN được bổ nhiệm, THẨM QUYỀN và trách nhiệm | ⚠ mục quyết định trong tình huống này | | ⚠ Người ban hành và thẩm quyền của họ | |
Từ khoá nhận diện:
"phòng ban không hợp tác, không nhả người" → ⚠ thường là thiếu điều lệ hoặc điều lệ không nêu rõ thẩm quyền "cho phép dự án tồn tại" → ⚠ điều lệ dự án "cho phép chi tiền và huy động nguồn lực" → ⚠ điều lệ dự án "nói rõ làm cái gì và làm thế nào" → ⚠ kế hoạch quản lý dự án, KHÔNG phải điều lệ
| ⚠ Bạn nên làm gì tiếp theo | Bước |
|---|---|
| ⚠ 1. Xin nhà tài trợ ban hành điều lệ dự án | ⚠ nếu chưa có |
| ⚠ 2. Đảm bảo điều lệ nêu RÕ thẩm quyền huy động nguồn lực | |
| ⚠ 3. Gửi điều lệ cho các quản lý chức năng liên quan | ⚠ kể cả Nancy |
| ⚠ 4. Thương lượng cụ thể về người và thời gian | ⚠ điều lệ mở cửa, thương lượng mới lấy được người |
| ⚠ 5. Ghi cam kết nguồn lực thành văn bản | |
| ⚠ Đừng | ⚠ leo thang lên cấp trên của Nancy trước khi thử hai bước đầu |
| ⚠ Vì sao điều lệ phải do người NGOÀI dự án ban hành | Lý do |
|---|---|
| ⚠ PM không thể tự trao quyền cho chính mình | |
| ⚠ Người ban hành phải có thẩm quyền cấp nguồn lực | |
| ⚠ Tạo tính chính danh trước toàn tổ chức | |
| ⚠ PM có thể | ⚠ SOẠN THẢO điều lệ, nhưng không PHÊ DUYỆT nó |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn đã có điều lệ được ký chưa | | | Điều lệ có nêu rõ thẩm quyền của bạn không | ⚠ không nêu thì mặc định là không có | | Các quản lý chức năng đã nhận được điều lệ chưa | ⚠ có điều lệ mà không ai biết thì cũng như không |
Và bài học nghề nghiệp: điều lệ dự án không phải thủ tục giấy tờ, nó là nguồn thẩm quyền duy nhất của bạn. Trong tổ chức ma trận, đó thường là thứ duy nhất phân biệt một dự án thật với một lời đề nghị lịch sự.