For the sceptics, it's worth noting that an IAG Consulting report by Keith Ellis found that more than 70% of companies in the top one-third of requirements discovery capability reported a successful project. 54% of their projects are on time, within budget, and deliver all requisite functionality. And - here's the kicker - as a group those companies pay about 50% less for their applications.

What's a successful project? One that is on time, within budget, and delivers all requisite functionality.

By contrast, the main culprit in failed projects is poor requirements discovery.

Companies with a poor requirements discovery competency take 39% longer and spend 49% more to deliver their projects. Nearly 80% of their projects were over budget and time, and a whopping 50% were runaway projects. (Runaway projects are those that go 180% over time, 160% over budget, and deliver less than 70% of functionality. )

And why does poor requirements discovery continue to thrive? Because of template zombies.

There are three components to competent requirements discovery: planning, people and process, all inter-related and not separate.

But a lot of companies replace planning and process with templates. At first glance it seems to make sense: you obtain a standardised approach, right? Well, yes. But the result is also a sub-standard, outcome. And that's normally due to the notorious, even infamous business requirements specification (BRS), functional requirements specification (FRS), requirements specification document (RSD) or one of the many other TLA terms camouflaging corporate bureaucratic mediocrity.

Perhaps that's a little harsh, but if these documents had a decent structure they may not be so bad. However, as it is they mix business requirements with solution requirements and design - that's a recipe for disaster.

In fact, typical planning in organizations that rely on these camouflaging real analyst practices (CRAP) documents consists of the analyst asking: "So, how do I fill in these blanks as quickly as possible?"

It's that kind of approach that sets companies up to snatch defeat from the jaws of victory. As Albert Einstein so famously said: "Insanity: doing the same thing over and over again and expecting different results."

But so what if a project takes a little longer or costs a little more? Well, it costs 15 times the amount to fix a defect during the user acceptance stage and nearly 18 times as much to fix it after go-live as opposed to getting it right during the requirements stage, according to research by the National Institute for Standards and Technology in the US. And if this happens in your organization, it will continue to happen until you get the right people, following the right processes, and performing proper planning. Why pay more for less?

And why allow template zombies to continue shuffling around threatening the living?

Don't forget to leave your comments below.

Robin Grace is a Business Analyst Principal Consultant at IndigoCube