Welcome to part 2 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 2 – where you’ll learn why more time for analysis is not always a luxury, and how to engage new stakeholders even when it feels mighty uncomfortable.
Jumping in as a Brand-New, Just-Hired Business Analyst
Once upon a time, I was a new business analyst, fresh off the “just hired” presses and transitioning out of my quality assurance role. After a few months impatiently shadowing a senior BA on our team, writing up her notes, and updating her documentation, I was finally assigned to lead a project.
I was so excited I could barely stop myself from digging into drafting the requirements spec over the weekend.
A project!
Of my own!
Woot!
Then something kind of crazy happened. As I started reading background material and learning about the objectives, I realized that this project had the potential to be the biggest project I’d ever seen at this company. (As a QA engineer, I’d worked on over 30 projects, so I had a diversity of experience to draw from.)
There were at least 3 new significant features that I’d never seen done on our platform. And, well, the product represented an entirely different business model than our other offerings.
Looking at this project through a technical lens, I couldn’t help but wonder if this was all really doable and how it would work on our existing platform.
My head started spinning.
And did I mention I was a brand new business analyst? Although I had critiqued many requirements documents and now updated a few, I’d never actually written one before. Come to think of it, I had never discovered information about the scope of the project before, or sat down 1-1 with a business sponsor, or kicked off a scope discussion with a technology team…
Or.
Or.
Or.
But over ten years later, this product is still in use. So I say we did something right in putting the first phase out into the marketplace.
Let’s look at how this project unfolded.
Receiving the Mixed Blessing of Time
Most BAs crave more time for discovering and analysis and as a new business analyst, I was no different. I had well over a month to meet with the sponsor and deeply understand everything she wanted the product to do.
Looking back, I see this as a mixed blessing because while I had time to get oriented around the project before being on the hook for a deliverable (that’s step 1 of the business analysis process), no technologists were engaged. The meetings were limited to understanding what was wanted, not what was possible.
To make things worse, I still had half of a technology hat on and I had trouble moving forward without seeing how this would work. So I did something that felt incredibly smart. I put together a solution approach.
You see, in QA, I’d learned how the systems worked. Since this product would be built on those pre-existing systems, I thought I could figure out the technical design too.
Big mistake.
Jumping forward to the project kick-off, I had a first draft of a 50+ page requirements document and a technical approach mapped out.
When it came time for me to talk about scope, I talked about the solution. And, well, the developers weren’t so keen on my ideas.
We had no choice but to take a step back.
Finding the Solution Approach
As a project team, we independently looked at each feature the product manager requested. In the end, after a lot of discussion, brainstorming and decision-making, we came up with a solution approach that was very, very close to my initial idea.
You might think that I felt validated, but I actually learned a very important lesson I’d like to pass on to you.
My ideas didn’t matter if the team didn’t embrace them. As a business analyst, it wasn’t really my place to tell the technology team how to solve the problem, no matter what kind of expertise I had.
My rookie mistake was to analyze too far forward before getting the technical team involved, a challenge we’ll see me face again in part 3 of this series, but handle in a different way.
Technical approach in hand, I began to analyze the detailed requirements in a large body of use cases. I established a rhythm of two meetings each week and we were making consistent progress. In the end there were more than 40 use cases in total, covering two different systems.
That reminds me of another kink in the requirements process for this particular project.
Making Sure You Discover All of the Impacted Systems
Traditionally, my business analysis team worked on the customer-facing aspect of the product – how our end users searched, retrieved, and used content online.
But for this project, we needed an entirely new business model. Even with my newbie hat on, I sensed this was a big deal and not something I could skirt over in the requirements process.
In the end, we ended up touching systems I didn’t even know existed at the start of the project, and touching them in a bigger way than any project my BA team had worked on in the past.
I decided to form a small side team to work on this aspect of the requirements. We began plugging away at identifying the key requirements, figuring out the solution approach, scoping the detailed requirements, and finally, designing the system.
To ensure success, I also needed some very high-level stakeholders and this was mighty uncomfortable at first. Here I was, a very new and very young professional in this organization inviting the VP of I don’t remember what to a meeting to talk about the Siebel system I’d never even seen before.
I couldn’t get a sense of the current capabilities because the details of this system were undocumented and access extremely restricted.
Typically, this VP dealt with an entirely different side of the business. She had no idea how my team worked, let alone what I was responsible for.
- I learned to facilitate meetings even when I felt unprepared with people I didn’t know and use those discussions to focus on discovering information, since there was no background material available.
- I learned to focus on what capabilities we needed and step aside from understanding every aspect of how those capabilities would be addressed.
- With coaching from my project manager, I learned how to break down an unknown into a sequence of steps I could take and forecast a reasonable timeline, even when I knew very little about what I would discover.
(All of these learnings have made it into the 8-step BA process we go through in detail in the BA Essentials Master Class.)
In the end, we successfully implemented the new business model by touching at least 3 different systems owned by technology teams that were not used to working with each other.
But even then, my job as a business analyst was not complete.
Seeing Things Through, Changes and All
As the development team began working in earnest, there were changes – lots of them. Functionality that seemed feasible when they approved a use case proved not to be so.
Most of the changes were just big enough to merit input from the business sponsor, but not so big that there was a lot of contention about how to resolve them. Ideally the technical team would have thought of these issues before they approved the requirements. But as we know, the real world is not often a good match to the ideal world. We were all doing our best work.
Although small, the changes did need to be analyzed, decisions needed to be made, and, most importantly, decisions needed to be communicated. By being involved in the decision-making process, I saved a lot of wasted time due to miscommunication that could have extended the timeline or further reduced the scope.
This is why the business analysis process does not stop when the requirements are defined and approved. As a BA, it almost always makes sense to be engaged after the requirements are complete. But how to stay engaged differs from project to project. In lesson 6 of the BA Essentials Master Class, you’ll learn all the ways you can stay engaged so you can choose the ones that make sense for your particular project.
And, by the way, the launch went out without a hitch while I was on vacation in Seattle and Portland.
Looking at Lessons Learned
So what did I learn from this project?
- Avoid figuring out the solution approach on your own. Project team members need time to absorb the key requirements, allow their creative energies to work on the problem, and be involved in the brainstorming and decision-making process. Going forward, I took a much more collaborative stance from the very beginning, even when I thought I knew what system design would work.
- You are never too new to be successful. I was lucky to have a trusted set of templates and business analysis approach to follow, the support of two strong mentors all the way, and work in a mostly collaborative organization. But in the end, I was able to make a very solid contribution, one that I’m still proud of, and that’s because I was constantly investing in doing my absolute best work.
- Time is not always a luxury. With too much time and too little involvement from other project team members, the business analyst risks getting ahead of other project team members and losing the value of a collaborative approach. (I’ve experienced this in multiple phases of the project, not just the initial phase.)
So that’s my first project. I made some rookie mistakes but I’m darn proud of what I accomplished. Stay tuned – in part 3 I’m going to talk about a project where external factors made survival, not success, the primary goal.
It will get a little ugly because, well, real projects do get ugly sometimes and we all learn best when we learn from our mistakes. I’m going to let you learn from mine. (And I’m still here, so I’d say I survived.)
While you are waiting, 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.