A significant point in the PMP exam is that you must follow the PMI standards for PM. Now, you have more experience in project management, even many years. But the PMP exam is challenging and very tricky. It’s all about scenario-based questions. And it would be best to have the PMI mindset to answer these questions. For example, when you manage a project in real life, you try to provide a solution to resolve it very quickly. But in the PMP exam, if you want to come to a solution, you must follow a proper process. This means not taking any shortcuts, that’s very important.

Project Manager’s Role:

1. PM should always be proactive, a servant leader, and a good steward:

• Team has been demotivated ➜ Find out why, then take action based on their personal motivations.
• Erring team members ➜ Remind the team about ground rule

2. Puts the team before themselves and demonstrates servant leadership. Servant Leader - don't give solutions; work with the team to help them come up with one. Shield team from interruptions.

3. The team self-organizes and self-assigns work. PM manages and develops the team according to every stage: Mô hình tuckman

4. Never bypass steps/processes/documentation to speed up delivery or closure.

5. Understand the needs of your team members and find out what may motivate them. Coach the team to handle/deal/resolve issues, and don't leave them alone to fend for themselves.

6. Provide a safe environment for disagreements. Do not punish anyone for having a difference of opinion.

7. PM does not hire, replace and/or fire resources. Coach the team members if they have problems.

8. PM manages conflicts. See more.

9. Make the customer’s success the primary goal.

10. Work with the customer to move the project forward and achieve the project objectives.

11. Never ask someone else to do work for you.

12. Never pass the problem to someone else.

13. Direct, in-person interaction is favored over email or other forms of indirect communication:

• Face-to-face communication is always the best unless the team is geographically dispersed, so you must settle with virtual meetings..
• Prefer co-location (if possible) for the benefits of osmotic communication within the team

14. Always add communication with the PO about the status of the project and customer in Sprint (Sprint is important for communication for both customers and the team).

15. Information should always be radiated through large charts and graphs. Information radiators include Scrum-board/Kanban Board, Burned-up/Burned-down, etc. Use inclusive tools like a whiteboard with a marker versus complex software

16. Consistently communicate and re-communicate the project vision to the team.

17. Make sure people understand what failure and success will look like on the project.

18. Be a central figure to the team, not a dictator. Have good ethical values.

19. Try to limit the work in progress through the use of Kanban. See more.

20. Review the methods work completed by doing a retrospective.

21. Utilize feedback loops. Feedback loops occur when you’ve completed the task and then take what you’ve learned from that and input the lessons learned into your next task.

The mindset for answering the questions:

1. Any information needed to answer the questions will be in the question ➜ never assume otherwise.

2. The prescribed approach is to always think it through BEFORE you act on something (unless it deals with dire consequences like health and safety or mandatory regulations).

3. Never take action without first creating a plan/reviewing it if it had before.

4. ITTOs - try to remember which process you are in: Initiating, Executing, Monitoring & Controlling, Closing. Keywords to remember:

        - Planning - Plan, Estimate, and Define

        - Executing - Manage, Conduct, Implement

        - Monitoring & Controlling - Monitor, Control, and Validate

If the question concerns initiation or planning, look for those processes. If the question says "in execution", the answer won't be a planning process.

5. The rule of don'ts (not absolute but generally):

        - Don't remove a team member or a vendor.

        - Don't escalate to the Sponsor, Steering Committee, Stakeholders, PMO, or Product Owner. Except for cases with a huge impact, affecting the project's viability.

        - Don't ask for a budget increase.

6. MVP is the way to go when there are just too many wish lists from stakeholders but limited resources. Use a prototype when demonstrating the product's value.

7. The approach to the PMP exam questions:

     - Step 1: Assess! Always assess first!!

     - Step 2: Review relevant plan

     - Step 3: Analyze/Analyze with the team

     - Step 4: Update relevant project documents

     - Step 5: Communicate with the stakeholders and project team

     - Step 6: Take action

     - Step 7: Continuously review

Step 6: Take action on the Type of PMP Questions

Tips for taking the exam:

1. The options that contain words like must/only/all/each one/most/every/100%/none/ zero/except/immediately/bypass/every, are not likely the answer.

2. The options that suggest extremes, such as terminating contracts, firing people, stopping payment, hiring people mid-project, hiring consultants, and closing projects because of inconveniences, closing the project, refusing something to the customers, or going to a sponsor with a problem, are not likely the answer.

3. The options that indicate PM's inclusiveness, collaboration, and decisiveness are likely the answer.

4. Take note of cue words:

     - May/might/could mean revisiting the risk register and risk management plan.

     - Will/would/has (or any event already done) means reviewing the issue log and requiring an issue resolution.

Knowledge Area in the exam:

A/ Change:

The Triple Constraint Triangle is SCOPE + TIME + COST = QUALITY. Changes to any one of these factors will affect the others. Besides, changes to any factors will affect the others, despite of one of these factors.

Ex. For all scope changes, PM should be assessed how they will impact all other parts of the project, including schedule, cost, quality, resources, communications, risk, procurement, and stakeholder engagement.

Changes ➜ Assess and evaluate the impact on the project, then go through the formal change process, including approval. Never put a change through without approval.

Change Management – 7 steps in PICC process:

B/ Scope/Requirements:

➡️ After obtaining input from the customer and other stakeholders, the project team is responsible for developing the scope baseline.

➡️ The scope statement must be precise and can be quite detailed.

➡️ The Scope Statement includes 3 parts:

• Description of the project and product scope
• Deliverables
• Assumptions and constraints

➡️ The Detailed Scope Statement includes​:

• Product scope description
• Deliverables
• Acceptance criteria
• Exclusions

➡️ Customers approve the product scope (i.e., their requirements) but do not generally approve the project scope (what you will do to complete their requirements).

➡️ Requirements are then used to measure the completion of the project. If you don’t have complete requirements, you can’t measure whether the project is complete. Whereas perform Quality Control checks for correctness (in software, this is like QA testing), Validate Scope checks for acceptance (where the customer checks that the finished product fully meets their requirements).

➡️ If anything is missed in scope ➜ which may lead to the rejection of deliverables, submit a change request.

➡️ Prototype ➜ This is the best option for a demo. A prototype is helpful when most of the requirements are already known.

➡️ To prevent the scope creep ➜ Summit/Approval formal change request.

➡️ A WBS is developed by the team but is used to communicate with all stakeholders:

• The most valuable result of WBS is team buy-in.
• WBS also helps prevent works from falling through the cracks and avoids gold-plating projects.
• Control Accounts are higher level than Work Packages and are figured out in schedule management during Define Activities (post creation of the WBS)

➡️ A context diagram can be used during Collect Requirements. It visually depicts the product scope system and how people and other systems interact. Presumably, BPMN diagrams and other "flow charts" used by BAs are considered context diagrams.

➡️ In Agile Method: Engage the Product Owner to document and prioritize the features in the product backlog. Only the Product Owner can prioritize the features in the product backlog. If the product owner refuses to do so because they feel all of them are valuable, then you must train them on the benefits of doing so. DO NOT prioritize the features yourself; this is the Product Owner's job.

➡️ Stakeholders may provide input and feedback on requirements or products, and the Product Owner gathers feedback and suggestions from various sources. However, the individual with the final authority over product requirements is the Product Owner, as their role is to maximize/optimize the value of the product

C/ Schedule:

• Estimates can be definitive (± 5-10%), budgetary (± 15-25%), or order of magnitude (± 50%), depending on the stage of initiating or planning that you are at.
• What-if analysis in project scheduling is often done using Monte Carlo analysis. You enter a distribution of possible durations of each activity, and it spits out a distribution of possible durations of the overall project. Monte Carlo only produces good results if your initial inputs are valid.​
• In Estimate Activity Durations, WBS and RBS are used at a low and detailed enough level to allow the work to be estimated.
• Activity attributes include not only who and where the activity will be performed but also predecessor/successor linking info, duration/float, leads/lags, etc. They do not include cost information, however. See more.
• Milestones are started in the project charter but are formally set when defining all activities. Milestones are activities with a duration of 0.
• Float: (See more)

       - Float = Late start (LS) - Early start (ES)

       - Float = Late finish (LF) - Early finish (EF)

       - Free Float = ES of next Activity - EF of current Activity - 1

       - Forward pass in the schedule checks each activity's earliest start and finish. Backward pass checks the latest start and finish

• Rolling wave planning (a form of Progressive Elaboration) means if a task can't be broken down yet, leave it high level and break it down further.
• You can’t publish the schedule until resource availability (Resource Management) is confirmed!
• A negative variance means that actuals are behind schedule / over budget. Negative is bad, and positive is good!
• SPI is scheduled while CPI is Cost. To remember if it's good or bad, treat 1 like 100%, which is the ideal baseline:

       - Anything above 1 is good;

       - Anything below 1 is bad.

D/ Cost:

1/ When creating the Project Charter, provide a budget RANGE (which could be informed by analogous or parametric estimation, among others)

2/ If a stakeholder asks for a precise project budget before planning is done, tell them to wait until planning is done! (even though a budget range might have been provided early on in the Project Charter)

3/ An analogous estimation is a form of top-down estimation. It doesn't use "detailed" historical task breakdowns; it’s a high-level comparison.

4/ Project setup costs are considered fixed costs, not overhead costs.

5/ The output of Determine Budget is a Cost Baseline. A Cost Baseline is different from a Project Budget.

6/ Determine the Budget using the resource calendar (Resource Management).

7/ The S-curve shows the cost baseline, remaining budget, and time.

8/ CPI is calculated with actual costs, not estimated costs. A CPI of 0.5 means only getting 50% of every dollar invested. It's not about progressing at a rate (that's SPI)

9/ Value analysis (different from EVM) is about seeking ways to do the same work at the least cost, decreasing cost while maintaining the same scope.

10/ Cost Risk = risk that costs of the project go higher than planned.

11/ Identified risks are both an input and an output of Estimate Costs.

E/ Quality:

🔻The quality requirements should be defined early in the project and be checked often to ensure they’re getting done.

🔻The customers are the best people to check a deliverable for scope conference and quality requirements being met as they are the ones that will actually use the product.

🔻Quality policy is the organization-wide quality intent. The quality management plan then documents how the quality policy is implemented on the project.

🔻Modern quality management complements project management, as both disciplines recognize the importance of customer satisfaction, prevention over inspection, and continuous improvement.

🔻Quality is achieved when the product meets requirements (aka customer expectations). In other words, "quality is the degree to which a project meets the requirements."

🔻Quality can be about conforming to a standard (e.g., specs document) previously decided.

🔻Emphasis is on prevention, as quality costs more later. The Cost of Quality (COQ) is the cost of bringing a product that did not have acceptable quality initially back up to standard. It is the sum of 2 types of costs:

• Cost of Conformance, which includes the cost of Appraisal ​​(i.e., measuring quality periodically) and cost of Prevention
• Cost of Nonconformance, also called failure costs, made up of Internal (before shipping to the market) and External costs (after shipping)

🔻An organization is said to have a quality culture when it is aware and committed to quality in both its processes and the products it creates.

🔻Though everyone is responsible for the quality, the PM is ultimately responsible for the quality of the project.

🔻Quality management must address quality of management, product, project management, and meeting customer requirements.

🔻For each project, one must decide if cost, quality, or schedule is more important.

🔻The quality management plan includes quality policy and quality control charts.

🔻Note that there is no such thing as a quality baseline (only scope, schedule, and cost baselines).

🔻In the quality management plan, you develop a plan to make use of Tests and Checklists. However, the actual tests and checklists aren't developed until manage quality.

🔻Checklist vs. Check-sheet. The checklist is to verify compliance with the steps of a procedure. The check-sheet is for tabulating test results.

• Frequent errors scattered across the product without a discernible pattern? Use check-sheets to identify areas of error concentration and then prioritize the response strategy

🔻Quality attributes = measurements for if the product is acceptable

🔻When planning and measuring quality:

• Specification limits are the allowable limits specified by the customer. Control limits are the limits used by QA (which are most likely narrower than the specification limits). See more.
• Accuracy is about values being close to the true or target value, whereas Precision is about values being clustered close to each other and having little scatter. See more.

🔻Sigma (σ): 3σ = 99.7% | 2σ = 95% | 1σ = 68%

🔻Tools for planning quality:

• Design of experiments (DOE) is a statistical process for identifying variables that can most impact quality.
• Design for Excellence (DfX) in Manage Quality means you purposefully design the product to optimize one or more specific variables such as reliability, deployment, cost, service, safety, usability.

>>> E.g., DfX to reduce costs while improving quality and performance.

>>> E.g., optimize for reliability, safety, and cost​.

• Scatter Diagram shows the relationship between two variables. This tool allows the quality team to study the possible relationship between changes observed in two variables. Dependent variables vs. independent variables are plotted. The closer the points are to a diagonal line, the more closely they are related.
• The scatter diagram is useful for 1-1 analysis. The affinity diagram is for grouping.

🔻Inspections are sometimes called reviews, product reviews, audits, or walkthroughs (but not "stage gates").

🔻Focus groups are not used in quality; they are for scope.

🔻Remember definitions of TQM, Six Sigma, Deming's PDCA cycle, and Lean.

🔻When it comes to selecting QA staff, experience is the most important factor. However, attitude and other factors are important too.

🔻Quality audits:

• Can be used to confirm that policies are being followed, to improve processes, AND to confirm the implementation of approved CRs.
• Identifies process problems, gaps, non-conformity, etc. but does not seek the root cause. Process analysis (subsequently) finds the root cause.

🔻Quality reports:

• Summarize quality management issues that the team has escalated and any corrective actions recommended or implemented.
• Information that other departments can use to take corrective actions to achieve quality objectives.

🔻Common causes are normal variations, and special causes are due to defects. A data point in a control chart that requires investigation is called a special cause.

F/ Resources:

➡️ The PM negotiates with the functional manager for resolving resource conflict (PMO is not involved in staffing).

➡️ Check with the Functional Manager to see if they're available resources to help or hire before going to the PMO.

➡️ Release Criteria is about releasing HR team members. It's both the timing and method of releasing them.

➡️ When estimation is required ➜ the team is the best people for estimation because they are subject matter experts.

➡️ When conducting estimating, uses a bottom-up approach will lead to more correct estimates but will require more work. Upon the scenario, we can use other estimating techniques, such as Analogous estimating, Parametric estimating, Three-point estimating, Bottom-up estimating, etc. It's essential to tailor your estimating techniques/choose the suitable estimation techniques to the specific needs and characteristics of your project.

➡️ The best people to break down work is the project team.

➡️ If a team member needs more skill, put them in training. If the stakeholders or the organization are new to agile, show them the benefits of agile (i.e., workshops, training).

➡️ The Resource Management Plan:

• describes when resources will be brought on and taken off and how team members should communicate with the PM.
• could be broken down into a Team Management Plan (which can include policies such as when to be onsite) and a Physical Resource Management Plan.

➡️ Various documents help you visualize people and physical resources:

• RBS (Resource Breakdown Structure) is a hierarchical list of team and physical resources related by category and resource type that is used for planning, managing, and controlling project work. Each descending level represents an increasingly detailed description of the resource.
• Project Team Directory is a documented list of project team members, their project roles, and communication info.
• Resource Calendar identifies the resources' working days, shifts, business hours, holidays, etc. When starting Acquire Resources, you consult this.
• Resource Histogram shows the resources used per period. You don’t just send the Functional Manager the resource histogram; you have to discuss it with them and ask their opinions.
• WHO does each project activity in the schedule is managed with the RAM (resource assignment matrix).

➡️ Control Resources is really about physical resources, whereas Manage Team is for people, especially tracking performance and optimizing performance.

➡️ Conflict resolution

• Before resolving a conflict between team members, make sure to understand the source of the conflict.
• The source of conflicts in a project, from highest to lowest respectively, are: Schedules, Priorities, Manpower, Technical, Procedures, Personality, and Costs.
• Some commonly used techniques for conflict resolution are Withdrawal, Forcing, and Compromising. However, the order of preference for conflicts should be:

              - Confrontation
              - Compromise

              - Smoothing

              - Forcing

              - Withdrawal

• If the team is fighting, start with ground rules, then schedule team building.

• All matters which related the conflict resolution and escalated the following steps below:

             - All parties and individuals will solve firstly (Team conflict ➜ Put them in "one room" and facilitate mediation).

             - PM is a facilitator to conclude effectively.

             - If it cannot resolve, then formal disciplinary action (formally written).

             - The last option will be escalated with the Functional Manager or Sponsor.

• If the problem is for the individual, then we should meet this individual ➜ Private meeting and find the root cause to solve.
• If the problem for the team, the majority, then we should have a meeting and facilitate ➜ Enhance the effectiveness, efficiency, reach the target, buy-in, and cross-functional.
• Don't delay taking action.
• If the sharing problem, get the information, but the stakeholder is concerned about the confidential, personal issues privately ➜ Using Interviews.
• The conflict between Team & Team:

              - Meeting and Coaching to benefit the project objectives, not to satisfy one member over another

              - Keep priority WIN - WIN prefers first and satisfies both teams

              - Understanding the root cause of the conflict

              - Sorting by positive and negative

              - Based on roles and responsibility

              - Run Retrospective (Agile)

• The conflict between Team & Stakeholders:

              - To resolve the direct who has a conflict

              - Keep priority WIN - WIN prefers first and satisfies both teams

• The conflict between Stakeholders & Stakeholders:

              - Based on the Key Stakeholders' ideas

              - Negotiate on a process.

➡️ Tacit knowledge involves emotions, experience, and abilities. Sharing this requires trust. This is different from explicit knowledge, such as facts and lessons learned.

➡️ Project performance appraisals = how an individual performs, whereas Team performance assessments = how the team is doing together.

➡️ Reward and expert power are the best to use. An expert can take some time to establish, so it’s either rewarding or formal in the early days. You probably can’t use reward in a weak matrix, so expert is all you’ve got.

G/ Communication:

➡️ Before communications are sent out to stakeholders, ensure to analyze their needs and determine what they’re looking for, how often, what method they would like it delivered, and who will deliver it to them.

➡️ When engaging your stakeholders, ensure they understand the communications they receive. Tailor your communications to individual stakeholder needs.

➡️ Utilize emotional intelligence skills to analyze your feelings and those around you to respond to stakeholders' needs and requirements. Emotional intelligence allows you to solve problems quicker and more effectively.

➡️ Effective project integration requires an emphasis on communication at key integration points.

➡️ When to use different types of communication:

     - Informal verbal communication, such as F2F, is the best way to handle issues of poor performance and resolve disputes among team members.

     - Face-to-face is critical even for contract negotiations. However, contracts themselves are formally written (e.g., by procurement).

     - Extensive use of written communication when solving complex problems, so everyone involved receives the same information.

     - When differences in culture and remote employees, use written formal communication to keep everyone in the loop.

➡️ Collection, creation, distribution, storage, and monitoring of project information are activities that fall under Communications Management, mostly under Manage Communication.

➡️ 5C's of written communication: correct grammar, concise, clear purpose, coherent, controlling flow of words and ideas.

➡️ If you talk in a meeting and people don't say much and just nod, then you need Active Listening skills.

➡️ If the team has a hard time understanding stakeholders' concerns, train them in cultural and active listening.

➡️ Review push and pull communications. A blog is a "push" method since you publish regardless of the recipient's interest.

➡️ Knowledge management tools are not just repositories but for actively connecting people and getting them to communicate.

H/ Stakeholder:

1. A communication style assessment should be performed before stakeholder engagement assessment, particularly for unsupportive stakeholders.

2. The role of the stakeholder is determined by the Project Manager and the stakeholder collaboratively. The Project Manager does not order the stakeholder!

3. The Project Management Plan has 4 key areas to help manage stakeholders:

• Communications management
• Risk management
• Change management
• Stakeholder engagement

4. Issue log and Change log are the 2 tools that you can use to build communications and trust with stakeholders day-to-day.

5. An issue log is an important artifact to go through monitoring stakeholder engagement (aka adjusting strategies for engaging stakeholders).

6. If stakeholders outside the team are risk owners, influencing them to ensure their engagement is most important. A risk system and regular calls are good, but the influence is needed most.

7. Networking is very useful for problem-solving, stakeholder influencing, and obtaining support.

I/ Risk:

✅ Identify as much risk as possible as early as possible on a project. All identified risks should be documented in the risk register along with their corresponding risk responses.

✅ Risk should be an agenda item at every team meeting.

✅A negative risk is a threat, while a positive risk is an opportunity. Ensure to identify and document responses to both. See more.

✅ Identify Risks techniques: document reviews, prompt lists, brainstorming, and data analysis such as root cause analysis, checklist analysis, and assumption and constraint analysis.

       - Prompt lists, in particular, are when you prompt the team with pre-defined lists of generic risks such as PESTLE (political, economic, social, technological, legal, environmental), TECOP (technical, environmental, commercial, operations, political), and VUCA (volatility, uncertainty, complexity, ambiguity)

       - Risk data quality assessment is the process of validating the reliability of the inputs for data analysis

✅ Types of risk:

       - Event risk, e.g. a key supplier may go out of business during the project.

       - Variability risk = uncertainty about characteristics of a planned event or activity, or decision (e.g. more bugs than expected, bad weather during the construction phase).

       - Ambiguity risk = what might happen to arise from lack of knowledge or understanding, inherent systemic complexity in the project.

       - Emergent risk = emerges from our blind spots, outside our mind/cognizance, arising from limitations in our worldview. Also known as unknown-unknowns.

✅ When planning risk responses:

       - Risk responses aren't just for when risks occur (reactive); they can also include proactive action to be taken throughout the project

       - Risk Mitigation is where you reduce the probability or impact of an event. ​

       - Risk Acceptance is where you can't modify the event, so you let it happen without doing anything or planning around it (for example, shut down for the summer). Passive acceptance is best when your best course of action is to deal with the problem if and when it occurs simply.

       - Another response to risk can be Escalation. When you escalate a risk, it’s the responsibility of the person you escalated to (e.g. Program Manager).

      - If additional risks are identified during the response planning session, those are secondary risks. Document them but keep planning risk responses; don't stop and jump back to identify risks immediately.

      - Output includes both Risk Triggers and Contingency Reserves.

✅ When managing the project:

       - Influencing risk owners is part of implementing risk responses.

       - Monitoring secondary risks is part of Monitor Risks.

       - "Risk reassessment" is conducted in Monitor Risks.

       - When baselines are far off, consider risk re-identification and analysis.

✅ When an unplanned risk is identified but not triggered, qualify it. However, if it is triggered, then you need a workaround.

✅ Qualitative Risk Analysis outputs a prioritized list of risks and a watchlist of low-priority risks that we don't analyze further:

        - You can use a bubble chart to see a 3D visual of risks by detectability, proximity, and impact and prioritize accordingly

        - You can use a tornado chart to compare and prioritize the relative impact of different risks (a form of sensitivity analysis)

        - Risk propinquity is the degree to which a risk is perceived to matter by one or more stakeholders.

✅ Quantitative Risk Analysis outputs the probability of achieving time and cost objectives (but NOT quality objectives). A numeric value is assigned to risk impact and probability, but risks are NOT prioritized the way they are in qualitative risk analysis.

✅ A risk audit is for anywhere in the risk management process.

✅ Decision tree: a SQUARE represents a decision, and a CIRCLE is a chance of an event occurring.

J/ Procurement:

 When selecting a contract to use on a project with potential sellers, always use a contract mutually beneficial to both the seller and the buyer to benefit the project objectives.

 The purpose of a contract is to distribute a reasonable amount of risk between 2 parties. The most important role that the Project Manager plays in the contract is protecting the interests of the project.

 Contracts go through an intense approval process, even more than the Project Management Plan.

 If there is any issue related to payment/contract with the vendor ➜ always ask them to check with the appropriate department.

 When a delay in an item sent by a vendor or a quality issue with the vendor arises ➜ meet and brainstorm with the team and come up with solutions.

 Plan Procurement Management process includes several things that you might think happen at Conduct Procurements but doesn't:

       - Make-or-buy analysis

       - Source Selection Criteria

       - Bid documents (also called Procurement Documents)

 Conduct Procurements is the execution of the RFP process, which can include contract types, independent estimates, and advertising.

 “Bid, tender, or quotation” terms are used when the seller selection will be based on price (commodities), while “proposal” is when technical capability or technical approach is paramount. Bidder conferences save time!

 Records Management Systems (RMS) - Control Procurements includes storing contracts and other documents in the RMS.

  Regarding certain types of contracts:

       - CPFF requires all costs on the invoice to be audited closely.

       - FF (fixed fee) is paid continuously, not all at the end.

       - A purchase order is a unilateral contract.

       - T&M is best used when the project scope includes the progressive elaboration of the scope of deliverables.

 Regarding breaches and disputes:

         - When disputes arise, contract claims administration is used. File a claim and then negotiate with the vendor on any disagreement. Arbitration is next, then litigation (last resort).

     - Constructive changes = a situation when a contractor performs work beyond the contract requirements without a formal order under the changes clause, either due to an informal order from or through the buyer's fault. This is also a change where the buyer and the seller cannot reach an agreement.

     - If during contract negotiations you also have a signed note (separate from the contract), if the contract ultimately doesn’t have what’s on that note, the seller is only required to deliver what’s in the contract.

     - If the contract requires certain things before commencement and the seller does not issue, you can issue a default letter (notice of default)

    - If the seller violates the T&Cs, such as issuing an invoice for a higher amount, you can issue a breach of contract notice (then, presumably, talk to them).

 Dealing with Vendors ➜ Conflict, Issues, and Procurement Strategy:

     - Review procurement management plan/agreements/contracts

     - Talk to them Face-to-Face or call to resolve issues

     - Evaluate alternatives if needed

     - Audit procurements as needed

     - In the event of a claim, escalate to Claims Administration.

     - If the contract does not align with the project goals, take preventive measures - could be to cancel the contract.

 Review the CPIF formula and the Point of total assumption (where the seller bears the risk and sharing ratio goes away).

 Control procurement is not just for monitoring contracts but also for contract closure.

K/ Integration:

1/ PM’s main job is to be an integrator of the many different components within a project. Do not concentrate your time and efforts on one particular thing while ignoring others.

2/ When overall guidance is required ➜ refer to the Project Management Pan. Refer to Project Charter when you need high-level guidance.

3/ The Close Project or Phase process is started once all the work has been verified, delivered, and accepted by the customer. All open issues have been raised, and finalized (come to a conclusion and closure).

4/ The sponsor is the one to sign off on the project closure.

5/ You need the Project Management Plan, Project Charter & Business Documents at closing. In particular, the project charter contains project success criteria. Business documents include the benefits management plan to check against. Business documents are the business case and the benefits management plan.

6/ The projects that are terminated early still need to be closed formally through the close project or phase process.

7/ Know the Closure sequence:

• Confirm the formal acceptance of the product (by all stakeholders, then the customer)
• Transfer the product/service/result to the next phase or operations
• Obtain financial, legal, and administrative closure and ensure transfer of liability
• Obtain feedback from relevant stakeholders to evaluate their satisfaction
• Create the final project report
• Update lessons learned
• Archive project documents
• Release resources

8/ Update the lesson learned register throughout the entire project. This way it can be transferred to future projects in the organization.

9/ When closing the project, ensure all bills are paid, and resources are released.

10/ Project closure documents are formal documents that indicate the closure of the project and transfer to operations. Product support details are part of the project closure documents. The customer may have written them and will send them to you for archival.

11/ Phase end:

• At the end of each phase, closure ensures the phase met its objectives.
• Exit criteria at the end of a phase are also called Phase end criteria (not "phase closure or phase termination" criteria).
• At the end of the phase, you might decide to extend the phase, continue to the next phase, or close the project. But this is not where you initiate a new project.
• Closing the project also involves documenting the degree to which each phase was properly closed.

12/ Things that are NOT part of closing:

• Performance measures, which are taken earlier during Monitor & Control
• Validate Scope, which happens in Control Scope
• Contract closure, which happens in Control Procurements

13/ Scope validation:

• can be done at closure as a result of tailoring.
• doesn't require your team to verify deliverables if the customer is responsible for verification themselves.

Xem thêm

PMP® GUIDE - HƯỚNG DẪN LUYỆN THI PASS PMP® ON THE FIRST TRY TOÀN DIỆN

MỌI KIẾN THỨC VỀ PMP®

MỌI CHUẨN BỊ CHO PMP®

LUYỆN THI PMPPRO 14 BUỔI

PMI Gaps

Agile Gaps