282244_gun_2

Sometimes the benefit of completing and implementing a solution just doesn’t justify the cost. Or, despite the best of intentions, a project will be implemented that just doesn’t end up solving the problems it was intended to.

Unfortunately, in many cases an organization will spend months-worth of time and other valuable resources on such an implementation before coming to either realization. When this happens, the company has to cope with not only with the sunk cost of resources spent on the abandoned project, but also the opportunity cost of what those resources could have been used for otherwise.

So, how can situations like this be avoided? I could give a long answer, but I’ll keep it nice and short: Business Analysis.

Root cause analysis, business case justification and definition of clear and reality-based objectives are all fundamental business analysis functions. By performing them well, and early in the process (the earlier the better!) we can help our customers have confidence that we’re on track to solve the right problem in the right way, which gives them the best possibility of realizing the return on their investment.

There’s a commonly-held truism in the industry that the earlier a defect is detected in the life of a project, the cheaper it is to correct. That being the case, what better time to avert these ill-fated projects than before they even get started!

As analysts, it’s widely known that we produce specifications. We hold meetings, ask a bunch of questions, create nifty diagrams, and lots of other things. What I think is less widely known – or at least acknowledged – is the value that a good analyst can provide before a work request is even submitted.

Personally, I feel every bit as successful when I help save a customer from the sunk and opportunity costs mentioned above by scrapping a project before it gets started as when I help see a project through to successful implementation. In either case I’ve provided real value not only to the customer, but to the delivery organization as well.

To be able to do this, the BA needs to be “in the loop” early as a trusted adviser to the business and empowered to ask the types of challenging questions that can either reinforce a strong business case, or dismantle a weak or misguided one.

So, have you ever “killed” a project? Are BA’s in your organization involved in the process early enough to head off projects that shouldn’t be undertaken? Do you agree that it’s the business analyst’s role to get involved at such an early stage?

I’ll be interested to hear your thoughts and comments.