The Value PMLC Process Capability

The Value of Project
Management
Lifecycle Process
Capability
Bill Monroe, CMQ/OE, CQA, PMP
President
Project Portfolio Excellence, Inc.

- 2 -
Bill Monroe, CMQ/OE, CQA, PMP ©2016 Project Portfolio Excellence, Inc.
wmm@projectportfolioexcellence.com
Introduction – Here’s Where We Are
In the summer of 2001 there were fewer than 35,000 certified Project Management Professionals in the
world. I know because that’s when I attained my PMP certification. Back then, the vast majority of
organizations were frustrated and dissatisfied with the value and benefits they were getting from their
enterprise software and software-related projects.
In the 1st
quarter of 2016 the number of Project Management Professionals surpassed 700,000… and the vast
majority of organizations are still frustrated and dissatisfied with the value and benefits they’re getting from
their enterprise software and software-related projects. So, while PMP certification has become a guide for
selecting applicants for interviews, there’s little evidence that it directly affects the probability of success for
enterprise software implementations and other software-related projects.
This paper exposes the factors that lead to project underperformance and details an approach to improve
project value and benefits, lower Total Cost of Ownership, and simplify ongoing management of software
deliverables by analyzing and increasing the capability of the Project Management Lifecycle processes.
 It doesn’t matter how expertly you manage a project that has no chance for success
 It doesn’t matter how much potential value a project has if it has no chance for success
 It doesn’t matter how badly you need, or how desperately you want a project to succeed, if you
don’t have the skill, the will, and the capacity to achieve it
Question # 1:
Is your organization getting the expected value and benefits
from enterprise software and software-related projects?
I’ve been asking this question for years and the responses are consistent. If I’m speaking with IT, they usually
describe the good relationship they have with their Business “partners” and how they consistently deliver
quality results and value. If I’m speaking with someone on the Business side of the house, however, the
answer is usually quite different. How would you answer this question?
Question # 2:
How would you describe the level of
quality in your production environment?
Once again, the answer depends on who you’re speaking with. Senior managers might express that
production quality may not be perfect, but for the most part it’s good (It should be noted that recently more
executives are expressing concern about poor quality in the production environment, some to the point of
being worried for the future of their organizations if these quality problems can’t be resolved).
On the other hand, Business Professionals (the people who perform operational processes on a daily basis)
will more likely paint a picture filled with applications that don’t work the way that they’re supposed to, with
data that is inaccurate or incomplete, with systems containing contradictory data and functionality, and with
projects that never seem to get it right when it comes to fulfilling the needs of business operations. Take

- 3 -
another moment to think about how you would describe the quality of the applications and data in your
Production environment.
If your organization is like most, you’re not receiving the value and benefits that are envisioned when
projects are approved for funding and execution. It’s been reported that projects fail to achieve scope,
budget, and schedule objectives anywhere from 50% to 70% of the time. Whether this is correct, or even
close, isn’t important. Because, for most organizations, the lack of value and benefits received from projects
calls into question whether many projects should have been approved in the first place. And the poor quality
that most organizations suffer from in their production environments results in a significant amount of time,
money, and energy wasted in order to address post-implementation quality issues and deficient functionality.
This is likely to be a fairly accurate description of your organization’s current position. If so:
Question # 3:
Is the pain of poor quality, lack of results, and insufficient software and
project value and benefits enough that you’re ready to do something about it?
If so, then let’s start by defining what it means for a project to be successful. The traditional measures of
project success are based on whether the project meets its objectives, defined by the so-called triple
constraint (scope, schedule, and budget). But, most of the time, projects aren’t funded and launched based
on scope, schedule, and budget; they’re launched because they promise to return more value than they cost.
You could argue that a project that met the objectives of the triple constraint but didn’t return the expected
value might not be successful, or that a project that returned the expected value, but took longer, or cost
more than originally envisioned might be a tremendous success. Whether a project was worth undertaking
in the first place depends on the value and benefits resulting from the investment of time, money, and
capacity to execute it. In this sense, when a project returns less value than expected it means that time,
money, and capacity may have been wasted.
In today’s business climate, few organizations can afford to waste time, money, and energy on
underperforming software and project investments.

- 4 -
What is Value?
So, if project success is mainly about the attainment of value, how do we define value?
Value is a desired byproduct of process execution.
The value derived from a process depends on particular process characteristics and operational factors. Here
are some critical process characteristics for value attainment:
 The process must align with the organization’s strategic direction
 The process must support the agreed upon tactical approach
Successful execution of a process that isn’t aligned with the organization’s
strategic direction may be a waste of time, money, and energy
Planning Hierarchy:
STRATEGY  TACTICS  OPERATIONAL PROCESSES  PROJECTS
 Strategy is determined by Senior Management
 Tactics are designed by Business Professionals to accomplish the strategy
 Operational Processes are defined and implemented to support the execution of Tactics
 Technical Professionals develop tools to enable Operational Processes to be executed
Here are some critical operational factors for value attainment:
 Process demands must not exceed the capabilities, capacity, or constraints of the organization
 The process must be able to deliver an acceptable level of quality
“Operational Factors” refers to capabilities, capacity, and constraints. When software and project results are
not meeting expectations, it’s likely that one or more of these factors is being violated. Operational Factors
can all be quantified, although few organizations implement formal processes to understand their actual
capabilities, capacity, and constraints. As a result, many projects are approved and launched even through:
 The skills and capabilities required for success are not fully present or available
 The capacity (time, money, resources, etc.) is not available
 Organizational constraints make success with the project unlikely (maybe even impossible)
Value Attainment Hierarchy:
PROJECTS  CAPABILITY/CAPACITY/CONSTRAINTS  QUALITY  VALUE
 Projects are approved for execution
 Projects cannot exceed organizational capabilities, capacity, or constraints
 Quality is determined by the capability of the Project Management Lifecycle processes
 Value is determined by the quality of the process deliverable

- 5 -
The quality of results of an executed process determines the
extent to which the process is capable of returning value
The importance of gaining an understanding of Project Management Lifecycle process capability is that, in
most cases, deficiencies in operational factors can be detected before a project is launched. When this
happens not only can potential project failures be avoided, but resources that might have otherwise been
wasted can be deployed to more promising initiatives. It can also expose areas of weakness that must be
corrected or properly managed in order to maximize the probability for success in cases where a project is
mandatory.
The causes of project failure are easy to diagnose, simple to understand,
and are often detectable before project kick-off!
What is Process Capability?
In order to understand the importance of process capability we should first define what is meant by process
capability. Process Capability is:
The characteristic of a process that, when it’s executed as
defined, it produces the expected results, at the expected
level of quality, thereby producing the expected value
Consider this example:
If you were a manufacturer, and your processes resulted in 50% of your products not meeting specifications,
you would surely conduct an investigation. If your order fulfillment process resulted in customer orders
being filled incorrectly 50% of the time, you would absolutely have to figure out what was going wrong.
It’s been reported that software-related projects fail to meet expectations 50% of the time or more. How can
organizations continue to neglect the analysis and correction of their Project Management Lifecycle
methodologies? When projects fail too much time is spent pinpointing blame for the failure and not enough
time pinpointing the causes. The focus is too often on people instead of the process.
Project failure is a process problem, not a people problem!
The Project Management Lifecycle is an enterprise-spanning process that’s owned, jointly, by everyone
involved. Therefore, when a project fails, it’s EVERYONE’s responsibility. Everyone should be concerned with
exposing the flaws in the process that led to the project not meeting expectations.
It’s important to stop worrying about who is to blame and start thinking about how the current methodology
is flawed because:
 It doesn’t matter how flawlessly you execute a flawed process
 Until a process can consistently produce the expected results you can’t make meaningful
management decisions regarding process cost or improvement. You can only guess!

- 6 -
The expected value and benefits from a project investment play a large part in project selection, funding and
prioritization processes. But, if Process Capability is lacking, any attempt to forecast value and benefits from
projects is guesswork.
Many organizations are facing an increasing number of project requests, and they’re looking for ways to
increase throughput and decrease costs.
Increasing the velocity of a flawed process just creates poor quality faster (something many organizations are
currently experiencing in their Production environments).
It’s not how project management is designed, it’s how project management is executed!
If your current process is incapable of creating consistent results of acceptable quality, how can you make
any meaningful decisions regarding process improvement or cost reduction?
You can’t control quality costs if you don’t know what quality costs!
Until you can consistently achieve quality, you can’t understand how much it costs to create quality. And
until you know how much it costs to create quality you can’t make strategic management decisions to
balance process cost and value.
Process capability is achieved through the
Effective execution of a Capable process
The components that combine to determine Process Capability are:
 Having a process that is capable of producing quality results
 Being able to effectively execute that process
You have to be able to execute the process effectively and consistently before you’ll be able to determine
whether the process is capable of producing quality results and value.
The process we’re talking about is not the diagram on the wall (or more often, these days, in SharePoint); it’s
the process in real life. Often, when I ask if there’s a formal PMLC process I’m shown a beautifully detailed
process map that, upon further questioning, bears little resemblance to the way in which project work is
actually performed.
It’s not the methodology on the wall that counts, it’s the methodology on the ground
If you find that you’re consistently disregarding your supposed standard process in order to meet the
demands and expectations of project sponsors or management, the formal process is insufficient for your
needs and the enterprise standard should be reviewed and redesigned.
It’s of tremendous value to acknowledge the actual way that projects are executed, especially if it’s not
according to agreed-upon practices. Until you link your actual results to your actual practices, you won’t be
able to begin to meaningfully measure, manage, or improve your processes.

- 7 -
We’ve defined what’s needed in order to achieve Process Capability. There are several conditions which
contribute to a lack of Process Capability:
 Ineffective execution of a capable process
 Effective execution of an incapable process
 Ineffective execution of an incapable process
If your process is perfect but you’re unable to execute it effectively, no matter what the reason, you won’t
achieve the value and benefits that you expect from your projects.
If your process is flawed then, no matter how perfectly you execute it, expected value and benefits will not
be realized.
If you ineffectively execute a process that’s flawed in the first place, then you have the worst of both worlds.
But, until you develop the ability to consistently execute the process, you won’t be able to accurately
measure the extent to which it’s capable of giving you the results you expect. You also won’t be able to
determine where the weaknesses are. Here’s the order in which process analysis and improvement must
occur:
What is the Project Management Lifecycle (PMLC)
Process?
Figure 1 - The Project Management Lifecycle (PMLC) Process
CONSISTENT execution of the process allows for analysis of the
EFFECTIVENESS of the process, which enables improvement of
EFFICIENCY, COST, & VALUE components of the process.

- 8 -
This is a simplified illustration of the PMLC process. It contains all of the detailed processes that are used for
the analysis, selection, funding, prioritization, management, and execution of project work. The Software
Development Lifecycle (SDLC) processes are included in the PMLC.
It’s important to note that various activities in the PMLC process are the responsibility of different groups
within the organization. I’ve shaded the boxes in the diagram either red or green to show that some are the
responsibility of Business Professionals and others are the responsibility of Technology Professionals. You
can see that Business Professionals are ultimately responsible for over half of the activities in the PMLC.
Because there are always more project requests than the organization is able to pursue, proposals are usually
considered based on the value and benefits that will be returned for the investment of resources. Decisions
must also support the strategy and strategic direction of the organization.
Senior Management’s Responsibility in the PMLC process:
Figure 2 - The PMLC Contains Strategic Elements
Senior Managers understand strategic considerations
Organizational strategy is the purview of Senior Managers. They understand where the organization is
headed in terms of future goals and objectives. These goals and objectives will be important when
considering which projects will be approved for funding and execution. It’s critical that approved projects
don’t inadvertently exceed the capabilities, capacity, or constraints of the organization. For example:
 If an approved project depends on skills that are either lacking or unavailable, for whatever reason,
the probability for success for the project will be diminished
 If an approved project exceeds the capacity of critical resources, whether from IT or Business, the
project will have a diminished probability for success
 If an approved project violates organizational constraints, whether pertaining to budget, scope,
schedule, culture, etc. the probability for success for the project will be diminished

- 9 -
Senior Managers may not have direct visibility into all of these issues. That’s why it’s important that they
collaborate with Business and Technology Professionals during portfolio management activities.
Business Professionals’ Responsibility in the PMLC process:
Figure 3 - The PMLC Contains Tactical Elements
Business Professionals understand tactical (operational) considerations
Senior Managers may dictate the strategy of the organization but Business Professionals are the experts
when it comes to evaluating what needs to occur to weave strategic or regulatory changes into the fabric of
daily work.
Defining, designing, and validating the tactical elements that will achieve strategic directives must be done by
Business Professionals because they’re the people in the organization who have the greatest understanding
of the business processes that are executed every day. Their knowledge extends beyond simple “happy-
path” understanding, and includes awareness of how exceptions to normal processes are handled.
Business Professionals, specifically the people who own the processes which are being affected need to be in
the loop and in the conversation when considering and documenting project requirements. If they’re not
present, or not allowed to adequately focus on the issues, bad things can happen such as:
 Requirements may be insufficiently detailed necessitating follow-up meetings
 Requirements may overlook seldom used process paths leading to an incomplete solution
 Requirements may not properly consider secondary systems and interfaces
 Specifications may not supply adequate coverage of the Business Requirements
The consequence for any of these situations is wasted time for rework or post-implementation maintenance
because of a solution that can’t properly support the tactical objectives needed to achieve the strategic
directive. Another frequent consequence is outright project failure.

- 10 -
Technology Professionals’ Responsibility in the PMLC process:
Figure 4 - The PMLC Contains Technical Elements
Technology Professionals understand technical considerations
Seniors Managers set direction and strategy, Business Professionals define tactical and operational needs,
and then Technology Professionals build systems and tools which enable tactical plans to be executed.
It was mentioned earlier that if Senior Managers approve projects that violate the capabilities, capacity, or
constraints of the organization, the probability for project success is diminished. If Business Professionals
aren’t given sufficient time and opportunity to fulfill their responsibilities concerning project definition,
design, and specifications, project success is also negatively affected.
Technology Professionals normally don’t have high visibility and input into organizational strategy. They
don’t have the level of detailed knowledge of Business and operational processes that Business Professionals
do. What they do have, often to a greater degree than either of the other two groups, is knowledge of the
systems and applications used throughout the organization. They can provide essential information
concerning the application infrastructure when new projects are being considered. When Technology
Professionals are not included in early project analysis bad decisions can easily be made. This can result in
additional cost over the life of the project, lost time spent correcting mistaken assumptions, and considerable
frustration on the part of everyone.

- 11 -
It’s through the effective collaboration of Senior Managers, Business Professionals, and Technology
Professionals that the probability of success for software-related projects is maximized.
Figure 5 - Strategic, Tactical, and Technical Balance

- 12 -
Evaluating PMLC Process Capability
It was stated earlier that in order to effectively manage and improve the PMLC you must first understand
why you’re getting the results you’re currently getting.
How is this done?
Figure 6 - The Project Management Lifecycle (PMLC) Process
Each sub-process in the PMLC represents an opportunity for error. Some examples:
 The vision of the project sponsor isn’t in alignment with the direction of the organization
 The justification for the project is biased or based on erroneous estimations of value or cost
 Prioritization is made based on incorrect assumptions
 Project planning and design are not given enough attention
 Detailed requirements are inaccurate or incomplete
 Many other possibilities…
You can see that there are many opportunities for missteps, and we haven’t even gotten to the point where
IT designs and builds the solution!
Errors made in upstream processes will propagate downstream to be discovered at a later stage, where they
will be more expensive to correct. In the worst case scenario, defects are promoted into the Production
environment, requiring post-implementation maintenance or rework.
Every hour, dollar, or thought spent fixing post-production
quality issues is stolen from future, value-adding project work

- 13 -
PMLC Process Capability is measured over the entire lifecycle, from beginning to end. It includes analysis of
each step in the process, how it’s being performed, and whether capable execution of the process returns
the expected result and value. The objective is to expose the origins of poor quality, understanding that:
 The point at which poor quality is discovered is downstream from where it originated
 Actions that result in quality problems can happen anywhere in the PMLC process
The ideal situation would be to have quality checks at each stage of the PMLC process. That’s not often
practical or feasible. There are three points in the lifecycle where quality issues are most often detected:
 During programming and IT testing activities
 During User Acceptance Testing
 After promotion to the Production Environment
Figure 7 - Validation Points for Process Capability
Development and IT Testing
The first point where quality problems are most likely to be exposed is during programming and IT testing.
This may be the point where gaps in requirements are caught. It may also turn out that during the course of
addressing those gaps previously overlooked or unrecognized requirements are exposed.
Completing requirements after development has already started is extremely expensive and wasteful. When
this happens it may also indicate a weakness in your PMLC methodology. Maybe not enough time is being
dedicated to requirements gathering and definition, or maybe the right people aren’t being included in those
activities.

- 14 -
User Acceptance Testing
The next point where quality problems are likely to be exposed is during User Acceptance Testing. Hopefully,
by this point, the only problems that will crop up will be cosmetic and easily fixed. But it’s often at this point
that Business users discover that the solution they’re being presented with is not what they thought they
asked for. Adding missing functionality at this point is not only more expensive than if it was included to
begin with, but it’s frustrating for Business users, when they’ve been waiting for the solution only to find out
that it’s not sufficient for their needs.
It can be extremely valuable to figure out whether a problem at this stage is a one-time issue or whether this
kind of thing happens consistently because of an inherent problem with your upstream processes.
Post-Production Rework
The final, and most expensive point where quality problems are captured, is after the solution has been
promoted to the Production environment. At this point problems with functionality and data can negatively
impact your customer’s experience. Poor quality can ultimately result in the loss of credibility and possibly
even revenue.
Once quality problems get into the Production environment, decisions have to be made as to whether to
spend the time, money, and energy to fix the problems at their source, or to simply react to daily issues as
they occur. Regardless of the final decision, the assignment of resources to deal with quality issues after the
fact reduces the amount of resources available for new project work, and may also impact projects that are
already in flight. This compounds the effect of poor process capability and, unfortunately, this is where very
many organizations find themselves today.
Building PMLC Process Capability
Hopefully by now, an adequate case has been made as to the Value of PMLC Process Capability and the
importance of analyzing and measuring it. Now the question is how to improve the capability of your PMLC
process. That’s the topic of this last section.
If you’ve had any exposure to Continuous Improvement or Lean Thinking concepts you’re probably familiar
with Plan-Do-Check-Act. Some folks refer to this as the Deming Cycle, some call it the Shewhart Cycle
(including Deming himself), and some just call it Plan-Do-Check-Act, or PDCA.
It’s about creating a “Closed-Loop” system in which you:
 Gather and analyze data about the capability of your PMLC process
 Decide whether your level of capability is satisfactory
 Figure out what needs to be done to improve your capability
 Adjust the process accordingly
 Return to step 1, to gather and analyze new data

- 15 -
The previous segment illustrated the three most likely points in the PMLC process where information about
process quality can be obtained. This is illustrated again in Figure 8.
Figure 8 - Validation Points for Process Capability
When a quality-related issue is found, a decision must be made as to whether corrective action can be, or
needs to be taken. If it’s decided that the situation is not acceptable, or that Process Capability is not
adequate, the point in the PMLC process where the problem occurred must be identified.
Since quality-related problems can originate at any point in the PMLC process, it’s important to take the time
to determine specifically where quality issues are originating. This is referred to as Root Cause Analysis. The
point of performing Root Cause Analysis is to make sure that improvement initiatives are targeted at the
actual causes of the problem rather than addressing symptoms of the problem. For example, what may look
like a programming error could have many different causes:
 Maybe the person who defined the requirements didn’t understand the Business process
 Maybe insufficient time was available to adequately design the solution
 Maybe critical information was missed because subject matter experts were not consulted
 Maybe the developer was overloaded and didn’t have time to adequately focus on the task
All of these issues indicate a lack of process capability. They also point to different stages of the Project
Management Lifecycle. In order to improve process capability the solution needs to be applied at the
appropriate point in the process.

- 16 -
There are many other possibilities, but all can be tied to a flaw in one or more processes. With effective
determination of the Root Cause, corrective actions can be applied at any point in the PMLC process. This is
illustrated in Figure 9.
Figure 9 - Applying Process Capability Corrective Actions
To reiterate how important it is to apply corrective actions at the proper point in the process, a quality issue
that is identified in User Acceptance Testing may have originated at any of several points upstream:
 Maybe the developer misunderstood the specification
 Maybe the specification lacked clarity
 Maybe the developer lacked the skill required for the task
 Maybe the developer has been given conflicting assignments or has been overloaded
 Maybe the design didn’t correctly satisfy the needs of the specifications
 Maybe the design didn’t properly capture secondary system requirements
 Maybe insufficient time was available to consider all of the design implications
 Maybe the requirements were inaccurate or incomplete
 Maybe the project schedule was too aggressive
 Maybe the project budget was insufficient
 Maybe critical resources didn’t have the capacity needed for planning
 Maybe bad assumptions were made as to capabilities, capacity, or constraints
 Maybe the project should never have been selected and approved in the first place
Look again at Figure 9 and think about other possibilities that can contribute to a lack of PMLC Process
Capability.
Any improvement efforts applied to symptoms instead of actual causes will only conceal the problem.
Additionally, these initiatives may simply add an extra layer of waste to an already underperforming process,
making it even more costly.

- 17 -
Every organization would love to be able to get projects done faster and cheaper with fewer resources and
better quality. At the same time, most organizations have little understanding of their capabilities, capacity,
and constraints. These are the factors that have the greatest impact on the ability to achieve the value,
benefits, and quality envisioned for enterprise software and software-related projects.
Project Management Lifecycle Process Capability can be measured, evaluated, and improved. The vast
majority of organizations are desperate to attain the value and benefits promised by enterprise software and
software-related projects but they have no idea why their efforts so often fail to meet expectations.
To reiterate, the simple fact is that:
The causes of project failure are easy to diagnose,
simple to understand, and are often detectable before project kick-off!
For questions, or a PMLC Process Capability action plan contact me:
Bill Monroe, CMQ/OE, CQA, PMP
(502) 598-1912

The Value PMLC Process Capability

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to The Value PMLC Process Capability

Similar to The Value PMLC Process Capability (20)

The Value PMLC Process Capability