Zombies, dead and mindless creatures that shuffle about sucking out the brains of the living, have invaded your office.
It`s time to exterminate the zombies from your office.
Template zombies, while not necessarily the most dangerous kind, since they don`t suck actual human brains but instead suck the brains out of projects on the boil, must die, because they are one of the biggest factors in ruined projects. And this isn`t happening in Los Angeles or New York, as Hollywood`s movies may suggest - it`s happening right here in South Africa. The undead, or in this case the brain dead, are among us.
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. Fifty-four percent 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-standardoutcome. 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, and that`s a recipe for disaster.
In fact, typical planning in organisations 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 the cost 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 organisation, it will carry on happening 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?
Share