Welcome to part 3 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 3 – where you get to learn how to survive – with grace and dignity – when everything around is looking very, very dismal.
Looking at What “Everything Going Wrong” Looks Like
A lot of projects die a passive slow death of non-use. Few projects prove so lacking in value to the organization that the code isn’t even worth maintaining on a server somewhere.
Within 12 months of finishing this project and leaving this organization (along with the key executives sponsoring the project), I learned that the servers had been reformatted and re-purposed, some perhaps even sold.
I told you it would get a bit ugly, didn’t I? Not lying, people! This is the real deal.
Let’s Start at the Beginning (or Duct Tape and Hair Ties)
It’s my first day at a new BA job. We have $1M+ in funding and big aspirations to change the way scientists search for information.
There is a business case that proves the market potential of this brand new product. I’ve never seen a business case before and spend a few hours poring over it, figuring out what we’re doing and why.
I meet with stakeholders across the organization to learn about what we do. Everyone but the product manager for this project cares about one thing – the existing business, which is making money but not fast enough, and the existing system, which is running on duct tape and hair ties.
But I’m not here to fix that system. My manager makes that perfectly clear. I’m here to build a new product that will only touch that system in very small ways – the smaller the better.
No Challenge Is Too Big with a Glass of Wine and a Big Piece of Cardboard
I set about doing what I know how to do best. I create a functional specification that contains every item the product manager can envision ever including in this new system. We pore over it for days, making sure it’s clear and complete.
The product is so big I can’t quite wrap my head around it. We have no existing technology architecture – except for the one pieced together with duct tape – and I can’t see how we are possibly going to build this.
There ends up being a rather fun solution to this problem, which gets us past step 3 of the business analysis process.
One work day, I go home a little early and pour myself a glass of wine. I get out a piece of cardboard as big as my kitchen table and some index cards. I write down features, components, and key elements of the navigation. I start piecing the project together bit by bit.
I start to see what we’re building with clarity – at least from a functional perspective. (The lesson to learn here is that the pieces are nearly always there, sometimes you just need to step outside of your preconfigured boxes to see how they fit together. In the absence of a technical team to collaborate with, I chose wine and cardboard. If you’ve ever collaborated with difficult technical stakeholders, you might be envious of my choice here. Just keep reading – you won’t be envious too much longer.)
I recreate the model in Visio (much, much later I learn that this is an example of functional decomposition) and copy it into the spec. (By the way, the Visio version of this model is included in our Visual Model Sample Pack.) It becomes a guiding light holding together the pieces and parts of the project and organizing what’s quickly becoming a mammoth specification.
Going From Concept to Solution
By this point in the project, we have hired a project manager and a technical lead. We begin to evaluate key vendors and products to help us build the technology.
The visual model I created with a little help from wine and cardboard transforms into an actual solution approach, with component names and integration points.
As an aside, sometimes it makes sense to interview vendors early in a project to learn what’s possible. Each vendor we interviewed provided some important aspect of the functionality we were looking for. Many revealed new possibilities we hadn’t thought of. The functional requirements provided a touchstone from which to analyze each vendor, and each vendor provided a strong dose of reality from which we could piece together our approach.
Evaluating vendors was all part of our discovery process and eventually we decided on a handful of tools to use as part of the solution approach.
Getting Ready for Detailed Requirements
I start writing use cases to dive deep into different layers of functionality. The product manager hires a user interface designer to help us present the complex layers of functionality in an intuitive way. I work side-by-side with him to hone the design and tweak the use cases.
We’re all set to go from a requirements perspective except for one thing. We don’t have a development team.
To make matters worse, the person filling the technical architect role leaves. Before he does, he gracefully recommends a consulting organization he’s worked with before. We hire them. We are ready to start the detailed design and start working with a new technical lead from the consulting organization.
(In retrospect, I suspect the technical architect saw the upcoming train wreck and decided to jump off the train before it got moving too quickly. But I digress.)
To keep things moving, I’ve been making a few critical assumptions up to this point.
- The development team will work from use cases.
- The requirements are feasible.
- The requirements are complete.
#1 plays out. #2 and #3 do not. While the use cases articulate what the business stakeholders want, as we get into the technical walk-throughs we end up making many adjustments so they are implementable and add new elements to ensure completeness. Many of the adjustments have a ripple effect through the use cases, so one new insight leads to many changes…and that means a lot of rework for me and the business team.
The lesson to learn here is about not making promises when you can’t control the outcome. We had gotten into such a pattern of “approving” use cases and there was so much urgency driving our progress, that I lost sight of how the functionality would be implemented. This is another unintended consequence of the so-called luxury of time we learned about in part 2, and can happen easily when you don’t have technical stakeholders fully engaged in step 5 of the business analysis process.
The second lesson is that there will be project factors that are outside of your control and impact your success. Looking back, I still think I did my best possible work given the project conditions. However, on future projects, I was much more vocal about when I needed a technical expert assigned to my projects and could speak with more confidence about the risks of not having them involved.
But Here’s Where Things Really Start to Go Wrong
We were able to recover from all of the issues we’ve talked about so far. But as we actually started to implement, things started to get ugly.
As we begin processing content, new and unexpected technical issues start coming up. At the pace we were processing content, it would be 5-10 years before the product would be ready for testing, let alone deployment.
Yet we continued to figure out user interface details for the product that will present all of this processed content to the end user. And write more use cases. And solve some complex problems about how the new system would talk to the old one.
And that reminds me of one of the more complex requirements challenges we worked through – getting the new and old systems to talk to each other. I learned firsthand how you can facilitate a technical problem solving discussion without understanding the technical design. Both teams used coding languages and database technologies I’d never been exposed to. And of course, they were both different so there was a lot of turf protecting going on.
I learned that asking the obvious questions and keeping the focus on functional needs (even in a deeply technical discussion) could create clarity and break down barriers. I also learned that just by staying engaged, I could absorb information about the technical architecture. This became useful as I worked on requirements for related functionality.
I also earned the respect of both technical teams, an asset that helped me expand my responsibilities within this company and could have led to a job opportunity with the consulting organization, should I have chosen to go that route.
Getting back to our main issue, the technical team does finally figure out how to get content into the product. Then we notice something just as problematic. The search is insanely slow. You click. You wait. (Wait as in get a cup of coffee wait.) And then you might see the results. You narrow. You wait again. The whole point is to have an interactive application that enables discovery. Even scientists don’t drink this much coffee.
At this point, I’m done writing new requirements. The only priority is to get some meaningful subset of the massive body of requirements I’ve written deployed so we can pre-sell this product to the customer.
The Value in Stepping Outside the BA Role…and the Project
There being no need for more requirements and the challenges being largely technical, I take over managing the daily work of the off-shore-test team who is submitting bugs at the rate that mosquitos propagate on a hot summer day in the Midwest. Luckily 80% of them are duplicates and I’m able to filter them down, prioritize them, and work with the technical team on solutions.
I also start helping the other areas of the business update their duct-taped-together system. These are small changes; you might not even think of them as projects, but because of the complex business rules and fragile nature of the system, each change requires intense analysis. I’m able to help speed up these mini-projects by applying BA principles.
(In part 4, we’ll go into detail about how to add value by applying BA principles to small changes.)
The lesson here is that finding a way to add value leads to career advancement and opportunity. Before I moved on from this organization, my decision to step into these roles proactively led to a promotion and an expanded set of responsibilities, despite the fact that this project didn’t turn out as expected.
But let’s finish our main story. The technical team releases something saleable. It’s still slow and buggy and partial, but it works according to some standard of success.
One person buys it. Not one organization, but one person. Expecting organizational customers, we didn’t even have a way to set up a single user in the system and had to create a work-around for him.
I think that is the only sale ever made. I don’t know what happened to his license when they dismantled the servers. By then, the train had slowed down enough for me to jump off too.
Looking at Lessons Learned
Let’s look at what I learned:
- Engage with the technologists, even after the requirements are “complete.” Although it was tough to rework use cases, add new deliverables, and be part of tense technical discussions, my continued support of and engagement in the process helped the team work through many tough issues and ensured that the decisions made represented the business objectives.
- Pitching in can be a strategic career move. Even though much of the work I took on was outside my core BA responsibilities, it helped position me for new opportunities and create lasting personal connections, some of whom I’m still in touch with to this day.
- System expertise is not a pre-requisite for success. Every piece of technology we worked with was brand new to me. Still, I was able to contribute by focusing on the business needs and desired functionality, and being open to learning about new technologies, capabilities, vendors, and systems.
Luckily for me, I survived this project and went on to develop a much stronger career in business analysis. Sometimes, we simply must learn from our own mistakes.
In part 4, we’ll switch things up a bit and look at how to apply business analysis principles to smaller initiatives – so small you might not even consider them projects.
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. Of course you can always learn from your own mistakes, but wouldn’t it be better if you didn’t have to?
