From time to time, The Standish Group publishes reports about their CHAOS research, which analyzes the factors that drive success and failure in large IT projects. The first CHAOS Report, published in 1994 and now freely available on the Standish Group’s web site, has become famous in the software industry. The report identifies these failure factors:

1. Lack of User Input
2. Incomplete Requirements & Specifications
3. Changing Requirements & Specifications
4. Lack of Executive Support
5. Technology Incompetence
6. Lack of Resources
7. Unrealistic Expectations
8. Unclear Objectives
9. Unrealistic Time Frames
10. New Technology

I’m astounded that this list omits the single most important failure factor. I call this missing, crucial factor The Prime Project Failure Factor.
So important is The Prime Project Failure Factor that if it isn’t present in your project, you can prevent the project from failing even in the presence of all of the other failure factors.

Imagine this scenario. You have been asked to commit to a proposed project. You notice that you have been given unclear objectives, no user input, requirements that are incomplete and unstable, and unrealistic expectations and timeframes. You have no executive support and few resources. You do have some new technology to use, but the few people assigned to the team are technically incompetent to use even the old technology.

This horrifying proposal exhibits all of the Chaos report’s top ten failure factors. The project is clearly doomed to failure, right? Well, no, not quite. No matter how many failure factors a potential project exhibits, you can still prevent failure by choosing not to do the project.

Seems simple enough, and yet I wonder. Think of a failed project in which you took part. Did you really not know at the outset that the project’s objectives were unclear, or that you didn’t have executive support, or that expectations were unrealistic? Did nobody know these things? And did nobody feel in their bones, right from the word go, that these factors doomed the project to failure?

Many “failed” projects fail from the start by ignoring The Prime Project Failure Factor: Choosing to proceed with a doomed project.

The Manifesto for Agile Software Development, also known as “The Agile Manifesto,” says:

We are uncovering better ways of developing software
by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right,
we value the items on the left more.

The key relationship expressed by the repeated word “over” is ranking. We compare pairs of items and rank one higher than the other. The summarizing statement that “we value the items on the left more” goes beyond this ranking and sorts all of the items into two buckets. The items on the left are the primary values of agile software development, and the items on the right are secondary values.

Sorting values is a fundamental way in which a community defines itself. As important as this sorting is, I see an even stronger, richer relationship among these values: secondary values in service to primary values. We value the items on the right to the extent that they serve the items on the left.

For example, we value following a plan to the extent that following the plan serves individuals and interactions, helps the project collaborate with its customers, and helps the project respond to change. In order for us to value following a plan, we first want to see how it serves either our identified primary values or some deeper, more fundamental values that transcend The Agile Manifesto.

Trouble starts when projects treat the secondary values of documentation, contracts, processes and tools, and following plans not merely as potential means to achieving deeper values, but as ends in themselves.

As I was reading Robert C. Solomon and Fernando Flores’s book
Building Trust
today, I created this thought experiment about trust, disappointment and choice.

Part One: Imagine a relationship in which you trust the other person in many, many ways, and the person always fulfills your trust. Whatever trust you give, the person never disappoints your trust. What thoughts do you have about this relationship? What feelings?

Now set those thoughts and feelings aside.

Part Two: Imagine a relationship in which you choose to trust the other person only when you see no possibility that the person will disappoint your trust. Whenever you see the slightest possibility of disappointment, you choose to withhold your trust. What thoughts do you have about this relationship? What feelings?

Part Three: Now compare your thoughts and feelings about these two imaginary relationships. Compare these imagined relationships to your real-life relationships. What do your comparisons tell you about trust? What does the possibility of disappointment have to do with trust? What does choice have to do with trust?

I’d love to hear your comments about this.