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.
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?
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!)
Powered by Facebook Comments