BKPM Pocket Guide for Project Managers
1
BKPM Pocket Guide for Project Managers – Release 4
© 2020 by Think
The information, material and techniques presented in this guide are
for authorized users only and are not to be shared outside of the
Think Systems Inc. employee, client and marketing base. Further,
these materials are not to be copied or used for any other internal or
external purposes.
02/01/2020
BKPM Pocket Guide for Project Managers
2
Contents
Forward ....................................................................................4
How to Use This Guide .............................................................5
BKPM Guidance for Transformation .........................................6
BKPM 10 Minute Daily Checklist ......................................... 6
Project Phase Guidance and Details ................................... 7
Think’s Rapid Control Process ............................................... 10
1. Discovery & Immersion .................................................. 10
2. Planning ........................................................................ 10
3. Validation & Risk Mitigation ........................................... 11
4. Kick Off .......................................................................... 11
5. Active Management & Control ....................................... 12
Roles in the Rapid Control Process ........................................ 13
RCP – Initial Project Meeting (Immersion) .............................. 16
Initial Project Meeting: Readiness Review ......................... 16
RCP – Initial Meeting ......................................................... 16
Project Planning: Specific Requirements & General Rules ..... 22
Project Reporting: General Rules ........................................... 25
Weekly Status Report Template Example ......................... 28
Large or Small Data Projects – ............................................... 29
Squaring Agile with Project Management ............................... 31
Conflict Resolution .................................................................. 37
Recognizing Reasons for Conflict ..................................... 37
Planning for Conflict .......................................................... 37
The BKPM Conflict Resolution Model ............................... 40
Using Principles for New Options for Action ........................... 42
PM Principles and Techniques ............................................... 43
Access (Escape) Portals ................................................... 44
Anti-fragile ......................................................................... 44
Change Management ........................................................ 44
Chunking ........................................................................... 45
BKPM Pocket Guide for Project Managers
3
Conflict Resolution ............................................................. 45
Co-opt Risk ........................................................................ 45
Enumerate without Fear ..................................................... 45
Executive Options .............................................................. 46
Forced Clarification ............................................................ 46
Forced Conflict ................................................................... 46
Forward Motion .................................................................. 46
Guard Rails ........................................................................ 46
G-R-E-A-T .......................................................................... 47
Iterative Approach .............................................................. 47
Land Mines ........................................................................ 47
Mistake Management ......................................................... 47
Momentum over Analysis ................................................... 47
Pre-Mortem ........................................................................ 48
Recovering Value ............................................................... 48
Risk Management .............................................................. 48
Shredders .......................................................................... 48
Simplicity ............................................................................ 48
SMART+ER ....................................................................... 49
Snaking .............................................................................. 49
Spectrum Analysis ............................................................. 49
Strategic Marketing ............................................................ 49
Tempo ................................................................................ 50
Three-Sided Table ............................................................. 50
Time Slicing ....................................................................... 50
Triple Constraint ................................................................. 50
Unafraid of Conflict and Confrontation ............................... 50
Personality Traits of a PM ...................................................... 51
Operating Within the PM Zone ........................................... 53
Working with our Customers’ PMO ........................................ 54
BKPM Pocket Guide for Project Managers
4
Forward
This pocket guide is based upon the principles and frameworks
presented in, Bare Knuckled Project Management; How to
Succeed at Every Project. What is BKPM? In a word, control.
Bare Knuckled Project Management is first and foremost a
mindset; a learned, limbicly conditioned, level of effectiveness
that provides reliable options for action even when rational
decision-making goes out the window. It is a framework for
explaining how to achieve and maintain control over both typical
and highly complex projects. It works because we recast the
role of a project manager and adhere to a set of guiding
principles that we use to reframe how we view and manage
projects. It endures because we systematically alter the
instinctive responses of project managers to be effective in the
face of project wild-cards like stress and data overload. BKPM
is simple, direct and effective. It
leverages the knowledge and
techniques of traditional project
management, like those found in
PMBOK (PMI’s Project
Management Body of
Knowledge), but does so with a
bias toward control and
momentum vs. process. BKPM
works in Agile and Waterfall
projects. It does so because it is
a new way to think about
projects, not a project
management process.
BKPM Pocket Guide for Project Managers
5
How to Use This Guide
Think follows key Project Management principles in
everything we do. So, put this guide next to your keyboard, in
a convenient pocket, stain it with coffee rings or condensation
from a cold drink, but keep it handy. This is your get out of jail
free card; however, it isn’t magic. It’s a tool and you’ll need to
learn how and when to use it. It applies to working with your
sales team, starting a project and getting it under rapid control
regardless of development methodology (e.g. agile, waterfall),
to closing out a Think project.
The single most difficult thing for you to learn is when you should
reach for this guide. Believe it or not, you already know. You just
don’t know that you know and you need to become more attuned
with your feelings. That’s right, you’re human, you have a
powerful brain and a big part of your brain gives you your
feelings. These are the single most valuable indicator that you
need to do something different. Consider this, while managing a
project, if you feel anything other than absolute control, it’s time
to figure out why. Feelings like anxiety, fear, concern, or perhaps
worst of all, indifference, are BIG indicators and tell you that you
need to be doing something other than what you are.
When you feel anything other than control, ask yourself,
“Why?” You may know and simply need to slow down enough
to realize it. Even more likely, especially at first, you’ll ask
yourself why and reach the conclusion, “I have no clue.” As
soon as that happens, grab this guide! There are many useful
tips in this guide including PM principles, Think’s Rapid Control
Process, project kick-off job aids and much more.
BKPM Pocket Guide for Project Managers
6
BKPM Guidance for Transformation
Are you ready to hack your brain to become a BKPM? It is
possible; you just need to learn to slow down your thinking and
trigger the cognitive frame shifting that makes you look at a
project the way a BKPM does. Over time, this becomes an
intuitive conditioned behavior and you’ll become a master
performer that seems to think ahead of everyone else.
BKPM 10 Minute Daily Checklist
1. Look at your project plan:
a. Are you on track on all active tasks?
b. Are all of your resources focused on what
they should be?
2. What could possible go wrong today? What could
possibly go right?
a. Run through ALL of the BKPM principles.
b. Have a feeling? Develop a plan of action
and execute.
3. Clear your mind and put your Strategic Project
Manager hat on:
a. Evaluate your own tactical efforts.
b. Seeing any cultural shredders?
c. Are you able to recognize lurking project
constraints?
d. Where might the project hold intrinsic value
to the organization that can be captured?
4. Execute!
* reference the project phase guidance that follows for more
details
BKPM Pocket Guide for Project Managers
7
Project Phase Guidance and Details
Start of Project
It doesn’t matter what the project is, you must immerse in its
details to develop a minimal level of ownership in the process
you document and manage to. Work through the Rapid Control
Process (RCP); it is detailed in your pocket Guide. Adjust each
step in the RCP so it is right-sized for your project, but complete
it! Make sure your project plan has enough detail (tasks,
resources and deliverables) to understand what everyone
should be working on when you look at it each day.
Daily Checklist (additional detail)
Dedicate 10 minutes of your morning to think through your
project like a BKPM:
1. Look at your project plan. Answer these questions:
a. Are you on track on all active tasks? Don’t assume.
How do you verify?
b. Are all of your resources focused on what they should
be? Again, how do you verify?
2. Ask yourself, “What could possible go wrong today?”
It’s far more difficult to answer than you could possibly
imagine. This is where you must learn to slow down your
thinking and use cognitive frame shifting:
a. Run through ALL of the BKPM principles. Many will
not apply to the specific stage of the project you are
in, that context is ever changing, but some will.
b. When you read a principle that causes you to have a
feeling that is anything but control, investigate it.
Develop a plan of action and execute.
BKPM Pocket Guide for Project Managers
8
Now ask yourself, “What could possibly go right today?”
Are you prepared to take advantage of it?
a. Is it possible to complete a task early; can you
accelerate other tasks; can you use the break to
capture value in another way?
b. Can you use an Access Portal that you have
previously established; can you create a new one;
how do you demonstrate that you have control?
c. Is there an opportunity to publicly recognize progress
made or relate accomplishments to new business
capabilities; can you look beyond the Triple
Constraints to correlate progress with business
value?
3. Clear your mind and put your Strategic Project Manager
hat on:
a. Evaluate your own tactical efforts. Is the project
showing any signs of straining the triple constraints? If
so, start laying access portals and tighten-up risk
mitigation. You are not responsible for the solution;
develop a process that identifies multiple solutions.
b. Are you beginning to recognize any cultural
shredders? Do you need to adjust expectations or
plans?
c. Are you able to recognize project constraints outside
of the tactical time, cost, scope parameters? There
are often project constraints that lurk just below the
surface of daily project activity.
d. Think about the project from the point of view of the
project sponsor and their key stakeholders. Do you
think you understand their needs and concerns? How
BKPM Pocket Guide for Project Managers
9
do you push gently to learn more about their value
system? Where might the project hold intrinsic value
to the organization that can be captured? Should you
develop an access portal for it?
OK, now execute!
Project Wrap-Up
Projects can sometimes wind-down slowly and eventually meet
an unceremonious end. That’s bad news for a BKPM and
exposes your project process and standards of execution to
undue risk.
1. Determine if project requires team-based Capturing Value
meeting. If so plan and conduct.
2. Wrap-up project documentation and archive appropriately
3. Hand-off any ongoing tasks formally and publicly.
4. Develop your last status report and deliver it
5. Consider if you have created any additional principles or if
you have recognized any cultural shredders. If so,
document and share them with your BKPM peers.
BKPM Pocket Guide for Project Managers
10
Think’s Rapid Control Process
Our framework for initiating new Business Intelligence projects
and getting them under control is called the Think Rapid Control
Process. The roles, responsibilities, deliverables, and artifacts
that must be “buttoned-up” in order to be successful are
presented below.
1. Discovery & Immersion
Organize and consume all historical project knowledge and
artifacts. Includes meetings with key individuals, review of
documentation, etc. Conduct the initial meeting (reference:
Initial Project Meeting: Readiness Review) and follow through
on any To Do’s and Open Action Items. At the conclusion of this
phase, conduct a Project Kickoff Readiness Review meeting to
present your full project understanding and correct any
discrepancies in the early stages of planning.
Deliverables: working knowledge of the project.
Participants: Think Account Manager, Strategic PM,
Tactical PM, Client Stakeholders
Work Effort: Usually 8-24 hours, depending on
complexity of the project.
2. Planning
Multi-pass planning starting with “Strawman Plan” development,
reflection of plan with key individuals, resource development,
timeline/outcome balancing.
Deliverables: Draft Project Charter, Project Plan,
Resource Plan, List of Risks, other
supporting documents as needed.
BKPM Pocket Guide for Project Managers
11
Participants: Strategic PM, Tactical PM, Client
Stakeholders
Work Effort: Typically 24-80 hours, depending on
complexity of the project.
3. Validation & Risk Mitigation
The Draft Plan is subjected to the stress of validation and risk
mitigation to determine fragility. Involves tough discussions of
how risks will be confronted as they emerge in the project.
Deliverables: Near-final Project Plan, Resource Plan,
Risk Plan, Schedule, Approval to Proceed,
and agenda for the Kick-off Meeting.
Participants: Strategic PM, Tactical PM, Client
Stakeholders, BA if required.
Work Effort: Typically 8-40 hours, depending on
complexity of the project.
4. Kick Off
Think presents the final project documentation package (all
documents created in previous steps) to the stakeholder team.
Ownership of tasking is cemented and ground rules for
engagement are discussed and accepted by team members.
Final adjustments are made and advertised.
Deliverable: FULL PROJECT CONTROL.
Participants: Strategic PM, Tactical PM, Client
Stakeholders, BA if required.
Duration: Preparation requires a few hours to a day of
work (2-8 hours) culminating with the Kick-
off meeting.
BKPM Pocket Guide for Project Managers
12
5. Active Management & Control
Once the kickoff is complete, the Tactical PM will actively control
the project by socializing it with appropriate personnel,
managing the tempo, conducting weekly review meetings, and
by providing reporting and tracking updates. Risks encountered
are confronted aggressively.
Deliverables: Project Tempo, Weekly Reporting, Active
Risk Management of the Project. The
process is now owned by the Tactical PM;
the outcome of the project is fully owned by
the project sponsor.
Participants: Strategic PM (as needed for meetings and
risk mitigation), Tactical PM, Client
Stakeholders, BA and Strategic
Communication Manager if required.
Work Effort: Varies depending on the level of complexity
of the project, from 8-40 hours per week by
the Tactical PM and a few hours per week
by the Strategic PM, as determined by the
resource plan.
BKPM Pocket Guide for Project Managers
13
Roles in the Rapid Control Process
In the Think Rapid Control Process, there are unique roles for
project managers. These are the Strategic PM and the Tactical
PM and Business Analyst, who must work together to achieve
proper control of the project quickly. While there are times when
the Strategic and Tactical PM role is filled by one resource, the
approach used more often is split to capitalize on the thinking of
two distinct resources and make our plans less fragile in
response to risk. Distinguishing the two allows us to substantially
mitigate all known risks and keep the proper perspective on the
project by maintaining relationships in accordance with the
Three-Sided Table.
Strategic PMs (SPM) are broadly experienced, having served
many years as a tactical PM, and are capable of creating and
articulating a clear vision for the process of achieving the desired
outcome. The SPM leads the Discovery and Immersion
meetings to uncover the success criteria and objectives; uses
success criteria and objectives to develop strategic options that
will help drive the project from inception through
planning/immersion; leverages strategic options to design an
appropriate approach with the project sponsors, and; works with
the tactical PM to create the “Strawman” (early draft) project
plan, validate the plan, mitigate risks, and achieve active control
of the project.
Tactical PMs (TPM) are quick learners who are driven, astute,
nimble, highly detailed and analytical. They use a Bare Knuckled
approach and partner with their SPM to mitigate risk and
implement the Three-Sided Table to drive projects to
completion. They quickly plug-in and drive the project tactically,
BKPM Pocket Guide for Project Managers
14
document and reflect back the project goals and priorities to
management and project sponsors. They effectively integrate
into an existing client team but remain highly tactical and operate
at arm’s length.
Strategic PMs actively facilitate and aggressively control project
discovery meetings with key stakeholders while tactical PMs
synthesize that information to develop comprehensive project
plans, determine other project artifacts that may be needed, vet
the project plan with the project team and key stakeholders to
gain commitment and make the project plan “anti-fragile.”
Control of the project transfers to the Tactical PMs at the kick off
meeting, and then the TPM manages the schedule via the
project plan, weekly meetings, and weekly status reports. This
is a true partnership between the two roles with clear delineation
between the roles.
The Business Analyst (BA) role exists as a support role to the
Tactical PM but occupies the fulfillment team side of the three-
sided table. Many companies assume that the PM will conduct
business analysis as part of their project management duties.
Although we are all accustomed to doing some business
analysis as PMs, as a function in a project, designating the “BA
stream” of work has many advantages in the project and
produces higher quality than merging that function with the PM
role.
BAs drive requirements at various levels of detail and are highly
inquisitive with attention to detail. They work side by side with
the PM, client, and multi-disciplinary teams to analyze and
synthesize complex information and produce clear written
BKPM Pocket Guide for Project Managers
15
requirements; own requirements specifications and the gap
analysis process, work with the client and PM to set the scope
and schedule and help manage within the Triple Constraints;
assist with the testing and delivery; design the formal client
acceptance process, and; create user and system
documentation and participate in client training and transition.
Another, optional yet sometimes essential, role is that of the
Strategic Communications Manager (SCM). The SCM role is
reserved for high-touch, high-polish communications campaigns
in projects that effect large numbers of stakeholders. The SCM
is responsible for the design and execution of external strategic
communications campaigns that build awareness, set
expectations, and increase adoption of new software and
processes. No matter how well software functions, if no one
uses it, it is a failure. This kind of deliberate communications
approach has been very successful for many IT projects.
BKPM Pocket Guide for Project Managers
16
RCP – Initial Project Meeting (Immersion)
Initial Project Meeting: Readiness Review
The Initial Project Meeting (Immersion) is an activity that is a part
of Think’s Rapid Control Process. Prior to attending this initial
meeting, make sure you are ready and have reviewed the goals
of the Initial Project Meeting. Plan exactly how you will facilitate
and what you want to achieve. The Initial Project Meeting is
designed to qualify project scope, list deliverables and high-level
planning chunks, identify risk and mitigation plans, and agree on
commitment dates with the Customer/Sponsor. This meeting
enables Project Managers to restate what is known (typically
minimal) and quickly build on that knowledge to further immerse
in the project.
RCP – Initial Meeting
During Think’s RCP – Initial Project Meeting, the PM team,
consisting of a Strategic PM (SPM) and Tactical PM (TPM),
should facilitate through project discovery discussions using
these seven categories as organizers, at a minimum:
1. To Do List (immediate actions during the RCP Initial
meeting)
2. Rough Scope Statement (what’s in / what’s out)
3. Project Plan Outline (high level chunks)
4. Key Resources
5. Risk Registry (+ draft mitigation)
6. Open Action Items (e.g., known areas that require
additional analysis)
7. Commitment Dates
Each of these specific areas define a starting path to get Rapid
Control. They are used to capture project related details with the
BKPM Pocket Guide for Project Managers
17
PM team in a short working session, ideally in a “war room”
environment, using a white board or large Post It pads. This
methodology allows for a collaborative session and creates a
starting point from which the PM can start planning. Each of the
categories are described in more depth below.
To Do List
The To Do List should be a quick action list of items to
review/kick off in the RCP Kickoff Meeting. At the conclusion of
the RCP – Initial Meeting, the To Do List may include the
following items:
1. Review Notes (SPM/TPM)
2. Project Plan Outline (TPM)
a. Create STRAWMAN Plan
b. Upload Plan to Think Corporate SharePoint
Drive
c. Add High Level Chunks (Deliverables) to
Project Plan
3. Project Charter (SPM)
a. Use Notes to Define Scope Statement
b. Draft Initial Charter
4. Risk List (TPM)
a. Add initial mitigation statements
b. Add to Project Summary Report
5. Key Resources
a. Add to Project Plan
6. Budget Review (SPM with Customer/Sponsor)
7. Next Steps
a. Create Project Summary Report (Draft)
b. Create Executive Summary Report (Draft)
8. Commitment Dates
a. Draft Plan Commitment Date
BKPM Pocket Guide for Project Managers
18
b. Hardened Plan Commitment Date
c. Project Kickoff Meeting: Readiness Review
Date (Customer/Sponsor Meeting prior to
Kickoff Meeting)
d. Project Kickoff Meeting Commitment Date
This list can include additional items but is a good start to keep
the team moving through the Initial Project Meeting process.
Rough Scope Statement
No matter how formally (i.e., in a Project Charter) or informally
the project scope statement is documented, it is imperative to
push on the project scope to test what’s in and what’s out of
scope. The project scope is not only needed to define project
level boundaries (e.g., technical capabilities; final deliverables)
but is also needed to define the sphere of influence that the PM
must control. For example, if your project’s outcome owner tells
you that, “I have a different team that can take care of that.” You
need to learn what happens if they don’t. Typical PM challenges
might include: Are you sure? Should I manage them? If they
don’t, do you want me to find someone who will? Do we need to
discuss options if they don’t come through as you expect? Will
you have them report progress status to me?
Project Plan Outline (high-level chunks)
During the RCP – Initial Meeting, it is important to document the
project in high-level chunks and to not dive too deeply into any
specific area until the full breadth of the project scope is defined.
This is a critical error that many PMs will experience while in the
stress of facilitating the initial meeting. Your goal is to uncover
all areas of the project that require a process for completion and
that need to be monitored for status. It is also critical to
BKPM Pocket Guide for Project Managers
19
communicate the standards and expectations that you have for
level of detail in plans and in reports. Often, the level of detail in
a practical plan for a PM will overwhelm other team members
and you must learn what level of detail is appropriate for team
consumption.
Key Resources
This is fairly simple and straight-forward list of people, hardware,
services, software, facilities, etc. Once key resources are
identified, you must learn if there are going to be competing
demands for those resources, who manages them, and what
priority level outside demands have. Many organizations are
accustomed to thinking of resources as though they were fixed.
Explore the possibility of outside resources in order to provide
options in case of low productivity, technical issues, and/or to
find project acceleration opportunities.
Risk Registry
At first, risks will typically be fairly high-level. Even at this stage,
however, they cannot exist as identified risks without some form
of mitigating action. The mitigating action doesn’t necessarily
need to be corrective action, but it must be a plan of action that
is discussed and agreed to before the risk manifests itself in the
form of project impact. Early in a project think more about
process. What are we going to do? Who needs to be involved?
How will it affect the Triple Constraints? Remember the PM
owns the process not the solutions. Solutions must come from
the team who will execute the solution and must be agreed to by
all parties. You will likely leave your side of the Three-Sided
Table in order to facilitate solution discovery and to develop
BKPM Pocket Guide for Project Managers
20
Access Portals. Leave briefly and get back to your side of the
table.
Open Action Items
Open action items differ from items on the To Do List, but may
overlap. Many projects are already in progress at some level and
existing open action items may exist. Often they are still open
because someone has not taken time to chunk them down into
actionable tasking and does not own the process that will lead
them to completion. Open action items often suffer from analysis
paralysis and may affect the scope of the project or present risks
to the project that must be mitigated. Document open action
items and determine what needs to be accomplished to close
them out if necessary.
Commitment Dates
It is critical to discuss several standard RCP commitment dates
and ensure they are attainable and realistic, as these are the
earliest indicators to the Customer/Sponsor of Think’s
performance. The four dates listed below allow the Project
Manager to get immersed, meet with key resources, adequately
understand the scope of work, determine the resources needed
and establish the time the project will needed given the Triple
Constraints.
Draft Plan (STRAWMAN) Commitment Date:
This is the date the Tactical Project Manager agrees to have a
rough project plan in place and ready to review with the Strategic
Project Manager. It is likely that the plan will still have unknowns
as this date approaches, but it is important that the TPM’s plan
aligns with the SPM’s vision. During the Draft Plan review
BKPM Pocket Guide for Project Managers
21
meeting the SPM will walk through the project plan with the TPM
to ensure the direction of the project is on target and discuss
changes/edits and next steps. Additionally any new risks can be
discussed for a mitigation plan.
Hardened Plan (anti-fragile) Commitment Date:
This is the date the Tactical Project Manager agrees to have a
hardened project plan ready for review with the Strategic Project
Manager, prior to the Kickoff Readiness Review meeting with
the Customer/Sponsor. This date is typically set a couple of days
prior to the Kickoff Readiness Review meeting so the plan
should be as close to complete as it can. The TPM should be
prepared to complete a ‘dry run’ walk-through as if presenting to
the Customer/Sponsor and be prepared to make any last minute
updates prior to the Customer/Sponsor meeting.
Project Kickoff Meeting: Readiness Review Date:
This is the date both the Strategic and Tactical Project Managers
agree to have a project charter, project plan, a risk registry with
mitigation plans, resource allocation report and project summary
report ready for presenting to the Customer/Sponsor. This
meeting is where the Customer/Sponsor has the ability to ask
questions about the plan, therefore it is critical to gain
confidence that the project plan is thorough and has enough risk
assessment to avoid missing the project completion date.
Project Kickoff Meeting Date:
This is the date the Project Managers and the Customer/
Sponsor agree to kick off the project and begin executing
against the project plan.
BKPM Pocket Guide for Project Managers
22
It doesn’t matter what tools you use to manage your project
plans. What matters is that they contain the level of detail
needed to maintain control of the project process (usually task,
duration, work, start, finish, precedent, and resources needed),
are easily updateable, and communicate realistic tasks and
durations.
Project Planning: Specific Requirements &
General Rules
Project planning within the Think Rapid Control Process is
flexible, has a few specific requirements, and follows several
general rules.
Specific Requirements:
All Projects must have a project plan in some form. The project
plan must specify tasks, duration, work effort, and resources,
at a minimum.
• Tasks must be action oriented in such a way that the
resource tasked understands exactly, the deliverable that
must be produced in order to complete the task.
• The time required to complete the task or produce the
deliverable must be articulated in both duration and work
so that the resources, over the entire plan, can be
aggregated (preferably in a resource table).
• Both the aggregated and task specific resources must be
reviewable so that overall levels of resources can be
tested and confirmed and individual resources can be
assigned and scheduled reasonably.
BKPM Pocket Guide for Project Managers
23
General Rules:
• Tasking should be tracked in chunks no greater than 5
days, but preferably no greater than every 2 days, either
as task complete or percent complete. A great deal of
effort must go into maintaining project status. Really, task
duration depends on how resources are linked to it. If a
single person is responsible for a task that lasts two weeks
and that’s all they are working on, and it cannot be
chunked further to measure progress, then it can be
allowed, but caution should be used.
• The project plan must remain achievable. You must not
allow tasks to go un-completed without documenting them
and adjusting the plan to accommodate (either through re-
planning or use of slack). You must have a manageable
way to keep them under control; usually, this involves
properly vetting and snaking with all parties. Minor
interruptions might be OK, but they may snowball, or
worse, develop as blind spots in your planning. Project
plans must reflect real word as much as planned world.
• Schedule risk mitigation, sometimes called contingency,
should be allocated to those tasks deemed riskiest. It
should not be considered a slush fund that can be
consumed by any task that is running long. There is no
way to accurately predict down-stream impact otherwise
and poorly applied contingency is a sign of a project plan
that is not well thought out.
• “Everyone, review this,” is not a reliable strategy for
communicating task expectations or for learning of
potential issues. The PM is likely to be the only individual
that can consume all of the detail in a good project plan. If
BKPM Pocket Guide for Project Managers
24
you want good feedback and team awareness, then
tasking may need to be broken-out per individual. You
should ask (Snaking principle):
a. Can you get this finished as planned?
b. Do you know of anything you need in order to
accomplish this and can I help you get it?
c. What is the worst thing that could happen that
would prevent you from finishing (apply Pre-
Mortem principle)?
• Visibility is required to make your plans anti-fragile. Print
them and post them frequently (weekly at least). Require
that team members and stakeholders review them. Include
a pdf version with every project report. The more visibility
a plan has, the better accountability experienced in
projects. If everyone knows what is expected by them,
their role, deadlines, and deliverables, they are more
prone to own them and report possible expected
slippages.
• Task descriptions must be action-oriented. Reading a task
name should invoke a call to action that is clear and
descriptive. Use action verbs like develop, review, test,
assign, etc.
• Use task preambles and color coding to enable rapid
scanning of plan tasks. Preambles often include
abbreviations like: MTG: meeting, DLVR: deliverable,
CUST: customer task, APRVL: approval
Ex: MTG: Conduct kickoff meeting at customer facility
BKPM Pocket Guide for Project Managers
25
Project Reporting: General Rules
1. A Weekly Status Report (WSR) is a critical tool for project
managers. There are hundreds of “correct” formats for
WSRs. The key to a WSR is that it communicates what is
important and that it is easy and accurate to maintain. It
doesn’t matter if the report is maintained in Word, Excel or
in a central database. What matters is that they are
effective for the project.
2. Many WSR templates are pushed down to PMs from a
PMO and are rarely focused solely on enabling a project
manager to control their projects; they typically place
additional burden on PMs so the PMO can report
information that is important to the PMO. PMs should test
WSR templates to make sure they are simple, direct and
effective, and that they do not cause undue burden on
running the project effectively.
3. Here are a list of fields that we often find are needed in a
WSR:
Field
Description
Project Name
Easily recognizable name
Status as of
Date (mm/dd/yy)
Begin
Project inception date (mm/dd/yy)
Projected
Completion
Date (mm/dd/yy)
BKPM Pocket Guide for Project Managers
26
Active Phase
Discovery & Immersion, Planning,
Validation & Risk Mitigation, Kick
Off, Active Mgmt & Cntrl, Close Out
Executive
Sponsor
Executive (e.g., CFO) name
Project Sponsor
Technical (e.g., CTO/CSO) name
Project Manager
Strategic PM / Tactical PM name(s)
Executive
Update
Monthly high-level accomplishments
and major activity forecast
Profit/Loss statement; cost projection
Schedule tracking and projection
Overall Health
Color-based health indicator –
green, yellow, red, hold (red
diagonal lines)
Team Update
Color-based health indicator +
Weekly update used to provide
status to sponsors, stakeholders,
and team members
Major Milestone
Updates*
(repeat as needed)
Color-based health indicator +
Milestone Name +
Date range (MM/DD to MM/DD) +
Status description
BKPM Pocket Guide for Project Managers
27
Current Risk
Items*
Quick reference ID +
Risk/Impact Description +
Mitigation Action +
Back-up Plan +
Owner +
Color-based impact rating (L, M, H)+
Color-based risk rating (L, M, H) +
Current Action
Items*
Quick reference ID +
Created date +
Description +
Actions Taken Log +
Owner +
Status (New, In Prog, Closed)
Out of Scope /
Parking Lot
Quick reference ID +
Created date +
Description
Change Control
Register
Quick reference ID +
Classification (budget, time,
features, risk)
Description and impact on project
Requested by + date (mm/dd/yy)
Approved by + date (mm/dd/yy)
* Completed items are moved to archive one cycle after being
reported as complete
BKPM Pocket Guide for Project Managers
28
Weekly Status Report Template Example
BKPM Pocket Guide for Project Managers
29
Large or Small Data Projects –
Application Differences in the RCP
Think’s projects vary in size. All are required to stay in a state
control through to completion. For all projects, we still use the
same Rapid Control Process and principles regardless of size
and scale. The principles accentuated may change and skill
level required in “big data” projects may require more
participation by the Strategic Project Manager, but the projects
include the same basic components. Here are some ways in
which variation may occur:
Planning will likely take longer in larger projects. Using the
chunking, plan for a plan, and forward motion principles, the PM
will break down a large project or program into smaller, more
manageable micro-projects. These are sequenced, cascaded,
or overlapped to accomplish the outcome of the project by
properly managing the triple constraints to account for resource
constriction. Since the PM role is a stated project resource, very
large projects may require multiple project managers to “own”
several micro-projects each. In these types of projects,
managing against the triple constraints, especially elements
balanced against resources become key.
Big data can require more involvement by the Strategic Project
Manager. Small data projects are generally more tactical with
localized chunks, deliverables, and immediate and attainable
goals. Large data projects often require more attention to the
more strategic impact on the overall corporate entity and may
require longer-term, sometimes phased planning. Typically, the
BKPM Pocket Guide for Project Managers
30
Strategic Project Manager is required to play a larger role for a
longer period of time.
Big Data projects are likely to involve “Super Processes” that are
not normally part of smaller projects. Super Processes may
involve optimization, organization-wide communications,
strategic impact analysis, or cultural elements. This means that
project plans must consider and plan for more than the standard
software development lifecycle processes, typical of smaller
data projects. Big Data projects are less insulated from
executive level scrutiny, although that does not release the PM
of proper management at the smaller level. In Big Data projects,
the intense rigor and scrutiny of executive review must be
considered as well as the political impacts on all aspects of
planning.
Note: Even small projects can suffer from hidden objectives…
insulated until the project emerges within the company, then
others impacted by the project begin to add requirements
(changes to the project.)
Some of our best control refinement occurs on the big data
projects that we undertake. New practices filter through
everything we do as a team in projects of all sizes. Sizing our
Project Management effort properly, using the RCP, is critical to
our ability to manage projects of all sizes routinely.
BKPM Pocket Guide for Project Managers
31
Squaring Agile with Project Management
to Maintain Control
The Agile movement is not anti-methodology, in fact many of us want to
restore credibility to the word methodology. We want to restore a
balance. We embrace modeling, but not in order to file some diagram in
a dusty corporate repository. We embrace documentation, but not
hundreds of pages of never-maintained and rarely-used tomes. We
plan, but recognize the limits of planning in a turbulent environment.
— Jim Highsmith, History: The Agile Manifesto
Agile is a philosophy that embodies many development
methodologies. Our project management methodology is very
well suited for managing Agile projects. Both are meant to be
simple, direct and effective; however, there are some very
important things to remember about managing Agile projects:
Scrum masters are NOT project managers. Scrum masters exist
to serve as local scrum process experts, remove impediments
to team productivity and to develop high-performing teams.
When viewed through the principle of the three-sided table,
scrum masters are on the side of the table with the fulfillment
team and, as such, are already co-opted and would have a very
difficult time also serving as a project manager. Scrum masters
should be skilled at all of the engineering and team management
dynamics that are required to make a good product. Their
attention to detail should be focused on engineering process
and challenges.
BKPM Pocket Guide for Project Managers
32
Product Owners (Chief / Big / Small) are NOT project managers.
Product owners are executives with product vision. They
understand their business, are responsible for product features
and capabilities and work closely with scrum development
teams to help with design decisions made during each sprint.
They are responsible for ROI, developing product roadmaps,
and managing stakeholders. They create financial forecasts,
track product performance, write user stories, attend scrum
meetings and are responsible for the execution of all tactical
duties on the project.
Product Owners are often assigned the duties of project
management; however, whoever thought that one person could
possibly be able to cognitively frame-shift well enough to do all
of these things properly and at the same time was sadly
mistaken (except possibly on projects with the tiniest of scope).
It is nearly impossible to own the project process, transparent
communication to all stakeholders, the technical solution, the
technical resources, the outcome and executive options, all at
the same time. There are simply too many overlapping details
and competing priorities not to take shortcuts or make flawed
assumptions. Senior executives often mistakenly assume that a
product owner and scrum master will have the wherewithal to
drive a team to a technical solution and manage the project at
the same time. It’s an understandable mistake; it is one of the
promises of the Agile development process.
The issue is that Agile has made the lead executive on the
project, the product owner, responsible for all project
management activities and said you don’t a project manager.
BKPM Pocket Guide for Project Managers
33
On Agile projects, a project manager should operate as an
extension of the product owner. They become their top
lieutenant, trusted collaborator and clear the road of much of the
administrivia that would otherwise occupy their time. As the top
lieutenant, the project manager must be able to operate at an
executive level (strategic) and also be a high performer at
tactical and perhaps even project coordinator levels.
The scrum process does not officially recognize the role of the
project manager because of fear of command and control
difficulties, should the project manager also have people
management responsibilities. This is no excuse for not having
project management over an Agile project. A PM, using the
Three-Sided Table principle, will always separate people and
project management responsibilities. Fear of allowing the PM to
make decisions that should be made by the product owner is
also a false distraction. A PMs role is not to make product
decisions. It is to maintain situational awareness, see around
corners and make sure that risks are mitigated with good
executive options. Tracking progress, compiling project data,
managing the more frequent but less impactful operating
decisions is where the project manager should be focused while
operating at a tactical level.
Daily scrum meetings are often viewed as a method for
providing minor course corrections and risk mitigation steps that
keep a project on track, in other words, an alternate form of
project management. The truth is that the amount of real project
management that occurs at a daily scrum is but a fraction of
what a professional project manager performs. Again, this
represents a total collapse of the Three-Sided Table and is
BKPM Pocket Guide for Project Managers
34
accompanied by all of the issues likely to occur if a project
manager is co-opted to the fulfillment team side of the table.
Daily scrums should focus on the collaborative creation of high-
quality code and capabilities, not on project management. To
the extent that the product owner needs to collect or convey
information in order to properly guide the project, the project
manager might participate, but most of that type of activity
should occur at a different time.
Agile projects minimize accountability. They shouldn’t, but it is
important to recognize that the promise of Agile effectiveness
has somehow been used to rationalize a loss of accountability
for project issues or improper planning. Surprisingly, this holds
true for almost everyone, from business executives to Agile
team members. Teams are taught to provide transparent
communications during sprint reviews; however, objective
commitments that were made and not achieved are simply
footnotes that place the objective back in the product backlog
stack to be worked on during the next sprint. Slips and delays
are often seen as a necessary part of an Agile development
effort and are rarely resisted, until too late.
Sprint Review and Retrospective steps focus on demonstration
of work completed and team continuous process improvement.
Project management activities in these critical stages are
conspicuously under-represented. Downstream impact on
resources, delivery date adjustments for product capability
releases, impact on project P&L, and schedule impact caused
by continuous process improvement are but a few things that
may not be adequately considered for overall project planning
purposes.
BKPM Pocket Guide for Project Managers
35
PMs make Agile teams better. They enable team members to
focus on what they are good at and manage the rest of the
project for them. PMs are able to maintain a project-level
perspective that is important to the overall health of the project
and to the outcome/product owner. PMs layer accountability
back into the Agile development process, which is obviously
resisted by most scrum masters and Agile teams, but it is NOT
their role to become an enforcer. They are there to help. They
bring and maintain the proper project-level perspective needed
to manage an Agile project over the long-term. They also help
Agile team members chunk-down sprint objectives into
measurable actionable tasking. Again, the measurable aspect is
often resisted, but if you cannot measure progress, how can you
predict finishing on time or on budget? Measurable, for a PM, is
something that can be tracked in increments of no more than 5
days, but often preferably only 2 days. It is simply unacceptable
to have a 3-4 week sprint and not know where you are until sprint
review.
PMs are able to help identify long-term planning steps/durations
and help identify opportunities for interventions when things are
moving exceeding well or not as well as hoped. Often in large
Agile development efforts the accumulation of objective
capabilities result in more QA and regression testing than is
intuitively predictable. PMs track and provide data that can be
used to provide trend analysis that can help product owners
predict project completion more accurately. The PM also has the
responsibility to report any project accelerations or delays to the
outcome/product owner and to do so with pre-thought
executive options that can be implemented if needed.
BKPM Pocket Guide for Project Managers
36
PMs should be involved in Agile projects from inception to
completion. They will need to be a part of all planning and review
stages and may need to be a part of daily scrums during critical
project phases or when a project is not going well. The PM will
also need to periodically collect feedback on progress made
during a planned period, but should not interrupt daily scrum
meetings for such information. All interactions with Agile team
members should be as simple, direct and efficient as possible
and strive to provide value to the Agile team member. Questions
like, “What can I do to help you meet completion of your
objective,” and “Do you need help in breaking this down into
actionable tasking,” should often be asked. A PM should be
seen as a value-added enabler to an Agile project, not a
bureaucratic administrator. If an Agile project is complex enough
to require a scrum of scrums, the project manager should always
be a part of them.
BKPM Pocket Guide for Project Managers
37
Conflict Resolution
There is always a reason when a conflict arises. If it is
necessary to resolve the conflict, you may need to consider an
array of strategies to decide on the correct one and act. This
simple aid can provide you with a short-hand method that drives
you to ask the right questions and develop the most
advantageous strategy possible. For additional detail, reference
Bare Knuckled Project Management, Chapter 7.
Recognizing Reasons for Conflict
• Ambiguity
• Accountability (or lack thereof)
• Incompatible Goals
• Unbalanced Cost/Reward
• Mean, Evil, Nasty People
Planning for Conflict
1. Know and understand the situation from multiple
points of view
a. Some people reflexively avoid conflict;
others go straight to DEFCON One
b. Try to expand timeframe so you can
consider things properly
2. Determine your desired outcome
3. Strategize specific behaviors and actions needed
BKPM Pocket Guide for Project Managers
38
BKPM Principle: Access Portals
Conflict almost always provides an opportunity to create an
Access Portal. When you address conflict and analyze possible
outcomes, you have an opportunity to pre-empt emotional
responses from those who are in conflict and establish some
plans for addressing the reasons of conflict before they trigger
emotional responses. When you do this and once people are
triggered, you’ll already have laid a path forward. You look like
you have a crystal ball and have seen the future. This is a very
powerful tool for a project manager.
BKPM Pocket Guide for Project Managers
39
Developing an Access Portal is a nuanced technique that gets
easier and more front-of-mind over time. Here is a simplified
process for establishing an Access Portal:
1. Recognize potential future conflict
You intuition as a PM will tell you this.
2. Understand impact from all points of view
What are the goals and objectives of those in conflict
and why are they misaligned?
3. Envision a mitigating process or action
Can you negotiate a solution or is a direct
confrontation needed? Is a face-to-face meeting
necessary? Is a meeting in front of a manager
necessary? What is your strategy?
4. Setup appropriate cause and effect
Cause and effect should be considered from all
angles. When x says or does something, what can I
put in place to trigger a process-driven path to a
solution? Process is easier to get agreement on than
a solution. Example: Person x will not commit to a
delivery date until person y provides needed
information. Process: person x will halt all
development, teams will collaborate until needed
information is provided, then development will
resume.
NOTE: These process solutions must be presented
and agreed to by all concerned before forcing a
meeting; too late once emotions are engaged.
5. Implement strategy / response
• Meeting / Communication
• Accountability
• Contract / Third-Party
BKPM Pocket Guide for Project Managers
40
The BKPM Conflict Resolution Model
BKPM Pocket Guide for Project Managers
41
BKPM Pocket Guide for Project Managers
42
Using Principles for New Options for Action
PM principles and techniques are designed to help you make
the right decisions while managing a project. You can have the
best process in the world, but you also need to be sensitive to
project conditions and you need to make the right decisions in
order to execute.
PM principles and techniques provide an alternate point of view
from which you can evaluate your current state. Adopting this
new point of view can unlock new options for action. Not all
principles apply to every situation, so the challenge is in finding
the right principle for your current situation; remember there may
be several.
Examples:
• You have a new project and you’re trying to get your
arms around it, but it just seems too amorphous and
has too many unknowns. Chunking might help, so
might Enumeration without Fear.
• You’ve identified a risk but don’t have a perfect way to
mitigate it. At best you have a pretty good idea how to
react if it does happen. Better consider developing an
Access Portal.
• No one agrees how to get going and everyone keeps
suggesting more analysis to attempt to identify a
solution. Don’t get frustrated. Forward Motion is the
principle you are look for and you may need to
implement Momentum over Analysis.
BKPM Pocket Guide for Project Managers
43
PM Principles and Techniques
Of all of the principles in this guide, the concept of managing
project as if the PM is sitting at a Three-Sided Table is one of
the most fundamental. Almost everything else is designed to
maintain this relationship between project owners and fulfillment
teams.
No project manager,
not even the most
highly skilled, can do
it alone. Executive
leadership sets the
tone and provides
the support; project
sponsors establish
the goals; the
solutions team
partners to do the
work; and the project
manager runs the
plan and process. Establishing clear goals, roles, and
expectations for the different project players is a necessary
precondition for the PM.
The following table provides a list of established PM principles
and techniques, but it doesn’t need to stop here. If you find
something that works well for you, add your own to this list and
use it to become a better PM.
BKPM Pocket Guide for Project Managers
44
PM Principle Description
Access
(Escape)
Portals
A strategy the
when conflict and problems arise.
Portals
for conflict resolution.
Anti-fragile
see if they hold up under new
scrutiny.
are solid and buttoned up, then make them
Anti-fragile.
Change
Management
modification, project planning, and
management.
BKPM Pocket Guide for Project Managers
45
PM Principle Description
Chunking
responsibili
impact it, or variables that it may introduce
down. Chunking is the process by which a
PM continually breaks-
components into actionable pieces, even if
the action is to break it down further.
Conflict
Resolution
strategy for resolving the conflict. A PM
doesn’t have to fight every battle, but is
purpose if a battle is warranted.
Co-opt Risk
What happens when the Three-Sided
Table
manager becomes aligned with one of the
remaining two sides.
Enumerate
without Fear
Create a punch list. Free yourself from
worrying about
importance and simply list everything that
you can think of that needs to be dealt
added to a punch list. Once the punch list
is established, every item can be broken
down and planned.
BKPM Pocket Guide for Project Managers
46
PM Principle Description
Executive
Options
exceeds the general ability of a PM.
work within the triple constraint model to
enable large investment/authority
changes that provide
options. Executive Options generally
result in Access Portals
Snaked.
Forced
Clarification
The process by which the PM ensures
that the customer or sponsor defines the
moving forward with the project.
Forced
Conflict
A purposeful situation where the PM sets
up a direct conflict to force a resolution to
risk.
Forward
Motion
A PM
constantly, even when goals aren’t clear
(which is most of time).
Guard Rails
This describes what we do to set up and
pattern of execution that is pre-
phase of the RCP sets a weekly meeting
and Agenda and commits to it through the
committed executions, and others like it,
we call Guard Rails.
BKPM Pocket Guide for Project Managers
47
PM Principle Description
G-R-E-A-T
works best when people are clear about
goals, roles, expectations, attitudes and
aptitudes, and time.
Iterative
Approach
When the outcome isn’t clear up front, the
clarity and understanding. May be part of
an agile process.
Land Mines
parti
result in a negative outcome if hit and,
therefore provide negative reinforcement.
Mistake
Management
A process that provides a framework and
directives for dealing with mistakes before
they spiral out of control. It must be
addressed without fear of confrontation,
mistakes are rarely intentional. Look for
additional mistakes.
Momentum
over Analysis
A strategy used to make the project move
forward regardless of unknowns. If mired
down in analysis, build small achievable
steps to force forward progress.
BKPM Pocket Guide for Project Managers
48
PM Principle Description
Pre-Mortem
During plan review and snaking, ask task
owners to conduct a pre-mortem that
creatively projects absolute worst-case
scenarios. Examples: hit by a bus, down
with the flu, disaster power outage, test
environment equipment failure, business
fails regulatory check, etc.
Recovering
Value
The PM alternative to ineffective “lessons
learned,” a strategy to extract value from
projects.
Risk
Management
A six-
contingenc
development).
Shredders
These are barriers to project success.
overcome at the PM level, shredders are
cultural barriers in your organization that
may only be overcome by applying
constant pressure at the corporate level.
Simplicity
simple, direct, and effective. Elaborate
without expending a lot of energy.
BKPM Pocket Guide for Project Managers
49
PM Principle Description
SMART+ER
An acronym for a set of standards used to
validate and measure project outcomes.
Realistic, Time-constrained, plus Ethical
and Rewarded.
Snaking
everyone who has a role in plan tasking to
make sure they have had a chance to
provide a
commitment to deliverables and dates,
and
dependencies.
(Attributed to a Chevron CPDEP concept)
Spectrum
Analysis
A thought process step in which you
challenge your instinctive perception of a
risk, constraint, or possible solution. Slow
down and think best case, worst case and
what could possibly go wrong to invalidate
your assumptions of the situation.
Strategic
Marketing
Just getting
plans and accomplishments in order to
maintain momentum and drop barriers to
implementation of planned activities.
BKPM Pocket Guide for Project Managers
50
PM Principle Description
Tempo
"I think fast, talk fast, and I need you to act
fast..." -- Winston Wolfe. We use tempo
as one technique to establish control in a
Thinking fast and moving fast for a client
makes it easier for them to contribute and
they appreciate the sense of urgency
Three-Sided
Table
A PM approach to project management in
which the PM owns the process (but not
owns the outcome (but not the process),
technical solution.
Time Slicing
A method used to enable cognitive frame
coordinator, tactical PM and strategic PM
Triple
Constraint
consisting of the time constraint, the cost
(or resources) const
mandatory performance criteria, ranked in
constraint and weak constraint.
Unafraid of
Conflict and
Confrontation
A core competency of a PM that results in
resoluti
communication.
BKPM Pocket Guide for Project Managers
51
Personality Traits of a PM
PMs have a set of personality traits that describe them at their
very core. The ideal PM, our PM Archetype, is highly
operationally disciplined, focused on the project management
process and the team, only slightly concerned with maintaining
personal relationships, and not very concerned with getting into
the creative aspects of developing options for technical
solutions.
This chart represents the natural resting state of an ideal Bare
Knuckled Project Manager. The darker area in the center is their
natural resting state; however, everyone can expand their zone
in time of heightened awareness. A Strategic PM’s zone
expands to be even larger, but similar.
BKPM Pocket Guide for Project Managers
52
BKPM Pocket Guide for Project Managers
53
Operating Within the PM Zone
Not everyone’s natural preferences and personality traits match
our PM Archetype. When projects are running well and you are
not experiencing stress, most PMs can force themselves to
operate in the PM zone.
If your natural resting state zone differs from the archetype, you
will need to recognize when you’re operating outside of the
zone and expend energy to get back into it. Use PM Principles
to get control.
BKPM Pocket Guide for Project Managers
54
Working with our Customers’ PMO
Many PMOs come into existence by executive action. Their
director enforces standardized processes and templates in
order to provide "best practices" with the goal of enhancing
project success. We embrace good practices and work willingly
with our customers’ PMO.
For most PMO’s however, limiting their involvement to just
providing best practices is seldom the case. Often the largest
PMO mistake manifests itself in the form of governance. Every
breakdown or failure results in a new governance rule or process
and, in no time at all, the concept of effectiveness has been
destroyed by a bureaucracy. Each rule or process can arguably
make sense in isolation, but the compendium of many rules and
processes soon becomes burdensome. It has been Think’s
experience that this type of top-down, governance-driven, PMO
needs to be refocused on effectiveness or run the risk of
becoming irrelevant to the organization and people it is there to
serve. Therefore, we intentionally distance ourselves, to the
extent possible from the customer PMO.
For Think to be successful, we want project success first;
everything else follows. We believe that the best measure of
PMO effectiveness is this, “If an organization’s PMO was
zapped out of existence, would the practices implemented by
the PMO endure?” If the answer is something like, “Well I’m not
going to use that template anymore” or “At least now I don’t have
to create those time-consuming reports anymore,” then
something went wrong somewhere.
BKPM Pocket Guide for Project Managers
55
Many times PMOs are established for good business reasons,
but then implement practices that do not directly aid project
management success and, in fact, make it even harder to
successfully manage a project. We limit our commitments to the
customer to those practices which add value to our
implementation and facilitate success.
PMO meetings, resource utilization reports, one-size-fits-all
standardized process, project inception documentation,
approval processes, etc. all take time away from the simple,
direct and effective way in which PMs need to manage projects.
Not that these things are bad; we need to provide those artifacts
and adhere to those processes and practices which make the
most sense to our implementation and make our work effective.
Sometimes this means doing something that is already being
done differently, doing something altogether new, and
surprisingly often with mature PMOs, killing specific practices
that do not enhance PM effectiveness and succeeding in the
outcome of our projects.
Every organization is unique. The measure of “effectiveness”
considers many things that other PMO models do not consider.
Things like organizational culture, tempo, project types, internal
PM skill levels, etc. We must be aware of these and consider
them in the context of our projects.