Confessions of a legacy business analyst

legacy1After 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 for that baby, 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 then 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 talking a completely different language. As I was listening, things started making sense and I began to realise that there is so much more to business analysis, that our profession is busy changing, adding multiple new facets, and that I’m at risk of being left behind.

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

So, let us define what a legacy business analyst is.

  •  A “recipe” for business analysis: The legacy business analysis applies the same approach to every project. Whether it is using the same old BRS template, using the exact same format for workshops every time or compiling the same set of diagrams for every project – they follow the recipe every time. On your next project, suggest to the other BA’s 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 bigger the possibility is that your BA’s 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 translate to 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 right now, 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 shoots it down first, 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 at that stage 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 BA’s I missed because of that.)

The BA’s world is changing

As business analysts, we can no longer depend on our traditional role as requirements scribe to show our value to the business organization. We have to expand the range of our skills and adapt them 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 of-the-shelf software they bought is going to change their business processes. As we were taking a break, one of them (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 the business analysts, but are the ones most applicable to me right now.

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 lately and businesses are looking for alternatives to technology as a solution 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. Read the quote from Bill Gates at the top of the page again. The approach should be to view a technology solution as the last option.

Customer Experience

The theory of customer experience is an offshoot of the latest buzz word, 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 BA’s, 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) and 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 organisation.

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 year olds. 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 doing some research on 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 6 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 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!)

Leave a Reply

Your email address will not be published. Required fields are marked *