The reason many projects fail is quite simple. People are all too human. And people become immersed in rhetoric; rhetoric that may have no real substance and definition behind it. Project goals may sound good, but cannot always be easily defined, or sometimes cannot be defined at all. A good symptom of such an intangible circumstance may be apparent when many buzzwords are being offered in place of concrete definition.
Programming is a literal sport. Code does exactly what it is configured to do, no compromises. When the definition of a task is fuzzy, it is up to the developer to do what they believe is correct. Does the code reflect what is desired? That answer is left open to interpretation. Sadly, developers may not have a clear understanding, and even the users requesting the solution may not be sure. The results can be very painful for an organization. Expectations may not align with the delivered solutions. Users will blame IT; IT will blame users.
The word “literal” itself is open to interpretation. To narrow the literal field for our purposes, literalness means that each command or function does exactly what it was created to do. Fortunately, while a developer may not be able to fully explain that function to others, developers know that each command does what the command does because they watch it do what it does over and over again during every coding task. Add, multiply, concatenate, move, substring and so on and so forth. Each command works without variation. People are not runtime compilers, and how they respond, even to the exact same commands will vary based on any one of a number of factors or contexts.
How a business person may attempt to explain a desired function, task, or endeavor can be all over the map between clear and crazy. And, if answers vary each time the same question is asked, things become a sea of troubles. The unclear, the fuzzy, the imprecise must eventually be forced into concrete terms. Terms that are actionable, terms that are agreed to by all. Leading business users to this level of precision is very hard, but necessary in order to improve the odds for success.
People often get confused. When people see clarity in a specific screen or report they often assume that it means there is clarity everywhere, clear conversations, clear documentation, etc.
There was an organization that was audited and confirmed as CMM Level 3 compliant. They documented everything, but the documentation was largely boiler-plated gibberish. When developers were queried about how they could possibly code from the documentation, they explained that they didn’t. Developers simply coded what they thought was needed based on what was heard at meetings. Another organization felt burned by IT in the past. Projects would fail, and IT would point the finger at business. This business was so afraid of not getting what they wanted and being accused to be at fault, they truly believed that very soft-focus definitions were the answer. They truly believed they could just say, “And anything else,” as part of the requirements and that ambiguous reference would magically make it so within the built solution (or at least it would make the miss the developers fault and not theirs.)
Agile methods help when they are successful in bringing the business into close partnership in both defining and building solutions. All approaches related to expanding and increasing communication between users/subject-matter-experts and development teams are good. Organizations that operate from a perspective of only being involved in IT solutions a little bit in the beginning to define-things-and-then-get-back-to-their-real-work are largely doomed to disappointment.
The real question may not be, “Why have so many projects failed?” but, “Why have so many projects actually succeeded?”