The three elements of project management, people, processes, and tools must focus on processes first. Without a process, the tools have no purpose. Without a process, the people are unguided, or at best self guided

1. Increasing The Probability of Success
Integrating Process, People, and Tools
Dallas MPUG
May 6th, 2009
Glen B. Alleman
VP, Program Planning and Controls
Lewis & Fowler
www.lewisandfowler.com
Increasing the Probability of Success for Enterprise IT Projects Starts with
Credible Information About the Performance of the Project. This information
comes from tools. 1

2. It’s Not Really About Tools
 You’ve seen all kinds of demonstrations of project tools
 This will not be one of them
 We’re going to talk about what happens before tools
application – the business reasons for using tools
 We’ll see screen shots to show how some tools can be
applied 2

3. Today's Learning Objectives
 Cost, Schedule, Technical
Performance†, and Risk are
inseparable elements of a
project
 Process integrates these
inseparable variables
 People are the source of all
information, need, and the
consumers of business value
 Tools can be used to implement
processes, but only the right
processes will return the value
from the tools
3
†Technical Performance includes all non-cost and schedule elements of the project

4. So What Are the Real Problems With IT Projects?
4

5. Here’s The Fundamental Problem With All Projects
 Having and using tools is necessary but far from sufficient
 Understanding the principles of project management is the next step
 Dealing the statistical nature of project work is the starting point for
successfully applying tools to the problem of “managing in the
presence of change”
5

6. The Three Fundamental Elements Of All Projects
People Process Technology
 People pay for  Processes guide the  Tools are the glue to
solutions to development integrate processes
problems, not the activities toward the with people.
 Tools transform data
tools and processes business goals.
 Processes provide
that produce those into actionable
solutions. boundaries which information for the
 The processes and control the action of stakeholders.
tools are simply the individuals and
“cost” of doing groups.
business, provided
by the supplier.
6

7. 5 Processes For Successful Enterprise IT Projects
1
Identify Business
Why Needs
Operational
Needs
Capabilities
Based Plan
System Value
2
Stream
Identify
Requirements
What
Baseline Technical
Technical
Performance
Requirements
Measures
3 Establish a
Performance PMB
Measurement
Baseline
Technical
Performance
How
Measures Earned Value
Where Performance
4 Execute the
When 0% /100%
Performance
Who
Measurement
Baseline
Changes to Changes to Changes to
business strategy requirements project plan
5 Continuous Risk Management Process
7

8. Connecting The Dots For Project Success
Continuous Risk
Management is the
glue that connects all
elements of
Enterprise IT project
management
8

9. Let’s Skip the Processes and
People and Move To Our Topic
What tools are needed to support
the People and Processes?
9

10. Requirements Management Tools
Developing precise and accurate requirements is a crucial step in the
success of a development project or new business process.
— Visual Studio 2008 Extensibility Site
10

11. Schedule Management Tools
A Schedule is NOT a Plan
A Plan is the strategy for the successful completion of the project;
The Schedule is the description of the work to produce that success.
Both Plans and Schedules are needed!
11

12. Cost Management Tools
Time is NOT Money
Money can be preserved, Time is lost starting the 1st Day of the Project
12

13. Risk Management Tools
Risk Management is How Adults Manage Projects
— Tim Lister
13

14. Integrating Tools For Project Success
Plan
Integrated elements for project
success
Cost Schedule
The Enterprise Program Management
System
Performance
Technical
14

15.  A Defined Set Of Business
How to Produce Value
Capabilities
by Integrating Tools  A Structured Requirements Flow
with the People and Down Tree
 A Well Defined Work Breakdown
the Processes Structure
 Clear And Concise Descriptions Of
Deliverables
 Work Packages To Produce These
Deliverables
 Measures Of Physical Percent
Complete
 Continuous Risk Management At
Every Step
 An Integrated Digital Environment
 Training To Recognize What “done”
Looks Like
 The Will To Make All This Happen
15

16. Before We Move On To Some Solutions, There Are
Some Questions We Need To Answer
 Do we know what the customer wants?
 How much will it cost when it is done?
 When will we be done?
 What stands in our way to reaching done?
 Who works on what parts of the solution?
 Can we speak about our progress in units of
measure meaningful to the customer?
16

17. To Reach Done We MUST Know What Done Looks Like
The Way To Describe DONE is to build a WBS that:
 Is product or services oriented
 Includes all work in the project
 Logically aggregates each element of the
product and those elements below it
 Reflects the manner in which the work will be
done
The WBS becomes the framework for Cost, Schedule, and Technical
Performance Measurement.
The WBS is the organizational structure for the Work Packages
This sounds simple at best and possibly lame at worst. But without a
description of what the project is delivering, you might as well not
even start. You’ll just be wasting everyone’s time and money.
17

18. Building The WBS In MSFT Project
 Don’t use the WBS field, it wants to do things its
way, use a custom TEXT field
 Build the WBS in a logical manner with a tool that
support hierarchical decomposition – MindJet®
 The WBS is derived from the requirements, not
from the functions that implement the
requirements
 The WBS states in unequivocal terms what “done”
looks like – when all the deliverables are delivered
we’re done
18

19. Guidelines For Building A “Good” WBS
 The 100% rule – all work in
the WBS
 Mutually exclusive elements
– no overlapping scope – a
pure hierarchy tree
 Planned outcomes, not
planned actions – define the
deliverables and their
components
 Levels of detail
– The 80-hour rule for each end
item
– Work should cross only one
accounting period
How long are you willing to wait before you find out you’re late? 19

20. Using MindManager® To Build The WBS
 Capture the contents of this
“Map” in the Product
Development Kaizen
 Focus on the “product”
decomposition not the
functional decomposition
 This is an iterative and
incremental process
 Have the stakeholders in
the room
 Connect the WBS with the
“needed business
capabilities” by asking why
do we have this product
element here?
www.mindjet.com
20

21. The Output Of MindManager®
 The MSFT Project WBS can
be derived directly from
the Mind Map structure
with a mouse click
 This example uses the WBS
field, but that’s
discouraged
 Use a text field and a
template
21

22. What’s In A Name? The WBS Dictionary
 The WBS dictionary is
the guide the “Done”
 It states what the
evidence is for the
product or service
 Enter this information
into the Notes field for
each project activities
 Print this report for
the WBS Dictionary
 Use this to assess what
is being delivered
22

23. Connecting The WBS With Work Packages
WBS
A decomposition of the work
Business Need
Process Invoices for Top
needed to fulfill the business
Tier Suppliers
requirements
1st Level
1st Level
Electronic Invoice Routing to Payables Department
Submittal
2nd Level 2nd Level
Material receipt Payables Account
verification Verification
Terminal Node in the WBS
2nd Level
2nd Level
“On hand” balance
defines the products or
Payment Scheduling
Updates
services of the project
Work
Terminal node of the
Deliverables defined in WP
WBS defined by a Work Package
Package
Deliverables
Tasks and Schedule
Tasks within the Work
Package produce the 1 2 5 A
Deliverables
3 6 B
4
Management of the
Work Package Tasks
is the responsibility of
100% Completion of deliverables is
the WP Manager.
the measure of performance for the
These are not held in
Work Package
the master plan
23

24. Building A Credible Schedule
 What are the units of measure for “Credible?”
 “What does DONE look like?”
The schedule is the description of the work needed to
produce value to the Stakeholder
 The schedule must be a logical flow of the increasing
value produced by the work effort
 The durations must have statistical measures
associated with the static durations
 The “reader” must be able to recognize how the “value
flow” is constructed
24

25. It’s The Not Work Effort We’re After
It’s “What Does Done Look Like?”
The schedule must speak in units of measure meaningful to the
stakeholders – business value and physical percent complete 25

26. Sample Schedule Health Check
http://www.steelray.com/index.html 26

27. The Risk Management Paradigm
MANAGING RISK WITH A STANDARD PROCESS RISK MANAGEMENT IN FIVE EASY STEPS
1. Hope is NOT a strategy
2. No single point estimate of cost
or schedule can be correct
3. Cost, Schedule, and Technical
Performance are inseparable
4. Risk management requires
adherence to a well defined
process
5. Communication is the #1
success factor
http://www.sei.cmu.edu/risk/index.html
27

28. Two Types Of Project Risk
 Technical risk  Programmatic risk
– The risk that the project – Cost overruns
will fail to meet its • The project will exceed
performance criteria its planned budget
• Hardware and software – Schedule overruns
failures • The project will exceed
• Requirements failures its planned completion
date
Date: 9/26/2005 2:14:02 PM Completion Std Deviation: 4.83 days
Samples: 500 95% Confidence Interval: 0.42 days
Unique ID: 10 Each bar represents 2 days
Name: Task 10
1.0
0.16 Completion Probability Table
Cumulative Probability
0.9
0.14 Prob Date Prob Date
0.8
0.05 2/17/06 0.55 3/1/06
0.12
0.7
Frequency
0.10 2/21/06 0.60 3/2/06
0.10 0.6 0.15 2/22/06 0.65 3/3/06
0.20 2/22/06 0.70 3/3/06
0.5
0.08
0.25 2/23/06 0.75 3/6/06
0.4
0.06
0.30 2/24/06 0.80 3/7/06
0.3
0.35 2/27/06 0.85 3/8/06
0.04
0.2
0.40 2/27/06 0.90 3/9/06
0.02 0.1 0.45 2/28/06 0.95 3/13/06
0.50 3/1/06 1.00 3/17/06
2/10/06 3/1/06 3/17/06
So much for our strategy of Completion Date
winning through technical
Risk+ is at: www.deltek.com
dominance 28

29. The Risk Register
 This tool is free, approved by DoD and used on highly visible, mission critical
programs and comes with a manual
 But commitment is mandatory to maintain content and make decision on this
content
http://www.mitre.org/work/sepo/toolkits/risk/index.html 29

30. Monte Carlo Simulation (Risk+) Of A Schedule Date
 No single point estimate of cost or schedule can be credible without
understanding the statistical variances
 Without this schedule modeling information – Hope is Your Strategy
Most
Min Likely Max
Date: 10/4/2005 1:58:06 PM Completion Std Deviation: 1.55 days
Samples: 23 95% Confidence Interval: 0.63 days
Unique ID: 143 Each bar represents 1 day
Name: Construction Schedule Margin
1.0
0.35 Completion Probability Table
0.9
0.30 Prob Date Prob Date
0.8
0.05 2/6/06 0.55 2/9/06
Cumulative Probability
0.25 0.7
0.10 2/6/06 0.60 2/9/06
Frequency
Target Date
0.6 0.15 2/7/06 0.65 2/9/06
0.20
0.20 2/7/06 0.70 2/10/06
0.5
0.15 0.25 2/7/06 0.75 2/10/06
0.4
80% confidence
0.30 2/8/06 0.80 2/10/06
0.3
0.10
0.35 2/8/06 0.85 2/10/06
0.2
0.40 2/9/06 0.90 2/10/06
“The purpose of modeling is to
0.05
0.1
0.45 2/9/06 0.95 2/10/06
relentlessly expose the inevitable
0.50 2/9/06 1.00 2/14/06
2/3/06 2/9/06 2/14/06
outcome of our assumptions” –
Completion Date
Anonymous 30

31. Monte Carlo Simulation (Crystal Ball) Of A Cost
 The same approach is taken for cost analysis
 Cost Risk, Schedule Risk, and Technical Risk are inseparable
 Managing in the absence of this understanding means, Hope Is Your Strategy
Combined Cost Modeling
and Technical Uncertainty
Cost = a + bXc
Cost Modeling
Uncertainty
Cost
Estimate
Historical data point
$
Cost estimating relationship
Standard percent error bounds
Technical Uncertainty
Cost Driver (Weight)
www.oracle.com/crystalball/index.html 31

32. Resource Loaded Schedule?
 Resource loading individual tasks
is a waste of time and effort
 Resource allocate at the Work
Package level
 Let the Work Package manager
assign, allocate, and manage
these resources within the Work
Packages
 Use this resource allocation as
the basis of the labor spreads
 The WP Manager keeps these
balanced by looking at the labor
spreads in the Resource View
32

33. Capabilities Requirements Master Plan Execution
MindJet MindJet Project Project
 Map of  Flow down of  Deliverables  Physical Percent
dependencies requirements from connected to Complete recorded
between Capabilities Requirements and in Master Plan
 Produce Excel of  Embedded Risk
capabilities Capabilities
 Group capabilities  Work Packages
details for mitigations
into business traceability define one identified in Text
 Connect
benefits deliverable Field
 Trace capabilities to  Technical  Technical
requirements with
stakeholder needs Organizational Performance Performance
Structure Measures reportable from
 Tradeoffs visible embedded in notes MSFT Project
with dependencies field
Continuous Risk Management
 MITRE risk management tool
 Risk+ or @Risk for Project Tool
33

34. Ok, It Is About Tools After All
… Sort Of
 But only after you’ve established all the business and
programmatic processes
 Then and ONLY THEN can the tools provide value to the
organization
34

35. The Starting Point for Building a Credible
Schedule in MSFT Project
Work Description Work Arrangements
 Work Packages derived from WBS  Finish to Start relationships the vast
and Deliverables, never bottom up majority of the work
 All work contained in schedule  All constraints are AS SOON AS
produces outcomes. Never build a POSSIBLE (ASAP)
 Task durations are approximate as a
functional schedule (design, code,
test) start.
 Work Packages are linked through a  Schedule margin is EXPLICIT in the
connection tasks, that represent the schedule NEVER buried in the
intermediate outputs duration estimates
 Activities inside Work Packages  No widows or orphans in the schedule
 All work flow to deliverables
describe end to end work for the
 Resources are “assigned” inside the
deliverable
 Zero duration tasks represent the Work Packages and balanced by hand
deliverables through the Resource Usage view
 All work “trees up” to deliverables
 Measures of progress focused on
deliverables, not the passage of time
35

36. Work Coded
Deliverables
To WBS
Finish to
Start Only
IT-1 PAX River Test Van Risk Buy Down Activities
Embedded
Risk Mgmnt
Gate Review & Publish
“Quick Look” for FA-18 Test
Range Instruments Complete
Task Names
State what is
being done
Durations on week
Show Slack
boundaries
No Negative!
The Schedule MUST read a literature.
Informing the reader what is happening, what is the result of the work (Deliverables), how risk is
dealt with, and when the deliverables are planned to be “Delivered.”
NEVER EVER CONFUSE EFFORT WITH RESULTS 36

37. The Next Tool After Project
PERTChart Expert
www.criticaltools.com 37

38. The Next Tool Is a Monte Carlo
Simulator for Programmatic Risk
Planned
Completion
12/1/2010
In order to credibly assess the programmatic risk, the schedule must be properly formed. The schedule
health check and basic structural integrity described in the previous slides is the starting point
80%
Confidence of
completing on
or before
12/10/2010
38

39. The Final Tool That Integrates Everything
Put the all
Capabilities
programmatic
data under
Requirements change control
Derived from
Capabilities
Risk mitigation or
retirement in the
schedule
WBS WBS
Formal risk
management in
RM Tool
Credible Work
Work Packages to
Packages
produce
sequences to
deliverables in the
produce delivered
WBS terminal
value needed by
nodes
the business
Increasing the Probability of Success Means Thoughtful Actions
39

40. Input Tool Outcome
Connection between
Requirements
Capabilities Identification requirements and
Management
business value
Connection between
Requirements Requirements
requirements and
Management Management
planned work
Traceable costs to
Work Breakdown Structure
deliverables
Measures of Physical
Deliverables
Percent Complete
Microsoft
Work Packages of Project Allocated effort and
Deliverables Or measures of progress
Project Server In line description of risk
Risk Mitigation Plans
retirement plans
Cost spreads for Work Align cost and schedule
Packages with deliverables
Risk Identification and Connection between risk
MITRE Risk Management Tool
Management and mitigation efforts
40