Increasing The Probability Of Success For Your Project
Thank you for attending this session today. I know there is lots of competition for your time and attention. My
name is Glen Alleman and I’m a Practice Vice President for the Aerospace and Defense offerings of Lewis &
Fowler, in Denver Colorado.
What you will learn today will allow you to go back to your company and change the way you think about
projects. Not because of tools, because this session is not about tools. Not because of some magic formula for
running your project, because there isn’t one. But because you’ll have a different view of how projects are
structured and different words to use when talking about how you run your projects. The first set of words are
“The Probability of Success.”
Let me finish my opening here with a bit about myself. My primary interests these days is the application of
Program Planning and Controls (PP&C) in the aerospace and defense business. What this means of
management of the cost, schedule and technical performance measures of complex technology programs
using Microsoft tools integrated in a distributed teaming environment.
I’ve been a program manager in aerospace and defense, deputy CIO in a Department of Energy weapons plant
decommissioning project, a program planner, a proposal writer on a variety of programs ranging from aircraft
flight controls to manned spaceflight systems.
My formal training is in particle physics, where I wrote software digital filters to process the data stream from an
accelerator. That turned into digital filters for radar, sonar, and guidance systems. Then into managing those
types of programs. With a stint in the commercial side, I returned to A&D. Eventually I moved into the
consulting business, where we now provide PP&C, IT project management, process improvement, and strategic
planning services to both commercial and A&D clients. Between doing engineering and managing engineers I
was sent back to school to get a Masters in Systems Management – blend of Systems Engineering and Finance.
This may be a new concept, this is the phrase Probability of Project Success (PoPS).
Y may assume that all projects are successful, but we all know that’s not the case.
th t ll j t f l b t ll k th t’ t th
There are many reports about troubled projects. In fact some firms make their living by reporting how bad
projects are. It is assumed then that your project will be troubled as well.
But let’s invert that notion and look at project management from another point of view.
How do we increase the probability of success of our project? We’ve been told our project is not doing well, but
how can we improve?
There are several important words here:
Increase – make better.
Probability – the statistical chance that something will occur.
b bili h i i l h h hi ill
Success – the beneficial outcome of some kind of effort.
So if we want to increase the probability of our project’s success what do we have to do?
But there’s one word that keeps recurring – DONE.
It’s really DONE that we’re after. That’s what the customer bought, that what the customer wants to happen
from your project.
So first let’s review what is a project.
It’ a one off event. It’s not operations. It’s not repeatable processes – although the processes that manage
ff t It’ t ti It’ t t bl lth h th th t
projects is repeatable, the project itself is a one time occurrence.
I’m telling you this just to make sure we don’t get confused between finite, one off work and the continuous
work of operations once the project has produced its product or service.
The reason this is important is that projects are a “one chance to get it right” type of endeavor. Operations has
several chances to get it right. Maybe a lot of chances. Sometimes only a few. But never just one.
That’s why we’re here today. To learn a bit about increasing our probability of success in the “get it right the first
time,” world of projects.
Now there is another word here – probability
Projects have a probability of success. There is no guarantee. We’d like this probability to be as high as possible.
For some projects the probability is high – close to 100%. For some projects the probability, while acceptable is
There is 1 chance in 149 of losing the mission for the Orion Manned Spaceflight program with specific types of
What’s the probability of having your Enterprise ERP project rollout fail in a way that causes an unrecoverable
loose to your company? Good question.
How can you improve the probability of success for your project? Another good question.
We’ll get to the answers to these questions during this presentation. In the end you’ll be able to answer your
own questions in my absence.
We’ve all seen the numbers.
We’ve ll b
W ’ all been told how bad things are.
t ld h b d thi
77% are due to poor planning or poor project management.
Here’s one more look.
But we’re here to work on only one aspects of the “money flushing” business of Enterprise IT or what ever high
risk business you’re in.
We’re here today to talk about the project management aspects of projects.
The planning, scheduling, costing, management verbs of projects.
These are called the Programmatic Elements of the project. Versus the technological aspects.
As a program manager I’m very interesting in the technology. But my job is to make sure the programmatic
aspects work, so the technology has a chance of actually showing up on time.
Here’s our first actual learning opportunity.
These are th fi elements needed t i
Th the five l t d d to increase th probability of success for your project.
the b bilit f f j t
When you read these you’ll all agree they are obvious. We know the definition of all these words.
All the words have been said before.
We’ve pretty much “been there done that.”
Well maybe. Maybe there some subtleties here.
But for the moment, let’s pretend that we know these words, but our problem is how to put them to work.
How to make these words and the phrases they construct – ACTIONABLE.
Actionable is a good word in project management. Because if it’s not actionable it’s not that useful.
g p j g
So let’s get started on the first step toward ACTIONABLE OUTCOMES that increase the probability of project
The first step in increasing the probability of success is to start with discovering what capabilities we need from
the project Capabilities may be new to some of you in the project management business. A Capability is an
ability to do something of value for the enterprise. It’s not a requirement exactly – but requirements come from
Think of a capability in this way. If what I want was free, showed up Monday and worked in exactly the way the
brochure said it did – what would I do with it.
Here’s some words closer to home.
We need to pre-process insurance claims at $0.07 per transaction rather than the current $0.11 per
We need to remove 1½ hours out of the retail ordering process once the merger is complete.
We need to change the wide field camera and the internal nickel hydride batteries, while doing no harm to
We need to fly 4 astronauts to the international space station, dock, stay 6 months, and return safely.
We need to control the Hell Fire Missile with a new touch panel while maintaining existing navigation and
guidance capabilities in the existing touch panels.
We need to integrate two customer facing inventory control systems within 2 months of our merger.
From capabilities we can derive requirements. Requirements are the glue that holds the project together. You’d
think is was the schedule the plan, the budget. But not true.
schedule, plan budget true
Poorly managing requirements is the major contributor to project failure. Increasing the probability of success
for your project means getting your arms around requirements and the management of those requirements.
But before we get too far into this, let’s ask what is a requirement? Here’s a formal definition. Formal definitions
are good, since they don't provide much wiggle room for people to wiggle out of actually stating what the
A Requirement is …”A statement identifying a capability, a physical characteristic, or a quality factor that bounds
a product or process need for which a solution will be pursued.”
— IEEE Standard 1220–1994
Now this may not be that useful for your project, but it’s a start. Let’s seen where this definition can take us.
Notice this definition uses the word “capability.” this definition was created before the Capabilities Based
Planning paradigm was developed.
So let’s stop here and ask “how many people believe they have good requirements for the current project they
are working on?”
With our requirements defined, we can start to develop a Plan. But this Plan is not a schedule – yet. the Plan is
the strategy for our success. It is the strategy for getting to “Done ”
The Plan is a strategy to successfully complete the project, described as the significant accomplishments and
their accomplishment criteria.
The Schedule is the sequence and duration of work needed to implement the plan.
The Schedule (the activities that complete the Accomplishment Criteria) is derived from the Plan (the flow the
With this definition, how many people here today would say they have a Plan in addition to their Schedule?
Now let’s put all this together.
Starting ith th WBS th t
St ti with the WBS, the terminal nodes are represented in project with Work Packages.
i l d t di j t ith W k P k
You cannot have a project without some form of a Work Breakdown Structure (WBS). Building a good WBS is a
day long workshop all in itself.
So how many here have a Work Breakdown Structure for their project?
This may not be a term you’ve heard of before. A Work Package is a lump of work that produces a single
outcome. A “package of work” that produces something.
For the schedule putting the Work Packages in the proper order is the starting point for a credible schedule. If
you can get the Work Packages in the right order, with their durations defined, then you have the start of the
The next step is to not do nay more scheduling in MSFT project. Instead let the Work Package manager look
have the activities inside the Work Package and be done with it.
This is how large Defense and Space programs schedule. There are three levels of schedules mandated by a
government “rule,” DID 81650.
For the commercial side there is no mandated regulation. But 881A and the PMI Work Breakdown Structure
Guide are the best places to start.
The Master schedule – a top level “picture” what is happening in what order.
The Intermediate Schedule – the sequence of Work Packages.
The Detailed Schedule – the day to day activities of the project.
For IT projects, the Intermediate schedule is a sweet spot. One that connects cost with work and deliverables.
One that minimally imposes effort on the team and fits well with the agile world of Corporate IT software
Since agile is focused on defining deliverables and measuring progress through working software, it is a natural
fit for a WBS.
There are several risk management paradigms. This one belongs to the Software Engineering Institute. The
Continuous Risk Management (CRM) process.
Another paradigm is the Department of Defense Risk Management Guidebook.
These two approaches provide essentially the same framework. One place is the Project Management Institute's
Guide to the Project Management Body of Knowledge®.
I’d recommend the SEI CRM for its completeness.
But along the way remember there are five easy pieces of risk management.
1. Hope is not a strategy. Only actionable outcomes can be the measure of risk handling
2. All measures are random variables. You must know the underlying statistics and variances of those statistics
to have any meaningful discussion of risk
3. Never forget cost, schedule, and technical performance are inseparable. Change one, the others change
too, in some way.
4. You have to follow a known risk management process. SEI is good, so is the DoD process. PMI is OK. PMI’s
better than nothing
5. If no one knows your looking after the risks, than you’re wasting your time. Communicate risks!!
Let’s revisit where we’ve come from.
We have fi process areas th t we need t i
W h five that d to increase our probability of success.
b bilit f
1. Identify the needed business capabilities.
2. Identify the technical and operational requirements that cause those capabilities to appear.
3. Build a Plan and a Schedule to implement those requirements.
4. Execute that Plan and Schedule.
5. Continuously manage the risk of the project.
With these concepts in mind let’s look at how we can actually do this.
Having knowledge of something is critical to actually putting that knowledge to work.
But trying to d
B t t i t do work without having the underlying knowledge creates “rework.”
k ith t h i th d l i k l d t “ k”
Let’s put what we’ve learned so far to work at the next level through some examples from “real” projects.
Here’s a picture of actual output a capabilities development session for a major ERP system integration
Starting in the upper left, the needed capabilities are captured through a Product Development Kaizen with the
stakeholders in an offsite session. These Kaizens are full contact meetings where the participants work “on the
wall” to reveal the capabilities and the attributes of these capabilities.
These sticky notes are then captured in some organizing tool. My favorite for this level of detail is MindJet’s
Mind Manager. It is a hierarchical organizing tool that can export its structure to MSFT Project.
No matter what tool you use, you’ve got to have some way to “discover” the business capabilities before
moving the next stage of the project.
Without a clear and concise description of the needed capabilities you’ll have a hard time recognizing “Done”
when it arrives – if it ever arrives.
We’ve all heard of, or possibly used a system that met all the requirements but failed to provide the business
value that was promised.
The development of the Capabilities – preferably in a Concept of Operations document is the foundation for the
remaining efforts in increasing the probability of success for your project.
With the Capabilities in hand, the technical and operational requirements become clear – or at least clearer.
The first step is to separate “product” requirements from “process” requirements. The product could be a service
as well, but the product (or service) is not the same as the process that delivers the service that may be enabled
by the product.
We can see there are several components of this separation. Later on in this session we’ll put this taxonomy to
use with a process for requirements management.
While this type of taxonomy looks unnecessary, later on we’ll see it can serve to reduce complexity, focus our
efforts on important the parts of requirements management, and reduce the overall effort of managing these
We‘ need to separate the requirements into process requirements and the product requirements. As well we
need to have BOTH classes of requirements.
Process Requirements without Product Requirements have not way to implement the processes.
Product Requirements without Process Requirements have to business value generation opportunities.
Many IT project start with the Product Requirements and then try to figure out how to put this product to work.
“Let’s install a portfolio management system.” “Let’s buy Project Server to manage our collection of projects.”
Statement like these are Product Requirement centric. While not a totally bad idea, most project failures can be
connected to missing process requirements. Even if the product requirements have been fulfilled.
The inverse is not as much of a problem. With a well defined set of processes, the products needed enable
those processes can be acquired over time.
When we talk about “the customer” along with all the other sources of requirements, it’s important to know
what exactly the role of the customer is.
This role is limited. Not limited because we don’t want to know what the customer wants. It’s limited because
the customer can provide only a limited amount of requirements information.
Here’s some of the things a customer can provide
Here’s a real example of a master plan and the master schedule that goes with it.
The Pl is
Th Plan i a strategy t successfully complete th project, d
t t to f ll l t the j t described as th significant accomplishments and
ib d the i ifi t li h t d
their accomplishment criteria.
The Schedule is the sequence and duration of work needed to implement the plan.
The Schedule (the activities that complete the Accomplishment Criteria) is derived from the Plan (the flow the
This is a “real” Integrated Master Schedule, complete with the Integrated Master Plan.
Each Accomplishment Criteria represents the “exit criteria” for a Work Package.
The completion of the Work Packages provide the needed completion of the Significant Accomplishments.
These S Significant Accomplishments are the entry criteria for the Program Events, where the planned maturity
of the programs deliverables are assessed.
An example of a Significant Accomplishment would be “Initial Database Design and Sizing Complete”
An example of an Accomplishment Criteria would be “Initial legacy user list captured”
The Accomplishment Criteria is the EXIT criteria for a Package of Work needed to capture all the legacy user
The Significant Accomplishment represents a 100% DONE outcome that can be put to work in some way.
Either in actual use or as the basis for a higher level deliverable.
Program Management and the Program Management Office must “earn their keep.”
This takes l
Thi t k place th through 4 value propositions
h l iti
1. Management of Cost, Schedule, and Technical Performance at the individual project level is the
responsibility of the Project Manager. When individual projects are collected into a Program, these
measures of performance become the responsibility of the Program Manager and the Program
2. The tools needed to assure project and program performance come from the Program Management
Office. The processes needed to successfully deploy these tools and their benefits are the responsibility of
the Program Management Office.
3. The Program Management Office and Program Managers can normalize the information flow between the
business stakeholders and the individual projects. The traditional asymmetric exchange of information is
replaced with standardized performance measures making visible cost, schedule, and the technical
performance of projects and their programs.
4. Monitoring and oversight of cost, schedule, and technical performance and the resources needed to
produce the needed compliance for the project’s and program’s success
When we speak about increasing maturity, evolutionary development and measures of physical percent
complete – one good way to visualize this is through a product maturity flow diagram
This diagram is a “real” one from a claims processing ERP system rollout, complete with COTS (Commercial Off
The Shelf) integration with legacy systems and custom software development. The worse of both worlds.
The critical success factor here is the define upfront what “done” looks like for all the incremental business value
elements of the program.
Each of the circles is a point of maturity, where the delivered product or service can be put to use in some way.
As well the project can be canceled at each of these and the investment put to work. Many people would be
unhappy, but the financial aspects of the program would remain intact.
This type of diagram also shows the dependencies between the down stream (right) and up stream (left)
elements of the project. What has to come first, before business value can be delivered.
In other domains (defense and government) these diagrams are built during the Product Development Kaizen
process to show what must be done to get to “done.”
Here is a simplified Risk Management process.
Th management of risk i h
t f i k is how adults manage projects.
d lt j t
Risk management is a continuous process taking place during every phase of a project.
So let’s connect our 5 process areas with the three attributes of any project.
H ’ a notional picture of th
ti l i t f these connections.
The term notional means a picture that “could” the real way to do something, but it is not actually the way it is
done in practice.
In other words it’s a nice power point slide of what might take place. But there’s more to it than what’s shown in
the power point slide.
Since we talked only about the “processes” in this session, this leaves the people and tools unaddressed.
With the processes you can buy tools.
With the processes you can find good people to implement them.
It’s the project management process that i the anchor to increasing the probability of success f the project.
h j h is h h i i h b bili f for h j
So here’s our final visit to the questions we need to answer to increase our probability of success.
Wh t capabilities do we need? This is the “why” question. Wh are we d i thi project. we’re d i it
biliti d d? Thi i th “ h ” ti Why doing this j t ’ doing
because our business needs a new capability. We’re doing it because our nation wants to explore Mars.
Without the answer to Why, we can easily get lost when something goes wrong on the project.
With our capabilities defined, what are the technical and operational requirements that must be met.
Answering this is straight forward of we follow the advice of the Requirements Engineering thought leaders.
With this information we can build a credible schedule, measure our progress to plan, and remove any
impediments to this progress
All these processes and their interactions we need to put all this into perspective.
While t l
Whil tools and processes are critically important, having the right people in the right “ t on th b ” as Ji
d iti ll i t t h i th i ht l i th i ht “seats the bus” Jim
Collins would say in “Good to Great,” is as critical. These people must have a deep understanding of how to put
the tools to work on their behave or the tools are of little value to the organization.
We’ve seen this many times, where a program management or technical groups purchased a tool as the
solution to their problems. Only to discover they did not understand the problem, so the tool had no chance of
OK, this was nice, but what are some next steps.
1. Ask and answer the five questions we’ve been speaking about for the last 60 minutes
2. If there are no answers, find out how to get the answers. Without the answers, you can not really start to
improve the probability of success.