Skip to main content

Author: Jaco de Goede

Are the Business Analysts Becoming the Bottleneck?

Written by Jaco de Goede on . Posted in Articles. 1 Comment on Are the Business Analysts Becoming the Bottleneck?

One of the advantages of doing so many short-term assignments at different companies is that I’m exposed to several different business analysis teams with different methodologies, cultures and problems. There is one complaint that I’ve heard at a number of these companies, irrespective of the methodology used or company culture:

“Sorry, we can’t start the project yet, we are waiting for the BA.”

At first I saw this as an indication of how valuable we, as business analysts, have become and how few business analysts there still are. But then I was contracted to do some business process work at a company with sixty business analysts. And I heard the same complaint. There was a backlog of projects waiting for BAs to be assigned and projects were being postponed because the analysis was more complex than expected.

This comment, from a blog I recently read, articulates the problem in a very practical way:

“I dread getting a call from a business unit to discuss an issue or problem they are having…. I’ve got no one to send them who can have an intelligent conversation. All I can do is send them a consultant.

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.

Sound familiar?

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.

Confessions of a Legacy Business Analyst

Written by Jaco de Goede on . Posted in Articles.

After printing your requirements document, do you normally walk through the office looking for a heavy duty stapler or a really big punch? Or, like me, do you actually own your own heavy duty stapler AND a really big punch?

The last requirements specification I wrote was a beauty: It took me five months to produce over 300 pages of as-is and to-be business processes, describing the entire enterprise to the last detail. I couldn’t find a stapler big enough after I printed it, so I eventually split it up in eight different documents. Today, it is saved somewhere on a SharePoint folder, not read, not signed.

You see, the project changed direction during those five months, and there wasn’t enough time to keep the documentation up to date. And the stakeholders started involving some other people. People who, in my opinion at least, knew absolutely nothing about requirements definition. But I had to listen to them as the project stakeholders were listening to them even though it sounded like they were speaking a completely different language. As I was listening, things started making sense, and I began to realize that there is so much more to business analysis, that our profession is quickly changing, adding multiple new facets, and that I’m at risk of being left behind.

But at least this sad story has a happy ending. Does some of it sound familiar to you? Are you at risk of becoming a legacy business analyst?

Let’s define a legacy business analyst.

  • A “recipe” for business analysis: The legacy business analyst applies the same approach to every project. Whether it is using the same old BRS template, using the exact same format for every workshop or compiling the same set of diagrams for every project, they follow the recipe every time. On your next project, suggest to the other BAs that you don’t compile a context diagram—you’ll quickly identify the legacy business analysts from their reaction.
  • Big requirements up front: The longer the requirements phase of your project is, the greater the possibility that your BAs are legacy business analysts. The legacy business analyst has to get ALL the requirements before he (or she) is satisfied. The reality is that sometimes we don’t have that luxury. Sometimes the external pressures on a project mean that 80% or even 70% of the requirements will have to do, and we’ll figure the rest out as we go along.
  • An Agile objectionist: It’s not just Agile, it’s every new methodology. Agile is the one that everyone is talking about, and it is what the legacy business analyst is objecting to right now. But every time an alternative to traditional functional business analysis is suggested, the legacy business analyst is first to shoot it down because it doesn’t fit the recipe.

(OK, another confession. Some time ago I was responsible for interviewing every business analyst who applied for positions at my employer, and there was one question that I always asked, the question that really mattered: “What goes in the table of contents of a requirements specification?” Ouch, I wonder how many potentially great BAs I missed because of that.)

The BA’s World Is Changing

As business analysts, we can no longer depend on our traditional role as a requirements scribe to show our value to the business organization. We have to expand the range of our skills and adapt to find the best solution to each business problem we face. Because, our primary responsibility is to solve business problems, not implement technology.

I spent a large part of my day yesterday leading a workshop with a group of business users to figure out how the new off-the-shelf software they bought is going to change their business processes. As we were taking a break, a senior business manager asked me:

“What are you? A project manager?”

“No,” I answered, “I’m a business analyst.”

“But I though the business analysts are the ones that do the technical documents for IT?”

I didn’t have enough time to answer that one.

There are three alternative approaches that I currently focus on. They are definitely not the only alternatives available to business analysts, but they are the ones most applicable to me right now.

Business Process Management

Business Process Management (BPM) is not new and business process re-engineering even less so. But it seems that every time there is a downturn in the economy there is a renewed focus on BPM. Lean Six Sigma has become popular again, and businesses are looking for alternatives to technology as solutions to business problems.

The increased maturity of business architecture also compliments BPM and enables us to really evaluate the business (and technology investment in the business) critically. My favourite quote by Bill Gates is:

“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second rule is that automation applied to an inefficient operation will magnify the inefficiency.”

The approach should be to view a technology solution as the last option.

Customer Experience

The theory of customer experience is becoming very relevant with the advent of Big Data, and I interpret its impact on business analysis as “Treat your customer’s customer as if he is your customer.” You may think that this doesn’t really affect us as BAs, but here is a real life example: Quite a bit of my 300-page BRS mentioned above is dedicated to the requirement that customers must register on the website before they can purchase anything, what information they must provide, how their password resets work, etc., etc. That’s a given, right? The “other” people applied the principles of user-centric requirements (it’s not a new concept—the textbook I now have on user-centric requirements was first published in 1998). Their first requirement was that customers don’t want to register and log in every time to buy because they are used to the Amazon “1-click.” Somehow that makes sense, doesn’t it?

Going Agile

If, like me, you are not a real fan of SCRUM, have a look at Disciplined Agile Delivery, developed by Scott Ambler and Mark Lines. I think it’s time that business analysts, instead of opposing going Agile, start advocating Agile methodologies in the IT organization.

The Next Wave

What’s next? What do we have to prepare for?

Firstly, the first iPhone was released in 2007—when some of your business users were 14 or 15 years old. The big impact of smartphones and tablets on business analysis is that they change the way our users view the applications we design for them. So we have to start considering that our users will expect to interact completely differently with business applications.

Secondly, the one I’m researching at the moment is gamification, a concept borrowed from gaming platforms suggesting that users are “rewarded” for interacting with an application in the expected manner. It sounds a bit fuzzy, but the biggest investor in gamification in the world at the moment is SAP. Later this year SAP will launch its first gamification platform, so maybe it’s worth looking at.

Lastly, my son is six years old this year. I still want to be a business analyst in 15 years’ time when he will probably enter the job market. The way he interacts with technology, and is going to interact with technology in 15 years’ time, is completely different from the way I interact with technology. As a business analyst, I must never stop learning and never stop reading so that I will be prepared for that day. (If you really want to blow your mind, go have a look at Makey Makey—he’s definitely getting that for his next birthday!)

Don’t forget to leave your comments below.