Welcome to part 1 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 1 – the project where I didn’t get my way, but I learned a lot about how to collaborate with other team members, break bad news to a vendor, and visually model different solution approaches.
Getting the Call
This project ended about two days before Christmas. I was doing some final shopping and the salesperson for a vendor I liked very much called to ask about the status of her contract.
My heart stopped for a minute. My manager, the CIO, was supposed to call her days earlier to break the bad news.
I thought this vendor’s product was the best thing since, well, something even better than sliced bread.
But my team didn’t and my team won.
This salesperson, who had invested months in working with us in a very reputable and non-pushy way, was going to find out from me just days before Christmas that she wasn’t getting her commission.
I sucked it up and shared the news.
But let’s start back at the beginning, because this conversation, while uncomfortable, had been months in the making.
Envisioning a Consolidated Technology Platform
Months back, we started envisioning a shared technology platform to support all of our business units in delivering core features. We had already done our due diligence in terms of understanding the current state of each unit’s technology capabilities and core business processes. We found significant overlap. We also found a lot of common issues that would be expensive to solve in 5 different technology systems.
The vision was simple: One technology platform that could be customized by each unit and would replace the existing 5 separate technology platforms.
Search was a key feature so we started exploring solutions in that area almost immediately.
We started by digging deeper into the functional requirements provided by each of the 5 existing technology platforms and pulled them together into one massive list. We engaged subject matter experts from each business unit to confirm their current requirements, as well as provide input on what they would like their future search feature to work like.
We developed a list of key requirements and skeleton use cases to confirm those requirements. Knowing that it wouldn’t make sense to build our own search engine, we began comparing products from various vendors against our search requirements.
There were demos.
Then questions about feature sets.
Then customized demos.
Then detailed technology questions.
Then technology due diligence.
And finally, there were pricing discussions.
Along the way we discovered that to select the right search tool, we also needed to figure out aspects of our content management and taxonomy management strategy. For a few weeks we went down that rabbit hole and looked at yet another set of technology components we’d eventually need to invest in.
Finding a Solution Approach
After a mountain of analysis work, we came up with two feasible solution approaches, part of step 3 of the business analysis process.
- One approach involved committing solely to one vendor whose product provided about 90% of our core requirements. We had the option of integrating in a taxonomy component later to meet the rest of our requirements. The benefit of working with the first vendor is that we’d receive 90% of the functionality we needed already integrated together.
- The second approach involved integrating three different components to meet 100%+ of our core requirements right away. The second approach also gave us unexpected functionality that we could envision leveraging in the future. It was available at a lower price point, but it involved significant in-house development to make it all work.
The decision about which solution approach to move forward with crystallized with an impromptu whiteboard session. The Lead BA and I were talking through the options (not yet having come up with clarity on what those were). The architect floated in. We drew components. We drew circles around different approaches involving different components. We highlighted business benefits, costs, and risks.
Together we began to see the two options clearly. The architect strongly favored #2. I favored #1. It became clear we were going to present our final decision as a result of this discussion, so we called in two other key members of the technology team and the project manager.
Getting Alignment on the Go-Forward Approach
We talked through our options and clarified the pros and cons of each.
The result was beautiful and utterly incomprehensible to anyone who walked into my office without context. I left the drawing on my whiteboard for over a month and explained the visual model to anyone who asked about it. It proved to be a great tool to let others know how carefully we had made such an important decision.
This picture is still in my memory as one of the best white board drawings I’ve ever helped create, and one of the best examples of collaborative decision-making I’ve ever been a part of.
I’m glad I have this good memory because I still wanted solution #1. But everyone favored solution #2 – except me – and their reasons were good.
In the end, the completeness of the solution, the flexibility we’d have in integrating them together, and the lower price point were the team’s rationale for suggesting solution approach #2 to our CIO, who took the team’s recommendation and signed the appropriate contracts.
Looking at Lessons Learned
Let’s look at what I learned:
- Visuals communicate more clearly than words. We had been discussing the decision for weeks and not getting anywhere. The whiteboard drawing finally enabled us all to clearly communicate our concerns, perceived benefits, and have a meaningful conversation around the options.
- You don’t always get your way. The collective intelligence of the team supersedes your individual intelligence. If you’ve made your case to the best of your ability and it’s not convincing people you trust and respect, sometimes it’s better to let go of your opinions and align yourself with the team.
- Technical solutions must be considered against business objectives. When we were only looking at technical options, the solution picture was incomplete. It wasn’t until we were able to visually overlay the business objectives, features, and solution components together that we were able to make an informed decision. (The business analysis process asks you to define your primary business objectives before your solution approaches for a reason.)
That’s where we’ll end today’s story. Next you’ll receive Behind the Scenes #2, which will look at how to recover from some very common business analyst mistakes.
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.