Are you a business analyst who is jaded with the statistics of how poor requirements are #1 cause of failure in projects?
And to your utter delight this theory and statistics repeats every year.
According one of the many statistics the #1 cause of failure of projects is due to requirements… In one particular CIO analysis
for example, the number was as high as 37%.
So, specifically the top cause of project failure is due to:
Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
In this post, I am not proposing that having the right BA templates will help an analyst communicate requirements clearly and solve this problem and elevate us to the sainthood of project and business success. However, you’ll see factors and practices that trace back to some of these elements that causes project failures.
If you’ve been a real BA (and still practicing) long enough like me, you’ll appreciate the synergistic power of “things coming together”. When you have the right template, communication and collaboration approach and a bit of tough headedness – success can’t be elusive.
I want to use the analogy of the famous biblical “Seven Sins”
to help you understand and avoid some common mistakes made by business analysts when it comes to using business analysis templates in their work.
1. Lust of Completing All Sections
Lust (an intense desire) of treating a BA template as a mere object that needs to have no empty cells. This BA templates sin is exemplified by the intense desire for fame and grin of approval from the project manager or the sponsor.
You have to know and realize that a BA template’s sole purpose is to provide a structure and save time. This is your standard format of putting the consensus achieved over a period of time (sometimes several months). Refrain from the desire to fill out all sections when there is no need to (you can simply delete them with a note). A template exists to ensure you’re complete in your coverage of analysis and approval and not necessarily complete in blobs of words.
I have seen time and again non-functional requirements (I don’t like this name btw) getting the second class citizen treatment and always rushed to completion without adequate analysis and thinking through (more on this later). When in reality not spending adequate time on non-functional requirements is one of the major causes of project failure or non-performance.
2. Pride of What and How You Do it
The information that is documented in a template goes through an intensive elicitation and analysis process (not “gathering” btw). If you’re working in a large team with stakeholders spanning across geographies and cultural spectrum, you’ll appreciate the importance of collective representation. You may have burnt the mid-night oil in putting together a piece of information and creating a really fancy colourful (I am Canadian eh!) Visio diagram, but nothing matters if your stakeholders have not provided a gradual collective buy-in.
Stay humble; park your pride… this will take you farther! (De-pride – acknowledge the expertise and accomplishments of others)
So, don’t be bogged down by what you know and how you fill out a template. Don’t add fluff that’s not needed or confirmed in some form earlier (more on this later).
Lock this in your memory or write it on the wall!
“You maybe a Visio rockstar, but if your stakeholders are not singing as a choir, you’ll have an empty concert.”
It is essential that your work products represent an agreement, before this is translated into the final version of the work in a standard template.
A word on tools and requirements management software… all I have to say on this is: “A fool with a tool is a more dangerous fool” (enough said)!
3. Envy of the Who Knows What
When you’re documenting requirements, ensure that the key stakeholders are getting their limelight when needed. If your lead developer knows the interface between two systems really well, let him have the stage to sing (even if you think you know it better). Consult him, have a review with him early on, ask a favor to confirm.
Consider showing what you’ve done early on to key stakeholders. If you’ve just completed a stakeholder section, have a quick 20 minutes chat with the sponsor or project manager to ensure you’ve included everyone. If you’ve just added some functional requirements that trace to a contentious stakeholder or business requirement, run it by your architect or lead developer to check feasibility.
4. Rage Against the Templates
We all have at least one BA template that we despise. Every time we start using it, beautiful language emanates.
All is fair in love and (template) wars. You raise your rage, and forget about it when your train to go home is delayed by 2 hours.
Tomorrow is another day of rage against another template.
If this has been ongoing for too long, you should simply purge that BA template or modify it to the liking of how it would fit into the project you’re working on.
Why should you anyways right? It’s the job of the glorified requirements centre of excellence (CoE); they get paid big bucks to do this (and let them get a dose of reality right?).
The next time this happens, take a deep breath and do what it takes to fix it; and while you’re at it, send an email to the CoE to let them know how they can remain gainfully employed.
5. Slothful Elicitation and Analysis
This is probably the most dangerous of all the BA templates sins. When there is a temptation or opportunity to add a requirement (or even an assumption or constraint) or extend something without asking all the right questions, performing additional elicitation and analysis, you’re being slothful.
So, when you learn that the users need a way of auditing the information that is changed by a user action, you simply add an auditing requirement on chapter 7 section 2 and wash your hands off.
Do you ask: (If you do, Kudos!)
Why is there a need for this? (there are many ways of asking “why”)
How long do we need the audit data for?
What fields need to be captured for the audit data?
Does this have any sensitive data that needs encryption?
Do we even have this data to audit?
Who will need access to this audit data and why?
What are the implications of not having this audit data?
You get the idea?
6. Greed of Fluff
You add stuff for the sake of adding stuff. Enough about fluff. Remember, sometimes,
“Less is More!”
7. Abstinence of a Good BA Template
You should understand and realize that templates saves time and define a structure for the documentation of all the hard work you’ve done in a project. Not making use of a good template and thinking through it right in the beginning can hamper your productivity and scatter your valuable outcomes.
If you see a good meeting minutes template, pay attention and use it. If you don’t have one, create one yourself. Keep a look out for another post from me on how you can create a powerful BA templates and toolkit using ‘The Golden Circle of BA Toolkit’.
Which of these sins you see being committed the most or are guilty of?
Are there any additional sins that you’d like to share so that we create an awareness in the BA community about it?
Please share your feedback, thoughts and questions in the comments section below.
Unprecedented CBAP-CCBA Study Guide, BABOK eMindmap, eTables, BOK Cartoons, Audio and Video. The Ultimate All-in-One Study Aid is here.
Go to top