Welcome to part 4 of our 5-part Behind-the-Scenes in Business Analysis series where I’ll walk you through how I’ve handled some of my most interesting business analysis projects using the business analysis process.
Part 4 – where we look at what to do when the business stakeholders have already told the developer everything they think he needs to know and, more generally, how the business analysis process still applies on changes that take less than a week to implement.
Learning a New Business Domain
Once upon a time, I got called back for a repeat engagement with a client. The first project had been one of those big, strategic initiatives that changed how the organization did business. It was also agile. (We’ll actually talk about this initial engagement in part 5, so I don’t want to get ahead of myself now.)
The second time I got called back, all I knew going in was that there were some communication issues between business and software development in a different business unit than I’d worked with previously. And wouldn’t I please come in and help clear it all up?
Yes, of course! That’s exactly the kind of situation where a business analyst can add a lot of value.
I spent the first two days getting a detailed demo of the existing process and system from a very nice fellow on the business team. He is and was one of those subject matter experts that gets pulled in 20 directions because he knows just enough about everything to solve all kinds of interesting problems.
I don’t know how he spared 3 hours of his work day on 2 consecutive days with me, but he did. And I was grateful.
Without any process or system documentation, this series of demos was my grounding or “getting oriented” into the system and the business process (which just so happens to be step 1 of the business analysis process). I took copious notes and followed up these demos with my own exploration of the system.
Lesson learned: When you can get access to the right business subject matter expert (or sometimes experts) you can learn about the current state very, very quickly.
Clearing Up the Communication Issues
But there are changes to make to the system and that’s really what I’m here to figure out. The project manager organizes a short meeting to introduce me to the rest of the business stakeholders. They speak vaguely of the meeting they had 2 or 3 weeks back to discuss a set of changes they still haven’t received from development yet. They want to know the status.
The PM says the developer (we’ll call him John) is waiting for information. The business says they are waiting for John to deliver.
The problem becomes clear. I volunteer to talk to John to see what he needs. I need to get to know him anyway to understand his perspective on how the system works and how I can help him from a process perspective.
It turns out that nothing has been done since the meeting a few weeks back. John has been waiting for the business to clarify what they want and he senses that what they need is actually something much bigger than what they asked for.
My BA alarm bells start going off. I’ve seen this situation before. Lots of discussion. Lots of ideas. No commitments. And most importantly, no accountability and no meeting notes.
Being the Bearer of Not-So-Good News
I go back to the business and let them know we need to have the discussion about what they want, again. Yes I talked to John and John says he doesn’t have a clear understanding of what you want.
I get a very typical response: But he was writing down notes? Perhaps, I say, but he doesn’t have all of the information he needs to ensure he solves your problem. I know it’s going to be painful, but I think the fastest way forward is to start from the beginning and have you share with me what you want. I promise to write it all down and make sure it gets to John so he can get started as quickly as possible.
When you have these discussions, it’s important that everyone gets to save face. I was careful not to damage John’s reputation while also being careful not to make the business stakeholders feel like they screwed up. Even though I am here to rescue the team from this miscommunication issue, I’m not going to be making any friends if I start playing hero. Instead, I am apologetic for the situation they find themselves in, and clear about what I think I can contribute.
We have the meeting. It’s clear in the first 5 minutes that John was right. The 3 primary stakeholders, each representing one business team, all have different ideas. Even though I don’t know the system all that well, it’s obvious their ideas don’t fit together.
We go back even another step – what problem are we solving here?
Ah, that gets the answer we need. Fundamentally, this is a reporting issue. But we’ve been talking about changes to the business process and what data fields are available to log specific kinds of issues. I start to see the big picture and know that I can lead them through this.
The lesson learned here is that even if there is a project history, if everyone can’t share a consistent story, it makes sense to start right back at step 1 of the BA process, even when it’s a little painful.
Getting to the Root Cause of the Real Problem
The end result of all of this discussion is a collection of development work that takes John maybe a week. Within three weeks of my arrival on the scene, we are able to deploy the change into production.
Luckily for me and my salary, the business needs don’t stop there, or this would have been a very short contract. For the next 6 months, we continue to make small changes and deploy releases every 2-4 weeks. I invest most of my time getting these same three stakeholders to see each other’s perspectives and figure out how they will work together.
The fundamental source of all of their problems is that they deployed a business intelligence reporting system without fixing their business process. They have fancy, I mean very fancy reports, with up-to-the-hour data that give them the wrong information or no information at all. We are fixing that situation one small step at a time.
A nice little side lesson here is that if your data is the output of a flawed business process, it’s not going to tell you much “intelligence” about your business. This sort of situation typically comes about when you focus on the technology part of the solution to the expense of the actual business problem to be solved.
But I digress. Let’s get back to our story, because there is a bit more learning I’d like to share with you.
Validating Requirements (Here’s a Bit of BA Heresy)
Typically, when I validate requirements, something that’s covered in step 5 of the business analysis process, I ask stakeholders to walk through written documentation and approve the words-as-requirements. I tried this approach 3 or 4 times with this business community before I set it aside.
Even if I printed out a half page document and put it in front of them, they wouldn’t read it! It was maddening. Here I was investing time in getting the words right, and they preferred to talk amongst themselves and go in circles about how everything was going to work.
Finally, I realized my approach wasn’t working and wasn’t likely to work any time in the near future. I also realized, that even this lightweight formality wasn’t really necessary. These were very small changes and I could take a few shortcuts without introducing much risk.
I noticed that when I put together a wireframe and projected it up on the screen, the stakeholders were engaged and we had much more focused discussions. So I started putting together a wireframe for each and every request and then structured my written requirements around the wireframe.
Here’s the part that’s a bit of heresy in BA circles. I stopped sending the business stakeholders the written requirements. They never saw them.
- I created them – for myself and the developer.
- I printed them out for my own use during the meetings.
- I spoke to them to generate feedback.
- I updated them based on input.
- I uploaded them into our development tracking system and they were used to provide implementable requirements to John.
But the business stakeholders never actually saw them.
Because the changes were small, we could use the wireframe to talk through them. In fact, often the wireframe brought up issues and impacts I hadn’t expected, so we actually got further faster without the written specs being the cornerstone of discussion. Of course, this approach did put a lot of burden on me to make sure I translated everything I heard verbally into written requirements.
I wouldn’t recommend this approach for a large project or large piece of functionality, but it worked really well for the tweaks and adjustments we were making. It’s something you might keep in your back pocket for a similar situation.
Looking at Lessons Learned
Let’s look at some lessons learned:
- When rehashing a discussion, show results as quickly as possible. No one likes to do rework. Often stakeholders already perceive time in meetings as wasted time. Still, scheduling yet another meeting to discuss something that’s already been discussed can be necessary. When you find yourself in this position, take care to over-communicate your next steps and get to some tangible result as quickly as possible. You’ll build personal credibility that will drive the project momentum forward.
- Be flexible with your business analysis approach. The requirements documentation approach that ended up working best for this stakeholder group was not something I’d recommend as a global best practice. But it worked, really well, for this particular context. I figured it out through trial and error and iteratively incorporating feedback until we found a way that worked.
- The business analysis process applies to small changes. Even though each change we discussed took on average 2-5 developer days, we had to go through the 8-step business analysis process. We figured out the business need, the solution approach, and the detailed requirements. Because the changes were small, we sometimes were able to do this all in 1 or 2 meetings. Some aspects of the process, like getting oriented and planning out the BA approach didn’t have to be repeated for every small change, as the work done for the initial set of changes extended to future changes.
That’s all for part 4!
In part 5 we’ll be looking at an agile project. In fact, it’s a project I worked on that switched to agile seemingly out of the blue. As a business analyst, you must always be ready for kinks and surprises. This project had both.
In the meantime, you can check out the BA Essentials Master Class, where you’ll learn how to navigate the 8-step business analysis process to handle any project like a pro.
