The Elephant, the Dead Horse and the Awesome Business Analyst

by | May 21, 2016

What makes an awesome business analyst?

To be an awesome Business Analyst (BA) you need to be a good BA with something special on top. You need to put your head above the parapet, take some risks and add extra special value to your organization. I’m assuming you’re already a good BA so here’s a 5 step recipe for the secret sauce that will transform you into an awesome business analyst:

  1. Focus on Measurable Outcomes;
  2. Work on the 20% of activities that will deliver 80% of your outcomes;
  3. Build good relationships over coffee;
  4. Point out elephants; and
  5. Avoid dead horses.

1. Focus on Measurable Outcomes

Sometimes projects can feel like a game of Snakes and Ladders with surprising, rapid ascents and unexpected, gut-retching falls. The destabilising emotional and mental impact of these rapid changes can be compounded by uncertainty. In military terms, this confusion resulting from uncertainty, ambiguity and change is called the fog of war:

“War is the realm of uncertainty; three quarters of the factors on which action in war is based are wrapped in a fog of greater or lesser uncertainty. A sensitive and discriminating judgment is called for; a skilled intelligence to scent out the truth.”h

— Carl von Clausewitz from: https://en.wikipedia.org/wiki/Fog_of_war

Awesome Business Analysts must learn how to operate well in the fog of projects. There’s always going to be ambiguity at the start of projects but it’s also the business analyst’s job to assist with removing ambiguity. Often ambiguity is hidden in project assumptions. Start by capturing an exhaustive list of all of the assumptions you’ve heard, both explicit and implicit, then attack them aggressively by doing what you can to clarify, validate and remove them. Project managers will be particularly happy if these investigations help to provide more clarity on the scope of the project.

From the beginning of a project, it’s important to try to gain consensus around what success might look like. That way, when lost in the fog, there is a compass bearing that everyone knows so that they can course correct throughout the project to ensure that everyone is moving in the right direction. This definition of success can be the compass that helps the project to alter course when lost in the fog. Success is most easily defined in terms of a high level objective.

What is the high level objective for the project? You should be able to state this in one sentence. A good business analyst can help the project sponsor and senior business stakeholders gain clarity on this by pushing them for simplicity and clarity.

The best explanation I’ve seen on this was at a presentation at Lean15 in Wellington last year by Christina Wodtke.  Christina describes these as OKRs (Objectives Key Results) and suggests that the Objective should be a single sentence that is:

  • Qualitative and Inspirational
  • Time Bound
  • Actionable by the Team Independently

And that the key results should provide the quantification. I’m not going to go into too much detail as there’s some great material in Christina’s blog and new book, Radical Focus, so I suggest you check it out.

Not only is it important to have measurable outcomes but you need to set targets and have a plan in place for attaining them. Too often projects hand over to the operational side of the business and then wash their hands of the whole thing. A business analyst can improve benefit realisation by encouraging the project to start with the end result and work backwards:

  1. Get yourself involved in the early kick-off meetings and ask, “What would success look like?”
  2. Document OKRs and share with the team
  3. Get commitment to OKRs
  4. Draft a benefit realisation plan which should include items such as:
    • specific instructions on how KRs will be measured and reported on
    • targets for each KR
    • A RACI chart showing responsibility and accountability for attaining each KR. [See here for an example RACI chart. ]
    • A high level explanation for how each target KR will be achieved

2. Focus on the 20% of activities that will deliver 80% of your Outcomes

Cambridge Image

Not much of the economics that I studied at Cambridge University really stuck but one thing that did was the Pareto Principle named after the Italian economist Vilfredo Pareto who observed that:

“approximately 80% of the land in Italy was owned by 20% of the population … [and] that 20% of the peapods in his garden contained 80% of the peas.”

“What have peas got to do with IT projects?” you may be thinking. Well, the Pareto Principle, recently popularized as the 80-20 rule, has many applications in the field of software engineering, with the suggestion for BAs that 20% of the requirements will deliver 80% of the potential benefits. The Institute of Industrial & Systems Engineers also suggests that you should:

“Prioritize software change requests and enhancements based on demand and need. Choose to make the changes that represent 80% of the user complaints, instead of the easiest one to implement or requested by the most demanding client.”

Many times, projects get steered by the requirements of the most vocal stakeholders. Often they dominate solution workshops and aggressively push for their own requirements to be met as noted by simplicable.

“80% of project politics come from 20% of your stakeholders”

Has this typically been the case for projects that you’ve worked on? What about your current project? Leave a comment and let us know if you agree!

It is the BAs job to carefully elicit requirements from all stakeholders and then prioritise based upon collective need rather than individual preference. This can be difficult to do as many projects operate in complex political environments but engage with the less vocal stakeholders in one-on-one meetings and capture their requirements in detail. Then present these requirements back to the wider group and ask, “how many people would benefit from this?”

Another way of interpreting the Pareto Principle is to remember that 80% is often good enough and good enough is good enough. Often BAs spend way too much time trying to perfect requirements, getting stuck in feedback loops with stakeholders correcting their own corrections and generally going round in circles. Yes, detail is important. Yes, feedback is important. Yes, iterations are important but time-box your endeavours and then move on. This is well expressed in a blog post by James Friberg,

“But when it comes to writing business requirements, are you killing yourself trying to write the perfect requirement spec?  … My advice to you is to quit trying.  It’s an impossible task that just leads to sleepless nights and constant worry.  And the reason why is simple, there’s no such thing as a perfect requirement spec.”

The reality check is to bring it back to the OKRs and ask yourself how well the requirements are contributing to the OKRs and whether any additional effort would improve the chances of hitting the OKR targets. If no additional effort is required then stop, get your head out of your computer, get off your chair and go have a coffee whilst humming along to that Disney video that my friend John’s five year old daughter loves to repeatedly sing along to:

“Let it go, let it go!
Can’t hold it back any more.
Let it go, let it go!
Turn away and slam the door.
I don’t care what they’re going to say.”

3. Build good relationships over coffee

RACI image

Building good relationships with all kinds of project stakeholder will be a key to success on the project. I always find the first couple of weeks of a project the hardest as I work hard to establish good relationships with the extended project team. This involves lots of small talk at the water cooler and sending out invitations to pop out of the office for a coffee. Initial conversations can seem like a waste of time but pretty soon these quick coffee conversations evolve into project talk, where the gossip and rumour can give you more insight than the more controlled atmosphere of one hour project meetings. The importance of these relationships and the value of the conversations usually ends up beings orders of magnitude more than the price of a few cups of coffee. So, invest in caffeine.

Play the long game and develop these relationships slowly so that people trust you and don’t feel overwhelmed by all of the questions thrown at them. In fact, often it’s just better to not ask many questions at all and just listen to hear what’s on them mind. The issues may be tangential but they’ll give you some good context to the project. It’s particularly important to develop relationships with a cross-section of the organization because you’ll hear very different and often contradictory things from people. Try to understand why that person is saying those things and look at things from their perspective. Then, after a few cappuccinos with a few different characters, you’ll probably start to hear about the elephant…

4. Point at the Elephant in the Room

Elephant image

Awesome BAs hit the ground running hard and quickly add value to new projects by asking smart questions. It’s amazing what a fresh pair of eyes, ears and the ability to play the ‘sorry for the stupid question but I’m the new guy around here,’ card can do.

Often Subject Matter Experts (SMEs) are so caught up in detail and politics that they struggle to see the wood from the trees. The power of precedent can be over-powering and I’ve often heard the argument, “well, we’ve always done it that way, why should we change it?” which reminds me of a story from Zig Ziglar:

“Let me share a story. This old country boy’s wife sent him to the store for a ham. After he bought it, she asked him why he didn’t have the butcher cut off the end of the ham. This old boy asked his wife why she wanted the end cut off. She replied that her mother had always done it that way and that was reason enough for her. Since the wife’s mother was visiting, they asked her why she always cut off the end of the ham. Mother replied that this was the way her mother did it; Mother, daughter, and “this old boy” then decided to call grandmother and solve this three-generation mystery. Grandmother promptly replied that she cut the end of the ham because her roaster was too small to cook it in one piece”

~ Zig Ziglar, See You at The Top, 1975

Now, I’m not saying that it’s easy to point at the elephant in the room but awesome BAs do things that are not easy. Often the elephant has been in the room for a long time and it’s made quite a mess but SMEs and stakeholders have got used to working around it and so have accepted that this is just the way things are.

Take time to get some credibility and social capital before you start pointing too hard. Carefully raise the issue with the project manager first although realise that many project managers are risk averse and don’t want to go near anything that might look or smell like an elephant because they know that elephants can take a lot of effort to move.

So, the question then becomes is the elephant getting in the way of your OKRs? If not then leave it alone. If it is then start the conversation making sure that you’ve got some good data points to back up your argument.
 

5. Get off the dead horse

dead horse image

The dead horse is one particular kind of elephant that comes up so often it’s worth its own section. The dead horse can be a particularly difficult elephant to point at as there are all sorts of ways of avoiding the reality that the elephant is in fact a dead horse. Dead horses are projects that are being kept on life-support systems due to political or egotistical reasons but they basically are defunct. The sunk cost fallacy also helps to explain why these projects stay around and people continue to throw good money after bad. Perhaps matters are improving with agile methodologies promoting ideas such as failing fast or learning fast but unfortunately there wasn’t much evidence of this in some of the government departments I was working in.

Resuscitating a dead horse is way beyond the means of modern medicine, so best follow the tribal wisdom of the Dakota Indians courtesy of the Guardian:

“The tribal wisdom of the Dakota Indians, passed on from one generation to the next, says that when you discover that you are riding a dead horse, the best strategy is to dismount.

But in modern business, because heavy investment factors are taken into consideration, other strategies are often tried with dead horses, including the following:

  • Changing riders
  • Arranging to visit other sites to see how they ride dead horses
  • Reclassifying the dead horse as “living-impaired
  • Hiring outside contractors to ride the dead horse
  • Harnessing several dead horses together to increase speed.
  • Providing additional funding and/or training to increase the dead horse’s performance, etc.”

Now, there can be lots of vested interest in projects riding dead horses and if that’s the only game in town then you’re going to have to start queuing up to beat the dead horse just like the other guys in the picture. Riding dead horses isn’t going to get you anywhere fast though and won’t get you many bonus career points so be carefully looking around for another horse that looks like it might have a bit more life in it.

Would you like more?

Thanks for reading. I’m considering some follow-up posts so let us know what you want to see more of in the comments … and if you liked it then please share it with your friends.

Image credits:

  1. Snakes and Ladders by Jackie Brown published under a Creative Commons Attribution-ShareAlike 2.0 Generic License
  2. TrinityCollegeCamGreatCourt.jpg from Wikipedia published under a Creative Commons Attribution-ShareAlike 2.0 Generic License
  3. Image from unsplash.com
  4. Image by Bit Boy – Flickr: The Elephant in the Room, published under a Creative Commons Attribution-ShareAlike 2.0 Generic License on Wikipedia
  5. Image created at imgflip
One more tool?
The service ‘glue’ between business and technology