Article Menu

Tuesday, 05 April 2011 10:31

It’s Time for Template Zombies to Die

Written by 
Rate this item
(0 votes)

Feature_April5Zombies, 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, 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 also 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. 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

 

Read 7317 times Last modified on Tuesday, 27 March 2012 13:46
Published in Articles
Robin Grace

Latest from Robin Grace

More in this category: « How to Impress Executives with Your Presentations The Business Analyst – A Leader Without the Title! »

Comments  

 
0 # subat 2011-04-05 05:34
Great article, but I'd like to see some ideas for solutions.
Reply | Reply with quote | Quote
 
 
0 # justin roebuck 2011-04-05 05:34
If no templates then what do you document the requirements and ancillary documentation with? I agree that sometimes templates are not the proficient thing to do but hwo do you either compliment or replace...great topic!!
Reply | Reply with quote | Quote
 
 
0 # Morgan Lee 2011-04-05 05:39
Great title. I also like the part about "So, how do I fill in these blanks as quickly as possible?". This is so true. I am working on a project where a client has to complete over 300 documetes based on a one size fits all template. We get a lot of N/A or blank sections. So how do we kill the template zombie? What will take their place? And please don't say template vampires :)
Reply | Reply with quote | Quote
 
 
0 # Michael 2011-04-05 05:44
Interesting article - you may want to give credit to Tom Demarco who coined the phrase Template Zombies with his colleagues in the book 'Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior - (Mar. 3, 2008)' I'd be a little bit cautious with linking maturity models and template zombies. The requirements maturity model rates an organization more favorably when they have a repeatable consistent approach to requirements definition; absence of a template is seen as a negative. A level 3 organization has defined checklists, prescribed layouts, and exemplars. Organizations as they grow need to have people march to the same drumbeat. Those organizations that Keith and you deem to be the role model likely have a template structure which forms a terrific breeding ground for zombies. The danger is when you stop maturing and see everything in terms of paint-by-number s which I think is where you are going with the template zombies thrust.
Reply | Reply with quote | Quote
 
 
0 # Ryan Goodale 2011-04-05 05:48
I agree that you can't replace templates with process; however, you need both. Templates make sure things are documented consistently. For example, if an organization does not have a template and process for documenting business processes then you will have people throughout the organization documenting their processes differently.
Reply | Reply with quote | Quote
 
 
0 # Jason Swetland 2011-04-05 05:49
Like so many other tools the problem isn't the template, imo, its the user of the template and a lack of creativity and- get this- critical thinking. The template should be utilized as the starting point; because the non-project person at the organization will be familiar with the overall structure and will be able to follow the modified documents overall structure and get the point of the document. A good analyst will take the template, and modify it both for the business requirement and appropriate audience. If the BA or PM is simply filling in a form, and not applying their skills and knowledge to make it fit the project then any monkey can do the job. I think it is more important to ask yourself if you are filling out a form or are you using your critical analysis skills to create a document that explains to the audience what they are viewing and how it applies as a solution to the problem at hand. The analogy of a zombie is on target when considering the use of this starting point because these staff members arent using their brain. However there is an important advantage to starting with a document that is recognizable to staff who may not comprehend what they are looking at if it doesnt conform to a uniform appearance standard. That doesnt mean the document cant be fleshed out to do a better job. Don't blame the tool, blame the wordsmith!
Reply | Reply with quote | Quote
 
 
0 # Cameron Watson 2011-04-05 06:55
Interesting article - I'm still a tad on the confused side. On the one hand there is a recognition that requirements should be clear, concise and well defined - the metrics provided in the article substantiate this premise. On the other hand, there is a broad brushed unqualified criticism leveled at any type of vehicle or mechanism intended to contribute to the defining of requirements - the implication suggesting they (templates) are of little value and used only by those with little or no brains (template zombies I believe is the term). The idea that wishful thinking could somehow morph itself into having all templates become the be all and end all to slay the beast of "organizational mediocrity" appears to overlook the harsh reality that has come to be known and accepted as standard operating procedure. I recognize I may be getting long in the tooth and my eyes not as good as they once were. The black and white or yesteryear all seems to blur into a calming hue of gray - I guess the requirements have changed before my eyes and I didn't have the template to properly document them. Thanks. Cameron Watson I
Reply | Reply with quote | Quote
 
 
0 # Kris M. 2011-04-05 07:51
I absolutely agree with Jason S. Don't blame the template - they are useful tools and provide a good starting point and common ground for project documentation. Blame the analyst who hasn't done the proper analysis. I get the"zombie" part. If I want someone that just takes dictation from the business units or the developers, and not apply any critical thinking or real analysis to the problem or project, and someone who just just mindlessly fills out the templates, then I'll hire a secretary or tech writer (and at less salary). A good analyst, with decent critical thinking, problem analysis, and communication skills, and who knows the audience of the template, will know when to stray from, or add to, a template. They should also know when to create a different document entirely, if necessary, or even be able to argue when a specific document isn't needed at all. Just as important is that management should also know that not all projects require all the same documents, and should allow for that in their processes. And if management finds that the templates are having to be regurlarly modified, or a lot of "N/As" put in, then they need to rethink their templates.
Reply | Reply with quote | Quote
 
 
0 # Bennett 2011-04-05 08:22
Templates are meant to be starting points. If overly elaborate, they then become the focus and assume a greater chance of failure due to the form-filling mentality. Ultimately people have to think about the objectives to be accomplished, rather than filling the form and thinking they're done.
Reply | Reply with quote | Quote
 
 
0 # Peter Lefterov 2011-04-05 08:59
Great article. As for the usefulness of templates... it may not be a politically correct comment but there's a reason it's plan, people, process and not plan, people, process and template. :) Template-dri ven process may be better than no process at all but in the long term the lacking process is easier to notice and correct while the template-driven one can endure for decades before someone questions the content of the template.
Reply | Reply with quote | Quote
 
 
0 # steve 2011-04-05 09:07
I agree that projects should use the same format (template) to prepare all documents for that project therefore having a common look and feel but my concern is having tempates that management wont allow to be modified by project. The same template format doesn't fit every situation e.g. what might work for a really big project doesnt necessarily work for M&E.
Reply | Reply with quote | Quote
 
 
0 # Brandon Soler 2011-04-05 09:45
I'm really only reiterating some earlier comments here, but I agree that a document template is necessary for uniformity and also the 'starting point' that others have mentioned. The requirements and functional spec documents are to be presented to people so that they gain an understanding of the present situation, actual requirements and suggested solution/s. It makes much more sense that these documents are presented in a format that is familiar; it makes your analysis flow in a manner that your audience is used to seeing - particularly in the case of large organisations. The fact that the template should be modified so that it is fit for purpose to me is a no-brainer. I would also like to reiterate another earlier comment that being an analyst writing an article like this, if you are going to 'poo-poo' an existing methodology, then following up with a suggested approach lends a lot more weight to your argument. This article smacks of personal frustration and lashing out, rather than a studied observation and constructive criticism. Bra ndon.
Reply | Reply with quote | Quote
 
 
0 # Chris Stobie 2011-04-05 10:17
I HATE template zombies. I've almost been consumed on many occasions. That's the thing, you don't necessarily see them coming until the same old rotting wordsmithed 'requirements' are still there 6 months after everyone should have moved on and you wonder....why?
Reply | Reply with quote | Quote
 
 
0 # Brian Logan 2011-04-05 10:47
I like to use templates as guidelines. As guidelines one needs to know enough about the rules to know when to break them. Unfortunately some people use them as a one-size-fits-a ll, even when, as BAs, we know that we need to craft our messages differently depending on the audience. Mandating unchanging templates indicates an attempt at solving a problem without understanding the underlying problem. (Maybe they need a BA to investigate the BA practices.) Template consistency also works for stakeholders. They learn where to expect information in the document, simplifying their comprehension of the content. These stakeholders are not concerned with the absence of irrelevant information removed from the document.
Reply | Reply with quote | Quote
 
 
0 # Cecilie Hoffman 2011-04-05 12:10
Grace, you write a good rant. I was hoping for a little more substance. In a previous life I had the task of creating and maintain the requirements templates for an IT organization that had strong governance oversight in the form of Sarbanes Oxley, and a difficult contracts management relationship with the third party outsourced development team. The templates were a bureaucratic nightmare for everyone - there is no denying that. My perspective was that the templates were just framework, a table of contents for what was expected by the reviewers. The templates provided reference points to help the BA achieve consistency with the needs of governance. The art and skill of the business analyst was not stifled by the template; the larger business processes around the templates was what stifled the business analysis work and made the BAs feel like zombies.
Reply | Reply with quote | Quote
 
 
0 # Judy K 2011-04-05 16:43
I agree with Kris M. "Management should also know that not all projects require all the same documents, and should allow for that in their processes" - this is a common downfall of organisations. Good BA's are supposed to know what tool, process and method of documentation to use for each project to best communicate the requirements. However, too often the organisations try to enforce the use of a one-size-fits-a ll template for all projects, which only results in some of the requirements being left out or not communicated as clearly as they should be.
Reply | Reply with quote | Quote
 
 
0 # Steve Riley 2011-04-05 17:47
Great article which I admit had me waiting for 'and so the answer is....' I was a little disappointed until I realised I already knew the answer. At one end of the process we have either a physical or implied 'list' of things to discover and at the other a template to capture the detail in a logical and understood format (level 3 thinking) The magic of the analyst and the value add is in the INTERPRETATION in the middle - there is no place for mindless Template Zombies
Reply | Reply with quote | Quote
 
 
0 # Charlene Mendes 2011-04-05 18:29
Agree with Steve Riley. Use a template or don't... As long as your document follows a logic, includes all the requirements and is easy to understand by all stakeholders. I use my own template because it helps guide my thinking to ensure I have considered all aspects, but the beauty of a template is that you can change it to suit each projects' needs. At the end of the day,however, it is only guideline and should be used as just that...
Reply | Reply with quote | Quote
 
 
0 # Chris DeTurk 2011-04-05 23:04
A template zombie situation arises from these conditions: -t he template is of marginal quality, usually put together by non-experts -st rict compliance to this marginal quality template is mandated by process An organization finds itself in this situation when the oversight of the requirements function is lacking in talent. Managers who do not understand the requirements discipline, or lack the insight to measure its success by true business results, retreat into a template zombie situation. While effectiveness is not achieved, at least uniformity is achieved. This provides a veneer of order, which is a “good enough” substitute for business results. Staff your leadership roles with experts in the field, lest your requirements practitioners need to add the undead to the list of obstacles they face in getting value out the door.
Reply | Reply with quote | Quote
 
 
0 # Bala Lodese 2011-04-05 23:19
the part that impressed me , " as it is they mix business requirements with solution requirements and design - that's a recipe for disaster". Most Organization knows that a Business requirements should come before Solution Design but, they ignore and expect Business Analyst to write Business requirements based on Solution Design. Often Business Analyst report to Technical people and It is disgusting when all the work session drill down to Technical specifications. This leads to everyone thinking that they have discussed everything they have to and wonder what to do when you actually schedule design meetings.
Reply | Reply with quote | Quote
 
 
0 # Maribeth 2011-04-06 03:18
This sentence spoke the loudest to me: However, as it is they mix business requirements with solution requirements and design - that's a recipe for disaster. YES!! In my most recent role, it was as if the development team took the high level requirements, did the design on the fly, and began development, with no planning, no business analysis - Thanks for the article - but I agree with the first comment - if we toss out the templates, what is our alternative? And how to keep the development team 'at bay' until the design is completed?
Reply | Reply with quote | Quote
 
 
0 # Tim P 2011-04-06 07:48
We've been going through this same thought process, and we're trying to move away from templates. My thoughts are that templates are good for styles, or even high level sections, but templates with two, three or even more levels of headings... well, you may as well just fill in a form. And I think that's the point of the article. We need repeatable processes, not forms to fill in. If we repeat the same good process, we will get the same good results. And the process needs to offer flexibility, to cover different needs, different options, different paths we may take - a template can't do that. We don't need a template, we just need a well defined process. (And making the document looks consistent could even be part of the process.) Take UML or BPMN - it's not a template, it's a set of mini-templates (e.g. what a decision looks like) and a framework for how it all fits together. So do that, define what a use case should look like, what information it needs to contain, who informs the use case, what section of the document it should go in, etc. etc. The aim is to make sure we get the right information, with the right level of detail, in the right format. So my group is working towards a framework - we're not allowed to say template any more!
Reply | Reply with quote | Quote
 
 
0 # Robin Grace 2011-04-06 20:49
Thanks for all you comments. I wrote the article, not so much against template, but rather against the woeful use of them by some analysts. The template must not be used to replace the brain. Thanks Michael for giving Tom Demarco the credit due for the term Template Zombie. He has always been up there in my list of top authors. Many of you are asking how do you kill off the Template Zombies or how we solve the problem of the brain-dead application of a one-size-fits all mentality? There is an approach which can do this (with the help of Liquorish Allsorts) and I’ll cover it in a future article, editor willing.
Reply | Reply with quote | Quote
 
 
0 # Arnel Capiral 2011-04-07 08:18
Great article specially the part where "mix business requirements with solution requirements and design - that's a recipe for disaster." I totally agree in segregating the business need, the solution and design to the solution. However, in the absence of a standardized template (which if I may suggest needs to be used as a "guideline") what solution would you suggest?
Reply | Reply with quote | Quote
 
 
0 # Hashim Rasheed 2011-04-07 17:54
totally agree with the idea. I spend a lot of time making documents according to the approved templates and then the QA department tells me that it has to be done over. it takes about 3-4 iterations before it is finally accepted. what a waste of time, since these documents are not even submitted to the client.
Reply | Reply with quote | Quote
 
 
0 # Z 2011-04-08 21:50
SUCH A GREAT ARTICLE! I am going to forward this to all the BAs in my team...in fact all the BAs who work in my company. NO MORE RETARDED LAZY TEMPLATE ZOMBIES!!
Reply | Reply with quote | Quote
 
 
0 # Katie Metcalfe 2011-04-09 10:22
Great article and a topic that is really relevant to BA work. I agree templates should not replace thinking. Templates are an adjunct to diagrams, models and thinking. They should not act as a constraint to requirements either. And when the template is complete, requirements aren't necessarily complete. BA need to think outside the template. I recall using templates (from the RUP process) when I was a new BA and found that I learned a lot from them. So I believe they can have use in educating a new BA. Templates can help in determining and developing a good requirements structure. Perhaps eliciting requirements without the template in hand can help BA's think outside it.
Reply | Reply with quote | Quote
 
 
0 # Tim Chandler 2011-04-12 05:54
Jason S. has it right - don't get lazy simply because you can generate the requirements "by the pound". It is a starting point and templates can be effective in ensuring everything is documented every time. Remember, somebody has to use these to build a system - you need to keep that in mind as you gather requirements. Y ou could also extend this to general project management or architecture. How many times have you been strangled by the need to fill in templates - for no apparent reason - but by doing some critical thinking and not turning off your brain - they can be effective as vehicles for documentation and a good starting point. I suspect that the "right" answer for organisations and the use of templates is somewhere in the middle between the organziation/pr oject and the need for boundaries. IM HO
Reply | Reply with quote | Quote
 
 
0 # Jason Martin 2011-04-12 23:29
Great article and I love the plain English style. One key point is the mixing of requirements with solutions. The two are difficult to mix in one document. As DeMarco pointed out so well in him 1979 text, Structured Analysis and System Specification, the analysis process must address the requirements (logical) separately from the solution (physical). Basic modeling techniques can be applied to specifying each perspective separately and carefully choosing options for the new implementation. As it has been for years, you just need to do complete analysis and design and resist the temptation to jump into code too early. Bad code in a modern language is still bad code.
Reply | Reply with quote | Quote
 
 
0 # Steve Pelikan 2011-04-13 05:01
Templates can certainly have a place in requirement documentation, particularly in organizations with immature processes. If you can implement a repeatable (read: documented) process with even just a 60-70% success rate, then that is far more effective than organizations that are "making it up as they go." Templates can introduce and reinforce the logical steps of business needs/goals, then design, THEN development. A nd as the organization and processes mature, you can evolve/phase out the templates as needed. That evolution can mitigate the risk of the org stagnating at the "we have templates and a 65% success rate" level.
Reply | Reply with quote | Quote
 
 
0 # Chris 2011-04-15 05:49
I think templates will always have a place in requirements documentation. This article is a nice complement to what we are talking about here: Are your requirements documents worth the drive space they take up? http://www.bridging-the-gap.com/are-your-requirements-documents-worth-the-drive-space/
Reply | Reply with quote | Quote
 
 
0 # BLemieux 2011-04-26 23:39
Every client environment is different.If I use templates I use them as an "idea" or "guide" to develop the document/templa te that I need for a specific project or program. I had greater successs finding and determining requirements by sitting down with the client one-on-one or in a small group setting and developing "templates" according to the initially defined requirements. I like to put my own "flavour" into my work.
Reply | Reply with quote | Quote
 
 
0 # Gottlieb Wilken 2011-06-07 19:38
Good article, pointing out what is happening in the industry today. I think a lot of Zombies do not understand their responsibility towards a project. I would like to add that a lot of these project are ran with project manager not understanding why there is a BA on the project in the first place. So the pressure is on the BA to deliver, and what is the deliverable? The completed template is what the BA has to show for having the work done. Delivering on this “means” he/she did the work on time and in budget. There is a lot more behind this problem, and the solution in my opinion is education; of the Business Analyst and the Project Team.
Reply | Reply with quote | Quote
 

Add comment

back to top