Skip to main content

Author: Robin Grace

How To Squash The Template Zombie Problem

Sept6FEATUREWestern culture worships the massacre of zombies by the dozen in movies, books, and music. Wherever we encounter zombies, whether it’s in the garden shed, the attic, the mall, or even the local if your name’s Shaun, we are taught to mow them down with whatever’s at hand.

We have only recently discovered that there are different types of zombies, and one type has invaded your office: the template zombie. There isn’t any need to panic but there’s cause for mild alarm and you should kill them. But in the nicest possible way, by feeding them sweeties.

Template zombies are BAs who just fill in the template blanks. When they’re asked to assist on a project, they immediately reach for the templates they’ve been given, fill in all the blanks and then send them on to the developers. And, let’s face it, that’s a lot of documentation to wade through and we all know developers bin the bulk of it, use a small section to write the programs and everyone’s happy. Or are they?

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

You see, grabbing for templates and filling in blanks is akin to BAs reaching for a bag of liquorice allsorts. There’s no control over what’s in the bag, they simply get the whole package whether they like it or not.

In doing so, there’s little, if any, thought given to what the business is actually looking for. The Dryfus model (used in the IIBA Competency Model Version 3.0) for skills acquisition defines a novice as “someone who rigidly adheres to taught rules or plans and is unable to use discretionary judgement.” The template zombie has never been allowed to develop beyond being a novice, no matter how long they have been doing the job, and it’s no wonder their brain dies after a while. That’s a poor approach since the BA has a role to play in achieving a desired business outcome. If it’s properly done, the business gets a working process, be it manual or automated, but if it’s improperly executed the business gets a lame duck.

In fact, the duck can be so lame that the business has late projects, projects that cost significantly more than they were supposed to, and processes, automated or manual, that don’t meet the requirements. More specifically, developers end up with reams of documentation they don’t need that require effort and expense to create, and they ignore most of it. Poor business analysis also negatively impacts stakeholder input and user acceptance.


Bullet to the brain

So now you know how to spot the zombies: they’re the mindless template devotees. What you must now do is rob the zombies of their sustenance and turn them back into effective BAs. How? Steal their liquorice allsorts and give them pick ’n mix. Pick ’n mix allows people to choose precisely what they want; it’s the ultimate in sweet flexibility because you get a bag and then you browse the seemingly endless options, placing the type and number of confectionery delights in it that you want. It gives a much wider selection than liquorice allsorts because the latter’s a predetermined bag of goodies, while the former is an endless sea of choice that lets wave after wave of sweetie, lolly and candy choice wash over you. Again, it’s effective and that’s our watchword in taking down the zombie menace one toe-scraping carcass at a time.

Template zombies like the liquorice allsorts approach because they get the bag, eat the sweets, repeating ad infinitum. But you have to shake them up, make them think. Of course, in doing so, you need to remember that you’re dealing with zombies here and even the most docile template zombie can be dangerous. Don’t give them free rein with the pick ’n mix bag of sweeties or they’ll likely shuffle along the shelves grabbing all their favourite goodies and leaving everything else. You need to point them to the right shelves and only then release them.

Frame the zombie

While it may be ideal to leave BAs to decide what sweets they want from the entire sweet store, only the most senior BAs are capable of doing that within the greater business context, which is the task of what the Dryfus model defines as an expert. Template zombies aren’t the senior BAs. They’re the other BAs. What template zombies need is a framework to guide them through the process.

The business analysis framework must deliver value to the business, otherwise why are we doing the project? And it implies a problem scope. Not necessarily problem in the standard sense—think of it more in the mathematical sense as a problem for which there is a solution. Once we figure out what the solution is, we need to figure out how we are going to deliver it. Think of it as three layers of a pyramid: at the top we ask a) why are we doing this project, followed by b) what do we need to do, and finally c) how do we deliver the solution?

When we ask why we are investigating the business objectives or goals, when we ask what we are eliciting the business requirements, and when we ask how we’re looking into the functional and non-functional requirements. 

Another way of looking at it is when we ask why we are seeking the value of the project, when we ask what we are investigating the entities, processes and business rules, and when we ask how we are looking at the required solution functionality. The framework gives us a matrix of objectives on one axis, and tasks or techniques on another, all culminating in outcomes and deliverables. It’s that matrix that arms BAs to choose which techniques are best suited to their projects. All BAs are armed with a bag of sweeties they can dip into, containing practices and disciplines such as planning, business case, business requirements, functional requirements, non-functional requirements, transitional requirements, solution validation, elicitation, and requirements communication. Within each of those portions of the matrix are tools that BAs can use to help them achieve their goal and that’s their pick ’n mix. They’re given the matrix, the framework, but they get to choose within the framework because that’s where they’re the domain experts. For example, they may choose more common tools such as process analysis, ERD, use case and others. But there are several methods of analysis, such as PESTLE, heptalysis (which is not a gum disease), MOST, SWOT, CATWOE (which is not a sad cat), De Bono’s Six Thinking Hats, Five Whys, MoSCoW, and others in their bag of sweets.

Powwow

But what are they looking for in selecting these techniques or sweeties? Some time ago I attended a presentation by Scott Ambler, who is an Agile guru. Often at a conference or industry powwow, there’s a pearl of wisdom that leaps out and sticks in your brain. For me it was, “We need repeatable results, not repeatable processes.” Pick the right tool for the job.

It requires some thought from BAs in the context of the business while considering the numerous techniques available before ensuring a suitable match. Handing BAs a bag of liquorice allsorts in which they’ll find a predetermined collection of techniques that they must follow because “that’s the way we’ve always done it” doesn’t cut it—that is just a repeatable process. You need to appropriately select the techniques that will most effectively deliver against the requirements in the context of the business objectives for repeatable results.

Don’t forget to leave your comments below.


Robin Grace is a Business Analyst Principal Consultant at IndigoCube.


A Dressing Down for Business Analysts

FEATUREJuly11BA: “They didn’t participate in my workshop. Again.”

Mentor: “You must be mortified.”

BA: “Seriously, they come up with these lame excuses: they don’t understand that computer stuff, they’re too busy, or they think it’s a waste of time. One even told me to just get it done and let him have a look when I’m finished. How must I fathom the requirements myself? And they call that idiot a professional.”

Mentor: “You sound like a stuck record. Every other week you stomp in here ranting about the users, the stakeholders, the so-called professionals who waste your time. You always blame everybody else.”

BA: “So now it’s my fault?”

Mentor: “When I was a green analyst I had the same problem. You know what I did?”

BA: “Hired Chuck Norris?”

Mentor: “I went back to basics – I started planning properly.”

BA: “Planning? First it’s my fault and now I did not plan! Well I did plan. I planned for all those morons to attendmy meeting this morning – I even bought muffins, for goodness’ sake – and none of them arrived. By the way – you want a muffin?”

Music to a BA’s ears

If I had 100 dollars for every time I heard a BA complain about the stakeholders not participating in  their meetings I would have – and I am not making this up – exactly 87 bazillion dollars and 50 cents. The big problem with people not participating in your meetings is that by the time you see a room full of empty seats it’s too late. The damage is done. You see, getting stakeholders to your meetings starts long before you even call a meeting.

In fact, it begins with a classic film: “The Sound of Music”. “When you read you begin with A, B, C. When you sing you begin with Do-Re-Mi.” And then you have the lines, “Doe, a deer, a female deer,” and so on. The point is that you begin at the beginning and the beginning of any BA project is planning.

So, as my fictitious friend asked earlier: What does planning have to do with putting people in the seats? For starters most BAs I come across don’t do enough, if any, planning, yet the Business Analyst Body of Knowledge (BABOK) clearly has an entire chapter devoted to it – Chapter 2 to be precise. Some of you may argue that you do plan. You create lists of stakeholders, you assign roles and responsibilities. But, on closer inspection, most BAs think that copying and pasting a list of stakeholders from some other project is a substitute for planning. It isn’t. There is no way around it. If you copied and pasted then you did not plan.

The list is important because it is the very first step the BA, that’s you, takes in understanding who does what, when, how, where and why. And if you don’t know that then you cannot convey any sense of understanding, relevance, or importance to the stakeholders. And without those only the soft-hearted will attend your meetings.

The BA communications plan describes how we will communicate with the stakeholders. Any stakeholders on the list that have an RACI “C” next to their name must become part of the elicitation process. Most often we will “C”onsult with them in a requirements workshop. We have to inform them of when we would like to “C”onsult with them and exactly what we will need from them.

It all makes perfectly good sense because you are ensuring that the right people are involved and that they know what is expected of them. The next thing you do is get their consent, their approval, because that leads to buy-in. You’ll need them to agree to what must be done, when it must be done, and who must perform each activity to gather all the requirements. There is also an implied contract that the BA needs those people to do their work for the sponsor and, if they don’t pitch, they are wasting the sponsor’s money. One way of getting that message across is through the content of the invitation to the workshop. Suggest that the participant’s involvement is crucial to the success of the project and that the sponsor is aware of this. If the sponsor has any organizational clout, it’s the added incentive stakeholders need to be there and be on time. In other words: wag the big stick.

The BA and the Paperwork

What you’ve done by ensuring only the right people attend the meeting is that nobody’s time is wasted. You don’t have people sitting around wondering why they never said a thing, never contributed to the proceedings. That quickly annoys people, particularly the busy ones These same people are the oneswho are important to the project at some point, if not right then. Having only the right people at meetings also makes the meetings move along more swiftly. Shorter meetings leave people more inclined to attend future sessions. More focused meetings with only the necessary people in attendance, also finish more quickly because everyone is driving to the same clear goal. So where do you find the required participants? You go back to your stakeholder list and communications plan, which should identify who should be present for the process under scrutiny and it’ll be correct because you didn’t just copy and paste.

The next item on your busy agenda is language. Imagine the conversation at the beginning of this story being between a BA speaking Russian and the mentor speaking Cantonese. They’re probably going to get things a little muddled and may even end up becoming frustrated with each other. By the same token you need to speak the language your stakeholders understand. If every other word you use is  jargon that only BAs understand, then your stakeholders will quickly get bored and start imagining the fantastic little getaway they’ve arranged for the weekend..

Context is king. Put the meeting in the context of your stakeholders so that they can understand the reasons why they are there in the first place: “I know you have customers and they place orders; tell me more about what you do when you receive a customer order.” It focuses the workshop immediately, the participants feel you understand what they do, and it shows you value their time enough to have done some groundwork.

If you do all of these suggestions,  through careful up-front planning to obtain a focused, contextualised outcome, then stakeholders will quickly feel appreciated and relevant and possibly even enthusiastic about your meetings. OK, maybe not always enthusiastic. But you will be able to imagine a completely different conversation to the one that opened this story.

I always say: If you can show business real value in what you do, then business will start to really value you.

Don’t forget to leave your comments below.

It’s Time for Template Zombies to Die

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