5 Proven Approaches for Project Success

Thank you for attending our webcast today.
This topic should be one we all are familiar with, since it is nearly impossible to
not have experienced a project failure at least once in our career.
We usually start our project management quest with capturing requirements,
building a schedule to deliver them, executing that schedule, and making
adjustments along the way when we’re not staying on schedule.
The principles I’m going to speak to you about are universal. Applicable to any
project, of any size, in any domain.
What you’re going to hear is not the solution to avoid project failure. It is the
framework for project success.
The actual mechanics of managing a project are based on these principles.
The practices used in this management should be based on the se principles.
And of course the process ad tools should implement the practices.
5 Proven Approaches for Mitigating Project Failure
Page 10:44

Nearly every business activity is based on a project in some way.
Even the operational aspects of a business are projectized through processes,
procedures, and business management governance.
Today I’d like to focus on the types of projects Land speaks of. The really
important ones that are nearly impossible.
I was a participant in one of those projects – Rocky Flats Environmental
Technology Site. The name of the site was a nice marketing term for the
cleanup of a nuclear bomb factory.
It was nearly impossible. And manifestly important The previous contractor had
spent $4B and not done much.
When Kaiser-Hill (a joint venture between ICF Kaiser and CH2MHill) won the
contract for $7B, they had a plan that was dramatically different from the past
attempts to cleanup and close the site.
This plan focused on applying the 5 Immutable Principles, defining the
“packages of work” that delivered the outcomes, measuring progress as
physical percent complete, and risk adjusting everything to produce a credible
Estimate to Complete on a weekly basis for 5,000 staff working on site.
Page 21:06

I’m going to present 5 Immutable Principles today that are the foundation of
project success.
These Principles are “Immutable” because they must always be present. They
are the foundation on which the Practices and Processes are built.
We won’t look at the Practices and Processes, but they are critical to the
success of any project as well.
Those are available in the book from AMACOM.
Page 30:20

There are nearly unlimited reasons for project failures.
Root Cause Analysis is the means to separate the symptoms of project
difficulties from the actual causes of those difficulties.
If the Root Cause is not found, prevented or corrected, it will reappear.
This is a short list of Root Causes.
You’ll likely have your own list, but I suspect it will overlap with these.
4

With this background, let’s start with the 5 Immutable Principles of Project
Success.
I would suggest these are applicable in any technical domain.
Any project management method.
Any business domain.
They are universal and Immutable – meaning they don’t change over time.
They are permanent principles that must be applied for the success of any
project.
The Principles are in the form of questions in this example. There are more
formal statements about the Principles, but starting by asking 5 questions
shows how the principles can be applied in any situation.
When there is not a credible answer to the question, this is an indication there
is likely trouble on the project and the probability of success has been lowered.
Page 50:40

With the Principles and Practices, we need Processes to put to work.
Some of you may recognize these as part of the Earned Value Management
processes in EIA-748-C.
But there are also the basis of all good project management work. You really
can’t be managing a project – in any credible manner – if you are doing these
11 processes.
• What are we building?
• Who’s on our team?
• Who’s doing what?
• What’s the sequence of the work?
• What are the outcomes of that work?
• What’s the budget for the work to produce those outcomes?
• What did it cost to produce each outcome?
• What was the difference between our budget and the actual costs?
• What’s the total differences for the entire project?
• What are we going to change to get back on budget and schedule?
• Did we record these changes?
6

We keep using the term Deliverable.
Here’s what that means.
It means the customer bought something they can put to work to fulfill a
business case or accomplish a mission.
The deliverables, taken individual are just individual functions of the project.
Taken as whole, they provide a set of capabilities that can be used by the
customer to accomplish something.
Along the way, each deliverable increases the maturity of the projects
capabilities.
We can start with a few deliverables. The customer may or may not be able to
accomplish something with those deliverables, but their presence may be
necessary for further deliverables to provide a capability.
There is a myth in the agile development business, that Value products need
to be delivered starting on day one. This may be appropriate for simple
projects. But most complex systems have pre-conditions for success. We need
to install the Database Server before we can use build databases. We have
foundation activities on which we build other capabilities.
So the challenge is to determine the order of the needed capabilities to reach
the needed maturity at the time that maturity is needed
7

So let’s revisit our 5 Immutable Principles once more with the Practices and
Processes in hand.
• What does our customer need to fulfill their business case or accomplish
their mission?
• What are the technical and operational requirements that must be delivered
to fulfill that mission?
• What’s the schedule for that work?
• How are we going to measure progress to plan?
• What impediments are we going to encounter along the way and how are
we going to deal with them, so they don’t impact the success of our project?
This is the basis of Capabilities Based Planning. It’s the capabilities that are
delivered. These are enabled by through the deliverables appearing tin the
right order, fulfilling the right requirements, each building on the previous
requirements and capabilities.
8

Traditional project management is a good foundation for all project work.
Performance-Based Project Management® adds another paradigm to that
foundation – we measure progress to plan in terms of performance outcomes.
This separate Output (effort, cost, deliverables) from Outcomes (the capability
to do something needed for success).
Performance-Based Project Management® is risk based, from Tim Lister’s
advice Risk Management is How Adults Manage Projects.
9

Here’s how to assemble the Practices to increase the probability of project
success.
This is a simple diagram, showing the order of work.
• Answer the question Why Do We Need This – by defining the needed
capabilities. If you start with requirements, you may or may not know why
those requirements are there. What there purpose is. These capabilities
have Measures of Effectiveness.
• Identify the requirements that produce the capability to do something. These
requirements have Measures of Performance.
• Layout all the work in the right sequence – this can be an agile sequence,
with current releases, future release, sprints and the like. But knowing what
capabilities we’ll need for project success is a Critical Success Factor, no
mater what development method you use.
• Execute that sequence of work and measure physical percent complete to
plan.
• Along the way, make sure you have all the risks identified, handled, and the
results included in future planning processes
10

So let’s move to the next step. Applying the Practices and Processes
11

The first Principle is to assure we know what Done looks like. This sounds like
a simple process. But turns out to be the root cause of most project failures.
Done is not described in any meaningful units of measure for the decision
makers.
Our first response is usually to make a list of features and functions for the
product or service produced by the project. This is necessary but far from
sufficient to describe Done. We don’t know how these features and functions
interact, how and when they provide value to the customer.
The interdependencies are next. We need to show how each feature or
function is dependent – if it is – on other features and functions. This usually
starts with the Work Breakdown Structure (WBS) showing all the deliverables
from the project. The WBS needs a WBS Dictionary to show how we are going
to measure the performance, quality, compliance of these outcomes with each
other and the customer.
But the WBS and its Dictionary are not enough to know what Done looks like.
We need to know what Capabilities are being provided by the project. What is
the customer going to DO with these outcomes? How are they going to satisfy
the business needs or mission?
The Capability to do something is what the customer bought.
Page 121:08

These Capability statements are clear and concise. Long before we ever arrived in
the moon, Robert Goddard knew what capabilities were needed to get there.
On October 19, 1899, Goddard climbed a dead tree to trim some branches. He was
17. He is quoted as saying … “I imagined,” he later recalled, “how wonderful it would
be to make some device which had even the possibility of ascending to Mars, and
how it would look on a small scale, if sent up from the meadow at my feet. . . I was a
different boy when I descended the tree from when I ascended, for existence at last
seemed very purposive.”
He had in his mind what capabilities were needed to fly outside the Earths
atmosphere. He knew some of the units of measure that had to be fulfilled to do this.
If we don’t have some vision of the project at the Capabilities level, we really can’t say
what Done looks like. We can describe the technical aspects, but we can’t say what
we are going to do with those technical aspects.
This definition of Capabilities is a Systems Engineering role. There are formal
processes to elicit these Capabilities through the Concept of Operations, Scenarios,
and Use Cases, making tradeoffs between cost, risk, schedule, and technical
performance, and balancing all the feasible alternatives.
The result is the Measures of Effectiveness which tell the customer the project will
meet the needed capabilities.
Page 131:15

With the needed Capabilities we can now develop a plan and schedule for the work.
Knowing how to get Done on–budget and on–schedule means knowing what
requirements will have to be fulfilled.
Poorly formed requirements contribute as much as 25% to the failure modes of
programs and projects.
This starts with Fact Finding, Gathering and Classifying the Requirements, Evaluating
and Rationalizing the Requirements, Prioritizing them, and Integrating and Validating
the Requirements.
With this in hand we can start building the packages of work that implement the
requirements.
The result is a Plan and a Schedule. The Plan is the Strategy for the proper delivery
of the Capabilities produced by the project. The Schedule is the sequence of work
needed to implement the Strategy. Both are needed.
The Plan is emergent, since it is a strategy. The Schedule tests this strategy on short
term boundaries, with measures of physical percent complete.
Both the Plan and the Schedule must be capable of responding to change as new
information about requirements, program performance, and risks emerge.
But the needed capabilities should remain stable if we are to have a baseline on
which to execute our project.
Page 141:05

The Plan can be very simple or it can be complex.
Here’s a plan that took us to the moon and back.
This picture shows a simple concept. Build the launch vehicle, the fuel to
power it, the space craft on the top, train the astronauts, do the testing, and fly.
The Plan shows the 6 major systems , their approximate duration in years, and
the dependencies between them are all that is needed to confirm the feasibility
of the project.
Notice the longest activity is the training of the crew. No one had ever flown in
space before all the way to the moon and back. So training was high risk and
critical to success.
Page 150:35

One view of the Plan is the vertical integration of the deliverables.
This is the deliverables traceability view. At the bottom is our deliverable.
The deliverable is produced by work contained in a work package. A Work
Package says its name. it produces a single outcome.
The technical capabilities needed for the project’s success are produced by
the Work Packages.
Finally these Technical Capabilities produce business or mission capabilities
needed by the customer for project success.
This traceability is necessary for a credible Plan and Schedule. It is also
necessary for a credible project delivery process.
This traceability tells everyone what Done looks like and how we are going to
get there.
Page 160:35

With the Plan in place and the “packages of work” identified in the Schedule,
we can construct a picture of how we are going to reach Done.
This picture is not like the typical horizontal scheduling activities we see in all
the scheduling tools.
This picture starts with the vertical integration of the deliverables as they
progress through their maturity life cycle.
This is called the Integrated Master Plan. This Plan shows the Measures of
Effectiveness and Measures of Performance we need to achieve to reach a
specific level of maturity.
This notion of levels of maturity can be seen is we use some words
Preliminary is a work. We all know what preliminary means. It means we’re not
done yet. We have a preliminary design, we have a preliminary cost estimate,
or a preliminary list of subcontractors. We know enough about the project to
make some decisions, but we need more details before we can say for sure
the cost, the design, and the subcontractors are all in place.
This incremental approach allows us to move foreword without all the details,
while still having visibility into what Done looks like.
Since many projects are discovery driven, planning needs to be increasing
maturity driven without the planning horizon.
Page 171:08

Projects are executed by people.
People consume time, money, and materials.
How can we know if we have enough of everything we need for success?
We need a Plan of course, in this case a Resource Management Plan,
showing people, funding, and materials, and when and where we need it.
We can start with a simple list. This gets us to write it down.
Next we need to assign people and money to the needed resources. How
many of each special skill type will we need for this project.
In the end though, we need to lay out these needs against the schedule of
work. We need to resource load the schedule. This sounds like a lot of work
and it is. But without this in place we really have no idea if the project is
feasible.
Page 180:40

We usually start by identifying risks. But risk is the result of uncertainty. There
are two types of uncertainty – reducible uncertainty and irreducible uncertainty.
We can do something about reducible uncertainty. We can buy more
knowledge about this uncertainty – it is epistemic. We can run tests, build
prototypes, look at what others have done. The risk that results is reducible.
The irreducible uncertainty is part of the world around use. This uncertainty
cannot be reduced – it is Aleatory uncertainty. The only way to deal with this
uncertainty is through margin. Cost margin, schedule margin, technical
margin.
We have to start by identifying these uncertainties and associating them with
the risks.
Then the impacts of the risk are identified along with their dependencies.
The probability of occurrence and the probability of their impact can be
assessed.
With these impediments in hand we can take actions to either protect our
project with margin or spend money to retire or handle the resulting risk.
Page 190:57

With our Plan, Schedule, Resources, and Risk Management Plan, we can now
determine how we are going to measure progress to these plans.
The customer bought outcomes, deliverables, capabilities. We need to
describe these in a way the customer understands. Units of measure that are
meaningful for making decisions.
These are best described as Technical Performance Measures. These are
attributes that determine how well a system or system element is satisfying or
expected to satisfy a technical requirement or goal
But these alone are not sufficient for the success of the project. We need
Measures of Effectiveness (MoE), Measures of Performance (MoP), and Key
Performance Parameters (KPP).
MoEs are operational measures of success that are closely related to
the achievements of the mission or operational objectives evaluated in
the operational environment, under a specific set of conditions.
MoPs characterize physical or functional attributes relating to the
system operation, measured or estimated under specific conditions.
KPPs represent the capabilities and characteristics so significant that
failure to meet them can be cause for reevaluation, reassessing, or
termination of the program.
Page 201:09

If we don’t have a plan. If we don’t have the proper resources available at the
needed time. If we don’t handle risks if we don’t have measures of physical;
percent complete.
We can’t have confidence the project will be successful.
Without these elements, the probability of project success is reduced. Possibly
to the point of project failure.
Without these elements, we have created risk to our success with no handling
plans.
It is this unmitigated risk that creates the unanticipated growth in our Estimate
At Completion.
Page 210:29

Over a large number of complex, high risk programs there have been a small
number of root causes discovered for failure.
There are shown here.
Reading them they seem obvious.
Dealing with them is more difficult .
But we must deal with them and we must have information needed to deal with
them.
This information comes from the tools and processes used to manage the
project.
Scheduling, cost, risk, performance measurement, and forecasting tools and
the processes used to apply them.
Only when all this information, integrated though a single “lens” can we have
the needed visibility to take corrective action to keep the project GREEN.
Stay on schedule, stay on budget, comply with the technical requirements. Or
if not, know about the variances soon enough to take corrective action.
Page 220:41

Let’s quickly review the 5 principles of project success in the time remaining.
What does done look like? The customer needs to know what capabilities will
be possessed when the project is done. The capabilities produce the business
value or fulfill the mission objective.
How do we get there? We need a plan and a schedule. We need to sequence
the work properly in the order to produce continuous value.
Are there enough resources? People, material, facilities? Are they the right
people, does the material arrive at the needed time, are the facilities adequate
to produce the needed outcomes?
What are the impediments to progress? Risk management is how adults
manage projects. Do we have a risk register? Do the risks have handling
plans? Is the cost and schedule baseline adjusted for these risks?
How do we measure progress? The only way is tangible evidence of physical
percent complete. This means “show me” the outcomes and show me they
meet the specifications, on the planned day for the planned cost. If not we’re
late, over budget, and out outcomes probably don’t work right.
Page 230:57

24

5 Proven Approaches for Project Success

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 5 Proven Approaches for Project Success

Similar to 5 Proven Approaches for Project Success (20)

More from Glen Alleman

More from Glen Alleman (20)

Recently uploaded

Recently uploaded (20)

5 Proven Approaches for Project Success