Business Analysis should be a visible cost

A story of derailment in outsourced tech projects I’ve seen all too commonly in business of all sizes is this:

The business has a problem that’s been festering for a while. The problem is important and urgent enough that all the stakeholders agree that it must be solved asap.

Because there is such a wide consensus that this is a burning problem, not much thought is given to analyzing it formally and in more detail. Why is this a problem? Can it be broken down into smaller constituent problems? What are the root causes of this problem? What are we doing to get by, that is, how are we solving this problem right now, even if sub-optimally? Etcetera, etcetera.

The affected stakeholders think they know the answers to these questions. Writing everything down sounds very boring, and they are legitimately busy, so very little time is spent in explaining the issues and documenting them. Formal business analysis is foregone.

The organization doesn’t have in-house developers, or if it does, they are completely busy for the next decade or two, so they don’t take requests. And if they did, they’d promptly reject the issue, because there is no strong case for this being a problem - seeing as business analysis has been foregone, the devs, perhaps rightly, dismiss it as a non-issue, or at best bury it somewhere in the unholy Babel tower that is their backlog.

But the business stakeholders all agree: there is a problem, it’s important and it’s urgent. So senior management agrees that if need be, money will be spent on solving the problem.

Agencies are then contacted and given a summary of the problem. Remember, we have reached this stage without formal business analysis, so the brief is at best a page or two summarizing the problem. Unlike internal development teams, agencies will not push back on your ill-defined problem: rather, they’ll welcome you with open arms, like the inn-keeper on the less-travelled road waving to approaching adventurers in the distance.

There are initial meetings, the tailwinds are strong, and the mood is joyous. Finally, the business will see a solution to their problems. The agency, on their end, is excited about the new revenue, and the prospect of adding a new logo or a flaming new project to their portfolio.

Now, the business wants to get the answers to two basic questions: how much will this cost, and how long will it take? These are important questions indeed, and difficult to answer in the best of circumstances. But to make things more difficult, the agency is still in the pitching stage, so they’re not making any money yet. They are asked to estimate with extremely limited information, because remember: we have foregone formal business analysis.

At this stage, the agency faces a difficult choice. Either they tell the customer that they need way more information to scope this properly, and that the customer needs to possibly wait a few more weeks and spend resources on better understanding the problem. Or they come up with a nebulous solution design that throws a lot of trendy logos around and quotes an estimate that sounds reasonable to everyone involved, hoping they’ll be able to bridge the analysis gap on the fly. The agency knows deep down that there is a lot of uncertainty associated with the project, but they will not allow that to ruin a good moment. Inshallah, good vibes, and high fives all around.

The project starts, and the strong tailwinds continue. Frameworks are scaffolded, the first code is written, the customer is deeply impressed about seeing a slice of the solution so fast.

Business analysis was nevertheless foregone, so it’s now being done on the fly. The agency is uncovering new requirements haphazardly in videocalls while they are juggling all the other plates related to development.

Everything looks good, until a critical requirement is discovered a couple of months into development. It is obvious that the fluxonator has to fluxonate, says the customer. Well, I’ve reviewed our comms history, and nowhere did you say that the fluxonator had to fluxonate, says the agency project manager. Well, I didn’t tell you because it was so obvious! How did you not know about the fluxonation of the fluxonator?

From there on, everything starts to sour. As it turns out, accommodating this requirement in the solution is not that easy. In the best of cases, it will mean a lot of work for the agency. In the worst case scenario, the entire solution is compromised, because a lot of technological decisions made upstream have been wrong.

The customer on their end doesn’t yet know that the agency is freaking out about the ramifications of this new requirement, but they sense that something’s wrong, so more eyes are laid on the project. Someone finally takes business analysis seriously and starts the process - a few months into development.

The story can end in a variety of ways; this is truly a choose-your-own-adventure affair from this point on. Maybe the agency and the customer go into a deep rabbit hole trying to retrofit fluxonator fluxonation into the system, at great cost and with an end result that compromises project adoption. Maybe new critical requirements are identified, now that we’re taking business analysis a bit more seriously, and there are talks about rebuilding from scratch. Perhaps the agency is fired amidst empty legal threats, or in a more peaceful resolution, the project slowly goes to die to the elephant cemetery of unfinished technology projects.

What’s common to all scenarios is that tens or hundreds of thousands go down the drain. [Tens of millions, perhaps, if you’re working on something of the scale of the failed Hertz website rebuild at the hands of Accenture] (I’m sure that story had way more complex causes and ramifications, but I wouldn’t be surprised if it shared some elements in common with our story here). The agency, despite invoicing 50% upfront could very well be in the red at this point, so despite the customer’s impression that they’ve been swindled, it’s quite common for everyone to lose.

But above all, the worst costs are psychological and cultural. The prevailing feeling is one of unrecoverable time lost. In the worst of cases, a collective sense of hopelessness remains in the business, affecting its ability to solve the original problem - and possibly other problems - through technology.

The moral of the story is simple: don’t skimp on initial business analysis, neither in time nor budget. Business analysis has value, and we’ve known this since the dawn of software. Agile methodologies subverted traditional approaches to project management, with the Agile Manifesto stating as one of its core tenets:

“Working software over comprehensive documentation”

And as a hacker, I could not agree more. But in no way does that imply that initial business analysis (and solution design) should fly out of the window, or that it should be entirely improvised live. It is inevitable, and therefore normal, for new business requirements to surface during development. What isn’t normal, however, is for critical requirements that could’ve easily been identified ahead of time to surface months into development. Business analysis follows a Pareto-like law where 20% of the initial work can reveal 80% of the critical conditions necessary for project success, and you’d be crazy not to reap these benefits.

If business analysis has a value, and assuming that things in life - much less in the business world - are rarely free, then it follows that business analysis must also have a cost. So if you’re a business stakeholder managing a tech project, take note of this: someone must be paid to do it, whether it’s an internal person or team you already pay, or an external agent. Explicit cost should be used as a proxy metric to ensure that the activity is actually being carried out. Or in other words, heed this improvised blues: if you’re not paying, then it’s time to start worrying, because it ain’t happening.

And if you’re an agent, don’t take on projects with poorly defined requirements, whether it’s at a fixed rate, or at an hourly rate where the customer thinks that they’re only paying for the development, since the result will largely be the same for them. I completely understand the pressure of closing new business, but you’re assuming undue risk that may blow up in your face. Take this as an opportunity to develop and sell a new service line. Business analysis and solution design can be much more profitable than development, with commensurate value created for the customer, despite any initial reticence. Take my word on it.