“Before the Internet, we thought the cause of stupidity was the lack of access to information. Well, it wasn’t that.”
David Dunning, the social psychologist known for the Dunning-Kruger effect.
Business Analysis today is a mature professional discipline. After several decades of management theory, and a couple of decades of the business analyst role being specifically considered and catered for within IT, we’ve got a wealth of tools, techniques, and frameworks in our arsenal. So why don’t we use them?
I’ve recently been taking fresh exams for the BCS Advanced International Diploma in Business Analysis. During my studies, I’ve encountered innovative and useful frameworks for almost everything I’ve ever needed to do with a business analyst hat on over the last 24 years. There are even techniques for my favourite business analyst situation: “This project is in a right mess – could you sort it out?”
Heck, there’s even a book: Business Analyst Techniques: 123 essential tools for success — but is it on your desk right now?
Whether you’ve got qualifications through the BCS, the IIBA, or you’ve studied for a full MBA, you’re bound to have encountered the classics — PESTLE, use cases, user stories, the various UML diagrams — and possibly the more esoteric too (Cynefin anyone? Bonus points if you can pronounce it in the proper Welsh! It’s pronounced Ku-nevin, apparently, as if Koo Stark married Jason Nevins.)
We’ve got more tools than a Formula 1 mechanic!
They say that knowledge is power, but that’s wrong. Knowledge is potential power. The APPLICATION of knowledge is power! We don’t just need to know our tools, we need to apply them!
Although there are a few things that I disagree with, and have found not to work very well in practice, a lot of those techniques are good and they do work. They’re a shortcut to success. Of course, we all have our personal pet hates too: if I see someone walking into a workshop with a stack of Post-It® notes, my heart sinks! But if I ever get to use a fishbone diagram in a workshop I’ll probably retire happy!
So what’s going on? Why are we bothering to reinvent the wheel? Why are we making life hard for ourselves? And how can we fix it?
Why should we use established Business Analysis techniques?
First though, what are the advantages of using the formal techniques when we can?
Better analysis — broader and deeper: The tools have been honed over time to help give us insights into problems. This can mean going broader to make sure we consider everything (e.g. the holistic view of the POPIT tool of People, Organisation, Processes, Information, and Technology), or it can mean going deeper, in the case of fishbone diagrams for root cause analysis.
Better communication: Some techniques give us ways to present information, and show people the results of our analysis, in ways that are easier for people to understand. Use case diagrams, context diagrams, and user story maps are excellent for quickly showing a situation and sparking a discussion.
Not forgetting things: Many of our tools are really just checklists, at heart, to give us a formal way to go through things and not forget anything important. If it works for pilots and surgeons, why shouldn’t it work for us? The book The Checklist Manifesto, written by medical man Atul Gawande, goes into depth on this.
Tried and trusted results: People can take confidence from knowing that these tools are widely used, and have been shown to get good results across a wide range of projects, provided they are correctly applied.
Standardisation: If we are joining someone else’s project, it’s useful if they are using techniques we are already familiar with. It saves time and potential misunderstandings, and gets us up to speed a lot quicker.
More professional image to inspire confidence: If we’re bringing out formal methodologies and techniques with fancy names, it makes us look like we know what we’re doing, and that can inspire our stakeholders to trust us more. And let’s face it, in most cases we do know what we’re doing, so let’s take advantage of that.
Root causes relating to ourselves
When looking at reasons we don’t use the tools more, we can consider the reasons that come from us, and the reasons that come from our colleagues and other stakeholders — or at least our perception of those people.
Let’s start by looking at the reasons in our own head, as business analysts, for why we might not use the tools. These include:
Self-reliance: We think we can get good results by relying on our own abilities and home-brewed concoctions. Sometimes we can, but other times this can lead to laziness and complacency.
Comfort with formality: Some business analysts like formality, discipline, and rigour, and others don’t.
Ability to apply and tailor the tools: It’s one thing knowing a framework theoretically, but putting it into practice is another matter entirely.
Initiative and discipline: How likely is the business analyst to hit the books, search the web, find the frameworks and use them?
Root causes relating to other people
Team readiness: How willing and ready are our team members to adopt or support our tools, especially when they are not familiar with them?
Culture fit: Is the organisation free-wheeling and flexible, or formal and bureaucratic? What are the expectations?
Perceptions: Will our stakeholders view our formal methods as too slow or too rigid?
Top ten reasons business analysts don’t use our tools more often
Here’s my totally unscientific top ten reasons, based on what I’ve seen happening in a variety of companies. Look for these reasons, and tackle them wherever you find them! Cut them off at the knees! Zap them before they zap you!
Lack of awareness and training: Many business analysts simply don’t know many of the techniques, and lack proper training on how to implement them effectively. This is easily remedied: buy the book and study it, or go on a course.
Lack of mentorship: This is a big one, because it’s very common. In companies where there is a lack of mentorship or knowledge sharing — which is most companies! — newer business analysts might never really get to learn the techniques unless they go on a training course, and then they might never get to apply them under supervision of a more senior and experienced analyst. If you work remotely then this can be a particular problem, when all the calls have a formal agenda or topic, so make sure you still provide mentoring opportunities and informal collaboration if you spend all day on Microsoft Teams!
Inability to tailor tools to the project: Established methods might not quite work straight out of the box, and business analysts (especially the more junior ones) might find that tailoring these methods is too restrictive or not feasible. I see the tools as a starting point in many cases, to be customised to the situation, not to be followed religiously.
Time pressure: A “get it done quick!” attitude can lead business analysts to use ad hoc methods that are perceived to be quicker, even if they are less effective in the long run and store up problems by not properly considering everything.
Short-term focus: The bane of my life, and the scourge of project success! To be fair, projects with a very short-term focus might not benefit from the detailed setup work that some frameworks require, leading business analysts to choose quicker or less thorough approaches. But on the other hand, if everything is driven by “The boss wants this by the end of the day, so JFDI!”, then the slapdash and weak attempt at analysis that the business analyst is forced into is only ever going to lead to missed requirements and other problems that lead to an ineffective and brittle solution.
Lack of empowerment: Business analysts sometimes feel they don’t have the authority to use their own choice of techniques or suggest alternative ways of working. A “this is how it’s done here” attitude can often hold things back. Actually, I’ve found that business analysts have far more power than we might think: people are often far more open to the suggestion of using new techniques than you might imagine. Also, I just tend to do what I think is best then ask for permission/forgiveness afterwards!
Overreliance on personal experience: Some business analysts prefer to rely on their own experience or intuition rather than on the more formal techniques, especially if they have had success with this approach in the past. I can sometimes fall into this trap myself, because I’m often keen to get started! I think it’s better to step back, take a breather, have a coffee, flick through the Business Analysis Techniques book, and mull it over before getting down to work.
Laziness and complacency over rigour and discipline: Sometimes, the root cause might be as straightforward as an analyst wanting an “easier” life, with less demanding ways of working. This can also happen if they aren’t confident in their knowledge of tools and techniques, and don’t want to risk this being exposed! Slapdash methods, or no methods at all, aren’t really easier, they just save up lots of problems for later.
Concern about being perceived as unagile: This one really irritates me when I hear it. Whenever you suggest some kind of actual thinking might be needed, somebody will pipe up “This is waterfall!”, or “We’re not being agile here”. I suggest those people have another read of the agile manifesto and the twelve agile principles that go with it, if they’re that concerned! Agile can lead to sloppiness and an attitude of “Don’t worry we’ll sort it out in the next sprint”. Definitely do worry, if you hear that! My opinion leans closer to the side of where things can be known in advance you need to at least consider them, even if you don’t elaborate those things until they’re needed later. The horrific misconception that any form of upfront analysis goes against Agile principles can prevent business analysts from using thorough, systematic methods, for fear of being labelled as Waterfall Willy or an old fuddy-duddy. Sometimes, getting the younger people on the project team enthused about the methods can help here, since people wrongly equate agile with youth, and waterfall with experience. (I don’t know where people get all these weird ideas from, but they get them from somewhere!)
Unfamiliarity with tools among team nembers: If other team members, including developers, project managers, and project sponsors, and stakeholders, aren’t familiar with the business analyst techniques, it can create friction or slow things down. This unfamiliarity can lead to resistance due to misunderstandings about the benefits or the purposes of our tools. There are two main ways around this. Firstly, if you’ve built up trust with your team, you can literally just say “Trust me, I’ve done this before and it works really well.” (Then you hope that it does!) The other approach is just explanation and education: here’s the technique, here’s why it’s helpful, and here’s how it works. I recently used the Benefits Mapping technique in a workshop, and although it went well and sparked some very interesting and useful discussion (which was the whole point of the workshop), I think it would have gone better if I’d spent slightly more time explaining the framework. I could have emphasised that the tool is designed to consider more than just the IT systems, and to also look at the changes to the ways of working that are needed to fit around the IT system if it’s to be implemented successfully. I’ll know this for next time!
Other reasons business analysts don’t use our tools
Less commonly, but still common enough to be worth looking for and eliminating, are these reasons:
Perceived complexity: Some business analysts see the tools as overly complex or cumbersome, or too big and heavyweight for a task they see as being quite small.
Inadequate software support: Some techniques are difficult to use without proper software tools to support us, and let’s face it, that software usually either doesn’t exist or we don’t have access to it! Even tools like the Benefits Map, which I love, can get quite complicated fairly quickly, once you start trying to link things together to decompose your goals. (See the book Benefits Management, Ward and Daniel, 2012, which is excellent but sadly out of print, although it’s available on Kindle, and second-hand copies can still be found online.)
Organisational culture: If the culture doesn’t value rigour or analysis, business analysts can find it difficult to apply standard frameworks. This could well be due to a lack of understanding of the benefits our tools provide, people stuck in the past, or a “not invented here” or “not how we do it round these parts” syndrome.
Resistance to change: There can be a general resistance to change within a team or an entire organisation, where people are reluctant to try new things even if they work better. Sometimes you need new blood from outside the company to come in and shake things up. I saw this in a major telecommunications company that I worked for, where an entire new department was created and had the (possibly unintended) effect of unlocking many new agile tools and techniques that had previously not been used. You can often find allies though, who are secretly unhappy with the status quo and would like to change and try new things, even if it’s just to make their CV look better!
Fragmented standards and overlapping techniques: In IT there are various competing standards and methodologies, largely because there are competing training companies looking to make money from pushing their particular ideology. This can make it difficult to choose which path to go down. Should you do AgilePM or PRINCE2? Scrum or kanban? Use cases or user stories? Both? Neither? As an example, many of the techniques for requirements analysis are fairly similar — use cases, user stories, etc — in that they’re really all seeking to achieve the same thing, where goals are decomposed into smaller sections and clearly documented. Sometimes it just doesn’t really matter which formal approach you take, as long as you take one! So just make a decision and run with it. It’s rarely fatal if a technique doesn’t work out, you can just pivot and try something else; you might need to rewrite a few things, but the effort you’ve already put in is rarely wasted.
Poor past experiences: If business analysts or their organisations have had poor experiences with established methods in the past, they can become sceptical and try to avoid using those methods again. This can be difficult to overcome, although a slightly different technique that achieves the same goal can be a way around it. Alternatively, you can sometimes use the methods by stealth: just have a chat with someone, but actually you’re structuring the interview around a framework, but they don’t need to know that!
Fear of appearing too formal: In some companies, especially those that aim for a start-up feel or an informal culture, there may be a concern that using structured methodologies could make the business analyst appear too rigid or bureaucratic. Beware offices with beanbags! This perception can discourage people from using formal methods in favour of more informal approaches. Of course, you can tailor the methods a bit and stick to just the main points, which can help here.
Concern about taking too long: In fast-paced environments, there might be pressure to show quick wins and to keep the momentum going. Agile methods such as scrum, with its usually two-week sprints, can force this rush to finish over the need to achieve a high quality result. Business analysts might avoid thorough techniques if they think (rightly or wrongly) that they will slow things down, because they don’t want to be held responsible for delaying things. What usually happens is you will get the delay, but it will be later when you’ve spent a lot more time and effort on doing the wrong thing, and then you have to backtrack. I got brought into a company where a project had been running for six months, and it became clear within a couple of days that they’d entirely missed the point and had wasted six months of effort from a team of about ten people! The whole thing had to be scrapped and started again. If better analysis techniques had been used from the start, perhaps with a more experienced business analysis (or in fact any business analyst at all, if I remember rightly), the massively obvious problems would have been identified and the course could have been corrected. Somtimes it really is a case of “Slow down to speed up”, as they say.
Techniques that are too difficult to be appropriate: Sometimes, we have tools that genuinely aren’t very good, or that take too long to get a result, or that require detailed mathematical knowledge, or some level of advanced skill in order to get a result. For many people, something like Monte Carlo methods or Weighted Shortest Job First (WSJF)prioritisation might fit into this category. Detailed notation like BPMN for processes often fits into this category: it’s a technique with a very complicated set of rules, and although it can be highly expressive, a flowchart where you’re just using boxes and lines, with the occasional decision diamond, are often good enough and most people would never know the difference anyway! The skill here is in choosing appropriate techniques for the task and the audience.
Plotting the reasons for not using tools onto a 2×2 matrix
There’s nothing a business analyst or consultant likes more than a good 2×2 matrix. If you’re feeling fancy, you could identify the reasons that seem relevant to your current situation, then plot these reasons on a 2×2 matrix, where the axes consider reasons that are “Coming from ourselves” and “Coming from others”. You can then see whether you need to work more on your own mindset, or work on influencing your colleagues.
Table 1: The barriers to effective tool usage in a team setting. It measures reasons coming from self versus reasons coming from other team members and external influences. This creates three active zones: work mostly on yourself, work mostly on others, and areas of joint responsibility where you must work on both.
One of the major insights from this matrix is that there’s nothing that’s totally 100% out of your control here. There’s always something you can do. Part of the battle is identifying the issues and their root causes, before trying to improve things.
What’s the solution? How do we use the business analysis techniques more?
Just recognising that there’s a problem is often the first step to finding a solution. So I hope this article has helped with that! It’s as much about wanting to use the techniques as knowing how to use them.
As I said before, the first step is to buy the BCS book Business Analysis Techniques: 123 essential tools for success. Make sure you read it closely! Then make sure you keep it on your desk and consult it regularly, whenever you have a new piece of work. The BCS companion volume Business Analysis, 4th edition, really needs to sit alongside it. If you’re not into the BCS worldview of business analysis (why not?!), then the IIBA has the BABOK (Business Analysis Body of Knowledge) which can help too.
Personally, I like to use checklists. I have my own requirements checklist that I’ve built up over many years, which I update from time to time. You could do the same. Checklists are good because they’re quick and simple, but they help to make sure you don’t forget things, which is the main point of many of the formal tools and techniques anyway.
Conclusion
We have a vast wealth of business analysis tools and techniques we can use to make our lives easier and our work more effective. We just have to get more motivated to use those techniques, as part of our ongoing commitment to professionalism.
The hurdles we face when trying to introduce these techniques fit into three broad categories: our self-perception, team dynamics, and the organisational environment in which we work.
Firstly, issues that come from ourselves, such as overreliance on personal experience, comfort with informality, and fears of appearing unagile or too formal, mean that we need time and space for some personal reflection — our own personal retrospective! (Best done privately!) We need to consider our own biases and comfort levels, and be alert to recognising when a structured approach could give us better results.
Secondly, the perception, professionalism, and skills of other team members plays a critical role too. If our valued colleagues are unfamiliar with our tools, we need to explain them clearly, by demonstrating their value and easing the team into these new methods with friendly education and gradual implementation.
Finally, the business environment we work in significantly influences the adoption of business analysis techniques. This is probably the hardest thing to recognise, and the hardest thing to change, because culture is often intangible. Although it’s not in the fabric of the building, it’s in the hearts and minds of the people, sometimes it feels there’s just “something in the air” that stinks! Sometimes we have to navigate environments that undervalue thoroughness and obsess over speed. Sometimes we find people and systems that are stuck in traditional ways that resist modern, agile approaches. Other times, we find the organisation is trying to be too agile, but hasn’t introduced it properly, so nobody knows what they’re really supposed to be doing! Breaking down these barriers sometimes needs us to just be bold and take the first step: start using the methods, take a bit of flak if you have to, and then win the doubters round when you come up with the goods!
You can start by identifying the root causes that I’ve mentioned that most apply to you. Then take proactive steps to eliminate these barriers, whether they are real or perceived. Talk to your project sponsor. Raise it in your performance reviews. Find your allies!
By unlocking the full value of business analysis techniques, you can get better outcomes, save yourself time, and get greater professional satisfaction from a job well done. So whip out that tool-chest today!
Recommended Reading
Cadle, James. Business Analysis Techniques: 123 Essential Tools for Success. Third edition. BCS, 2021. ISBN 978-1780175690.
Paul, Debra, and James Cadle. Business Analysis. Fourth edition.BCS, 2020. ISBN 978-1780175102.
Girvan, Lynda, and Paul, Debra. Agile and Business Analysis: Practical Guidance for IT Professionals. Second edition. BCS, 2024. ISBN 978-1780176178.
BABOK®: Business Analysis Body of Knowledge (BABOK®) Guide, third edition. International Institute of Business Analysis™ (IIBA). Available free if you join the IIBA. See
Ward, John, and Elizabeth Daniel. Benefits Management: How to Increase the Business Value of Your IT Projects. 2nd ed. John Wiley & Sons, 2012. ISBN 978-1119993261.
Gawande, Atul. The Checklist Manifesto: How to Get Things Right. Profile Books, 2011. ISBN 978-1846683145.
About the author
Ian Howlett has formally been a business analyst for 12 years, and was previously a software developer, with 24 years in the IT industry. He has a Computer Science degree, and an MBA with distinction from the University of Oxford. He has worked for some of the largest companies in the UK, for large US-owned companies, and for smaller companies too, in sectors including aviation, telecommunications, healthcare, media, and insurance. Outside of work he has a private pilot’s licence, plays the piano, and enjoys F1 motor racing, snooker, and reading.