Factors to project success and failure

I was reading through a few of the reports on the Standish Group website dealing with software engineeiring projects. In particular, I found the research on failures and success in software projects very interesting. Survey participants rated what they thought were factors that would lead to project success and conversely to project failure. These tables are copied from the Standish Group below: 

Project Success Factors

% of Responses

1. User Involvement

15.9%

2. Executive Management Support

13.9%

3. Clear Statement of Requirements

13.0%

4. Proper Planning

9.6%

5. Realistic Expectations

8.2%

6. Smaller Project Milestones

7.7%

7. Competent Staff

7.2%

8. Ownership

5.3%

9. Clear Vision & Objectives

2.9%

10. Hard-Working, Focused Staff

2.4%

Other

13.9%

 

Project Challenged Factors

% of Responses

1. Lack of User Input

12.8%

2. Incomplete Requirements & Specifications

12.3%

3. Changing Requirements & Specifications

11.8%

4. Lack of Executive Support

7.5%

5. Technology Incompetence

7.0%

6. Lack of Resources

6.4%

7. Unrealistic Expectations

5.9%

8. Unclear Objectives

5.3%

9. Unrealistic Time Frames

4.3%

10. New Technology

3.7%

Other

23.0%”

 

What I find interesting from this report is that these factors have all pretty common accross some other things I've been reading Fred Brooks and my software engineeing text (Berstein and Yuhas). This tells me that there really is a basic consensus as to how projects can succeed, and what makes them fail. But, simply reading these lists won’t automatically make a manager or architect capable of avoiding failure. Even though these factors seem pretty obvious, they are still subjective. Terms like unrealistic, lack, changing, incomplete, competent, clear, and focused do not have a precise definition in plain English or in software engineering jargon. I like the Standish Group report’s attempt to use these lists of factors to try to quantify the “Success Potential for Project.” The basic steps that they suggest are: get management support, develop clear and complete requirements, formally define and document the problem statement and plan, get knowledgeable hardworking people on the project, having realistic expectations and milestones, and clearly defined roles and objectives. The rater gets points based on the level to which the project meets each of the items on the extensive checklist, and this is ultimately summed up to a total value, the “Success Potential for Project.” The recurring theme that I’m seeing is that it is really important to try to quantify software projects in terms of cost, schedule, risk, and expectations. There is a basic idea of what factors can contribute to success and failure, and there is pretty good agreement about these factors. We’ve learned a lot of metrics and heuristics that can assist in quantizing the project, but a key factor is still the individuals and the organizations which do the assessments and planning.

Advertisements

4 comments

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s