Project failure is due to bad requirements

Projects can fail for a number of reasons, but at the root of most failures is a failure to gather correct and consistent requirements.  We've all laughed at some variant of the above diagram, but these issues are all because:

• We fail to capture correct and consistent requirements
• We play "broken telephone" when we are communicating requirements

Let's take a concrete example.  Suppose we have an orienteering challenge where you need to go from the start point below to the finish point, this is the actual requirement.  

But, there is a gap between what the actual requirements are and what is actually written down.

Good Requirements

As long as the written requirements don't diverge too much from the actual requirements, you will have time to adjust the requirements during project execution and still get to the finish point.  

So as long as the initial written requirements are in the green zone, you can still complete the project on time because the requirements point you in the correct direction.

Mediocre Requirements

Now suppose one of the following happen:

• You don't have all the core requirements because insufficient people were consulted
• You have conflicting requirements from different sources

When you have less than accurate requirements you will be in trouble.  The initial code and architecture of the project will be created based on the quality of the requirements.  If those requirements are suspect, then there will be rework as code needs to be adjusted as the scope of the project seems to shift.

So now you will find yourself in one of the yellow zones below

Even with the best execution, the project will be challenged.  Deadlines will be missed as you attempt to bring the requirements back to what they need to be.  This is like trying to change a tire on a car and discovering the jack is missing.

It is important to realize that adjusting poor requirements is not Scope Creep.  Fixing incorrect and inconsistent requirements is necessary and it is pointless for a project manager or executive to disallow these changes.  It would be worthwhile for project postmortems if the project manager tracked whether a requirement was missing or inconsistent.

Challenged projects are typically declared as successes, but only after massive compromises, burned out resources, damage to reputations, and loss of revenue.  When all the damage is taken into account, this is hardly a victory.

Bad Requirements

The last situation occurs where you only have vague requirements before you start a project.  This situation happens where the executives need a project done quickly and over-estimate the teams familiarity with the subject domain.

These projects start with requirements in the red zone below.  You don't have a prayer of completing this project and it will turn into a Death March with all of its characteristics (see Death March Calculus).

Making core course corrections to bad requirements are like trying to change a tire on a car when you are going down the highway at 100 mph.  It won't happen.

Conclusion

It is human nature to assume that the sooner you start a project that the sooner you will finish.   That assumption is only correct if you have good requirements to point you in the correct direction.  Good requirements are consistent and correct and include at a minimum the core requirements for the primary users.

Starting a project with mediocre or poor requirements is simply a recipe for project failure.  Mediocre or poor requirements are incomplete and inconsistent.

If you have been part of a project failure then you will discover that despite the other factors that went wrong, requirements failure was at the root of it.

Specifically, what is complexity?

People involved in software projects would say that software development is about understanding complexity.

What is complexity?

What can we do about it?

Complexity is easy to define at a high level, but people get vague when pressed for a precise definition.  Let's see if we can:

• quantify the problem
• define it
• suggest how to address it

Assume we need to develop a project of 50,000 lines of code ¹ , this project would take 5,000 man days to develop (scenario A) assuming 10 production lines of code per day ². Even if we are generous and assume 50 production lines of code per day per developer, the project would still take 1,000 man days to develop.

Now take that developed code and have a single developer re-enter it (scenario B). The developer is likely to be able to code at least 1,000 lines of code per day and it would only take about 50 man days to enter the entire program.

The difference between scenario A and scenario B is 950 days to create the same software system. So what are we doing in the other 950 days if it only takes 50 days to write the code?

95% of a project is about solving problems, not writing code

In scenario A we don't know which lines of code to write, time is expended in figuring out:

• determining what the actual requirements are
• translating the requirements into high level design
• designing an architecture sufficient to support the requirements
• translating the high level design into programming languages / libraries
• discovering where the code defects are
• rewriting code for incorrect functionality

While it might seem startling that 95% of our time is spend figuring out which lines of code to write, a little reflection will convince us that this is the case.  We mistakenly believe that projects fail because there is not enough time to write the code, but really, the problem is that we don't know what lines of code to write.

Projects do not fail because their is insufficient time to write code

When you see developers furiously coding at their desks, they are spending most of their time thinking.

Most developers are unable to sit and plan away from the computer, so when you see them at their keyboards they are primarily thinking. They will write and rewrite sections of code as they think through the problems (see Not Planning is for Losers).

Where does Complexity Come From?

Now that we have quantified how much time is spent solving complexity, where does it come from?

Complexity comes from team resources not understanding how to solve the problems they face. When confronted with a problem the team must think about how to solve it.

Each problem is like figuring out a path in a maze, it takes time to solve it initially.  Once you have solved the problem, it is easy to avoid all the dead ends and go straight to a solution.

We spend 95% of our time considering alternatives and hitting dead ends.

Complexity is not a issue if enough time has been budgeted in the project for the team to think things through. Complexity is a problem when you need to think through issues and insufficient time is budgeted.

Projects run late mainly because of two reasons:

1. Insufficient time
• You did not use formal estimation techniques and underestimate the project
• You use formal estimates and executives push for a delivery date independent of the problems to be solved in the project
2. Insufficient requirements
• You estimated sufficient time for your team's skill level to solve the problems but you did not have all the requirements

Insufficient time

It is pretty clear why insufficient time causes projects to fail, but here are some specific statistics.  Often executives reject formal estimates and then push for project deadlines independent of the work to be done (see Why Senior Management Declared Deadlines lead to Disaster)

Rejection of estimates for business reasons lead to productivity down 15% and quality down 21% 

Excessive schedule pressure leads to productivity down 16% and quality down 23% 

Insufficient Requirements

The second situation happens when you underestimate requirement complexity.  On a regular basis projects are launched where only a fraction of the requirements are gathered.  Once the project starts there is a mad dash to capture the missing requirements, i.e scope creep (see Shift Happens). 

Project plans are often based on the initial set of requirements and the project deadline is not adjusted when you discover that there are missing requirements.

Failure to estimate requirement changes to schedule lead to productivity down 16% and quality down 22% 

Why We Underestimate Requirement Complexity

Human beings are wired to underestimate complexity.  For example, suppose that a customer says that they want a car, we all know what a car is, correct?  Executives often talk in such generalities when they don't understand why the estimates are high.

Look at the following cars:

Clearly these cars are not the same, and the cost and time required to build them is not the same. Abstractly, we all understand what a car is and we can discuss this in general.  But when we start drilling into the details, there are many questions to be answered, such as:

• How fast does the car need to go?
• How many people does it need to seat?
• What kind of fuel economy do you want?
• What safety features are required?
• How sophisticated do the controls need to be?

In the rush to get projects started, we skimp on the requirements process and many questions are not answered.  But at some point the developers need that information so that they can solve their problems and the requirements need to be gathered.  Quite often projects run out of time simply because they never budgeted time to gather enough requirements.

Skill and Complexity

There is a clear trade off between the time required to solve a complex problem and the skill level of the team.  A problem is complex when you have never seen it before, but once you have solved it, then you always see the solution.

Just like the maze shown here, the first time might take a fair amount of time to figure out the solution.  If you have to solve the problem again then you will go directly to the solution without dead ends.

When gathering requirements, the better the analyst understands the domain, the less likely they are to miss requirements or have inconsistent requirements.  This eliminates the likelihood of inconsistent requirements and increases the probability that enough requirements are captured to start the project.  

When developers have experience with the domain then they take much less time to break the requirements into high level designs.  When they have experience with the language being used and the libraries they can translate that high level design into a low level design and code much quicker.


Solving Complexity

So successful software projects recognize that complexity amounts to the thinking time required for the team to figure out problems they have not solved before.

The more experienced a resource, the less time they need to think about the final solution.  The less experienced resources need more time to think through problems, especially when they hit dead ends.

• For the business analysts and product managers
• This is about understanding the subject matter and making sure to gather enough consistent requirements
• For the developers 
• This is about understanding the subject matter for high level design, and understanding the language and libraries for implementation
• For the project managers 
• This is about understanding how capable the team is and making sure that sufficient time is budgeted for them to solve all problems
• For the IT executives 
• This is about understanding that any given project team needs sufficient time to solve problems and not caving into executive pressure to arbitrarily shorten projects

References

• Jones, Capers.SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.

---

¹ Lines of code is a terrible metric and is only used here to illustrate a point about complexity. Software measurement should use function points or another relevant metric.

² Brooks, Frederick Phillips. “The Mythic Man Month”, 1995. ISBN 0-201-00650-2