Enterprise projects are not just larger small projects. They are completely different beasts - "radical Project Management," Rob Thomsett

1. Breaking the Project Failure Cycle
“Enterprise projects are not just larger small projects. They are completely
different beasts”
– Radical Project Management, Rob Thomsett
1

2. Today's Speakers
2
Glen Alleman is Practice Director Strategy and
Performance management with Lewis & Fowler. His
more than 25 Years of IT Leadership and Consulting
comes from positions in defense and aerospace,
petrochemicals, newspaper publishing systems,
manufacturing, electric utilities, pulp and paper,
government services, and semiconductors.
Glen holds advanced degrees in Physics and
Systems Management.
Scott Daley is the lead consultant for Microsoft’s
Enterprise Project Management team in the
Western US. Over the past 7 years, Scott has
delivered MS Project Server and related products
to many organizations. He focuses on the
challenges organizations face as they try to
improve their portfolio, resource, and project
management.

3. Projects and Their Plans
 The integrity of any project is its
Plan
 The Plan defines the anatomy and
physiology of the project
 The Plan is tool for communicating
between the project team participants
 The Plan is the Strategy for the
project
 The Plan evolves as decisions and
strategies evolve
Building project
success around a
credible plan is a
good start.
Executing that plan
comes next.
But the plan can
not guide the
execution if it is not
credible.
It’s the combination
of a credible plan
and a competent
execution team that
gives a fighting
chance of being
successful
3
Physiology – the mechanical, physical functions of the studied object
Anatomy – the consideration of the structure of the studied object

4. Root Causes of Project Failure
 Unrealistic deadlines
 Communication deficits
 Uncontrolled scope changes
 Unmitigated resource competition
 Uncertain dependencies
 Failure to manage risk
 Insufficient delivery skills
 Lack of accountability for the outcomes
 Disengaged customers or stakeholders
 Lack of business vision and goals
There is a nearly
endless list of
causes for project
failure.
Here are some that
we can actually do
something about.
4

5. Can Project Management Methods
and Tools save a project failure ?
 Probably not…
 Methods and Tools alone don’t help.
If they did we wouldn’t be here today
 What does help?
 Failure is not really a project
management problem
 It’s a business management problem
 The solution to business problem
starts with asking:
 How can we measure and control
value for our investment?
Methods and Tools
by themselves
provide little help
for a troubled
project.
Executing the
method, with
competent staff and
a credible plan is a
start. But there is
more needed than
this.
A set of principles
must be the basis
of any successful
project delivery
method.
5

6. The processes needed for a successful
project
Identify Needed
Business
Capabilities
Establish a
Performance
Measurement
Baseline
Execute the
Performance
Measurement
Baseline
Capabilities
Based Plan
Business Value
Stream
Technical
Performance
Measures
Earned Value
Performance
Technical
Performance
Measures
Business Value
Stream
Technical
Requirements
Establish a
Requirements
Baseline
4 core processes
need to be in place
to break the project
failure cycle.
All are important.
All are mandatory.
All must execute
with the highest
quality level.
None guarantee
success.
There is no such
thing.
6

7. The four processes work together to
break the Project Failure cycle
Process Outcomes supporting project success
Identify the
Business Needs
 A clear and concise description of the needed business capabilities
 A description of the value stream these business capabilities provide. This value
stream is the connection between to the Business , the Technical Requirements
and the project’s Performance Measurement Baseline
Establish a
Requirements
Baseline
 A Work Breakdown structure derived from the requirements
 Identification of the Work Packages that produce the deliverables the create the
business value
Establish a
Performance
Measurement
Baseline
 Balance the Budgeted Cost for each work package to match available resources
 Balance the Budgeted Cost for the entire project
 Identify how Physical Percent Complete will be measured for each Work Package
 Establish a single point of accountability for he success of each Work Package
Execute the
Performance
Measurement
Baseline
 Capture the Actual Cost of Work Performed and Physical Percent Complete
 Define the measure of progress by the delivered value for each Work Package
 Make management decisions for the project using this delivered value
7

8. Core Questions that should be
asked of any Project Manager daily
 How much will this project cost?
 When will it be done?
 What are the risk we won’t reach
the end within our budget?
 What are we doing about these
risks?
 What do we get when we’re done?
 Does the customer agree that
these deliverables are meaningful?
Deliverables Based
Planning is the
foundation of a
successful project
management
process.
The deliverables
define what Done
looks like, are the
measure of
progress and are
meaningful to the
customer.
8

9. Deliverables Based Planning can
answers these questions
But Execution is the key to Breaking
the Failure Cycle
Customers measure progress in terms of business value – the currency
of this business value are the project deliverables, not the passage of
time or consumption of money.
9

10. The 6 steps of Deliverables Based Planning
10
Decompose the Project Scope into a product based Work Breakdown Structure (WBS),
then into Work Packages describing the production of all deliverables
Decompose
Scope
Assign Responsibility to Work Packages (the groupings of deliverables) for the
owners accountable for the management of resource allocation and cost baseline
Assign
Responsibility
Arrange the Work Packages into a well formed network with defined deliverables,
milestones, internal and external dependencies
Arrange Work
Packages
Develop Time–Phased Budgeted Cost for Work Scheduled (BCWS) from labor and
material costs in each Work Package and the Project as a whole
Develop BCWS
Assign Objective Performance Measures for each Work Package and summarize these
for the Project as a whole
Assign
Performance
Measures
Establish a Performance Measurement Baseline used to forecast Work Package and
Project ongoing and completion cost and schedule metrics
Set Performance
Baseline

11. Project Execution Processes Beneficial Outcomes to
the Customer
Starting with a Deliverables Based Plan
Executing the Plan is next step along the path to success†
Agreement on
Interfaces
Risk
Management
Formal
Inspections
Metrics Based
Project
Management
Configuration
and Data
Management
Project Wide
Visibility
People Aware
Management
Defect Tracking
Binary Quality
Gates
Identify and
Correct
Defects
Planning and
Tracking
Minimize
Rework
Effective Use
of Personnel
† These principles are
not original.
They are taken
directly from the work
of Norm Brown, the
founder and executive
Director of the
Software Program
Managers Network
(SPMN).
SPMN is a consortium
of Department of
Defense Program
Managers dedicated to
improving the practice
of managing software
acquisition and
development projects
in commercial and
government domains.
11

12. Connecting the Execution Practices
with Tools
 The Execution Practices are the
foundation of any good project
management process
 The challenge is how to implement
them with the available tools
 Microsoft tool suite
– Project Server
– Portfolio Manager
– Share Point Server
12

13. Agreement on Interfaces
Expose the needed agreements
Execution Practice Tool Implementation
Use Interface Control Documents
(ICD) to define the nouns and
verbs for each interface
Share Point Services used as a
repository for Interface Control
Documents
UML automates the definition of
interface nouns and verbs
SysML (XML) repository in Share
Point Services searchable for
dictionary of nouns and verbs
These interfaces can take many forms – software, hardware, business
processes, business units, customers, contractors.
Documenting the “objects” exchanged across the interfaces creates the
“semantics” of these objects.
Their production and consumption provides the foundation for
“Agreement on Interfaces”
13

14. Defect Tracking
Identifies quality leakage
Execution Practice Tool Implementation
Keeping bug reports is necessary
but not sufficient, the metrics of
who, what, where, when, how, and
why are also needed
Issues tracking in Share Point
Team Foundation Server
Tracking metrics, basic indicators
relating to defects, schedule, cost,
requirements makes them visible
Defect tracking portal using
graphical dashboard of quality
Defects appear in many forms – software bugs, construction flaws,
product defects, processes disconnects, production failures.
Each defect must be identified, classified, dealt with, and the source of
the defect corrected as part of the execution of the project.
Not doing this mortgages the future with the debt of a poor product
14

15. Binary Quality Gates
100% done before proceeding
Execution Practice Tool Implementation
When project planning and
monitoring are based on
insufficient detail, the discussion of
the “true” status of the project is
illusionary
The right level of detail is driven by
willingness to assume risk.
How long are we willing to go
before we discover we’re in
trouble?
Project management without detail
is called “let’s pretend”
Connecting physical percent
complete with business value is
the first step
Incremental and iterative delivery of business value starts with a clear
understanding of the meaning of “incremental value” to the business.
Delivering small pieces that can be put to use, each with 100% quality
and 100% capability (in their own right), provides the basis for
continuous increasing maturity of the project.
15

16. Formal Risk Management
Risks must be mitigated in the Plan
Execution Practice Tool Implementation
Risk management embedded in all
the project management activities
Risk activities “in line” with Work
Package tasks, coded in WBS and
assigned resources in Project
Use programmatic risk
management to make visible “hot
spots” in the schedule
Risk+ and @Risk for Project
applied to a well former network of
activities
Risk management is how adults manage projects. But risks are not the
same as issues. Managing both is needed for success.
Identifying each risk and its mitigation takes place in the schedule, with
assigned mitigation budget.
16

17. Formal Inspections
Quality assurance made visible
Execution Practice Tool Implementation
The level of formality must match
the level of quality
Policies and procedures available
“on line” through Share Point
The term “inspection” can be
replaced with many domain
specific terms
Defining the activities of
“inspection” in the schedule,
coding
“Inspecting” the work products in some way defines the Exit Criteria for
all project activities.
This ranges from formal inspections to full simulation of the produced
products to “quality build it.”
17

18. Project Performance Metrics
How are we doing toward our Plan
Execution Practice Tool Implementation
The early identification of
programmatic problems is the
reason to have metrics
Project performance metrics start
with a credible programmatic
baseline established in Project
Server
The project management metrics
are the yardstick for measuring
progress to plan
Deliverables based planning, with
associated Earned Value baseline
held in Project Server
Using Earned Value is now generally accepted for all project domains.
Defining the baseline budget for the planned value, measuring the
Physical Percent Complete and calculating the Earned Value from the
Planned Value is the basis of Project Performance Metrics
18

19. Configuration Management
How do all the parts come together
Execution Practice Tool Implementation
Separating Configuration
Management from Development is
the basis of higher quality project
execution
Plans and schedules define
processes, artifacts and interfaces
for the CM activities in the Master
Schedule
Information approved at the Binary
Quality Gate level is a controlled
document held in the configuration
management system
Document control implemented in
Share Point Services
Controlling the configuration of the project’s output starts with defining
the proper configuration. Any uncontrolled change to this definition
impacts technical performance, cost and schedule.
19

20. Project Wide Visibility
Everyone knows where we are
Execution Practice Tool Implementation
The single most important factor in
the success of any software project
is the quality, experience, and
motivation of the technical and
support staff
Dashboard, portals, repositories,
seamless tools integration, work
flow, electronic document
management, programmatic
performance all reduce work load,
increase productivity and provide
visibility into personal contribution
Speaking to the customer in meaningful terms starts with understanding
what it is the “is meaningful.”
Making these meaningful measures visible is the basis of trust.
“I can see you’re doing what you said you were going to do, at the time
you send you were going to do it and for the cost we agreed on.”
20

21. People Aware Management
Everyone’s on the same team
Execution Practice Tool Implementation
Focus on people as the foundation
for the success of the project
It’s the people stupid
The single most important factor in
the success of any software project
is the quality, experience, and
motivation of the technical and
support staff
High performance organizations
start and end with people
Providing tools that enable communication, shared understanding,
trusted repositories, insight into performance, forecasting of future
performance, management of risk and integration of work processes
enables the people to work as a Team.
21

22. Putting all These Practices to Work
Managing projects requires a definition of done, how to recognize done, the
attributes of done and the units of measure of those attributes
22

23. A Sobering Statistic
A Study of 400 enterprise class projects revealed that
project performance does not tend to improve once
the project has passed the 15% completion point. It
often gets even worse!
23

24. Goal of any Project Management
Process must be to …
 Produce no surprises for the customer or the
supplier
 Build trust with free and frank discussions
about
– Risk, resources, planned effort, capabilities,
commitment
– Performance – financial, technical, personnel,
maturity
 Fully engage with customer’s strategies
– Communication of needs to solution providers
– Requirements traceable to business benefits
 Understand risk management is how adults
manage projects
– Identify, analyze, plan, and mitigate
– Risk informed management processes
24

25. Breaking the Project Failure Cycle
 Define “done” in terms of measurable
business value
 These units of measure must be agreed
to by the business
 Measure progress to plan only in
these units
 Deliverables produced for invested cost
 Do not use passage of time or
consumption of resources as the
primary metric. These are interesting to
cost accounts, but not project managers
If we’re going to
avoid project
failure, then we
have to start out on
the right foot.
Describe what done
looks like. Only
perform work that
produces “done.”
25

26. Process That Use These ToolsTools for successful
project delivery
What tools enable a well run
project?
Agreement on
Interfaces
Risk
Management
Formal
Inspections
Metrics Based
PM
Configuration
Management
Project Wide
Visibility
People Aware
Management
Defect Tracking
Binary Quality
Gates
Identify and
Correct
Defects
Planning and
Tracking
Minimize
Rework
Effective Use
of Personnel
Share Point
Project Server
Portfolio
Manager
26

27. Project Failure Root Causes and
Some Tools Based Approaches
Project Failure Cycle Root Causes Tool Enabled Approaches Tool
Unrealistic deadlines Identify the capacity for work using resource planning, past
performance measurement and required deliverables to define
credible deadlines
Project Server
Communication deficits Deploy all communication channels including dashboard, cost
and schedule forecasts, defect tracking, business case
measurements, data repositories and project portals
Share Point
Uncontrolled scope changes Use formal requirements management processes, with document
change control and tracking, sign offs, web access
Share Point
Unmitigated resource competition Use resource planning services Project Server
Uncertain dependencies Identify and confirm conflicts and dependencies across the
portfolio of projects
Project Server
Failure to manage risk Identify, mitigate and manage risk with “risk buy down” activities
embedded in all schedules
Project Server
Share Point
Insufficient delivery skills Provide skills inventory in the resource planning process Project Server
Lack of accountability for the
outcomes
Identify single accountabilities, provide reporting and visibility for
all deliverables
Disengaged customers or
stakeholders
Provide easy access to project documents, progress, change
management and deliverables
Share Point
Lack of business vision and goals Identify business value, connections to strategy and the
performance attributes of the project through web portal
Share Point
Balanced Scorecard Manager
27

28. Just a Reminder
 Tools are necessary,
 Process are necessary,
 Putting tools and
process together is
necessary,
 But more is needed:
 Skill
 Experience
 Innovation
 A bit of Luck
Initiating
Closing
MonitoringandControlling
Executing
Planning
Integration
Scope
Time
Cost
Quality
Human Resources
Communications
Risk
Procurement
Process Groups
KnowledgeAreas
28

29. Breaking the Project Failure Cycle
 As a project management, when your
project makes you feel like this, it’s time
to reconsider your approach …
 Define the
deliverables
 Measure
progress by
measuring the
deliverables
 Make
measurement
meaningful to the
business 29

30. Lewis & Fowler and MSFT
 Founded in 2002, Lewis & Fowler is a consulting
firm delivering business solutions through strategy
development, business process design, tool
selection and deployment ,and the project
management of these activities.
 Our singular focus of achieving strategic results for
our clients through operational excellence is based
on performance management, methodologies,
practices, and program management tools.
 Our long–term success depends on understanding
our clients business needs and available solutions.
 In the end, we help our clients exceed their
business objectives, through our experience,
processes and talent.
30

31. 31

32. Breaking the Project Failure Cycle
Lewis & Fowler
8310 South Valley Highway
Suite 300
Englewood, Colorado 80112
www.lewisandfowler.com
32