PMP Mind-set
Andrew Ramdayal – 1
1. Conflict resolution - problem solving or conflict resolution should be inclusive, include opinions of
both parties and then analyse for resolution.
2. Servant leadership - in agile, let the team solve problems, just empower, engage and coach the
team and sometimes get the members trained in something they are not aware of, but which is
required on project. If there is any administrative issue on the project, own it, solve it, and don’t
push administrative issues to team.
3. Team - In agile, don't change team within sprints or a defined part of product backlog. In traditional
project, this is possible but must be avoided on agile project
4. Customer engagement - if customer is not happy about deliverables, breakdown the work in more
& more smaller pieces and involve customer feedback or inputs on more & more smaller
increments of product for refinement of requirements and matching customer expectations.
5. Change management - on exam, suppress or deny the change are always wrong answers as we
always anticipate and embrace the change. On traditional project assess the change and manage
change once approved by change control board. On agile projects, bring everyone to table to assess
the change, be inclusive. Once change is there, get product backlog reprioritized by product owner
6. Compliance - no matter what and who is saying what, compliance is mandatory. If project sponsor
is not supporting compliance change, educate him why it is required for implementation, do the
changes to plan and manage execution of changes.
Mohammad Rahman
1.
2.
3.
4.
5.
6.
Always discuss, investigate, analyse, ask, assess before deciding on a solution.
Never settle for delays or extra costs. However, extra costs precede delays.
Be a servant leader! (Encourage, care, nurture, listen and never create friction in the team).
Value is gold.
Root cause analysis and MVP or demo are your weapons.
Any change will go through a change request process (for predictive). There is no change request
process (for agile).
7. Your team members are the experts, not you! Make every decision with them.
8. The PM makes the decisions and handles the issues (no running to sponsors, management or HR).
Note: The exam will mention project sponsor many times. ONLY go to the sponsor when there is a
problem with the budget (example, money is running out) BUT going to the sponsor should be the
last resort.
9. Everyone directly or indirectly involved is a stakeholder and must be added to the register
(stakeholder register) and how they impact the project.
10. No matter if the project is completed or terminated, the closing phase must occur (predictive).
11. In a predictive project, your plan is your map. Constantly refer back to it.
12. Predictive project keywords: change control board (CCB), change control process.
13. Agile project keywords: sprint, iteration, scrum, daily standup, backlog, Kanban, product increment,
product owner/manager.
14. When you or your team have no clue on what’s going on, a subject matter expert (SME) is what you
need. Or, you can refer to past projects in the lessons learned register.
15. When transitioning from predictive to agile, introduce agile concepts slowly (pilot project, inception
deck)
16. Agile projects are self-organizing - meaning teams are in charge however the PM can still step in to
manage and resolve conflicts
17. An agile project will always need consistent feedback from the customer
18. Never immediately reject a request or an opportunity - especially from a client
19. When the question mentions that a similar past project has been completed, choose the answer
that allows you to refer back to that project. (OPA's Lessons Learned Register, etc.)
20. When the answer mentions information NOT mentioned in the question, eliminate the answer.
21. Anytime an answer mentions 'Only' or any other word that eliminates all other possibilities,
eliminate the option.
22. When there is an occurrence that affects the schedule, choose the answer that looks at the critical
path.
23. Never give your team member an extra task that will reduce their capacity to focus on their primary
task. This includes grouping them with other members to train.
Andrew Ramdayal – 2
1. The Traditional PM Mindset Part 1
 Identification and analysis of stakeholders is something that is done throughout the
project not just at the beginning.
 Always follow a plan and never allow changes to the plan without an approved change
request.
 Any stakeholder that wants to change any component of the project management plan
will need to submit a change request.
 All change requests will need to be reviewed and assessed.
 Never take actions without first creating a plan.
 Consult with the project team before making decisions, as they will have a more
practical approach.
2. The Traditional PM Mindset Part 2
 Your final decision should always benefit the objectives of the project. For example, if
there are conflicting methods on how to complete a particular task, then choose the
method that would deliver the most value to the project outcome.
 Try to use tools that are inclusive such as a whiteboard with a marker versus complex
software.
 All scope changes should be assessed on how it will impact all other parts of the project
including schedule, cost, quality, resources, communications, risk, procurement, and
stakeholders’ engagement.
 When conducting estimating uses a bottom-up approach and not a top-down. This will
lead to more correct estimates but will require more work.
3. The Traditional PM Mindset Part 3
 Your 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.
 Update the lesson learned register throughout the entire project. This way it can be
transferred to future projects in the organization.
 When closing the project ensure all bills are paid off and resources are released.
 Projects that are terminated early still needs to be close formally through the close
project or phase process.
4. The Traditional PM Mindset Part 4
 The best people to break down work is the project team.
 The best people to determine when a particular activity may happen is also the project
team.
 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.
5. The Traditional PM Mindset Part 5
 Before resolving a conflict between team members be sure to understand the source of
the conflict.
 Conflicts between team members should always be resolved for the benefits of the
project objectives not to satisfy one member over another.
 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 to be
delivered, and who will deliver it to them.
 Utilize the skills of emotional intelligence to analyze your own feelings and those around
you to respond to stakeholders needs and requirements. Emotional intelligence allows
you to solve problems quicker and more effectively
6. The Traditional PM Mindset Part 6
 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.
 A negative risk is known as a threat while positive risk is known as an opportunity.
Ensure to identify and document responses to both.
 When selecting a contract to use on a project with potential sellers, always use a
contract that is mutually beneficial to both the seller and the buyer to the overall
benefits of the project objectives.
 Engage stakeholder often and regularly. Use things such as meetings, one-on-one
conversations, phone calls, and presentations to engage them.
 When engaging your stakeholders ensure they understand the communications that
they are receiving. Tailor your communications to individual stakeholder needs.
7. The Agile PM Mindset Part 1
 Be a servant leader to the team at all times. This includes empowering them and
removing any impediments. Give them the tools they need to succeed while staying out
of their way.
 Engage the product owner to document the features and to prioritize them 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 job
of the product owner.
8. The Agile PM Mindset Part 2
 Use a co-location
 Face-to-face communications with a white board and markers are the best form of
communications.
 Provide agile teams with lots wall space so they can write on them and use sticky notes.
9. The Agile PM Mindset Part 3
 Information should always be radiated through the use of large charts and graphs, such as
the use of a burnup or burned down chart.
 Any problem that occurs on a project should be resolved by the project team. Always let the
project team choose a solution while coaching and supporting their solutions.
 Provide a safe environment for disagreements. Do not punish anyone for having a
difference of opinion. Understand that conflicts is a positive step and an opportunity to
learn.
10. The Agile PM Mindset Part 4
 Try to limit the work in progress through the use of the Kanban. Kanban boards should be
displayed either on a large whiteboard or less desirable large monitor.
 Consistently communicate and re-communicate the project vision to the team.
 Understand the needs of your team members and find out what may motivate them
11. The Agile PM Mindset Part 5
 Make sure people understand what failure and success will look like on the project.
 Be a central figure to the team, not a dictator.
 Have good ethical values
12. The Agile PM Mindset Part 6
 Review the methods work was completed by doing a retrospective
 Utilize feedback loops. Feedback loops occurs when you’ve completed the task and then
take what you’ve learned from that and input the lessons learned into your next task.
Important – 1
1.
2.
3.
4.
Never break the law e.g. Safety or Authority Regulations
Never kick the can down the road – never avoid or delay dealing with problem.
Never make your problem the problem of someone else, e.g. another department
Consider escalation to others (e.g. Project Sponsor) as the last resort because it’s YOUR job to solve
the problem. Do not inform people or seek for advice, if YOU get an issue in the project. Solve the
problem by yourself
5. Be a servant leader –
 Never blame nor finger point people
 Coach the team members if they have problems
 Preferably meet with people face to face.
 Remove team impediments proactively
 If problems arise in a project confront them proactively.
 Understand people's concerns (feelings) always before taking actions
 Never fire/replace a team member
6. Before taking actions understand the root-cause and then review the needed documents for that
particular case, Get to the core of the problem first
7. Face-to-face communication is preferable over e-mail or other indirect communication
8. Take action but make sure what you are going to do actually solves the problem at hand.
9. Identify first if you're confronted with a risk or an issue - respond then adequately!
10. Understand whether the issue is based on assumptions/claims or on proven facts!
11. If customer interest is at stake, force is best approach. Also when team is new to agile, PM can be
directive mode till teams become self-organizing
12. Never wait to do something, be proactive!
13. Don't be bullied into deviating from your process
14. Welcome change, learning and work in small increments.
Important – 2
1. Once the risk has happened and is an issue now what should he PM do first in an agile project?
Analyze the impact the issue has on the entire project OR Work with the team to decide the course
of action
2. Always remember - Remember the Agile core values: Individuals and interactions over processes
and tools. One of the main tenets of Agile is co-located teams. Everyone's in the same work area, so
your team is all right there. There’s no reason to analyze it alone. Get their attention and swarm
around the issue.
Important – 3
1. General PMP Mindset (Applies to All Approaches)
 Always investigate, analyze, and ask before deciding on a solution. When the question
asks what the PM should do first or next, remember this principle. Also, depending on
the situation, sometimes you may need to talk to the team for more info.
 Never settle for delays or extra costs. However, if both exist, extra costs are accepted
before delays.
 Value is gold. Focus on delivering value in every decision and conversation.
 Root cause analysis and MVP (minimum viable product) or a demo are your weapons.
 Your team members are the experts, not you! Co-create decisions with them.
 Be a servant leader. Care, support, listen, and never create friction.
 Everyone directly or indirectly involved is a stakeholder and must be added to the
register (stakeholder register) and how they impact the project If a stakeholder is
unhappy, review and implement the plan they are not happy about
 Never immediately reject a request or opportunity—especially from the customer.
Listen first.
 Admin tasks should be done by the PM The PM makes the decisions and handles the
issues (no running to sponsors, management or HR). Note: The exam will mention
project sponsor many times. ONLY go to the sponsor when there is a problem with the
budget (example, money is running out) BUT going to the sponsor should be the last
resort
2. Predictive Project Mindset
 Your plan is your map. Keep referring to it.
 Any change must go through a formal change request and the CCB (Change Control
Board).
 No matter how a project ends (completed or terminated), closing must occur.
 You do not escalate minor issues. The PM resolves issues. Go to the sponsor only for
high-level problems like budget overrun.
 When in doubt or facing uncertainty, refer to lessons learned or a subject matter expert.
 Predictive Keywords: plan, WBS, schedule, CCB, change log, lessons learned, sponsor,
phase gate.
3. Agile Project Mindset
 Agile teams are self-organizing. They manage their own work. The PM supports, not
commands - meaning teams are in charge however the PM can still step in to manage
and resolve conflicts
 Stand up Meetings in Agile /Scrum are only for discussing 3 questions (what did you
work on yesterday? what will you work on today? any issues?)




In Agile, there’s no change request process. Changes are managed within the backlog.
Agile projects require regular feedback from the customer.
Introduce Agile slowly when transitioning from predictive—use a pilot or inception deck.
Agile Keywords: sprint, iteration, scrum, Kanban, product owner, daily stand up, backlog,
demo, product increment.
4. Incorrect PMP Mindset Statements (Avoid These Thinking Errors)
 “The PM decides everything alone.” No! Decisions should be collaborative with the
team.
 “Escalate to the sponsor for every issue.” No! Only escalate as a last resort—typically for
budget or scope threats beyond the PM's authority.
 “Only core team members are stakeholders.” - Wrong. Anyone affected or involved—
directly or indirectly—is a stakeholder.
 “Once a project is cancelled, no closing is needed.” - Incorrect. Closing is always required
to capture lessons, release resources, and update documentation.
 “Change requests apply in both Agile and Predictive.” - False. Agile does not use formal
change requests—they’re built into backlog refinement.
 “Agile means no structure or leadership.” - Wrong. Agile teams are structured and
disciplined. The PM still supports and may resolve conflicts.
Important – 4
1. When the option mentions the PM to take a step back and assess the situation before deciding on
an action, it is the correct option
2. If the question mentions that there will be a potential schedule delay or affects the schedule /
schedule change, always choose analysing / looking at the critical path
3. Never give your team member an extra task that will reduce their capacity to focus on their primary
task. This includes grouping them with other members to train.
4. If there are 4 bad answers, choose the best one; if there are 2 good answers, choose the one that
should be done first In Agile.
5. Product Owners are accountable to approve / reject changes and to reprioritize the backlog. The
PM and team can add/remove items to the backlog only after discussing with the Product Owner.
Also, Product Owners are the only ones that have the authority to cancel the sprint. They should be
involved when any changes/issues occur.
6. Review the problem before you inform stakeholders. If a task has already been reprioritized and
there are still issues, you should communicate to the stakeholders. Also, if there’s a risk (not
happened yet), you update the Risk Register. Don’t mix-up an issue (already happened) with a risk.
Important – 5
1. Situational questions:
 First, make it a habit to read the last sentence (the main question) FIRST before reading the
whole prompt. So you know to search what to: Do? Action, normally see impact or if there is
something already set in stone (The approval has been given, Law regulations enforced) then do
it Do first? Normally review a document/asses situation - should have been done? Look for
Reactive things. Not actions to do now that there is a problem. Not do? Least likely/most likely?
Most important least important? Notice the subtlety.
 Second, what framework are you in? (Agile, hybrid, predictive/waterfall?). That will help
eliminate good sounding options that are not valid because they are from another framework.
 Third, which process are you in? Are you initiating, executing, M&C, closing?
2. Mentality: Always think like servant leader, forget about experience while attempting exam. Never
ask for others to do your job (The sponsor, the PMO, the product owner...). Always try face to face
communication, Train your people is normally the best option.
3. May/might/claims = questions is about risk
4. Will/should/could = questions is about issue
5. Related to team issue = team charter
6. Stakeholder related = stakeholder engagement
7. Action is next step, assessing and review is 1st step Remember while selecting answer = assess >
review > action/implications
8. If questions related to safety problem, stop the project immediately.
9. If question likely to have problem due to new law may introduce or from internet information =
update the risk register. If not then do the action to follow it. If there is problem due to new law
implications, seek for guidance
10. Problem between member = team charter, meeting preferably face to face (not apply in case of
multiple locations).
11. Asking help from Sponsor and PMO is NOT an option.
12. Before any change, always asses and check impact. Change request is approved in formal process.
NEVER implement any change by yourself. Always with approval.
 If anything missed in scope which may lead to rejection of deliverable = change request
 Adding extra features = talk to team
13. Meeting and coaching are the best options for conflict.
14. Quality control = customer are best option
15. Not performing as expected = Quality
16. Bottom-up estimate is best option for cost
17. Prototype is best option for demo
18. Never remove a member, remove a vendor or hire a consultant
19. There should be predetermined acceptance rules for acceptance of delivery
20. If project required close, follow the formal process always.
21. If stakeholder don't know about agile, coach and teach them about agile
22. If there is any issue related to payment/contract with vendor always ask them to check with
appropriate department
23. Delay in item sent by vendor/ quality issue with vendor, meet and brainstorming with team and
come up with solutions
24. Always add communicated with PMO about status of project and customer in Sprint
25. Sprint is important for communication for both customer and team.
26. Not to take any bigger actions like a change request or closing a project without taking care of the
smaller tasks first. So whenever we see that "what should PM do next/first" it's almost always a
preliminary action like reviewing a plan or meeting with the team and using the information
gleaned in THAT step to make the decision on the larger task: 1- assess/ analyze the problem to find
out root cause 2- review the plan 3- meeting.
Important – 6
1. General –
 Always discuss, investigate, determine root cause, review, analyze, assess, and ask/consult
before deciding or taking action— especially if it says ‘what should PM do first or next’.
 Collaborate with the team when making decisions or developing plans.
 Act as a servant leader — support, coach, and mentor your team.
 Focus on prevention over inspection — deal with risks and issues proactively.




Base actions on data, trends, or impact assessments, not assumptions or gut feelings.
Refer to the project vision or objectives if the team is confused or misaligned.
Respect organizational processes and governance — don’t bypass them
Avoid escalating or involving third parties like HR, sponsor, or steering committee — unless
the situation explicitly calls for it.
 Don’t delay, pause, or stop the project unnecessarily — keep progress moving
 Don’t overreact — avoid firing, rejecting, or making extreme decisions unless ethically
required. If all the options sound bad, try to pick the better one. If all the options sound
good, try to pick the one that must happen first.
2. Stakeholders & Communication
 If a stakeholder is unresponsive → revisit the Stakeholder Engagement Plan.
 If a stakeholder missed updates → check the Communication Management Plan.
 Meet 1-on-1 with stakeholders to resolve conflicts or understand preferences.
 Tailor communication style and frequency to stakeholder needs, not fixed cycles (e.g., not
“monthly” or “daily” by default).
 Consider cultural and individual preferences, especially with global teams.
 Don’t act immediately on requests — analyze feasibility and impact first.
 Keep stakeholders engaged and informed throughout the project lifecycle.
3. Agile / Hybrid:
 Product Owner owns the backlog and prioritizes based on value and stakeholder input.
 Team owns sprint backlog, story points, and velocity estimation — empower them. Ideally,
velocity should be consistent.
 Once a sprint begins, no changes.
 Use demos for progress, retrospectives for improvement, and refinement for clarity.
 Backlog Grooming / Refinement can happen before sprint planning. Ensure safety / health /
security regulations are included in Definition of Done.
 If the org is transitioning to Agile → provide training and coaching.
 Agile is feedback-driven — use MVPs and early releases to validate and adapt.
 Use video calls for distributed teams to maintain face-to-face communication.
 Avoid command-and-control behaviours — support sustainable pace and shared ownership.
Burn down chart shows work remaining. Burn up chart shows work completed. Spike is the
horizontal part of the graph. Bottleneck in Kanban is when the number of items = WIP limit
 Hybrid = when part of the project is predictive (e.g., regulatory) and part is adaptive (e.g.,
user interface)
4. Predictive (Waterfall):
 Can’t update baselines (scope, schedule, and cost) without a formal change request.
 Initiating a change control processes involves assessing the impact.
 Work authorization and governance systems must be followed.
 Project charter = high level; scope baseline = scope statement, WBS, WBS dictionary.
 Cost baseline = estimates + contingency; project budget = cost baseline + management
reserves. CPI, SPI > 1; CV, SV > 0 means good (under budget, ahead of schedule).
 Risk, quality, and stakeholder management are ongoing efforts, not one-time tasks. For
schedule delays, prefer Fast Tracking over Crashing (unless the question says additional
funds are available). For resource optimization, prefer Smoothing over Levelling (to avoid
changing the critical path).
 If a project is terminated early, a formal project closure must still happen. Risk & Issue
Management:



“Something may/might happen” = risk, “has/will happen” = issue.
Add new risks to the risk register, and active issues to the issue log.
Don’t ignore or delay risk response — act early and appropriately. If a known risk
materializes → it becomes an issue; execute the planned risk response.
 Use Monte Carlo simulation for scenario-based risk analysis. Like when there’re multiple
scenarios that need to be analysed
 New regulations? → Assess impact first, then update risk register if applicable.
 Escalate only if the issue exceeds your authority — not just because it’s difficult.
Contingency reserves are for known risks and management reserves are for the unknowns.
Generally, approval is not required for using contingency reserves, but it is necessary for
using management reserves.
5. Quality, Procurement & Resource Management:
 Quality Control = product-level; Quality Assurance / Plan Quality = process-level.
 If a deliverable is rejected → review the acceptance criteria.
 For vendor/supplier issues → refer to the contract and procurement agreements.
 If a team member lacks knowledge → arrange training or mentoring. Refer to OPAs,
historical info, or lessons learned — especially if a similar project was done before. Consult
SMEs if absolutely no idea.
 For resource constraints → work with the Functional Manager to resolve.
 Establish and follow a Team Charter / Social Agreement with team norms and ground rules.
 Use the team charter or conflict resolution techniques for team issues or misbehaviour.
Collaboration (win/win) is usually best for conflict resolution. Compromise is the second
best.
 Recognition should be timely, relevant, and based on team member preferences. Team
evaluation should be fair and transparent.
6. Red Flags:
 Be cautious of options with harsh tone: instruct, demand, force, and command.
 Avoid answers with:
o Rigid phrases: always, never, only, immediately, do nothing, pause project.
o Specific timelines: weekly, monthly, daily (unless the question says so).
o Third-party escalation: HR, sponsor, steering committee — unless the scenario
involves them.
o Single-constraint focus: answers that mention just cost, schedule, scope or quality,
without considering the others.
Important – 7
1. Correct Answers:
 Facilitate, Engage, Collaborate, Discuss
 Assess, Analyze, Evaluate, Review
 Adapt, Align
 Support, Guide, Coach
 Prioritize (especially when dealing with the backlog)
 Root Cause Analysis or RCA, Minimal Viable Product (MVP) or Minimal Viable Feature
2. Incorrect Answers:
 Wait, Defer, Postpone, Delay
 Replace (a team member), Hire, fire
 Ignore, Escalate to Sponsor
Important-8
1. Following these 5 steps for almost anything along with common sense helped me get 65% of the
answers right.
 Identify/Update- Always identify the root cause before taking action
 Analyze/Evaluate- Once you identified it- Analyze it to see the impact it could have
 Implement- Once you know this is what I am going to use. Implement it
 Monitor- Monitor it to see if it adds additional risk or what is the impact now
 Control
2. Always update the assumption, issue, or risk logs when there is new information, a new risk is
identified, or when there are changes in the stakeholder, update the stakeholder register (e.g.,
someone leaves or joins).
3. If a customer is not accepting deliverables, review the acceptance criteria.
4. When a new team member joins, update the communications management plan.
5. For new projects or you get assigned to a new project or you are a new PM, start by identifying the
purpose and high-level requirements then follow your normal process
6. Predictive projects have a fixed scope, schedule, and budget. Avoid changing these elements as
they will have a significant impact on the project. if you have to, submit a change request
7. Change requests:
 Should be accompanied by evaluating new risks.
 When someone wants to add something to the scope.
 When critical requirements are not met.
 All change requests will need to be reviewed and assessed.
8. Never take an action without first creating a plan.
9. Consult with the project team before making decisions, as they will have a more practical approach.
Your final decision should always benefit the objectives of the project
10. The project sponsor is generally responsible for the development of the business case and is the
logical source of objectives for success.
11. Engage stakeholders as early as possible in any key decision-making or when communicating
challenges.
12. If the project is going to go over budget and requires more resources, do not try to finish it within
the original scope. Notify and request/submit a change request.
13. Re-evaluating the project scope is crucial because hybrid approaches often require more flexibility
and adaptability when Transitioning from a predictive methodology to a hybrid approach
14. If there are issues with stakeholders, identify them by meeting with them.
15. If multiple departments are involved, meet with the functional managers of the relevant
departments to ensure alignment with goals, then define detailed product requirements
David McLachlan – Fast track
General
1. When answering Exam questions, always assume the information you need to answer the question
is included in the question.
2. There will often be two or more possible answers: Prioritise the answers from best/most likely to
worst/least likely based on the information provided.
3. Avoid extreme actions in your answers, such as closing a project, escalating to the Sponsor or
other external party, not helping the customer, or answers that say you “must”, or “only”.
4. Aim for answers that have inclusiveness and collaboration, or an action by the Project Manager.
5. Don’t rush into action in your answers – first:
 Assess and analyse the situation (i.e. review the plan or brainstorm with your team) to
understand the Root Cause of the issue.
 Review your plan, Meet with stakeholders to work out a solution and then take Action
6. Don’t skip project steps, processes or documents to accelerate project delivery or closure.
7. Don’t pass the problem to someone else, or escalate to management unless it’s a last resort.
8. The Project Manager is always proactive, puts the team first as a servant leader and is a good
steward for the business / customer’s goals.
9. There may be different types of scenarios, that ask:
 What should you do? Normally an action.
 What should you do first / do next? Normally assessing the situation or reviewing a
document.
 What should have been done? Look for what could have been done to prevent it.
 What should you not do? Look for the worst option.
10. Dealing with Resource Requirements: work with the Functional Manager of that area.
11. Risks are things that might occur in the future, Issues have already occurred. When a Risk becomes
an Issue, manage it with the response already outlined in your Risk Register.
12. When guidance is needed, review the process in the relevant plan (i.e. Scope Management Plan).
Overall guidance is in the Project Management Plan.
13. Determine the source of any conflict before acting. Discuss issues with your team, using their
Expert Judgement.
14. Figure out what framework you are in: Predictive (Waterfall), Adaptive (Agile), Incremental,
Iterative or Hybrid, then answer accordingly. Sometimes it says it explicitly, other times you have to
guess (it might include keywords such as Iterations or Sprints, Product Owner, Retrospective, etc.
Traditional Project Mindset
1. The Project Manager assigns the work, based on the skills of the team and the work required to be
completed.
2. Stakeholder identification and analysis is done throughout the project, not just at the beginning.
This includes analysing, agreeing and tailoring communication needs. Engage and communicate
often (or as outlined in your Stakeholder or Communication Plan).
3. Virtual Teams will use video conferencing, accommodating time zones and cultural differences. The
preference is for co-location where possible.
4. Any stakeholder who wants to make a change to a baselined item (i.e. the approved Scope,
Schedule or Budget) will need to submit a change request.
5. Change requests are analysed for their impact to Scope, Schedule, Cost or Quality and brought to
the Change Control Board (CCB) for approval. This process (including members of the CCB) is
decided in your Change Management Plan.
6. If you are unsure, ensure your decisions ultimately deliver business value and benefit the
objectives of the project. This includes any decision, such as conflicts between team members.
Always revert to business value.
7. For any problem or conflict, find and understand the root cause before taking action.
8. Your job is to integrate the many parts of a project (Scope, Schedule, Cost, Resources, and Quality).
Do not focus on one aspect at the expense of others.
9. Your team are the best people to break down the work, estimate on its effort or time, and
determine when an activity should happen.
10. Your project customer is the best person (or group of people) to determine Quality requirements,
and ensure your product meets those requirements.
11. Identify and manage risk throughout your project, not just at the beginning. A negative risk is a
Threat, a positive risk is an Opportunity (identify both).
12. Risks are items that could happen in the future, Issues are items that have happened and we
manage them now.
13. When selecting a contract for a vendor, ensure it benefits both the seller, the buyer and the
objectives of the project.
Agile Project Mindset
1. The team self-organises and self-assigns work.
2. The Project Manager should be an advocate for Agile principles and methods.
3. Always use the Servant Leadership style to grow and develop your team, and remove obstacles or
blockers. Collaborate, don’t dictate.
4. The Product Owner represents the business or the customer, and prioritises the features in the
Product Backlog based on the highest business or customer value. Any changes in scope go through
them.
5. Co-locate your team to ensure fast communication and learning from conversations around them
(osmosis).
6. Always prefer face-to-face communication, as it is the richest form of communication (with body
language, facial cues, voice tonality, along with the words themselves).
7. Use an Information Radiator in your team area to showcase project information openly to anyone
who needs it. This can be charts on walls (physical or virtual) including the Kanban Board,
Burndown or Burnup charts, Remaining features, Releases, Risks etc.
8. When problems occur, problem solve with the team, coach and support them to a resolution.
9. Ensure psychological safety – where your team can fail or experiment without being punished,
raise concerns or ideas and discuss things openly.
10. Reduce or remove multi-tasking where possible to promote focused work instead, by limiting WIP
(Work in Progress) and solving bottlenecks. You can see these on your Kanban Board where User
Stories start to pile up.
11. Create a Team Charter with input from your team to decide ways of working, ensure everyone
understands the mission and what success looks like.
12. Fast feedback loops are important. Use Retrospectives to raise and solve issues in the team’s way
of working.
13. Use Demonstrations or the Sprint Review to gather feedback on the product from the customer.
Agile Scenarios
List of scenario examples and what to do –
Visual Data Representation Tools
Some important graphical representations –