Turning Around a Project in Trouble

1
Turning Around aProject in Trouble

• Project Management Institute
• Tampa Bay Chapter 2006 Fall Symposium
• October 6 and 7th, 2006

2
Purpose of this Presentation

• To discuss why projects fail and to suggest some
  practical approaches to turning around endangered
  projects.

3
Who am I?

• Wayne Heckrotte, PMP, MBA
• Program/Project Manager gt 30 years
• Asked to rescue projects behind schedule, over
  budget and below managements expectations

4
Project Management Statistics

• Projects can be a rather pervasive problem
• Only 16 of all IT projects are successful
• 53 of IT projects come in late or over budget
• 32 were cancelled prior to completion
• Studies suggest that the average project goes
  over budget by 189
• The average project lasts 222 longer than
  estimated
• 80 of IS-related projects are late, over budget,
  lacking in functionality or never delivered
• 52 of development projects are over budget by
  200 of original estimates
• Project over-runs cost US companies and
  government agencies 145 billion/year
• The greatest contribution to IT project failure
  is lack of project management

statistics from National Institute of Standards
and Technology, Software Engineering Institute,
Gartner and Forrester
5
Statistics of Failures

• The Robbins-Gioia Survey (2001)
• 51 of ERP implementations unsuccessful
• 46 of ERP systems in place did not solve
  business problems
• Project failure defined by the perception of the
  respondents.
• Advantage integrates multiple aspects
  (perception is reality)
• Disadvantage partial (where do respondents come
  from?)

6
Statistics of Failures - continued

• The Conference Board Survey (2001)
• 34 were very satisfied.
• 58 were somewhat satisfied,
• 8 were unhappy with what they got.
• 40 of the projects failed to achieve their
  business case within one year of going live
• Achievement of benefits took six months longer
  than expected.
• Implementation costs averaged 25 over budget
• Support costs underestimated for the year
  following implementation by 20

7
Are these Statistics Accurate?

• Figures dont lie, but liars figure. Mark Twain
• The Cutter organization says the data is dated,
  and skewed because of the methodology used.
• However, regardless of the statistics, we have
  all run into projects that need major infusions
  or transfusions to get them turned around.

8
Causes of Project Failure

• Unrealistic or unarticulated project goals
• Inaccurate estimates of needed resources
• Badly defined system requirements
• Poor reporting of the project's status
• Unmanaged risks
• POOR COMMUNICATION AMONG CUSTOMERS, DEVELOPERS,
  AND USERS (my emphasis)
• Use of immature technology
• Inability to handle the project's complexity
• Sloppy development practices
• Poor project management
• Stakeholder politics
• Commercial pressures
• Usually not technical

Why Software Fails By Robert N. Charette, IEEE
Spectrum September 2005
9
Other reasons projects fail

• Too many projects do not align with corporate
  strategy disconnect between spending on
  projects and strategic priorities
• Unrealistic expectations Expectations must be
  managed
• Apolitical decision making
• Too many trivial, unfit, weak mediocre projects
• Poor projects not evaluated regularly, so they
  take on a life of their own
• Resources are scarce and unfocused
• Big projects are too complex
• Inconsistent Project Management skills across
  projects
• Lack of executive visibility into current project
  portfolio
• Group think management style

10
Five Steps to Turnaround

• Common sense approach
• Identify the problem (s) - triage
• Perform triage (re-establish scope?)
• Develop new project
• Evaluate and change staff as necessary
• Work the plan (Communicate, communicate,
  communicate)
• Dont panic until I say so

11
Whats the Difference Between Now and Then?

• Expectations lower
• Environment has changed (probably worse)
• Cynicism prevails
• Project Team very defensive
• Blame is the name of the game
• Your job is to turn these negatives into
  positives and deliver a successful project

12
Problem Identification

• Why are we here?
• Understand the BUSINESS problem the project is to
  address
• Review business requirements with users and
  management
• Perform gap analysis between expectations
  (original requirements) and reality
• Present findings to management and users (dont
  hold back, tell it like it is)
• Reset Management and Stakeholder expectations
• Likely that poorly defined goals and loose
  requirements were major reasons for the project
  being in trouble
• Get them right this time
• Make sure that management and stakeholders
  understand this

13
Triage (MASH 4096)

• Separate the ballot from the Chad! (we are in
  Florida after all)
• Have management announce what is taking place
• Dont waste time playing blame games
• Recast CRITICAL requirements
• Prioritize CRITICAL requirements
• Develop plan for CRITICAL requirements
• Delay or drop other requirements
• Get agreement (sign-off) on new plan
• Redefining success
• New project starting from today
• If its not critical its Phase II or more

14
New Project

• Defining the end game what is a win?
• Be realistic
• Document assumptions and constraints extensively
• Short interval deliverables (make it easier to
  track progress and stay in front of management)
• Heavily involve Sponsor, stakeholders, users and
  key IT staff in development
• Heavy on milestones
• Emphasize it will take time to change direction
  of the Titanic
• Make sure the new project fits into the culture
• Original goals still in mind of management and
  stakeholders
• NEW focused approach must be reinforced new
  Project Charter
• Some wish list functions may be deleted
• The new approach is a compromise

15
The Right People

• Joe Torre is as good as his players
• Evaluate current KEY staff individually
  (including users, SMEs)
• Prune as necessary (euphemism for get rid of)
• Get the right people or put the staff in correct
  roles
• Make sure the staff is recognized by management
• Look for Designated Heroes
• Existing staff has a track record of a failure -
  the same people who gave you Pearl Harbor are for
  the most part still involved
• Can they deliver on a newly defined or greatly
  changed project?
• Does A Rod help the team more at third than at
  short?

16
Work the Plan

• The Hard Part Managing Expectations and Reality
• Communicate progress widely especially to
  Management
• Share with staff (they really like to know what
  is going on)
• Report daily at first, as progress is made go to
  weekly or sometimes even less
• Use charts, diagrams etc
• STAY CALM DONT LET STAFF PANIC UNTIL YOU TELL
  THEM THEY CAN

17
Be Firm with Management

• This is real SCOPE management
• Focus on what was agreed upon
• Demonstrate consequences of going astray
• Continually reinforce progress from when you took
  over
• Make them realize they have skin in the game
• Typically management will want to go back to the
  original requirements and plan

18
Goals Met

• Before the Project End party
• End the project - PMBOK
• Complete Lessons Learned very important for
  going forward (not a point the blame exercise)
• Recommend next steps (remember those requirements
  put aside?)
• Have a major BLAST!

19
Common Pitfalls and Mistakes

• Lack of Management support for changes to project
  
• Project staff resentful of new leadership
• Management expects immediate results ensure
  that they know it takes time to turn around a
  project (manage expectations)
• Compromise in revised plan includes too many
  non-essential tasks
• Ignoring the culture of the organization
• New PM doesnt assert control over project be
  professional, but take control

20
Turnaround Quick Tips

• Dont assume you know all the answers when you
  take over a project in trouble each one is
  different
• Only look at the past if it is germane to moving
  forward no blame games
• Ask questions to ensure that you know the real
  truth of the situation
• Dont begin solving the problem until you know
  what it is youre solving
• Get management buy-in immediately you will need
  a champion
• Develop a Communications plan as quickly as
  possible
• Get in front of management as much as possible at
  first
• Make sure the new project is realistic
• Make sure you have the right staff in the proper
  roles you dont have to be popular, but should
  be respected as a professional
• Dont back off from getting rid of non-producers
  (doesnt mean they have to be fired, but get them
  off the project)
• Communicate progress in as many ways as possible
• When roadblocks occur, get rid of them
  immediately
• Dont be afraid to say no to management, users,
  and other stakeholders
• Its an art, not a science

21
Open Discussion