Increasing the Probability of Project Success with Five Principles and Practices

There are many approaches to managing projects in every domain.
This seminar lays the foundations for increasing the probability of project success, no matter the
domain, what technology, what approach to delivering the outcomes of the project.
The principles of this approach are immutable.
The practices for implementing the principles are universally applicable.
Each chart in this presentation, contains guidance that can be applied to your project, no matter the
domain.
In our short hour here, we’re going to cover a lot of material.
The bibliography contains the supporting materials we can tailor to your individual project
Increasing Probability of Project Success
PGCS 2020 0:20
1/70

We only have 50 minutes to go through this webinar so it will be fast and furious as the movie says.
But what I want to leave you with are the principles which you can then turn into the practices and
processes suitable for your projects
2
11/11/20
Glen B. Alleman
PGCS 2020

Let’s look at a universal source of problems on all projects no matter the domain that technology or
the business content.
The root cause of project overspending and overrunning the schedule is because the projects are
complex when we think that they’re just complicated.
Managing in the presence of this complexity requires special processes and practices based on the
five immutable principles needed to increase the Probability of Project Success.
3
11/11/20
Glen B. Alleman
PGCS 2020

In our project management domain, like many others, there is always advice from the Greeks that is
applicable to our problems of today.
PGCS 2020
Increasing Probability of Project Success 4/70

To increase the Probability of Project Success start with risk management.
Risk management is based on Root Cause Analysis.
Find the root cause of uncertainties that create risk first, then probability of project success can
increase.
From research, here are four key factors that reduce the probability of project success.
PGCS 2020
5/70

The five immutable principles of project success are:
1. Know where we are going by defining “done” at some point in the future.
2. Have some kind of plan to get to where we are going.. The fidelity of the plan depends on the
tolerance for risk by the users of the plan.
3. Understand what resources are needed to execute the plan. How much time and money is
needed to reach the destination.
4. Identify the impediments to progress along the way to Done. Have some means of correcting,
preventing, removing, avoiding, or ignoring these impediments.
5. Have some way to measure planned progress, not just current progress, measured in units of
physical percent complete meaningful to the decision makers.
6/70
PGCS 2020

The path to showing up on time, on budget, with the needed capabilities, with the planned a set of
tangible goals, starts by defining the unit of measure to assess if the actual work is following the
planned path.
To do this we need units of measure that are meaningful that represent the actual performance of
the work, with precision and accuracy within the limits of the assessment process.
The primary measures needed for this process are: Effectiveness and Performance.
PGCS 2020
7/70

Here are 5 Practices used to implement the 5 Principles
1. Identify Needed Capabilities that achieve the project objectives or the particular end state.
Define these capabilities through scenarios from the customer point of view in units of Measures
of Effectiveness (MoE) meaningful to the customer.
2. Define The Technical And Operational Requirements to be fulfilled for the system capabilities to
be available to the customer. Define these requirements in terms isolated from any
implementation of the products. Only then bind the requirements with technology.
3. Build The Performance Measurement Baseline – describing the work to be performed, the
budgeted cost for this work, the organizational elements that produce the outcomes from this
work, and Measures of Performance (MoP) showing the work is proceeding according to cost,
schedule, and technical plan.
4. Execute the PMB’s Work Packages ‒ in the planned order, assuring Performance assessments
are 0%/100% complete before proceeding. No rework, no transfer of activities to the future.
Assure every requirement is traceable to work and all work is traceable to requirements.
5. Apply Continuous Risk Management for each Performance Based Management process to
Identify, Analyze, Plan, Track, Control, and Communicate projectmatic and technical risk.
PGCS 2020
8/70

Here are the principles and practices, connected to increase the probability of project success.
Practices without principles provide the opportunity to modify the approach without understanding
why.
Principles without practices are interesting discussions without measurable business benefits.
We must start with the principles, then move to the practices.
Without principles, there is no way to test practices to confirm they are on solid footing when they
need to be adapted to the situation.
With these connections, we’ll have the basis of a handbook to increase the probability of success, in
any domain, for any technology.
PGCS 2020
9/70

Here’s a map of the 23 steps we’ll use to connect Principles and Practices in the coming charts.
Each connection is presented in the section with the numbers 1 through 23.
PGCS 2020
10/70

Connecting principles with practices is a critical success factor for any approach to increasing the
probability of project success.
Practices without principles provide the opportunity to modify the approach without understanding
why.
Principles without practices are interesting discussions without measurable business benefits.
Both are needed, both must be present for success.
But we must start with the principles, then move to the practices.
Without principles, there is no way to test practices to confirm they are on solid footing when they
need to be adapted to the situation.
PGCS 2020
11/70

The Practice of Identifying the needed Capabilities is guided by 5 principles.
Where are we going ‒ is answered by Concept of Operations that states, for the users point of view,
what the system is doing when it is working.
How are we going to get there and what do we need along the way ‒ is answered by an Integrated
Master Plan defining the assessment of the increasing maturity of the Capabilities.
What Impediments Will We Encounter Along The Way ‒ is answered by the Risk Register developed
from each Capability defining the handling strategies to correct or prevent the risk from occurring.
How Do We Measure Progress ‒ is answered by assessing physical percent complete assessment of
the Measures of Effectiveness of the Capabilities to fulfill the mission or business strategy.
PGCS 2020
12/70

Capabilities drive requirements, but rarely do requirements by themselves have value
The stakeholders want a capability to accomplish a mission or fulfill a strategy.
Capabilities are what we would do with the resulting system.
The stakeholder puts the Capabilities to accomplish some goal.
If we don’t know want capabilities we need to produce from the project, we really can’t talk about
the project value, and we really can’t speak about what DONE looks like in a meaningful way other
than the passage of time and consumption of money.
PGCS 2020
13/70

The purpose of the CONOPS is to describe the operational needs, desires, visions, and expectations
of the user without being overly technical or formal.
A Concept of Operations (CONOPS) is a user-oriented document that "describes systems
characteristics for a proposed system from a user's perspective.
A CONOPS also describes the user organization, mission, and objectives from an integrated systems
point of view and is used to communicate overall quantitative and qualitative system characteristics
to stakeholders
A CONOPS "describes the proposed system in terms of the user needs it will fulfill, its relationship to
existing systems or procedures, and the ways it will be used.
CONOPS can be tailored for many purposes, for example, to obtain consensus among the acquirer,
developers, supporters, and user organization on the operational concept of a proposed system.
A CONOPS may focus on communicating the user's needs to the developer or the developer's ideas
to the user and other interested parties.
PGCS 2020
14/70

The Integrated Master Plan (IMP) is a representation of the increasing maturity of the projects
deliverables through a series of Events that assess that maturity.
The IMP is an event-driven plan that documents the significant accomplishments necessary to
complete the work and ties each accomplishment to a key project event.
It defines how the project is organized, structured, and conducted and how the total process will be
controlled to provide a product that satisfies stakeholder requirements.
PGCS 2020
15/70

The structure of the Integrated Master Plan (IMP) and Integrated Master Schedule (IMS)
provides a framework for assessing the increasing maturity of the project’s outcomes in units
of measure meaningful to the decision makers.
Together, the IMP and IMS demonstrate the project is adequately structured, realistic, and
executable and the planned tasks are achievable within schedule and cost constraints at an
acceptable level of risk.
The IMP and IMS are business tools to manage and provide oversight of projects.
In this picture Work Packages contain Tasks that consume resources (labor and materials)
and are the basis of the Integrated Master Schedule.
Each Work Package produces a tangible outcome defined through an Exit Criteria stated in
a measurable unit meaningful to the decision makers.
These Criteria are entry conditions to the Accomplishments needed t to move forward as
planned.
The Accomplishments define the Entry Criteria for the Events that assess the increasing
maturity of the project as a whole.
PGCS 2020
16/70

All projects are complex.
The two separate complexities on projects are the tasks themselves and the relationships between
those tasks.
Each of these complexities creates risk and risk must be dealt with in the project plan.
The handling of these complexities have to be part of the project plan itself and without this
handling strategy the probability of success of the project is greatly reduced.
A quote that should be remember here is
Risk Management is How Adults Manage Projects ‒ Tim Lister
PGCS 2020
17/70

Measures of Effectiveness are the primary assessments of a project’s progress to plan and the
ultimate success of the deliverables from that work effort.
The definition of Measures of Effectiveness belongs to the stakeholders or those paying for the work.
This is the effectiveness of the project’s outcomes to accomplish the mission or fulfill a business
goal.
Defining and managing the measures of effectiveness is the critical success factor for all projects.
Research shows missing or poorly defined measures of effectiveness are the root cause of project
failure.
PGCS 2020
18/70

With the capabilities identified, we now need the technical and operational requirements that will
implement these capabilities.
With the requirements we can start to plan the project implementation activities to deliver those
requirements for the needed cost at needed time.
A failure mode for many projects is to start with requirements skipping the capabilities phase.
PGCS 2020
19/70

The connection between Principles and Practices for the Requirements Baseline include:
Where are we going ‒ for each Capability, a technical or operational plan defines the facilities to
implement the Capability.
How are we going to get there What do we need along the way ‒ the Work Breakdown Structure
defines the deliverables and the processes needed to produce these deliverables. These individual
elements are rolled up to higher level deliverables, until we reach to top level of the project
deliverable.
What do we need along the way ‒ the resources, staff, equipment, facilities, and processes are
defined in a Resource Management Plan connected to the WBS. These resources are budgeted in
Work Packages and their Tasks, and summed in Control Accounts
What Impediments Will We Encounter Along The Way ‒ the Risk Register developed from each
Deliverable in the WBS defines the handling strategies to correct or prevent the risk from occurring.
How Do We Measure Progress ‒ physical percent complete assessment of the Technical
Performance Measures of the Capabilities to fulfill the mission or business strategy.
PGCS 2020
20/70

The first step in identifying requirements that fulfill the needed capabilities 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.
While this type of taxonomy looks unnecessary, later on we’ll see it can serve to reduce complexity,
focus our efforts on important parts of requirements management, and reduce the overall effort of
managing these requirements.
PGCS 2020
21/70

Value stream mapping is an approach to defining the needed capabilities for the business.
The value stream defines a sequence of deliverables that have measurable value to the business or
to the fulfillment of a mission.
Each of the deliverables has a measured value that can be assessed against the needed capabilities
of the project’s outcomes.
These outcomes include technical performance, efficacy of risk reduction, on schedule, on cost.
The key here is to have all measures be meaningful to the decision makers.
PGCS 2020
22/70

The work breakdown structure defines the decomposition of the deliverables from the project.
The WBS is not a breakdown of the work it is a breakdown of the outcomes of the work. The WBS is
the bill of materials for the project.
The WBS collects cost and the parent child relationship between the deliverable items.
A consistent WBS structure across the business or government agency allows comparison of past
cost to future estimated costs by WBS Number.
The WBS is one of the pieces of glue connecting all the work across the project.
PGCS 2020
23/70

Resources are needed to deliver outcomes for all projects.
These resources are typically the staffing that does the work, but it also includes, material,
equipment, and external services.
Having a plan by resource category is needed to define the cost basis for the project.
This resource plan is used as the basis for the integrated master schedule to sequence these
resources to make sure they are available when needed.
PGCS 2020
24/70

It cannot be stated enough, risk management is the basis of project success.
Each element in the WBS needs some type of risk assessment.
This information is held in the risk register for analysis and handling plans.
The connection between the Risk Register and the WBS is a critical success factor for the project.
PGCS 2020
25/70

Here’s an example of a risk register with its analysis connected to the WBS and the Integrated
Master Schedule.
Each element in the risk register has a probability of occurrence or some statistical assessment of its
variability and the impact on the outcome of the risk were to come true.
A critical success factor is to have the pre-mitigation and the post mitigation risk analysis in one
place to confirm to the project management staff that risks are actually being bought down.
This approach provides information about risks that cannot be reduced to zero so the project can
provide margin, management reserve, or cost contingency to cover that situation.
PGCS 2020
26/70

Measures of Performance describe the physical and functional attributes of the deliverable.
How fast, how slow, how big, how small, how reliable, how maintainable are all of the physical
measurements of the outcomes are part of measures of performance.
With this assessment it can be determined how much margin or contingency is needed if the item
does not meet the performance requirements.
The Measures of Performance are directly connected to the Capabilities produced by the project.
PGCS 2020
27/70

The Performance Measurement Baseline (PMB) is an important tool in the assessment of project
performance used by project Managers and Systems Engineers in the Technical Assessment Process
to appraise a project technical progress to plan.
It includes the undistributed budget, all summary level planning package budgets, and all control
account budgets but does not include management reserve.
It establishes the contract level timed phased baseline against which contract level performance
metrics are computed.
It establishes the scope, schedule, and budget targets for the project.
The PMB is usually a contractual document whose changes must go through the change control
process.
This is done during the planning process, and records what the project had planned, scheduled,
budgeted for, in terms of the schedule, scope and cost.
It should contain everything that the customer needs, as per the agreed scope.
The Cost, Schedule, and Scope baselines put together are called the Performance Measurement
Baseline.
PGCS 2020
28/70

The connection between Principles and Practices for the Performance Measurement Baseline
include. The practices of establishing the PMB are guided by the principles of:
Where are we going ‒ the MOE’s and MOP’s define the incremental maturity of the deliverables
assessed against the planned maturity.
How are we going to get there and what do we need along the way ‒ a resource loaded Integrated
Master Schedule described the tasks and Work Packages needed to produce the deliverables from
the project.
deliverable in the in the WBS defines the handling strategies to correct or prevent the risk from
occurring.
Performance Measures inform the progress to plan.
PGCS 2020
29/70

Eisenhower said “In preparing for battle I have always found that plans are useless, but planning is
indispensable.”
The Performance Measurement Baseline contains cost, schedule, and technical performance goals.
These are the basis of not only measuring progress to plan, but defining what Done looks like and
how we’re going to get to Done as needed.
PGCS 2020

Establishing the Performance Measurement Baseline is the process of integrating the scope,
schedule, and cost baselines into a single project baseline from which to manage and
control project performance throughout execution.
The Performance Measurement Baseline of the project is actually three baselines:
1. The technical baseline assures that all the deliverables are identified. Even if the details
are not known, the needed capabilities must be defined in some meaningful manner.
Otherwise the project will have no way to control the scope.
2. The schedule baseline says when the needed capabilities will be available, and
3. The cost baseline says how much each of these capabilities is planned to cost.
In addition to the scope, cost, and schedule elements, the performance measurement
baseline (PMB) also incorporates undistributed budget (UB) (along with its corresponding
work) and contingency reserves (alongside with the corresponding risks).
PGCS 2020
31/70

As the project progresses we need to incrementally assess the maturity of the project deliverables.
This incremental method is a critical success factor to avoid the big bang outcome of the project.
The big bang happens when we wait till the end to find out that what we’re delivering is not what
the stakeholders expect us to do.
Increment and iterative processes are critical success factors for all projects no matter the domain
technology or methods used to develop outcomes.
This incremental and iterative approach to project management is not just for agile software
projects it is applicable to all projects.
The Big Bang produces a smoking hole where the project was, with all the money gone.
PGCS 2020
32/70

An Integrated Master Schedule (IMS) is a network of tasks linked from project start through project
finish, reflecting the interdependencies between tasks and milestones.
It begins with the Integrated Master Plan (IMP), which details the contractual deliverables developed
from the Statement of Work/Objectives (SOW/SOO).
The Integrated Master Schedule (IMS) is a time-based schedule containing the networked, detailed
tasks necessary to ensure successful project execution.
The IMS is used to verify attainability of the project objectives, to evaluate progress toward meeting
project objectives, and to integrate the project schedule activities with all related components.
The IMS utilizes Critical Path network management techniques to optimize the relationship of critical
activities.
The IMS is a hierarchical, tiered structure capable of rolling up to a high-level summary
representations of activities as well as breaking down to the lowest level of task details showing
dependencies, resources, durations, and constraints.
PGCS 2020
33/70

Risk is always present on projects no matter the domain, technology, or business environment.
To have a credible project with a credible project plan that will increase the probability of project success we
must manage in the presence of uncertainty that creates risk.
Developing a risk adjusted cost and schedule starts with making a single point estimate of cost or duration of
the work.
This estimate is the most likely value that will occur in the presence of uncertainty.
With the most likely value we can then estimate the higher or lower value.
With this information we can then develop a model of the expected cost and expected duration of the work
defined in the schedule.
Monte Carlo simulation is a method to develop this confidence estimate. This approach has four steps:
§ Identify risks and uncertainties related to task durations, their start and finish time, cost and resources.
§ Perform monte carlo simulation.
§ Analyze risk-adjusted project schedule.
§ Perform probabilistic cost and work analysis of project schedules.
The discussion of Monte Carlo simulation is beyond the scope of this presentation, but detailed resources will
be provided in the bibliography.
PGCS 2020
34/70

Here is an example of a project schedule and the most likely values of the optimistic values and the
pessimistic values of the duration of tasks.
With this information a Monte Carlo simulation of the most likely value for the completion date can
be developed.
In the example here, the final testing plan completion date is planned for February, 10, 2003.
In the next chart will see the Monte Carlo simulation showing the confidence of completing on or
before that date.
PGCS 2020
35/70

With the Monte Carlo tool we can see the confidence of completing on or before a specific date.
Using the integrated master schedule from the previous chart and the high and low ranges of
duration for each task, the Monte Carlo tool shows the confidence of completing on or before the
needed date of Feb 10, 2003.
In this case the probability is low 40%.
A higher probability is shown in the chart in the lower right-hand corner.
We have an 80% confidence of completing on or before February 18, 2003.
This approach to schedule risk analysis is mandated in many domains including the United States
government domains.
PGCS 2020
36/70

Another critical success factor for increasing the probability of project success is the integration of
risk buy down into the integrated master schedule.
This describes how we need to plan to reduce risk as the project proceeds.
We can then assess the actual risk reduction against the planned risk reduction to determine if we’re
meeting the risk management plans and goals.
This risk buydown planning is considered a Technical Performance Measure.
This chart is produced by the same tool that uses the Monte Carlo simulation to assess the
performance of the schedule.
PGCS 2020
37/70

Since all projects have uncertainty, both reducible and irreducible, we must have a risk adjusted in a
graded master schedule.
This integrated master schedule in the presence of uncertainty requires a plan A and a Plan B should
the risks from the uncertainty turn into issues.
No schedule without margin can be correct.
Schedules without margin are late on day one.
PGCS 2020
38/70

Schedule margin is a project management tool for dealing with schedule contingencies.
Schedule margin provides a separately designated "buffer" in the schedule to "protect" the delivery
dates.
There are two approaches to schedule margin.
§ In the first the final task is baselined to finish ten days before an End Of Contract (EOC) milestone
aligned with the contract need date. The calculated difference between the final task completion
and the contract need date is the schedule margin to the contract need date.
§ In the second the EOC milestone is baselined to finish immediately after the final task – which is
still baselined to finish before the contract need date. The calculated difference is defined as the
schedule margin to the contract need date.
The example shows that margin can be placed before the deliverable date or after the deliverable
date.
PGCS 2020
39/70

It is impossible to estimate precisely how much something will cost or how long it will take.
If we want projects to meet cost and schedule commitments, we must budget and fund them with a
higher probability of success.
A Joint Cost and Schedule Confidence Level (JCL) is a quantitative probability statement about the
ability of a project to meet its cost and schedule targets.
Decision-makers and cost analysts should always think of a cost estimate as a probability
distribution, NOT as a deterministic number.
The best that can be provided to decision-makers is the cost probability distribution.
It is up to the decision-maker to decide at which confidence level they want to set the budget.
The probability distribution provides a quantitative basis for making this determination.
PGCS 2020
40/70

JCL is a process that combines a project’s cost, schedule, and risk into a complete picture.
If cost, schedule, or both are below a defined confidence level, the management team must make
decisions about risk mitigation measures and/or changing the project scope.
There are six steps to developing a Joint Confidence Level:
1. Identify goals for the JCL.
2. Build a JCL schedule/logic network (a summary analysis schedule).
3. Load cost onto the schedule activities.
4. Incorporate risk list.
5. Conduct uncertainty analysis.
6. Calculate and view results, and iterate as required.
PGCS 2020
41/70

Here’s a picture of a Joint Confidence Level, where the x-axis represents the final completion date, and the y-
axis represents the final cost through that completion date.
The scatterplot shows the simulated outcomes of the cost and schedule risk analysis.
Each dot in the scatterplot represents a specific result, or scenario, from the simulation calculation of the cost
and schedule.
In this example, the blue lines (the crosshair) intercept at the project’s baseline plan or point estimate (PE).
To the bottom left, the green dots represent all the scenarios that are at or below the baseline cost and
schedule.
The yellow line represents the “frontier curve,” or indifference curve, that specifies all the cost and schedule
combinations that will meet a targeted JCL.
Anything the the left and below the Yellow line is an acceptable cost and schedule for the project.
Anything to the right and above the Yellow line is an unacceptable cost and schedule.
The goal of project management is to keep the cost and schedule below and to the left of the Yellow line,
while maintaining the delivery of the needed capabilities.
This is called Keeping the project Green.
PGCS 2020
42/70

Technical Performance Measures are an assessment of the measures of performance and the
measures of effectiveness for the deliverables of the projects to meet the technical requirements.
The passage of time and consumption of money are measures of project progress.
But if these measures are not matched against the increasing maturity of the technical performance
measures the project will not deliver the needed value to those paying for those outcomes.
We must always remember the cost, schedule, and technical performance are tightly integrated.
Management of all three of these variables is the role of the project manager.
To increase the probability of project success all three variables must be tightly controlled.
PGCS 2020
43/70

The technical performance measure has a planned increase in its maturity as the project proceeds.
In this example the TPM is the Mean Time Between Failure of some article produced by the project.
As the project proceeds the MTBF needs to increase.
The current assessment of the meantime between failures is shown in the line achieved to date.
The planned value for the MTBF at this date is different than the actual value.
This variance is inside the lower limit and upper limit of the plan value.
As the project proceeds the MTBF must reach the threshold value for the project to meet the
technical performance measures.
If the actual values were to go outside the upper and lower control limits at any specific time a
collective or preventive action will be needed to put this variance back inside those upper and lower
limits.
PGCS 2020
44/70

With the performance measurement baseline established, we now need to execute that baseline to
deliver outcomes from the project.
45/70
PGCS 2020

The connection between Principles and Practices for Executing the PMB include:
Where are we going ‒ measures of Physical Percent Complete are the only measure of progress to
place. Not the passage of time or consumption of money.
How are we going to get there ‒ using incremental delivery, the progress can be measured on fine
grained boundaries.
What do we need along the way ‒ with the measures of progress to plan and risk adjusted
Integrated Master Schedule, future performance can be modeled.
Deliverable in the WBS defines the handling strategies to correct or prevent the risk from occurring
and contained in a risk adjusted PMB.
Performance Measures of the Capabilities to fulfill the mission or business strategy is used by the
Earned Value Management System to produce and Estimate to Complete and and Estimate at
Completion.
PGCS 2020

Physical percent complete is often confused with percent complete in a scheduling tools.
Physical percent complete requires tangible evidence of progress to plan for the technical
performance, cost, and schedule targets.
Here are several ways to calculate physical percent complete.
Never is physical percent complete calculated by the passage of time and consumption of money.
Only the contractual legal term, tangible evidentiary materials, is used to calculate physical percent
complete.
The description of this tangible evidence needs to be defined before the work starts.
This physical evidence needs to be useful to those paying for the work.
For example the number of drawings produced may be interesting to assess the performance of the
engineers, but it does not measure physical percent complete of the design.
Care is needed in defining the units of physical percent complete.
Again the passage of time and consumption of money is not physical percent complete.
PGCS 2020
47/70

Iterative and Incremental Delivery (IID) are terms often used in software development, but they are
applicable in any project domain.
The basic idea behind this method is to develop a system through repeated cycles (iterations) and in smaller
portions at a time (increments).
IID grew from the 1930s work of Walter Shewhart, a quality expert at Bell Labs who proposed a series of short
“plan-do-study-act” (PDSA) cycles for quality improvement.
The X-15 hypersonic jet in the 1950’s applied IID and the practice as a major contribution to the X-15’s
success.
There are many examples of iterative and incremental development and delivery at NASA in 1960’s starting
with Project Mercury, which ran ½ days iterations that were time boxed.
Some of those Mercury engineers later formed a new division within IBM, where "another early and striking
example of a major IID success [was] the very heart of NASA’s space shuttle software—the primary avionics
software system, which [they] built from 1977 to 1980.
The team applied IID in a series of 17 iterations over 31 months, averaging around eight weeks per iteration.
Their motivation for avoiding the waterfall life cycle was that the shuttle project’s requirements were
changing during the software development process.
PGCS 2020
48/70

The success of any project is likely to be judged by how well it achieves a defined outcome while
meeting performance expectations.
Most projects would not be undertaken if management had little confidence in a successful
outcome.
Many projects are subject to being cancelled, even late in the project cycle, if the forecasted
outcome does not meet expectations.
These factors drive the need throughout the project for updated forecasts of the project outcome.
Project forecasting is the process of making conjectures about future performance, which can help
managers decide whether to cancel this project, create new projects, or to continue with existing
projects.
PGCS 2020
49/70

Future Project Performance can be lumped under the project management principle of change management.
If we can’t forecast the outcome of a change, the probability of project success is low.
There are four different, though interrelated, challenges in dealing with change and the ability to forecast the
impact of that change
The first deals with the reality that the project's boundaries change as the project progresses.
Specific selections of equipment, systems, or processes impact the content of the project.
Refining judgments of capabilities leads to increases in scope more frequently than decreases in scope.
Competition for resources, changes in performance intensity, and external factors all put pressure on the
project plan.
A most common change in project forecasting is the increase that occurs when a greater scope of work is
attempted in the same amount of time.
Another factor is the reality that, as the project progresses, it is easy to record the spending of dollars and
difficult to assess what those dollars have bought.
This is why Capabilities Based Planning is a critical success factor for all projects.
Maintaining the connection of requirements to needed capabilities is critical to increasing the probability of
success.
PGCS 2020
50/70

All projects and projects are plagued by cost and schedule overruns and technical shortfalls.
Sources of these issues are summarized in four notions by Mr. Bliss, Director Performance Assessment and
Root cause Analyses (PARCA), US Department of Defense.
1. Unrealistic performance expectations with missing Measures of Effectiveness (MOE) and Measures of
Performance (MOP).
2. Unrealistic cost and schedule estimates based on inadequate risk adjusted growth models.
3. Inadequate assessment of risk and unmitigated exposure to these risks without proper handling
strategies.
4. Unanticipated technical issues without missing alternative plans and solutions to maintain the
effectiveness and performance of project deliverables.
All project work operates in the presence of uncertainty. Cost uncertainty, schedule uncertainty, technical
uncertainty that creates risk.
Knowledge of project risk provides information needed to make decisions in the presence of uncertainty,
where predicting future outcomes is part of the project management process.
Risk is the consequence of Uncertainty.
Managing in the presence of uncertainty is the role of the project manager, and risk management is the basis
of increasing the Probability of Project Success.
PGCS 2020
51/70

Earned Value is a fundamental measurement of a project’s performance but far from sufficient for
the project’s success.
Integration of risk, technical performance measures, and systems engineering processes are needed
to increase the probability of project success.
Success starts with a winning proposal, installing the right tools and work processes, establishing a
credible Performance Measurement Baseline, identifying and handling programmatic and technical
risk, and through project execution a variety of technical, operational, and staffing processes are
needed and based on Earned Value Management processes.
Increasing the probability of project success requires the application of 5 simultaneous project
management processes.
These 5 processes are inter-related, dependent, and supportive of each other.
Earned Value is at the heart of each of these 5 processes with the focus on measures needed to
forecast the future, rather than just reporting past performance.
PGCS 2020
52/70

All projects operate in the presence of uncertainty.
All risk comes from uncertainty.
Uncertainty comes in two forms on projects
Epistemic uncertainty, which comes from lack of knowledge, which is reducible
Aleatory uncertainty, from naturally occurring processes, which is irreducible
Managing in the presence of uncertainty is the critical success factor for increasing the probability of
project success.
Let’s repeat the quote that says it all about risk management and the success of project
management
Risk Management is How Adults Manage Projects ‒ Tim Lister.
The purpose of risk management is to identify potential problems before they occur so that risk-
handling activities may be planned and invoked as needed across the life of the product or project to
mitigate adverse impacts on achieving objectives.
PGCS 2020
53/70

The connection between Principles and Practices for Continuous Risk Management answers the
questions:
Where are we going? ‒ by identify the uncertainties on the project that create risk. These can be
reducible uncertainties or irreducible uncertainties.
How are we going to get there? ‒ by analyzing these uncertainties to find their root causes and the
properties of these causes.
What do we need along the way? ‒ by developing risk handling strategies to correct or prevent the
root cause from creating the uncertainties that create the risk.
What Impediments Will We Encounter Along The Way? ‒ we need to place the risks, with their
handling strategies in a Risk Register and assess the risk buydown effectiveness on fine grained
boundaries.
How Do We Measure Progress to Plan? ‒ we measure the effectiveness of the risk buy down
activities on the probability of success for cost, schedule, and technical performance measures.
PGCS 2020

Continuous Risk Management, when performed successfully, provides 5 key benefits:
§ Identify uncertainties that create risk.
§ Correct or Prevent problems before they occur – by identifying potential risks and deals with
them when it is easier and cheaper to do so – before they are issues.
§ Improve product or service quality – by focusing on the project’s objectives and looking for things
that many effect quality throughout the project lifecycle.
§ Enable better use of resources – by allowing the early identification of potential problems –
proactive management to input into management decisions regarding resource allocation.
§ Promotes teamwork – involving personnel at all levels of the project.
PGCS 2020

Risk identification is a process of transforming uncertainties and issues about the project into distinct
(tangible) risks that can be described and measured.
Identifying risks involves two activities:
§ Capturing a statement of risk.
§ Capturing the context of that risk.
The objective of risk identification is to locate risks before they become problems and to incorporate this
information into the project management process.
The data items found in risk identification include:
§ Individual uncertainties and issues about the project and project’s progress.
§ Groups of activities and issues which may risks.
§ Project data supporting information consisting of items such as the schedule, budget, plans, work
breakdown structure, that may provide information helpful in identifying risks.
§ For each risk identified, a statement of the risk with the associated context.
§ A Risk Register containing all this information about the risks identified for the project, their handling
plans, the probability or occurrence or naturally occurring variance, the probability of effectiveness of the
corrective or preventive actions needed to handle the risk
PGCS 2020
56/70

A well written risk statement can answer the following questions:
§ What is the root cause that creates the risk?
§ Why could it happen? What’s the probability of occurrence for event based risks and what’s the
impact from a naturally occurring risks?
§ If the risk becomes an issue, What is the impact on the project?
The risk statement provides clear and descriptive information required for a reasoned and defensible
assessment of the risk's probability or occurrence or natural variability and areas of impact.
A well-written risk statement contains two components. They are a statement of the Condition
Present and the Associated Risk Event.
In a risk statement, the Condition Present is itself an event: it is an event that has occurred or is
presently occurring.
Associated Risk Events are future events that might occur because of the Condition Present.
The Condition Present acts as the departure point from which one or more Associated Risk Events
may originate.
PGCS 2020
57/70

The main objective of Risk Analysis and assessments of the uncertainties that create risk, is the basis of
informed decision-making needed to increase the probability of project success.
Risk analysis is the process of systematically evaluating each identified, approved risk to estimate the
probability of occurrence (likelihood) and consequence of occurrence (impact), and then converting the
results to a corresponding risk level or rating.
Traditional Risk Analysis starts with evaluating and prioritizing risk, assessing the probability of risk occurrence
and probability of impact of the risk on project success, and placing this information in a Risk Register.
With this information. decisions can be made about to respond to risk should it become an issue.
This approach starts with qualitative analysis but fails to recognize there are still phenomena not taken into
account by classical project risk management.
These include propagation of simple risk, loops in this propagation model, reaction chains and non-linear
couplings of interrelationships between risks creating other risks, propagation of risks between
interrelationships creating further risk, analysis of alternatives and their risk assessment, the premortem
analysis needed to remove the uncertainties, and the dynamic evolving connections between cost, schedule,
and technical performance.
Quantitative risk analysis determines the root cause(s) of the uncertainties, but reducible and irreducible, that
create risk.
Risk Handling strategies are then created to correct or prevent the occurrence of the risk, used to the
Probability of Project Success (PoPS).
PGCS 2020
58/70

Risk Handling Plans are similar to any other type of project planning or problem‒solving activity.
Planning of the Risk Handling Strategy starts with translating risk information into decisions and handling actions and the
plans to implement those actions.
Risk planning is possibly the least practiced risk management process, but the most important.
Little or no formal risk planning typically exists on many projects.
This weakens risk management process effectiveness by causing risk issues to be missed, analyses to be inaccurate or
inconsistent, poor risk handling approaches, and subjective risk monitoring.
Formal risk planning should be performed on all projects and will aid overall risk management process effectiveness.
For Risk Planning to be credible it needs to address:
§ Risk Identification ‒ by defining the triggers of the risks and the planning sessions for handling the risk.
§ Risk Analysis and Modeling ‒ by assessing the feasibility of meeting cost, schedule, and technical performance.
§ Risk Planning ‒ by defining the roles and responsibilities of the participants in the risk management process.
§ Risk Tracking and Control ‒ for project cost, schedule, and technical performance and report this in short interval
status meetings.
Never forget, we must always answer the question how long are we willing to wait before we find out we are late. Assess
progress to plan at half that distance.
PGCS 2020
59/70

Risk Tracking (sometimes called Risk Monitoring) is an activity of systematically tracking and evaluating the
performance of risk handling actions against target metrics throughout the project management process and
develops further risk handling options or executes risk handling plans, as appropriate.
Its intent is to ensure successful Risk Handling and should be done as part of technical reviews, risk review
board meetings, or periodic project reviews.
Risk Tracking provides information back to other risk management activities of identification, analysis,
handling plans, and handling plan implementation.
Risk Tracking activities include:
§ Communicating risks to all affected Stakeholders,
§ Monitoring risk handling plans for their effectiveness,
§ Reviewing regular status updates,
§ Displaying risk management dynamics,
§ Tracking risk status within the Risk Reporting process, and
§ Alerting management when Risk Handling Plans should be implemented or adjusted.
The key to the tracking activity is to establish a management indicator system over the entire project.
The Project Manager (PM) uses this indicator system to evaluate the status of the project throughout its life-
cycle to assure risk impacts are being reduced as planned.
Risk Tracking should provide an early warning when the likelihood of occurrence or the severity of
consequence exceeds pre-set thresholds or limits or is trending toward exceeding pre-set thresholds or limits
so timely management actions to handle these problems can be taken.
PGCS 2020
60/70

Risk Control is one of four Risk Handling strategies, that include:
§ Risk Avoidance ‒ reconfigures the project so the risk is removed or is reduced.
§ Rick Control ‒ Risk Control is when risks are controlled by managing the cause and consequences
of the risk.
§ Risk Transfer or Sharing ‒ is when the risk is shared with a 3rd party.
§ Risk Assumption ‒ is accepting the loss, benefit or gain, from the risk when it occurs.
Risk control can take the form of installing data-gathering or early warning systems that provide
information to assess more accurately the impact, likelihood, or timing of a risk.
If warning of a risk can be obtained early enough to take action against it, then information gathering
may be preferable to more tangible and possibly more expensive actions.
PGCS 2020
61/70

Risk management is a continuous, forward-looking process that is a critical part of business and
technical management.
Risk management should address issues that could endanger achievement of critical objectives.
A continuous risk management approach is applied to effectively anticipate and handle risks that
have critical impact on the project.
Here are 17 processes that must be in place to effectively manage risk on projects.
Start with determining the sources of risk, which are the uncertainties on the project and put them
first into categories ‒ reducible or irreducible.
Then into the technical and operational categories.
Build plans for handling the risks and monitoring the progress of the plans in correcting or
preventing the causes of the uncertainties that create the risk.
PGCS 2020
62/70

With the Risk Register, and Handling Plans, build a formal risk management process defined in the
Project Management Plan (PMP) for assuring risk management is part of the business process.
This includes the proper resources, policies, roles and responsibilities, and training to properly apply
risk management across all project activities.
PGCS 2020
63/70

Put Risk Management under the same change control process as all other project activities.
Assure the stakeholders are informed and concur with the risk management process and provide
them with short interval updates of the status of the project risks and the current status of he
Probability of Project Success.
PGCS 2020
64/70

Applying the 5 principles and 5 practices, we now have the tools needed to start on the path of
increasing our probability of project success.
PGCS 2020

If there is any message from this last 50 minutes, it’s without a credible and effective risk
management process, the Principles and Practices the Project Success has a low probability of
happening.
PGCS 2020

PGCS 2020
67/70

Increasing the Probability of Project Success with Five Principles and Practices

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Increasing the Probability of Project Success with Five Principles and Practices

Semelhante a Increasing the Probability of Project Success with Five Principles and Practices (20)

Mais de Glen Alleman

Mais de Glen Alleman (20)

Último

Último (20)

Increasing the Probability of Project Success with Five Principles and Practices