How to Avoid the 'Seven Deadly Sins' of a

Level 2 PMO
Published: 29 December 2016 Analyst(s): Donna Fitzgerald

Summary
With the advent of digital and agile, program and portfolio management leaders who direct PMOs are
finding that it is becoming even more important to avoid the seven deadly sins of a classic Level 2 PMO.

Overview
Key Findings
 Level 2 PMOs tend to get trapped in an endless web of entanglements. No matter how hard they
work at establishing initial functional integration and other earmarks of Level 3 maturity, they are
never able break free of Level 2.
 In IT, the move toward agile and the desire to improve value are calling into question the very
existence of many PMOs.
 Managing a project isn't the same as supporting small IT work efforts. Too many "project managers"
actually aren't able to manage real projects, and very few make successful program managers.

Recommendations
Project management leaders looking to optimize the value contributed by their Level 2 PMOs should:
 Eliminate old tools, processes and attitudes that no longer support today's need to become more
agile and flexible in the digital age.
 Require measurable objectives as an integral part of all business proposals, and use their unique
positions as neutral third parties to help balance conflicting stakeholder priorities.
 Measure project accomplishments at frequent intervals, and deal with problems as they arise. Don't
let projects languish or spin out of control.
 Establish firm guidance for the actions to be undertaken when a project is deemed to be troubled,
and enforce key decision points that require selecting one of the four available actions: re-scope,
restructure, reschedule or cancel.
Analysis
Overview
After speaking to many project management office (PMO) managers over the years, we have seen certain
trends begin to emerge. The most common is that PMO managers are most vulnerable when they are at
the latter stages of maturity Level 2. At that point, they've fixed all the things that were easy (establishing
common practices) but find it difficult to make the shift to the more agile and enterprise-focused activities
like Level 3 digital demand. This research offers a quick assessment for Level 2 organizations to help PMO
managers take direct aim at seven of the behaviors and approaches we most often see trap a PMO at
Level 2 (see Figure 1).
Figure 1. Avoid the "Seven Deadly Sins" of a Level 2 PMO

"Prepare three envelopes" refers to an often-told joke about the consequences of failure. After the third
failure, the manager's only alternative left is to "prepare three envelopes" providing advice for the
manager's own replacement. Here's an example of the anecdote.
Source: Gartner (December 2016)
The First Deadly Sin: Failure to Be Agile and Deliver Value
With the changes digital business is bringing to IT, PMOs are not always entirely sure of what they are or
what is expected of them. Our experience, based on many inquiries from PMO leaders, confirms that
PMOs are increasingly being challenged by senior management to become more flexible, more scalable
and more involved in ensuring that projects deliver actual value.
Achieving these traits, however, involves deep, fundamental changes for a PMO. It means tossing out old,
familiar tools, forms, processes, habits and attitudes — many of the very things that made the PMO
successful in the past.
And, if the PMO doesn't do these things, others elsewhere in the organization will — without the umbrella
guidance the PMO could be providing.
This means PMO leaders need to form a new mindset about what is important to the organization and
what produces something of true value. And, immediately following this personal willingness to change
comes a willingness to lead others through change.
While PMO leaders take their direction from the businesses they support, they should be expected to add
value as they carry out their roles in the overall projects or programs:
 Ensure clear, measurable objectives beyond ROI. According to PMO leaders, too many project
proposals arrive at the PMO's doorstep seemingly ready to go, with management approval and
funding approval, but without clear and measurable objectives. By insisting that such measurable
objectives be a required part of the business proposal, the PMO leader not only adds value to the
organization, but can also save the PMO grief down the road, when the lack of specificity in results
becomes a sore point.
 Function as a neutral third party. Different stakeholders will have different concerns about exactly
what is to be measured and what yardsticks will be used to make those measurements. PMO leaders
are in a unique position to weigh the self-interests of the various stakeholders against each other
and against overall value contribution to the organization as a whole. Despite the common
misconception that there is an absolute yardstick a PMO can use to measure value, like beauty, value
lies in the eye of the beholder. Every PMO leader must listen to the voice of the customer and strive
to deliver the services the organization wants rather than the services the PMO insists the
organization needs.
 Identify and facilitate resolution of cross-team dependencies and issues. Today's increased
digitalization fosters the rise of more complex, more tightly coupled projects and systems, so cross-
team dependencies and issues are bound to emerge. If PMO leaders can function as both diplomat
and negotiator — proactively and objectively — they can contribute greatly to helping the PMO gain
the neutral, third-party status discussed above.
The Second Deadly Sin: Ignoring Resource Capacity as a Constraint on
Project Delivery
Level 2 PMOs are inevitably challenged by too many projects, too few people, the wrong skill mix or a
combination of these. The solution to controlling capacity constraint is to avoid starting more projects
than the organization can handle at one time. However, Gartner clients don't always feel at liberty to tell
the business that — because of resource constraints — it isn't possible to do all the projects they would
like. Even if the business has money to pay for the projects, IT's job is to see that the work gets done well,
not just to blindly do what is asked.
Money is the first constraint on the number of projects that can get done. If money is no object, the next
step is to evaluate the portfolio and identify which projects might be outsourced or supplemented, and
which projects must be done with in-house resources.
In any event, the PMO leader needs to ensure that projects launch only if the resources are identified and
in place before the project starts. Failure to ensure this basic project requirement means that — before it
ever starts — the project has almost no possibility of completing on time. We speak with many PMO
leaders who tell us their job is just to execute and they have no control over anything once they are told
to start. We strongly suggest you begin to exercise what is known as the back-pocket veto.
Since most organizations have more than enough "priority 1" projects — all of which are clamoring to
start immediately — we advise that you, as the PMO leader, make a small list of projects you think make
the most sense and begin your initiation phase. The only work you'll ask your project manager to do at
this juncture is to estimate a high-level, resource-loaded schedule. 4 If you don't know enough about a
project to do even that, take it out of consideration (figuratively put it in your back pocket) because it's
not ready to start, despite what the business says.
The secret to making this an effective exercise for change is to begin by instructing your project managers
to prepare a preliminary schedule that shows:
 The required resources
 The amount of time (both in duration and hours) the resources will be required (You will need to
adjust this number multiple times as you calculate the best fit against the projects you are
attempting to do.)
If the resources aren't available full time, you will need to add extra time to the work estimate to account
for the inefficiency. We suggest adding an hour per day to a unit of work if the resource will be assigned
to more than two activities. Be realistic about the levels of proficiency possessed by team members. A-
level players are often able to complete work faster and with a higher degree of accuracy than C-level
players, but it never makes sense to build an initial schedule around the A level of proficiency. Always
schedule to your average.
The schedule in Table 1 gives you a good overview of what you are working toward producing. The FTEs
Requested column shows how many people are needed to do the project quickly and effectively. The FTEs
Assigned column tells you how many actual full-time equivalents you've been able to assign to the project.
This number will generally be less than it should be. Note the difference between the planned duration
and revised duration columns, which shows the impact of not having enough FTEs assigned to the project.
 Table 1. Requested Versus Assigned FTE Project Staffing

FTEs Requested FTEs Assigned Planned Duration Revised Duration End Date Total FTEs

Project A 10 5 4 8 September 5.0

Project B 10 4 4 10 November 9.0
Project C 5 3 3 5 June 12.0
Project D 7.5 3 5 12.5 January next year 15.0
Project E 5 1.5 4 13.3 March next year 16.5

We speak with clients all the time who tell us they don't understand how and can't find a way to show
management what starting too many projects at one time is costing them. We think a simple approach
like the one shown above can help (see " Project Resource Capacity Planning for PMO Leaders: Crawl
Before You Walk " for more details).
The PMO's role is to lead change that helps deliver its core mission of improved project performance.
Resource capacity planning is one area where a PMO leader must sometimes force the issue if the PMO
is to be successful.

The Third Deadly Sin: Mistaking Consistent Process for Reliable Results
When we first identified this as a deadly sin, we focused on the pounds of paperwork that PMOs were
making project managers (PMs) fill out. We've been keeping an unofficial tally sheet on how many
documents PMOs have required PMs complete, and at the moment the highest number we've heard of is
57 (up from the previous total of 54). 5 With the increasing move to "better, faster, more value," most
organizations have begun decreasing this number substantially, but we are now seeing a new issue with
its roots in the belief that consistent process yields results.
As the business is increasing its involvement in what were once considered IT projects, we are now hearing
PPM leaders ask us: "How do we get the business to understand and accept how we do things?" And the
answer is: You don't. Of course, that statement should be read as one that conveys many shades of gray.
Sarbanes-Oxley Act (SOX) compliance, generally accepted accounting principles (GAAP) or International
Financial Reporting Standards (IFRS) may all dictate some non-negotiable activities, but in truth everything
else is up for discussion.
One client, an independent consultant in Australia, shared a story with us. Before digital, he had been
rewarded and praised for his skill at establishing great PMOs and making sure the organizations used a
single, fairly prescriptive process. And then the world changed. Now, as a consultant, he gets hired to tear
out the types of systems he specialized in implementing, and now he starts his client engagements by
asking the business areas: "How do you want to have your projects managed?"
We have another client who has been hired to run an enterprise program management office (EPMO) for
a large educational organization. He initially assumed — based on the direct request of the senior
leadership team — that his first job was to roll out a consistent set of project management standards to
all the various organizations on campus. But, he was told repeatedly by those organizations that they
didn't need any of his process overhead. Many heads of EPMOs find themselves caught between senior
management's desire to have a consistent project/program process in hopes of mitigating risk and the
business units' prevailing belief that consistency is of marginal value. 6 So, it wasn't that the organizations
didn't want any standards. They wanted the standards to be usable and understandable by them.
Consistent reporting standards are vital. Common sense would dictate that every project should have
paperwork to be completed to ensure that everyone is on the same page and working toward the same
desired outcome. However, even reasonable paperwork is at best a negative hygiene factor. 7 On one
hand, if it's not done at all, it's a problem. On the other hand, doing anything more than the minimum
required in each situation provides no extra value. In fact, it can impede the PM from doing what should
be done — actually managing the project (see "How Activist PMOs Streamline Processes, Protect Users,
Raise Stakeholder Value and Improve Governance").

The Fourth Deadly Sin: Failure to Make the "Business Case" (Not the
Project Charter) the Primary Document of Record
The role and usefulness of the business case are concepts that never quite get fully accepted, while at the
same time they never get completely rejected. We've seen 50-plus-page business cases that took a year
to prepare, and we know of one example where a client paid a consulting firm $650,000 to prepare one.
We also know of organizations that take pride in not doing them. Given so many different opinions about
the value of the business case, why would we say the business case is still vitally necessary? And more
important, why would we say the business case should replace the project charter in order to support
better throughput and better agreement that projects really are successful?
The answer: There needs to be stakeholder consensus on what needs to be done, how much is worth
spending to get it done and how value can be measured at the end. Note the italicized word "consensus."
Consensus does not mean multiple signatures on a document, nor does it mean multiple independent
agreements. Consensus means that all the critical individuals who will judge success agree to the terms of
the business case while they are in the same room. If there is no consensus, there is no project. If no one
really knows exactly how the project will achieve the business objective, there is no project. If there is
agreement and the funding is approved, then — and only then — the project can safely and swiftly
proceed forward.
The project charter records "how" the work will get done and the business case records "what" work
needs to get done. Contrary to years of bad practices in waterfall IT shops, the requirements process was
intended to elucidate more about the "how" — it was never meant to define the "what" after a project.
Making the business case the document of record has another advantage: The business case exists
regardless of whether a project is waterfall or agile.
In some agile organizations, the collaborative business case process we recommend has been replaced by
an "envisioning session" designed to capture the same "what are we going to do"-level information. This
technique would also work for organizations that absolutely, positively can't change the business case
process in their institutions. Problems with sponsorship and commitment of subject matter expert time
can all be resolved in this initial session.
The core problem with this deadly sin is it assumes the project team is supposed to deliver something that
might be of some value once they are told to start. But, from the moment the start gun fires, everyone
runs straight ahead never asking: "Is this what we should be doing?" Digital significantly increases the risk
that even well-thought-out plans may turn out to be wrong at a moment's notice. Focusing too heavily on
internally facing documents (like the project charter) to provide guidance rather than externally facing
documents (like the business case) significantly increases the risk the wrong things will be done or some
of the right things will be done in the wrong order — simply because no one really understood why they'd
been asked to deliver them. Making a collaboratively prepared business case (or the output of an
envisioning session) the primary document of record should be enough to finally begin to clarify how a
Level 2 PMO can improve to a Level 3, with formalized PPM leader roles and in-house management of
projects by cross-functional groups.

The Fifth Deadly Sin: Refusal to Deal with Troubled Projects

Here, we'll define "troubled" as anything that requires a change order to address something that wasn't
already identified on the risk list. Signals indicating a "troubled" project also include evasive status reports
and comments like "We're having a little trouble, but we'll get it sorted out soon."
When a project gets in trouble, too often, the first tendency is to extend the deadline and spend more
money on it in hopes of getting it finished. This is a bad idea, especially if the situation occurs late in the
project's life cycle.
Ideally, early on, the PMO leader should develop a basic list of conditions that will trigger an investigation
into whether a project is in trouble. Usually, a "consensus" on trouble inevitably will emerge, but it often
occurs too late in the process.
There are four basic approaches to dealing with a troubled project:
 Re-scope
 Restructure
 Reschedule
 Cancel
Re-scope
Begin by asking, "Can enough value be derived from the deliverable that can be produced within the
original time frame and at the original cost to justify continued funding of the project?" This is a difficult
discussion for any organization because it forces taking a detailed look at where the project is now, rather
than focusing on how much it will cost and how long it will take to get it to where it is supposed to be.
If this discussion is conducted correctly, terms such as "sunk cost" or "investment to date" should never
come up because if the investment to date has no value, then there is nothing worth building on. If the
answer is "Yes, the project can deliver enough value to justify continued funding," you need to determine
the minimum functionality needed to achieve that value and fund the project only to that point. Then,
Phase 2 of the project — containing the revised scope — should be placed into the pipeline and prioritized
against all other projects to see where it falls in the list of investment priorities.
Restructure
If a project is vital and re-scoping alone isn't a solution, restructuring is the next option. This solution is
difficult because it tends to upset staffers who are moved off the project (implying that they aren't good
enough). However, it needn't be that way. We suggest reassigning most of the staff before new individuals
are added. This may take an extra week or two in an already tight time frame, but it keeps the organization
healthy, which is worth the investment.
Reschedule
Projects that are good candidates for rescheduling often got started too early and are spinning in place.
This is often due to open questions about what the software should do, or whether the necessary
resources from the business or the IT organization are available. If no one has the wherewithal to cancel
the project directly, then give the project an implicit "starve" or "cannibalize" standing by reassigning
resources until the project has dipped below critical mass. Generally, this designation is given without
fanfare to preserve "plausible deniability." We know of one organization where the project was so
politically unpopular with the business that no forward progress was possible. The CIO insisted the project
go ahead at least on paper, but the PM made the decision to reassign 14 of his 16 team members to other
projects rather than waste their time doing nothing. The CEO eventually stepped in and stopped the
project pending a much lengthier discussion around how the existing systems in the company would be
replaced.
This approach is an easy solution but one that we see very few PMOs actually taking primarily because it
flags issues of authority. Strangely enough, taking authority is often a way to get authority. Starving a
project, or doing a back-pocket veto on projects that really aren't ready to start, are two of the most
common ways we see successful PMO leaders managing their delivery responsibilities.
Cancel
Finally, when all else fails, take the fourth approach — cancel the project.

The Sixth Deadly Sin: Failure to Speak the Language of Business

If your organization has clear and actionable strategy statements, it's relatively simple to ensure that
proposed projects are consistent with the overall strategy. However, if corporate strategy is vague, and if
it's unclear exactly what measurable business value a project is intended to deliver, consider using a
technique we call inferring strategy.
Any project can be examined and have an inferring strategy statement designed to support it. Frame a
strategy statement in the following format:
 "If we are taking action X (the proposed project), which impacts the practice of Q to benefit group
Y, then our strategy must be Z."
For example, if you applied this technique to a project intended to implement agile development practices
in the web development group, the strategy statement you develop might read:
 "We are implementing agile development practices (action X) to speed up the development of web
pages (practice Q) to support the e-commerce group (group Y) in bringing new products to market
more quickly, which will support our corporate strategy of increasing revenue (strategy Z)."
Once this strategy statement is constructed, it is possible to confirm the following points with project
sponsors and stakeholders:
 There is a strategy to support e-commerce group efforts to bring more new products to market to
increase corporate revenue.
 The best way to bring new products to market is via the web.
 The best way to bring new products to market via the web is to decrease the time it takes to build
the web pages.
  The best way to shorten the time it takes to build a new web page is to adopt agile development
practices.
We've learned from experience that it takes about 30 minutes to get a basic level of proficiency in crafting
strategy statements (a very minor investment of time). The power of the inferring strategy technique lies
in the discussion of the four points with the project sponsors and stakeholders.
Going a little deeper, be prepared for discovering that some element of the proposed project isn't exactly
the right approach or exactly the right output. For example, a client shared a story with us about a project
undertaken ostensibly to redesign the screen its call center employees used to resolve customer issues.
Under the current process, agents had to look at multiple screens to get to the information they needed.
The project request specifically stated that the new goal was to consolidate all the information on one
screen so the call center operators no longer had to flip between screens. When the strategy statements
were completed and reviewed with the business sponsor, the client was surprised when the sponsor said,
"What I really want is better call completion time. A current call takes five minutes, and I want to reduce
that to three so our agents can upsell the caller in the remaining two minutes a customer is willing to be
on the phone." At this point, everything about the project changed, which was disconcerting. But, as the
client said, "Better to learn we misunderstood earlier rather than later."

The Seventh Deadly Sin: Failure to Define Performance-Based

Competency Standards for Project Managers
We've saved this deadly sin for last, not because it's the least important, but because we know from
talking to hundreds of PPM leaders over the years that this is an issue where most leaders feel out of their
depth. Everyone knows there is a problem, but when pressed as to how it should be solved, the answer is
"That's why we spend so much time enforcing methodology compliance." For the past 20 years, that
answer has been judged to be sufficient, but with the advent of the digital economy, things are changing.
If PMO leaders really want to establish a value proposition of being able to help deliver projects with the
right outcomes more quickly, then they need to ensure the project managers assigned to lead (not just
track) the delivery effort have the right skills. Given that more and more organizations are adopting agile
methods, we advocate shifting the competency focus from Project Management Institute's (PMI's) project
phases to the more classic project management definitions of scope, time, budget, stakeholders and risk:
 Scope. If the sixth deadly sin — failure to speak the language of business — is successfully avoided,
scope becomes much easier to express clearly and maintain. Strangely enough, we find many
organizations have unconsciously conflated scope with requirements, which can get very confusing
in an increasingly agile environment. Scope is not the same as requirements. Scope is the guard rails
that have been set up for the project that say: "We are here to accomplish this high-level outcome
to yield a specified value at a rough cost of X and a rough duration of Y." Truly managing the scope
of a project takes project managers who actually understand at least something about what they
are delivering. If their only job is to define a schedule or fill out paperwork, then they aren't project
managers (see "Not Every Project Needs a Project Manager").
 Time management. While we know many organizations have begun to believe that scrum eliminates
deadlines (which is not true), if a project manager has been assigned, there will be — by definition
— multiple interdependencies that must be managed on a timeline. Failure to proactively manage
the schedule to deliver the product of the project by the deadline is a failure to show competency.
We know that many, many organizations have such severe resource management issues that a
 project manager is only really held responsible for submitting the change order to move the deadline
on a timely basis rather than actually meeting the project's original timeline. However, as we have
said, if the goal is to deliver quickly, then things have to change (see "Critical Soft Skills for Effective
PMO Leadership").
 Budget. In theory, a project manager is responsible for the cost of a project. In practice, we know
most organizations struggle with this. A competent project manager should be able to determine
when and if adding more money to a project can effectively deliver the value early, or at least on
time. A competent project manager should also be able to determine where the real financial risks
are, and either mitigate, or at least communicate, them early enough so that management can
influence the outcomes if they so wish.
 In a perfect world, we would like to see project managers (PMs) prepare monthly estimates to
complete, ensure the right accruals are made, and generally understand their budgets sufficiently
to discuss with management. In reality, we most often recommend that the organization ask finance
to work with the PMs to ensure these things get done. Of the five competency areas, this has proven
the most difficult for most PMs to master, and is the one most easily supplemented. So, while we
still keep it on our list, we think the other four areas are more important.
 Stakeholders. With the advent of digital business, the centricity of the "customer" or, in our lexicon,
the "stakeholder" is once again regaining its rightful place in the world of projects. It isn't just that
project managers need to report their status to stakeholders in the business; it's that project
managers need to understand how to ensure that stakeholder needs are met across a broad
spectrum of activities. Does the project support the right level of stakeholder engagement by type
of stakeholder? Have usability issues been appropriate addressed? Will value rather than just a list
of feature functions be delivered at the end of the project? Many organizations might say this level
of involvement with stakeholders is the product manager's job or the sponsor's role, and our
response would be "Great. Then you don't need to assign a project manager." Consider instead a
project specialist or a project coordinator (see "Not Every Project Needs a Project Manager").
Competencies define the role is the essence of a performance-based competency approach. A
specific assignment may not require all the competencies, but if too many of them are missing then
the role isn't required.
 Risk management. Dr. Lynn Crawford of the University of Sydney, who did much of the early work
on defining project management competencies, has stated definitively that risk management is the
single most important project management leader competency. After a moment's reflection, the
reason for this should be obvious. The only thing a project manager can ever be sure of on a project
is that something will go wrong; therefore, the primary reason we assign a project manager is so
that we will have someone who understands what is going on when the specific unforeseen event
occurs.
Many organizations are calling us and asking: "What will the role of the project manager be in the future?"
Our answer: The role of the competent project manager, as discussed above, will remain unchanged. The
role of the administrative project manager — potentially 50% of the PMs working in IT today — will most
likely slowly diminish because the shift from project to product will largely eliminate the need.
Administrative PMs will still have a role in a program management office but the majority of PM jobs
available in the future will be for competent project managers. PMO leaders who begin to change their
focus and ensure that their PMs are well-trained and supported in the role of a true project manager will
have the greatest success in the digital future.
https://www.gartner.com/doc/3558817/avoid-seven-deadly-sins-level