Prepare Project Management Professional (PMP) in 60 minutes 

Following are the step to effective engage stakeholders in project management

1. Identify stakeholders using expert judgment, focus group, workshop, OPA, and EEFS.
2. Put the Stakeholder in the Stakeholder Register.
3. Start stakeholder analysis. Analyze the stakeholder using upward, downward, sideward.
4. Prioritize stakeholders using a power-interest matrix, stakeholder cube, or salience model.
5. Once the stakeholder register is updated and criticized, initiation is completed.
6. Make a stakeholder engagement plan with strategies to engage stakeholders.
7. Use SEM- Stakeholder Engagement Matrix in the stakeholder plan checking stakeholder’s current and desired engagement state.
8. Once the stakeholder plan with strategies to engage them is approved by the sponsor or change control board, start implementing it.
9. Review the plan to ensure its validity for monitoring and control purposes. If the plan is found to be inadequate, raise a change request to update it accordingly.
10. Whenever a new stakeholder is identified, they are added to the stakeholder register. Subsequently, a change request is raised to update the stakeholder plan, communication plan, and resource management plan. Finally, the assumption log is updated accordingly.
11. Continuously assess the effectiveness of your plan and make modifications as necessary.

1. All the communication in the project will follow the communication management plan.
2. The communication management plan will have the 4R of communication – right information, right time, and right people to have the right impact.
3. It basically covers who needs information, when they need it, why they need it, how the communication will be delivered to them, how communication will be stored, and how the information will be discarded after use including which artefact will be used for it.
4. Determine the communication needs of each stakeholder based on cultural sensitivities, political awareness, and communication requirements, then incorporate them into the communication plan.
5. Face-to-face communication is always preferred and whenever a virtual team has a challenge in communication, try to have them co-locate at least for one time or one meeting.
6. Use pull, push, and interactive communication or a combination of them as required.
7. Whenever communicating, understanding the political awareness and cultural awareness is important.
8. Work performance data is raw information produced in execution which gets converted into work performance information in the monitoring and control process. The project manager combines them in integration as a work performance report and this is shared with all stakeholders according to the communication management plan.
9. Virtual teams have their benefits, but their challenges must be addressed by using interactive boards and information radiators.
10. Communication channels are calculated as n(n-1)/2 where n is the number of participants.

Steps to Lead and Manage Team

1. Identify which type of resources and skills you need for the project using SWOT analysis and project requirements.
2. Identify if you want to go for a virtual team, physical team, or hybrid team. Consider the pros and cons of each option.
3. Hire team members according to the skills needed for the project.
4. Create a team charter outlining ground rules, conflict resolution procedures, decision-making processes, and the project’s vision.
5. At the beginning, when the team is in the forming stage, provide them with the necessary direction to initiate work.
6. Over time, conflicts may arise within the team, indicating the storming stage. Here, you’ll act as a coach, employing active listening and emotional intelligence to comprehend the conflict’s context, considering the five levels of conflict and applying various conflict management techniques as required for the project.
7. If conflict is managed effectively, we will progress to the norming stage where the team starts understanding each other’s habits. Continuous support is essential at this stage to ensure the team remains on track.
8. Understand different motivational theories: Maslow, Herzberg theory, Theory X and Theory Y, Halo effect, expectancy theory, McClelland theory.
9. Finally, in the performing stage, the team is highly competent and can be delegated tasks while being monitored, resembling a laissez-faire leadership style.
10. Once the work is completed, the team will be released to pursue future projects.
11. You need to have a servant leader mindset – act like a mother/father to guide and support the team and remove any roadblocks they may have throughout the project.
12. Training Needs Assessment (identifying training requirements) is a continuous process for team development. You may have to coach, train, and mentor them at any stage. As a general rule, you may have to train the entire team at the beginning and as the project progresses, you may have to train individual team members.
13. The resource management plan will guide how you acquire, develop, manage, and release teams.
14. The resource management plan will also have budgeted and planned training for the project, as well as details regarding rewards and recognition for project accomplishments.
15. The resource calendar will define when resources will be available.
16. RACI will tell you who is responsible for the project, who is accountable, whom to inform, and who to consult.
17. RAM – Responsibility Assignment Matrix will only share who is responsible for the project.
18. As a PMI Project manager, you will always train team members and never fire the team.

1. Make a Requirement Management Plan.
2. Collect requirements using expert judgment, focus group, prototype, OPA, EEF, interview, value stream mapping, and context diagram.
3. Put all requirements in the RTM (Requirement Traceability Matrix) and requirement documentation.
4. Using the scope management plan, separate product and project scope.
5. You have the Project Scope Statement.
6. Decompose scope using decomposition techniques, and you have WBS (Work Breakdown Structure) and WBS Dictionary.
7. Project Scope Statement, WBS, and WBS Dictionary are called Scope Baselines, which require formal approval.
8. If you want to change scope, you have to raise a change request and follow the change management plan.
9. When the client approves deliverables according to the scope baseline, it is called validated or accepted deliverables.

Schedule Management

1. Create a Schedule Management Plan which will outline the software we are going to use and additional relevant details.
2. Continuing from where we left off in Scope management, we’ll break down work packages into lists of activities, along with their attributes, and compile a list of milestones.
3. Check activities relationships: Finish to Start (FS), Start to Start (SS), Start to Finish (SF), Finish to Finish (FF).
4. Verify activity dependencies, including mandatory and discretionary dependencies, both internal and external.
5. Check the duration of each activity using analogous, parametric, bottom-up estimation, and 3-point estimation.
6. Use the critical path method to calculate duration and schedule baselines.
7. If you want to reduce the schedule, use schedule compression techniques: Crashing (adding resources will add more cost) and Fast Tracking (it will make activities parallel but will increase rework).
8. Use resource optimization techniques: Resource levelling and Resource smoothing to manage resources.
9. Crashing, fast tracking, and resource levelling will require a formal change request.

Cost Management

1. Make a Cost Management Plan. This specifies details like which currency we can use, what our tolerance and threshold limits are. Plus, rough estimates and definite estimates and whether we are doing self-financing or someone is supporting us.
2. Make Funding Limit Reconciliation.
3. Using the same techniques as used in the schedule, calculate the cost of each activity and then add a contingency reserve (cost set aside for identified risks). This becomes the cost baseline. Cost baselines = Cost of Activities + Contingency Reserves.
4. Project Budget = Cost Baselines + Management Reserves. Management reserves (cost of unidentified risks that management puts aside) – Note you need to raise a change request to access management reserves.
5. Use earned value analysis to measure how you are doing cost and schedule-wise.
6. Schedule Performance Index (SPI) = Earned Value (EV)/Planned Value (PV). Greater than 1 is a good thing.
7. Cost Performance Index (CPI) = EV/Actual Cost (AC). Greater than 1 is a good thing.
8. Schedule Variance (SV) = EV – PV. Zero is on schedule, positive is ahead of schedule, and negative is behind schedule.
9. Cost Variance (CV) = EV – AC. Zero is on budget, positive is within the budget limit, and negative is over budget.
10. If your project is going out of budget, use Estimate at Completion (EAC) = BAC/CPI.
11. To Complete Performance Index (TCPI) = Work remaining/Fund remaining (BAC – EV)/(BAC – AC). TCPI greater than 1 is a bad thing.
12. “Scope, schedule, and cost baselines together are called performance baselines.”

Steps to Manage quality of Project Deliverables (Quality Management in PMP)

1. In plan quality, we make a quality management plan to ensure quality standards are documented and the cost of quality is mentioned (money set aside to handle any risk, consisting of the cost of conformance and cost of non-conformance).
2. Quality metrics, essentially Key Performance Indicators (KPIs), focus on measuring the most critical aspects or factors.
3. In execution, we ensure the right deliverables are being followed. Quality assurance is all about following the right process.
4. In control quality, once deliverables are made, we inspect them. If they meet agreed quality standards, we get verified deliverables.
5. Inspection is used to check deliverables.
6. Audit is used to ensure that we are following the right process or not. Audits can be first party (by your team), second party (someone else from the organization), or third party (someone independent and outside the organization, which is recommended).
7. Sampling is used to select a few items from a large quantity of data. Sampling can be random or statistical.
8. Histogram is a frequency distribution chart.
9. Scatter diagram is used to identify the correlation between two variables.
10. Fishbone diagram, also known as Ishikawa/Root Cause Analysis/5 Whys/Cause-and-Effect diagrams, helps find the main cause of a problem, revealing why it’s happening.
11. Control charts are used to control the process, and if any point goes out of the limit, it needs to be investigated.
12. Pareto charts are based on the 20/80 principle, highlighting the most crucial factors, serving as a prioritization tool.
13. Checklist is used to ensure the sequence of the process, confirming whether we are following the right process or not.
14. Check sheet is used to count the defects.
15. Quality is a continuous improvement process.
16. PDCA (Plan Do Check Act – aka Deming cycle) and Six Sigma (out of 1 million, only 3.4 defects are allowed – DMAIC: Define, Measure, Analyze, Improve, and Control) are continuous improvement techniques used.

Risk Management in PMP

1. Risk is R=PxI (Probability multiplied by impact).
2. For an event to be considered a risk, it must meet two criteria: a) It has not yet occurred, and b) There must be a plan in place to address it.
3. Use Organizational Process Assets, EEF, and other data to develop a risk management plan. This plan should define the organization’s risk tolerance, thresholds, risk appetite, risk attitude, and risk matrix.
4. Once the risk management plan is approved, begin the process of identifying risks.
5. Use expert judgment, focus group, workshop, OPA, EEFs, and prompts lists to identify risks. Document these risks in the Risk Register.
6. Use qualitative risk analysis to prioritize the risks.
7. If required, use quantitative risk analysis to further prioritize risks.
8. Once the risks have been prioritized, develop responses for both negative risks (threats) and positive risks (opportunities).
9. Remember, proactive risk response strategies involve actions such as avoidance, mitigation, and transfer for negative
10. risks, and exploitation, enhancement, and sharing for positive risks. As soon as risks are identified, take immediate action on them.
11. In reactive risk response strategies, such as risk acceptance, we identify risks, their triggers, and assign risk owners to implement contingency plans to manage those risks.
12. Risk escalation is used for both positive and negative risks if they go beyond our threshold limits.
13. Once a risk trigger occurs, risk owners implement the risk response and we measure the effectiveness of the risk response.
14. Residual risk: Refers to the risk that remains after implementing response measures, which is then assessed and measured.
15. Secondary risk: Refers to a risk that arises as a result of implementing a response to another risk, much like any other risk.
16. Risk audit: Is done to evaluate the effectiveness of the risk management process.
17. Risk review meeting: Evaluates the remaining reserves and documents their status in the risk report.
18. Anything that has occurred without a plan goes to the issue log.
19. Throughout the process, whenever a risk is identified, we document it in the risk register and it does not require a change request.
20. Anything which does not have a plan will go to the issue log. Note that an issue is always a negative event. Positive issues are known as missed opportunities.
21. Risks are exclusively recorded in the risk register; the risk management plan does not have any risk or response to it.

Steps to Handle Issues in PMP

1. Something unexpected has happened that was not planned; it should be recorded in the issue log.
2. Conduct a root cause analysis to understand why the issue wasn’t identified and planned for beforehand.
3. Determine if a change request is necessary to address the issue, and if so, submit a change request accordingly.
4. If the change request is approved, implement the response and update the issue log.
5. If this issue can reoccur in the same project, update the risk register.
6. Update the lessons learned register for future projects.

1. All changes must be raised and put in the change log.
2. The project manager will do impact analysis – checking how the change impacts scope, schedule, cost, and constraints and send it to the change control board.
3. If the change control board rejects the change, the project manager will update the change log and communicate the status according to the communication management plan.
4. If the change control board approves the change, the project manager will update the change log, communicate the status according to the communication management plan, and implement the change.
5. The project manager will rebalance the project with new baselines.
6. Note: Change in predictive and hybrid projects are handled in the same way. In Agile, all changes go to the product owner; they will reprioritize the product backlog and handle the change, and one change request is enough to update all plans.
7. We don’t need to change the stakeholder register, issue log, risk register, and all other documents. Only plans and baselines need a change request.

Managing Procurement in PMP

1. Decide what you want to do – Is your scope fixed or variable?
2. For fixed scope, we have firm fixed price contract, fixed price incentive fees contract, and fixed price economic price adjustment. The risk is on sellers.
3. If the scope is not fixed, we can utilize cost reimbursement, cost reimbursement plus incentive fees, and cost reimbursement plus award fees.
4. If we want to go for subscription, we can go for a time and material contract where the risk is maximum on the buyer.
5. We make a procurement management plan to outline how the procurement process will unfold.
6. We make a procurement strategy to define our approach and tactics for procurement.
7. PSOW: Procurement Statement of Work is written and shared with sellers to define what we need, when we need it, and how much we need.
8. We have a bidder conference in which the requirement will be defined further, and if bidders have questions, here is the time to ask them. After the bidder conference, the seller will provide a proposal.
9. Negotiation will happen, and we will get the contract signed. Once the contract is signed, it becomes a binding agreement. Everything must be done according to it.
10. If you want to do an audit of the organization, it must be mentioned in the agreement/contract.
11. Once deliverables are complete, we inspect them. If accepted, we proceed to pay the sellers and close the project.
12. If there is a conflict, we will follow this process:
    a) Try to get a win-win situation. If that is not possible,

     

    b) Try to do what is written in the contract. If that fails,

    c) Get a mediator/arbitrator. If everything fails, the last resort is,

    d) Go to court!

13. Note that procurements can be closed at various stages throughout the project, not just at the end.
14. Anyone who terminates the contract or breaches it will be responsible for paying the associated fees.
15. In agile, we follow agile contracts.

• Agile is a mindset that requires you to be adaptable and ready to implement changes at any given moment while also focusing on delivering progress incrementally.
• Agile is used when the requirements are not fixed and when you want delivery in parts.
• Agile consists of 4 values which are the heart of it, we need to memorize these 4 values and understand them in depth.
• Agile Mindset: Emphasize adaptability, incremental progress, and collaboration.
• Agile Values: Focus on customer collaboration, responding to change, working software, and individual interactions
• Agile Principles: Extend the four values to 12 principles guiding agile practices.
• Agile Leadership: Encourage T-type leaders with deep expertise and generalist knowledge.
• Agile Practices: Utilize Scrum, product backlogs, sprint planning, and daily standups for project execution.

• • Agile is a mindset that requires you to be adaptable and ready to implement changes at any given moment while also focusing on delivering progress incrementally.
  • Agile is used when the requirements are not fixed and when you want delivery in parts.
  • Agile consists of 4 values which are the heart of it, we need to memorize these 4 values and understand them in depth:
  • Individual and interaction over processes and tools.
  • Working software over comprehensive documentation
  • Customer collaboration over contracts negotiation
  • Responding to change over following a plan
  • Agile has 12 principles which are an extension of these 4 values.
  • In Agile, we aim for T-type leaders, also known as generalized specialists. They possess deep expertise in one area and a general understanding of other topics. This approach helps prevent single points of failure.
  • Team members are empowered and accountable; they select their work and are responsible for it and answerable for it.
  • The team decides how much effort (story points) it will take to complete a user story (requirement).
  • Agile is lightweight estimation. We use ideal hours, affinity estimation, Fibonacci series for estimation, and planning poker to get consensus on story points.
  • Velocity (how much work can be done in a sprint) of two teams cannot be compared.
  • In Agile, we have small teams of fewer than 12 team members. As a servant leader, we provide them with an environment where the team can learn and grow together. We need to make sure the team can make mistakes and learn from them.
  • Scrum is the most used project management framework in Agile.

• The Scrum master is a servant leader who removes impediments among the team members and the product owner.
• The product owner is the voice of the customer; they decide what holds the most value throughout the project’s duration.
• The product backlog is a prioritized list of user stories that need to be addressed in the project. It’s organized using techniques like MoSCoW or 100 Points, focusing on high-value and high-risk items first.
• A sprint typically lasts from 1 to 4 weeks, during which all the work for that period is completed.
• The sprint backlog consists of the tasks taken from the product backlog and scheduled to be completed during a specific sprint. Each sprint will have its own unique sprint backlog.
• The daily standup is a 15-minute status-sharing meeting where we only discuss progress. We discuss what we did yesterday, what our plan is for today, and if there are any roadblocks or impediments.
• We use information radiators to share progress in a co-location area: Burn down (how much work is remaining), Burn up (how much work is done), Task board (status board), and Kanban board (it gives work in progress and bottleneck in the process).

• Sprint review (Demo): Once your sprint is completed (time is completed), we show the customer only those user stories which are completed according to our definition of done, and the customer accepts them according to acceptance criteria. Anything that is rejected or not completed goes back to the product backlog, and anything accepted goes to product increment.
• Sprint review (Grooming): Once the demo is done with the customer, the product owner re-prioritizes the product backlog based on customer feedback for the next sprint.
• Sprint retrospective: Team members gather to reflect on the recent sprint following 5 steps:

1. Lean is all about waste removal. We try to minimize lead time (total time from requested till it is completed) and cycle time (when the team starts working on it till it gets completed), and we use value stream mapping for it.
2. Osmotic communication occurs when the team overhears conversations in a co-located area. It helps to clarify and improve team experience.
3. Spike is the time you set aside to handle risk. We have an architectural spike (proof of concept in sprint zero) and a risk spike to handle risk.
4. Scrum of Scrums (SOS): When the team is larger than 12 members, we can have multiple scrums.
5. Test-driven development: When you first write the test and then start coding. Initially, the test will fail, then pass, then you do refactoring (housekeeping – cleaning code).

Steps for Closing a Project or Phase

1. Project is successful/unsuccessful.
2. Get approval from the sponsor for closing the project.
3. Measure/validate the benefit of the project according to the benefit management plan.
4. Check procurements are closed and try to close them as much as you can.
5. Start writing the final report.
6. Start writing the lessons learned register and once done, update the lessons learned repository.
7. Start updating the documents, and once done, archive all the documents.
8. Both the artifacts, i.e., documents and lessons learned, go to OPA.
9. Make sure the operations team is trained and ready for transition.
10. Send the final report according to the communication management plan.
11. Release your team and perform administrative closure.
12. Celebrate success and close the project!

How to Solve the PMP Questions

1. Slow down and read the questions slowly so you can understand them better.
2. Identify the keywords. Every question will have a keyword; recognize it, and you can answer the question.
3. Understand where you are in the process groups: Initiation, Planning, Execution, Monitoring and Control, and Closing.
4. Determine whether the question is related to Agile or Predictive methodology. If unclear, consider it a hybrid question.
5. If a question exceeds three lines, start by reading the last lines first.
6. If you don’t do anything else, follow this: Elimination techniques – go through every single option and justify it as right or wrong.
7. Once you are done with the questions, review them and put your lessons in an excel file to review them.
8. In PMP questions, two options are typically irrelevant, and two are close to being correct. Always select the best answer, as there is no penalty for incorrect responses.