While preparing for the Project Management Professional certification, I identified mindset principles and lessons that can help others navigate the exam’s scenario-based questions. These insights go beyond theory, they reflect how to think through complex, situational problems. Keep in mind that many questions are nuanced. While multiple answers may seem valid, the correct one often aligns with the most appropriate mindset for that context. For a strong foundation, study the Project Management Body of Knowledge Guide, Agile Practice Guide, Scrum Guide, and the Agile Manifesto. This list is not exhaustive and should support, not replace, a thorough and well-rounded study plan. Here is the list below:
- Evaluate and assess the impact of changes before anything else
- Any change to the project baseline be it scope, cost or time must go through the Change Control Board for approval in predictive methodology, Agile does not have an official change control body because of its principle of flexibility, it manages change through its continuous feedback mechanisms such as the sprint review, daily scrum and retrospective
- Engage with stakeholders and collaborate with teams first before decision-making
- The stakeholder engagement plan is for strategies to connect well and engage with stakeholders based on needs, expectations, interests, and potential impact, and the communication management plan documents how best to reach them and keep them informed
- Contingency reserves are specifically allocated to address known risks. Management reserves are for unforeseen risks or situations not identified during planning.
- The sponsor is responsible for developing the business case document, they are also responsible for securing resources
- The project charter is created at the initiation stage of the project. It also provides the Project Manager with the Authority to manage the project within a defined scope and constraints
- Communication helps the team function better
- A good way to align remote teams is to make sure the right technologies are available for collaboration
- A situation that comes up, like defects, etc, should be recorded in the issue log, and the risk that is emerging should be documented in the risk register after the impact has been evaluated
- The Product owner is responsible for the Product backlog, and no matter how high the stakeholder is rated, they have to negotiate with the Product Owner for changes, even the Sponsor
- Escalation of issues should be a last resort
- A new sprint begins immediately after the conclusion of the previous one
- Audits are to ensure that control processes are being followed and solutions utilized are effective, so a quality audit ensures that a quality management plan is being followed, and risk audits ensure risk management processes are being followed
- In Projectized and strong matrix organizations, Project managers have a lot of power, but in weak matrix organizations, they have to seek the support of the functional manager
- To ensure effective use of resources by adjusting start and end dates to avoid over-allocation, use resource leveling
- If the project needs to be completed earlier than stated and there is enough budget, crash by adding resources to the critical path
- If the project needs to be completed earlier than stated and there is not enough budget, fast track by adding executing tasks in parallel or simultaneously
- Stakeholders must be carried along from the beginning, and attention must be paid to their requirements and success criteria
- If a stakeholder or team is not collaborating as they should, always hear from them first to ask why, and also work with them to solve the problem before anything
- Any changes that affect vendors should be noted by updating their contact agreement, after the Perform Integrated Change Control
- The Development team is responsible for creating the Sprint backlog
- All Scrum events are timeboxed
- Bottom-up estimating is best for projects with a large number of work packages
- The scrum artifacts are Product Backlog, Sprint, and Increment
- The sprint goal can not be changed, but during the sprint, the development team can reprioritize the sprint backlog and may ask for support from the product owner
- When a new member joins the team, the team reverts to the forming stage of Tuckman’s group development model, and a review of the team charter is necessary. A team charter shows complete agreement on the team’s purpose, goals, and how it will work together.
- Only the Product Owner has the authority to cancel the Sprint
- For multicultural teams, the Project Manager should take into cognizance cultural differences and nuances when engaging and encourage the project team to do the same
- Identification and analysis of stakeholders is an ongoing process in project management because change is constant
- Iterative and incremental delivery are Agile practices. Iterative focuses on refining the product through cycles of development and feedback. Incremental focuses on delivering usable portions of the product at regular intervals
- Kanban helps limit Work-in-progress, aka doing stage- stages are To do, doing, to be reviewed, done, other terms can be used, but the term synonymous with doing is where you limit work-in-progress
- Lean leverages deciding as late as possible and deciding as fast as possible in its principles, don’t confuse them
- The scrum master removes impediments for the scrum team and makes sure they adhere to Scrum Principles
- If a team member is not available for a period during the sprint, the development team should collaborate with the Product Owner to remove some sprint backlog items after evaluating the impact of their absence, if necessary
- A scrum team is between is made up of no more than 10 members
- Develop team versus manage team: Develop Team is the process of improving competencies, team member interaction, and the overall team environment to enhance project performance. Manage Team tracks team member performance, provides feedback, resolves issues, and manages team changes to optimize project performance.
- The developers are responsible for meeting the sprint goal at the end of the sprint
- The WBS is built using the project charter
- When two teams work together, the first thing to do is note the interdependency between them to see how that can affect the execution of tasks
- Systemic thinking involves examining project components as a whole and determining how each component interacts with and affects the others. This approach helps improve decision-making and problem-solving.
- Perform qualitative risk analysis before performing quantitative risk analysis. Qualitative risk helps recognize high-priority risks by looking at their probability and impact. Quantitative risk analysis uses numerical strategies to check the impact of overall project risks and other uncertainties
- A risk register is used to track risks and is updated as they are being identified, and risk reports are used to communicate the status of project risks
- Issues are actual occurrences that have affected the project; risks may or may not occur
- Lesson-learned documentation helps to document information from the current project or project phase that can help with future projects. It is an important part of the Organizational Process Assets, which are processes, policies, and procedures that guide project management practices in an organization. It can be captured during each project phase or at the end of the project
- Regulations and legal or compliance requirements may require specific documentation to ensure that the project meets certain standards or guidelines in Agile. Remember, Agile uses limited documentation, but documentation is not absent
- Verification helps ensure that the project is progressing as planned, that the scope is being met, and that each component meets/ conforms to predefined standards before moving forward. User testing, acceptance testing, and feedback. Verification answers the question” Did we build it right?” internally. Validation ensures that the final product or deliverable is truly what the customer or stakeholders need and is capable of meeting their expectations and requirements. This could be Inspections, reviews, and audits to answer “Did we build the right thing?” that is confirmed by external stakeholders and end users
- No official change control board in Agile, since there is limited documentation
- The daily scrum can not exceed 15 minutes. Like most scrum events, it is timeboxed
- You can review a definition of done you were not able to achieve during the last sprint in preparation for the next sprint during the Sprint retrospective, since a retrospective is the scrum ceremony where you identify bottlenecks
Leave a comment