Business Analysis Can Kill a Project (In a Good Way)

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.

About the Author

Jonathan Babcock is a management and IT consultant with expertise in business analysis, process optimization and solution delivery methodology. Practical Analyst is his outlet for sharing what he's learned, and for interacting with solution delivery professionals across the globe.

Author Archive Page

18 Comments

  1. A friend told me of a conference in which the presenter asked the 2000+ people if anyone had done analysis to find out if a project was even worth doing, and about 50 hands went up.

    He then asked people to keep their hand up if they found the project was not worth doing. About 20 hands were still raised.

    He then asked people to keep their hands up if the project was then canceled based on this finding. No hands were still raised.

    So why do we do projects even when analysis suggests we shouldn’t?
    I have heard some real mind boggling reasons, like these:

    1. Because we said to the board we would do it, and we are not going to the board to tell them otherwise.

    2. We have to spend our budget or we don’t get as much next year.

    Hmmn.

    Robert L. Glass has a great book “Facts and Fallacies of Software Engineering” that describes these types of situations and the fallacies that typically lead to rather questionable decisions.

    Rgs, James.

    1. Thanks for posting that comment, James. It certainly reinforces the ideas I was trying to get across, and speaks to a lack of awareness of the value of solid business case and feasibility analysis upfront.

      And I will look up that book, too.

  2. I agree with this article and have been in this situation. The project I was working on wasn’t killed though, it was pushed through and did not successfully meet the needs the business intended. I saw that and tried to convey it but the problem I ran into is that executive management set an objective and everyone scrambled to “get her done” no matter what. We were all under such pressure that no one wanted to risk missing the deadline for the item to be delivered.

    So as a result, we live in a business world where poorly developed projects are implemented because no one wanted to miss a deadline. Somewhere along the line, a decision is made to meet the deadline and fix the problems later. The problem with this is that if we’re not fixing the right problem, we’re creating a much bigger monster to slay!

    I think the ultimate culprits are 1) not understanding what a Business Analyst is and should do, 2) executive management making nuts and bolts decisions that are best served by the SME’s and 3) the lack of courage to acknowledge that we’ve been barking up the wrong tree and being willingness to redefine the problems we are trying to solve.

  3. I agree with this article and have been in this situation. The project I was working on wasn’t killed though, it was pushed through and did not successfully meet the needs the business intended. I saw that and tried to convey it but the problem I ran into is that executive management set an objective and everyone scrambled to “get her done” no matter what. We were all under such pressure that no one wanted to risk missing the deadline for the item to be delivered.

    So as a result, we live in a business world where poorly developed projects are implemented because no one wanted to miss a deadline. Somewhere along the line, a decision is made to meet the deadline and fix the problems later. The problem with this is that if we’re not fixing the right problem, we’re creating a much bigger monster to slay!

    I think the ultimate culprits are 1) not understanding what a Business Analyst is and should do, 2) executive management making nuts and bolts decisions that are best served by the SME’s and 3) the lack of courage to acknowledge that we’ve been barking up the wrong tree and being willing to redefine the problems we are trying to solve.

    1. Thanks for the comment, Tai. I think projects like the one you mentioned are exactly the type that end up in the “unsuccessful project” category on industry studies that cite such a high instance of unsuccessful projects. Some of them were doomed from the beginning.

      I like your 3 points. I would add for #3 that it may not be redefining the problem as much as identifying the “right” problem and analyzing it correctly.

  4. In the 30 odd years I’ve been in IT, the BA could make a case for a certain rationale (PRO and CON) but the actual decision for ‘killing’ a project was and remains an executive decision. All projects do not have to be cost-effective – if they are mandatory for the survival of the company. There are projects that will not see a ROI until about 5 years after implementation, especially where new equipment has to be installed and the project rolled out nationwide. The projects I’ve seen that did not solve the problems were initiated with the expectation that the hardware and communication lines, training, etc. would be available at the time of implementation, not because there was no initial analysis. If this is your experience, then the process of checks and balances is not there, and too much responsibility is expected from the BA.

    One thing to bear in mind, is that rework is core to being a BA and no system will ever be 100% perfect. When you are working in a highly competitive industry (like banking, telecommunication), time to market is extremely important and it could become necessary for the project team to carry out a triage of the deliverables to beat the competition. If you follow the waterfall cycle in your development methodology, the requirements must be constantly modified and by the time you are ready to implement, the original requirements have changed drastically – that is, the customer requirements have changed over that time and it is reasonable to conclude that you have not delivered what you set out to do.

    I’ve been working in the business analysis field since the mid 1970s, when there was really no name for it. Subsequently I’ve worked as a Business Systems Analyst and Project Manager, all in the same company, within a very ‘structured’ environment. Our BA’s work closely with the business sponsors and IT project teams, ensuring that every document prepared is walked through and clearly understood and signed off. Then these documents are reviewed and signed off by a senior executive, therefore, for our BA to ‘kill’ a project could possibly have some kind of legal ramification. (I’ve seen PM sued after project cancelled)

    1. Thanks for stopping by, Rosebud. I appreciate the feedback.

      I guess it’s a subtle distinction – and I can see where my wording may have lead you to interpret it otherwise – but my point was not to imply that a business analyst is in a position to be able to pull the plug on a project, but that good business analysis (with the BA in an advisory role) can help executives make informed decisions as to whether scarce resources should continue to be spent on a project when the business case just doesn’t look like it’s going to hold up.

      And I’ll grant you the facts that some – especially strategic/foundational – initiatives won’t see an ROI right out of the gate, and that some essential projects are not cost effective.

      I have to imagine, though, that in your 30+ years in IT that you’ve also seen some projects are just flat out ill-conceived and would have been better off never having been implemented. Those are the types of projects to which I’m referring.

      1. Hello. Good to see that you read my feedback and made a minor clarification.
        Yes, I’ve lived though a lot over the years including a situation where an incoming senior VP thought that BAs or BSA’s were not required and he laid them off. Programmers just started coding and implementing – and you’ve probably guessed it, they had to pull so many major implementations it was embarrassing… Then the company started re-hiring BAs once again.
        Today we have numerous systems that are outsourced; therefore the onus is on the BA to get the business requirements clearly documented and problem areas highlighted early. To support our complex systems which interface locally, nationally and globally with each other, BA’s do get involved as soon as the project initiation document is written and approved by the executive. The business user must be involved and made to feel empowered throughout the project. However, if you are assuming the BA role from a previous BA on an ongoing project, you have to be very sure that you know what you are talking about before suggesting anything drastic. I have taken over a project when it was supposed to be entering the implementation phase, but after a Gap Analysis on my part, the project went back to the requirements gathering phase.I didn’t kill it !
        Remember too that every business process does not warrant being automated!
        I cannot think right now of being involved in a project that was implemented and eventually caught cobwebs, but that does not mean there aren’t any. I am familiar with projects that were cancelled before they got to the implementation phase, even though they were fully staffed – with BA engaged at an early stage. I am aware of projects that were pulled (rolled back) during implementation and rescheduled for a later date. If during development we perceive projects to be incapable of meeting the user’s expectations, before implementing them fully, we will suggest to the user that a pilot project be conducted first (on hardware upgrades, business processes, operational changes) or in some cases, a phased implementation approach be employed.

        1. The issue is not whether the BA should recommend pulling the plug if user requirements are not 100% met, it’s more that the BA has a responsibility to the project’s business owner and sponsor, that if the benefits promised in the business case will not be realised, the the business case should be re-evaluated on that basis, then it’s the sponsor / executive decision to terminate, put on hold, or continue with a new case as appropriate

          1. Thanks for the comment and additional insight, David! You’re right – it’s not necessarily about requirements being met 100%, but about heading off ill-fated projects and requests that will not provide the business value needed to justify completion.

            After another read, I also think I might have chosen better wording when asking if readers have ever “killed a project”, in that it is never something single-handedly done by the analyst.

            The analyst’s tasks is to provide the facts, data and recommendations needed to put business stakeholders in a position to make informed, decisions, which may include abandoning the iffy project request.

            Again, thanks!

    1. No, it isn’t displayed for others to see. You can see it and I can see it in the administrative area of the site, but it isn’t viewable by other visitors.

Post a Comment

Your email address will not be published. Required fields are marked *