Pretty soon they won't bother calling IT at all. They'll just reach out to the consultants and outsourcers, since these are the people with whom they end up dealing anyway."
Good news for us consultants, but bad news for internal BA teams.
The business analysis profession has grown significantly over the past five to six years. As business analysts we have added structure to our role by creating the BABOK, the IIBA's Business Analysis Competency Model as well as tools, techniques and templates. The focus of all of these activities has been to get the requirements right the first time. And it has worked—the IT project success rate has doubled, failure rate had decreased by a third, and business's IT spending has halved.
So, what's the problem? Why are more and more IT departments viewing business analysts as part of the problem and not part of the solution? There are four potential reasons that I'd like to highlight:
Underlying business problems: Quite often the business wants to use technology to solve a business problem, and as business analysts we tend to unearth these underlying business problems during our analysis. Suddenly you can no longer just gather the functional requirements and present them to the development team; you have to dig deeper and assist with solving the business problem before implementing any technology solution. This adds significant time and scope to the analysis effort and suddenly the project is waiting for the business analysts.
Underlying IT Problems: As business analysts are "the sharp end of the wedge" when it comes to interacting with the business, any underlying problems with IT delivery become much more visible during the BA engagement. If the quality of software delivered is poor, the business tends to blame the business analyst as that is with whom they interacted. The same principle applies to poor project management practices and lack of resource planning. Because they are most visible, it becomes very easy to blame the business analysts.
One-size-fits-all BA methodology: I've seen organizations that went to a lot of effort to formalize their analysis methodology, adding tools, templates and techniques. But in some instances, depending on the size of the piece of work, not everything is needed. With a rigid methodology, every request from the business, irrespective of its size, could need a Business Case, Business Requirements Definition, Business Requirements Specification, System Requirements Specification and System Design document (and this is a real life example). The analysis effort becomes disproportionate to the overall effort, and BAs get stuck in even the smallest requests. The typical response then becomes, "we need more business analysts."
The rest of IT have moved on: As IT organizations are adopting Agile practices, quite often the Business Case, Business Requirements Definition, Business Requirements Specification response from business analysts has been a head-in-the-sand approach—insisting that the big up front requirements document is still needed and hoping that Agile will go away. This is not going to happen, and if we don’t adjust and find our place in Agile, the CIO is soon going to say, “we don’t need business analysts.”
There are three ways to identify a bottleneck:
- They are very busy, all of the time.
- Work piles up in front of them.
- People downstream are idle some of the time.
So, what can we do as business analysts to ensure that we don't become the bottleneck by falling into these traps?
Develop your business analysis maturity: A mature business analyst is one that develops a trust relationship with stakeholders, continuously looks for opportunities to develop innovative business solutions and keeps on learning. To do this, you must become a "trusted adviser" to the business who can filter requests to IT and identify opportunities for improvement. An understanding of the business and the problems they are experiencing combined with their trust that you will act in their best interest will significantly reduce the analysis effort required and increase the success rate of your analysis
Expand your analysis tool set: When was the last time you went on formal analysis training? Was it when you completed the FTI Business Analysis diploma four, five, six years ago? How often do you read articles about new business analysis techniques? The more skills you have in your tool set, the easier you can adapt to different environments. The IIBA lists 34 analysis techniques in the BABOK, but most of us were taught business analysis for classical waterfall projects and some of us for Agile projects. Can you really say that you know all 34 techniques? Do you know the different analysis techniques required for off-the-shelf software acquisitions, BPM projects, ERP implementations or exploratory proof-of-concepts
Become agile: Becoming agile does not only mean positioning ourselves as product owners or proxy product owners in Scrum. Yes, that is part of what we have to do, but we also have to adopt an agile mindset when analyzing requirements. Are there any requirements that can be delivered earlier or any requirements in the repository that can be reused? Which analysis activities can take place in parallel to development? Being agile is about adapting to the circumstances and delivering results in an incremental fashion
The business analysis profession has just recently developed into a mature and accepted part of the IT organization, but are we at risk of becoming obsolete already? As BAs we have to apply the same principles that we apply to business problems to our own profession. Our skills must continue to evolve and adapt to the changing landscape around us. So, don't stop reading, don't stop learning, and apply those critical thinking skills that make you a good BA to your own daily tasks.
Don't forget to leave your comments below.