Software Projects Failure 1

Nightmare on Project X Restoring Projects in Crisis

Project E“helping ngineering Technologies companies help themselves”

Deb Jacobs Project Engineering Technologies

2

Nightmare Projects A LETTER FROM CAMP Written by: Allan Sherman and Lou Busch - © 1963

Popularized by: Allan Sherman Hello Muddah, hello Faddah, Here I am at camp Grenada. Camp is very entertaining, And they say we'll have some fun if it stops raining.

Take me home, oh Muddah, Faddah, Take me home, I hate Grenada. Don't leave me out in the forest where, I might get eaten by a bear.

I went hiking with Joe Spivey, He developed poison ivy. You remember Leonard Skinner, He got Ptomaine poisoning last night after dinner.

Take me home, I promise I will not make noise, or mess the house with other boys, Oh please don't make me stay, I've been here one whole day.

All the counselors hate the waiters, And the lake has alligators. And the head coach wants no sissies, So he reads to us from something called Ulysses. Now I don't want this should scare ya', But my bunkmate has Malaria. You remember Jeffery Hardy, They're about to organize a searching party.

Project E“helping ngineering Technologies companies help themselves”

Dearest Faddah, Darling Muddah, How's my precious little bruddah? Let me come home if you miss me, I would even let Aunt Bertha hug and kiss me! Wait a minute, it's stopped hailing, Guys are swimming, Guys are sailing! Playing baseball, gee that's bettah, Muddah, Faddah kindly disregard this letter!!!

3

Nightmare Projects? ◆ ◆ ◆ ◆ ◆ ◆ ◆

Out of Control Project Project in Crisis Project Roadkill Disaster Project Project from Hell Death March Challenged Project

Project E“helping ngineering Technologies companies help themselves”

◆ ◆ ◆ ◆ ◆ ◆

IT Fiasco Runaway Systems Project Troubled Project Chaotic Project Crunch Project Mission Impossible Project

4

Agenda Timeline Why Projects Fail? Top Ten Signs Your Project is in Crisis The Road to Project Restoration Beyond the Nightmare Process Models Project Management

Project E“helping ngineering Technologies companies help themselves”

5

Timeline SOFTWARE ENGINEERING SOFTWARE PROJECT FAILURE AWARENESS TIMELINE 1960’s

IBMs OS/360 software project

1975

1981

Fred Brooks, The Mythical Man-Month, written about the IBMs OS/360 software project

1984

Capers Jones, Programming Productivity -- Issues for the Eighties

Software Engineering Institute (SEI) established by Congress to address software engineering unpredictability and high failure rate

1989

Watts Humphrey, Managing the Software Process

1991

1995

1997

1997

Initial Software Capability Maturity Model published

Initial Standish Group CHAOS Report, Research Paper Regarding Software Project failures

Ed Yourdon, Death March

KPMG Survey of Unsuccessful Information Technology Projects

Project E“helping ngineering Technologies companies help themselves”

1998

Updated Standish Group CHAOS Report

Before 1935, the word computer meant a person who calculated in surveying or other related fields.

6

Timeline: The Mythical Man-Month by Fred Brooks ◆

Written 30 years ago about SW project management – based on IBMs OS/360 SW project accomplished in the 1960’s ▼

“… software managers often lack the courteous stubbornness of Antoine's chef.” –

▼

▼

◆

“Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.” Menu of Restaurant Antoine, New Orleans

“Schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.” “… the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable.”

Today, we still make the same mistakes

Project E“helping ngineering Technologies companies help themselves”

7

Timeline: Programming Productivity--Issues for the Eighties by Capers Jones ◆

40 articles from the 1970's through 1986 era on software productivity and quality

◆

“If you can prevent defects or detect and remove them early, you can realize a significant schedule benefit. Studies have found that reworking defective requirements, design, and code typically consumes 40 to 50 percent of the total cost of software development. “

Project E“helping ngineering Technologies companies help themselves”

"If you don’t have time to do the job right, where will you find the time to do it over?"

8

Timeline: Birth of the Capability Maturity Model ◆

Software Engineering Institute was established by the federal government at Carnegie Mellon University in Pittsburgh, PA – Software engineering community lacked a shared view of the state of practice – Agreement about what constitutes good practice – Development activity and resulting products were unpredictable – Success or failure was totally dependent on the staff assigned

Project E“helping ngineering Technologies companies help themselves”

9

Timeline: Birth of the Capability Maturity Model (CMM) ◆

Managing the Software Process written by Watts Humphrey – Introduced and discussed formalizing the maturity framework which is the CMM we use today

◆

Watts Humphrey founded the Software Process Program at the SEI

Project E“helping ngineering Technologies companies help themselves”

10

Timeline: Capability Maturity Model ◆

Capability Maturity Model (CMM): software process framework

◆

CMM based on: – knowledge acquired from software process assessments – extensive feedback from industry and government

◆

Objective: ▼

help organizations achieve sufficient maturity to manage technology introduction

Project E“helping ngineering Technologies companies help themselves”

11

Timeline: Initial CHAOS Report ◆

Forward in CHAOS Report: ▼

“The Roman bridges of antiquity were very inefficient structures. By modern standards, they used too much stone, and as a result, far too much labor to build. Over the years we have learned to build bridges more efficiently, using few materials and less labor to perform the same task.” Tom Clancy (The Sum of All Fears)

– CHAOS research inspired by bridge building approach ▼

where bridge builders learned from the myriad of mistakes, software developers tend to “cover-up, ignore, and/or rationalize” their failures

– Moral: Learn from our mistakes Project E“helping ngineering Technologies companies help themselves”

12

Timeline: Initial CHAOS Report ◆

1995 CHAOS Report Results: ▼

U.S. spends $250,000/yr on IT development on approximately 175,000 projects

▼

31.1% of projects canceled prior to completion

▼

52.7%cost 189% of estimate

▼

Cost of failures and lost opportunities cost trillions of dollars each year

▼

Only 16.2% of projects completed on-time & on-budget

Project E“helping ngineering Technologies companies help themselves”

“The project was two years late in development. We had thirty people on the project. We delivered an application the user didn’t need. They had stopped selling the product over a year ago.”

13

Timeline: Initial CHAOS Report ◆

1995 CHAOS Report Results: SMALL VS LARGE COMPANIES SUCCESS RATES Small Company %

Large Company %

On-time and on-budget/Successful

28%

9%

Original features and functions

42%

74.2%

Projects challenged

50.4%

61.5%

Projects impaired and subsequently cancelled

21.6%

29.5%

Statistic

Project E“helping ngineering Technologies companies help themselves”

14

Timeline: Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects by Ed Yourdon ◆

◆

Ed Yourdon widely known as lead developer of structured analysis/design methods and codeveloper of OO analysis/design methods Death March ▼

Abstract: “How to survive a programming project that seems doomed to failure, and how to tell when to bail out.”

Project E“helping ngineering Technologies companies help themselves”

"The dismal track record of software projects is familiar to most IT managers, and even most senior corporate managers..." - Ed Yourdon

15

Timeline: KPMG Survey ◆

Failure Project Statistics: ▼ ▼ ▼

Project E“helping ngineering Technologies companies help themselves”

87% of failed projects exceeded schedule > 30% 56% of failed projects exceed budget > 30% 45% of failed projects failed to produce expected benefits

16

Timeline: 1998 CHAOS Report ◆

Study of 7500 IT projects by the Standish Group – 72% of IT projects come in late, over budget, or not at all ▼

▼

Project E“helping ngineering Technologies companies help themselves”

28% of IT projects are cancelled or never implemented out of the rest 46% are behind schedule, over budget, or both

17

Why Projects Fail?

Project E“helping ngineering Technologies companies help themselves”

18

Why Projects Fail ◆

Standish Group Top Reasons for Project Failures ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼

Incomplete requirements & specifications Lack of user input Lack of resources Unrealistic expectations Lack of executive support Changing requirements and specifications Lack of planning Lack of IT management Technology illiteracy

Project E“helping ngineering Technologies companies help themselves”

19

Why Projects Fail ◆

InformationWeek surveyed IT managers – Top 3 Reasons for Project Failure ▼ ▼ ▼

Project E“helping ngineering Technologies companies help themselves”

Poor Planning or Poor Project Management (77%) Change in Business Goals During Project (75%) Lack of Business Management Support (73%)

“The plan is nothing; the planning is everything.” Dwight D. Eisenhower

20

Why Projects Fail ◆

KPMG Study (Canadian-based International service provider) – 3 Most Common Reasons for Project Failures ▼ ▼ ▼

Poor Project Planning Weak Business Cause Lack of Top Management Involvement and Support

Project E“helping ngineering Technologies companies help themselves”

“What sometimes appears to be the end is really a new beginning”

21

Why Projects Fail ◆

Management’s Seven Deadly Sins Why Projects Fail - Gopal Kapur, president of the Center for Project Management (CPM): 1. Mistaking half-baked ideas for viable projects 2. Dictating unrealistic project schedules 3. Assigning under-skilled project mangers to highcomplexity projects 4. Not ensuring solid business sponsorship 5. Failing to break projects into manageable “chunks” 6. Failing to institute a robust project process architecture 7. Not establishing a comprehensive project portfolio to track progress of ongoing projects

Project E“helping ngineering Technologies companies help themselves”

22

Top Ten Signs Your Project is in Crisis 1. Lack of Communication 2. Inadequate Project Planning and Management of Plan 3. Unstable Requirements 4. Lack of Training/Mentoring for Managers/Leads 5. Unachievable/Unrealistic Schedules 6. High Turnover in Project Staff 7. Inadequate Use of Outside Resources 8. Inadequate Work Environment 9. Workforce Tied to Old Technology 10. Lack of Long-term Commitments Project E“helping ngineering Technologies companies help themselves”

23

1. Lack of Communication ◆

◆

Communication is key to ensure that all stakeholders understand what is expected Project Manager (PM) used as crucial interface to all aspects of a successful project including: – – –

◆

End Users/Client/Customer Project Staff Executive Management

Project Manager (PM) must be empowered and possess skills to communicate needs and decisions

Project E“helping ngineering Technologies companies help themselves”

End User PM Project Staff

Executive Mgt

“That’s my story and I’m sticking with it.”

24

2. Inadequate Project Planning and Management of Plan ◆

◆

Lack of Planning or Inadequate Planning is the most quoted cause for Project Failure Management of the Plan is key - planning is an iterative process – When plan is OBE, it must be updated

◆ ◆

Defining processes is crucial to success Risk Planning with contingency plans ▼

look for what could go wrong and figure out ways to alleviate or reduce the impact if they do go wrong

Project E“helping ngineering Technologies companies help themselves”

“People don’t plan to fail, they fail to plan!” Anonymous

25

3. Unstable Requirements ◆

◆

Poorly understood and uncontrolled “requirements creep” are a leading cause of failure Many tools are available for managing requirements both manually and automated – Recommend that every project use one regardless of size

◆

Basic Requirements Mgt tasks include: – gathering, analyzing, documenting and managing

Project E“helping ngineering Technologies companies help themselves”

26

4. Lack of Training/ Mentoring for Managers ◆

◆

Taking a great technical person and putting them in charge can cause some of the worst problems on projects Recommend that each new software manager be given training, mentoring, or both in Project Management – Best proven method is combination of training and mentoring

Project E“helping ngineering Technologies companies help themselves”

When Odysseus made his epic journey across the world, he left one of his best friends, Mentor, in charge of the education of his son, Telemachus. Through writings such as Odyssey by Homer, the word Mentor has come to mean an advisor.

27

5. Unachievable/ Unrealistic Schedules ◆

◆

Schedules are essential tools for each Project Stakeholder (a primary tool for PM) Project’s Critical Path and dependencies must be understood and tracked diligently ▼

◆

Defined critical path - tell you how far you are actually behind schedule - more than 25% lag is a good signal of insurmountable problems

Chunking or breaking large tasks into smaller more manageable tasks

Project E“helping ngineering Technologies companies help themselves”

Deadline: a line or limit that must not be passed original meaning - a line drawn around a military prison, beyond which prisoners were summarily shot.

28

6. High Turnover in Project Staff ◆

◆ ◆

High staff turnover indicative of low moral leading to project failure Build a team that works well together Build confidence and motivation in the team and keep them focused – Myriad of methods for attaining that objective

◆

New staff subtract productivity from existing staff hence keep current staff employed

Project E“helping ngineering Technologies companies help themselves”

Brooks' Law: Adding manpower to a late software project makes it later. Fred Brooks, The Mythical Man-Month

29

7. Inadequate Use of Outside Resources ◆

“Running leaner than ever, most organizations lack the technical, strategic and project management skills to handle the benumbing rate of technological and market change.” CIO Magazine Oct 15 1998

◆

Outsourcing can: – provide technical and management expertise without the risk and expense of a direct hire – augment staff

◆

Select resources that provide a transfer of knowledge to existing staff; don’t become too reliant upon one resource

Project E“helping ngineering Technologies companies help themselves”

“I want to build sand castles and leave. I don’t want to be there when it needs to be painted. I want to hand it over and go on to the next one.” Sherry Higgins , Top Gun at Lucent Technologies

30

8. Inadequate Work Environment ◆

Lack of adequate equipment can be detrimental to a project – Dissatisfied staff results in lower productivity – Inability to accomplish tasks

◆

Provide thinking-oriented office space ▼

▼

Each organization must determine most optimal work environment based on their unique needs "Peopleware" by Tom DeMarco & Tim Lister: cubicles hurt your productivity because it’s harder for people to get enough peace and quiet so they can concentrate

Project E“helping ngineering Technologies companies help themselves”

31

9. Workforce Tied to Old Technology ◆

◆

“Anyone who has never made a mistake has never tried anything new.” -- Albert Einstein The New Generation Gap no longer tied to age – If staff is too tied to the old, they will never see the benefits of progressing

◆

◆

Emerging technology is the basis for developing progressive systems - the cornerstone for today’s advancements Managers must walk a fine line between adoption of new technology and the risk involved

Project E“helping ngineering Technologies companies help themselves”

“We can easily forgive a child who is afraid of the dark; the real tragedy of life is when men are afraid of the light.”

32

10. Lack of Long-term Commitments ◆

Top Management

– Must be actively involved by providing periodic review with the Project Manager – Lack of Top Management Commitment: ▼ ▼

◆

lack of adequate resources ($, people, equip,…) lack of visibility for staff

Program Staff – High staff turnover – Low morale

Project E“helping ngineering Technologies companies help themselves”

33

The Road to Project Restoration

Project E“helping ngineering Technologies companies help themselves”

34

The Road to Project Restoration: Standish Group ◆

Standish Group Top Reasons for Project Success – Most successful projects: ▼ ▼ ▼

– – – – –

> six month timeframe > six people > $750,000 cost

User involvement Executive Support Experienced Project Management Clear Business Objectives Good Communications

Project E“helping ngineering Technologies companies help themselves”

35

The Road to Project Restoration: Capers Jones’ Essential Attributes ◆

“...there are myriad ways to fail when building large software systems. There are only a very few ways to succeed. All of the paths that lead to successful software have these twelve essential attributes…” Software Quality -Analysis and Guidelines for Success, Capers Jones

◆

Capers Jones 12 Essential Attributes For Successful Software: 1. 2. 3. 4. 5. 6.

◆

effective project planning effective project cost estimating effective project measurements effective project milestone tracking effective project quality control effective project change management

7. 8. 9. 10. 11. 12.

effective development processes effective communications capable project managers capable technical personnel significant use of specialists substantial volumes of reusable material

Software project management has been one of the most demanding jobs of the twentieth century. In the twenty-first century, there are indications that the difficulties of project management will grow even more taxing.

Project E“helping ngineering Technologies companies help themselves”

36

The Road to Project Restoration: Steve McConnell’s Ten Essentials ◆

Software’s Ten Essentials (he compared software to hikers & developed this list): 1. Product Specification - software project’s compass 2. Detailed User Interface Prototype - captures look and feel of product 3. Realistic Schedule - essential planning foundation 4. Explicit Priorities - essential features 5. Active Risk Management - prepare for and actively attack risks 6. Quality Assurance Plan - helps in correcting defects early 7. Detailed Activity Lists - schedule for comparing planned vs actuals 8. Software Configuration Management - manages code include backups 9. Software Architecture - promotes consistent design & implementation 10. Integration Plan - alleviates much of the integration nightmare

Project E“helping ngineering Technologies companies help themselves”

37

Beyond The Nightmare: Road to Restoration 1. Build a Task Force 2. Analyze the Issues 3. Determine the Problem 4. Fix the Problem 5. Monitor Project 6. Start Over, if needed Project E“helping ngineering Technologies companies help themselves”

38

Road to Restoration: Build A Task Force ◆

Task Force = team of people charged with determining and correcting problems – Keep task force small ▼

Size can be one or more persons, dependent on: – scope of project and problems – expertise and experience of team member(s)

– Selecting right members critical to success ▼

Wrong team members can cause more problems on the project

– give authority to make changes needed Project E“helping ngineering Technologies companies help themselves”

“Too few people on a project can't solve the problems - too many create more problems than they solve.”

39

Road to Restoration: Determining What Went Wrong? ◆

◆

Each organization is unique; however, study after study found that each organization’s failure projects follow a similar path Search for the “real” problems/issues – Go below the surface

◆

Examine the mistakes – Don’t finger point!!!

◆

Apply Lessons Learned

Project E“helping ngineering Technologies companies help themselves”

“How does a project get to be a year late?... One day at a time.”

40

Road to Restoration: What Can you Do To Fix It? ◆ ◆ ◆ ◆ ◆ ◆ ◆

Decrease/Limit Scope of Project Use Modular, Build, Iterative, or Chunking Approach Revise Your Plan, Don’t Just Throw It Out Understand your Requirements Improve Training Get Buy-in From Staff, Users, and Executive Managers Capture/Deploy your Project’s Processes

Project E“helping ngineering Technologies companies help themselves”

“THE PROBLEM with doing nothing is not knowing when you’re finished. “ Benjamin Franklin (1706-1790)

41

Road to Restoration: What Can you Do To Fix It? Decrease/Limit Scope of Project ◆

Project success is inversely proportional to size (The Standish Group CHAOS 1998) – > $750,000 = 55% success rate – $1M - $2M = 18% success rate – $5M - $10M = 7% success rate

Project Success Based on Project Size 60 50 40 30 20 10

Project E“helping ngineering Technologies companies help themselves”

0

> $750,000

$1M-$2M

$5M-$10M

42

Road to Restoration: What Can you Do To Fix It? Use Modular, Build, Iterative, or Chunking Approach ◆ ◆

◆

Break the project into small workable chunks Replanning a project can have a significant positive impact Instituting an incremental build methodology has proven to bring projects in line –

allows for building a strong infrastructure then adding functionality incrementally to ensure that it all works well together

Project E“helping ngineering Technologies companies help themselves”

"If there is a better solution...Find it." -Thomas Edison

43

Road to Restoration: What Can you Do To Fix It? Revise your plan, don’t just throw it out ◆ ◆

◆ ◆ ◆

Planning is an iterative process Schedules must be periodically updated to reflect the current state of the project Team-involved plan - Project team must own plan Always have a contingency plan for potential risks NEVER abandon the plan when the pressure is turned up, that’s when you need it most to keep track – Don’t let your project fall into the code-and-fix mode

Project E“helping ngineering Technologies companies help themselves”

“IT IS BETTER to look ahead and prepare than to look back and regret.” JACKIE JOYNER-KERSEE, Olympic track and field champion

44

Road to Restoration: What Can you Do To Fix It? Understand your Requirements ◆ ◆

◆

Fully understand each requirement Ensure that project staff and users agree on their understanding of each requirement Control “requirements creep” – Manage changes to requirements – Obtain management approval for any added requirements

◆

Start by documenting the requirements

Project E“helping ngineering Technologies companies help themselves”

I know that you believe that you understand what you think I said but I am not sure you realize that what you heard is not what I meant.

45

Road to Restoration: What Can you Do To Fix It? Improve training ◆

◆

◆ ◆

“We’re known for our on-the-job training.” “Only an idiot would needs training.” WRONG WRONG WRONG There’s always room for more training. Train your engineers, train your managers, train your users!!!

Project E“helping ngineering Technologies companies help themselves”

46

Project E“helping ngineering Technologies companies help themselves”

47

Road to Restoration: What Can you Do To Fix It? Get buy-in from staff, users, and executive managers ◆

◆

◆

All project stakeholders must: Walk the Talk At critical phases, you need everyone pulling together from the same sheet of music Project Manager is key to playing the interface in making this happen

Project E“helping ngineering Technologies companies help themselves”

“None of us are as strong as all of us.”

48

Road to Restoration: What Can you Do To Fix It? Capture/Deploy your Project’s Processes ◆

There are NO silver bullets – no lose weight without exercise or magic diet formulas

◆ ◆

◆

Changing project’s/organization’s culture is key Allow engineers to engineer and manager’s to manage by giving them the tools they need Start with what you do already and make it better

Project E“helping ngineering Technologies companies help themselves”

“WHEN PEOPLE are highly motivated, it's easy to accomplish the impossible. And when they're not, it's impossible to accomplish the easy.”

49

Process Models ◆

Several Process Models Available: – SW-CMM ▼

Software Capability Maturity Model - developed by the Software Engineering Institute at Carnegie Mellon University

– ISO ▼

Series of international standards used to ensure or at least enhance the quality of all products from manufacturing of products to development of products

– SPICE – SIX SIGMA – etc.

Project E“helping ngineering Technologies companies help themselves”

50

Project Management ◆

Research shows that Project Management is the Key to Successful Projects – Proactive Project Management Approach ▼ ▼ ▼ ▼ ▼

Project E“helping ngineering Technologies companies help themselves”

Project Planning Risk Management Project Tracking and Measurement Requirements Management Communications

“Make a decision! Make a decision! People are dying all around you!” Christopher P. Higgins (based on his Army experience), Bank of America National Manager Currency Services

51

Project Management Colin Powell's Rules of Leadership 1. It ain't as bad as you think it is. It will look better in the morning. 2. Get mad, then get over it. 3. Avoid having your ego so close to your position that, when your position falls, your ego goes with it. 4. It can be done! 5. Be careful what you choose. You may get it. 6. Don't let adverse facts stand in the way of a good decision. 7. You can't make someone else's choices. You shouldn't let someone else make yours. 8. Check small things. 9. Share credit. 10. Remain calm. Be kind. 11. Have a vision. Be demanding. 12. Don't take counsel of your fears or naysayers. 13. Perpetual optimism is a force multiplier. From Leadership...with a human touch, (March 9, 1999). Copyright © 1999, The Economics Press, Inc., Fairfield, NJ 07004 USA. All rights reserved.

Project E“helping ngineering Technologies companies help themselves”

52

Project Management Morgan W. McCall, Jr., Ph.D. - PM Flaws that Bring Career’s to Screeching Halt: The 10 Killer Flaws: 1. Insensitivity 2. Acting aloof 3. Betraying trusts 4. Overmanaging 5. Being overly ambitious 6. Inability to think long term 7. Inability to adapt to a new manager 8. Overdependency on a mentor 9. Making poor staffing decisions 10. Inability to deal with department's performance problems Project E“helping ngineering Technologies companies help themselves”

53

Contact Information Questions, Comments, Suggestions, or Just Want to Talk:

Project E“hengine ering Associates lping companies help themselves” Deb Jacobs Project Engineering Management Professional Consultant 13410 South 32nd Court Bellevue, NE 68123 402.293.9215

Project E“helping ngineering Technologies companies help themselves”

www.projectengineeringtech.com [email protected]