When discussing investment opportunities at governance meetings, senior managers invariably ask: “How much will the project cost us?” In the early phases of opportunity talks many IT leaders respond with the “SWAG” (Scientific Widely Aimed Guess) based on experiential supposition. Later, after governance approves a deeper investigation into the cost, IT leadership returns to governance with a slightly more predictable estimate known as a ROM or Rough Order of Magnitude, based on nothing more than executive level discussions, the research they’ve done from talking to vendors and presuming what resources will be needed. They don’t even have enough information at this point to distribute a formal Request for Information (RFI). Returning to governance, they supply a statement of work documenting what they believe is required, a Return on Investment (ROI) calculation based on the ROM, resource plan and projected schedule. If all goes well, governance is convinced of the projected derived business value and ROI and approves the project—all based on conjecture.
Nobody up to this point has gathered any of the actual requirements from the business users. The discussions thus far have all been very high level. This is highly ineffective IT Governance in action. You may also say this is IT Governance inaction. Ineffectual governance processes often lead down the path of conducting requirements elicitation and analysis early in the project lifecycle but only after the project is approved and funded. This is always a bad decision and one that leads to more problems for IT leadership down the line.
When Business Analysts start the requirements elicitation process after the project approval and kick-off, it doesn’t take too long to discover the original investment estimates were way too low. Now that the true business requirements are known, the project team realizes the scope to deliver the necessary functionality to the business is much broader than they first thought. As the project proceeds several months down the road, IT leadership goes back to governance and asks for more money to complete what they started and explain why the original timeline has to be extended. Governance either reluctantly responds to the increase in funding or trashes the project altogether. Whatever the case, IT leadership loses credibility with senior management.
Do you think this scenario is farfetched? It’s not. I’ve worked in organizations that have followed this exact process and have witnessed it time and time again. Senior leadership’s loss of trust and credibility in the IT organization is always the result. It is a difficult if not nearly impossible obstacle to overcome. Trust and credibility can be regained over time, but it takes a lot more than continuing with the same processes that got you into trouble in the first place. It often requires replacing the senior IT staff and embarking upon a long journey of IT business process transformation.
The truth is that questions surrounding IT investment and prioritization cannot be fully answered until at least one practice area of the SDLC[1] is executed and at least partially concluded. That area is performing the processes and practices governing requirements elicitation and analysis. This may also be known as a feasibility study. The question that now comes into play is “How deeply must I capture the requirements at this phase?”
The answer is variable depending on the project, but as a general rule of thumb, if we apply the Pareto principle to investment value and requirements, the resulting theorem says, “80% of the business value of an investment comes from 20% of the requirements.” This tells us that we don’t have to capture all of the requirements in the initial pass. We only need to capture the major requirements in a quantity sufficient to extrapolate a fairly accurate resource allocation and cost projection. A common practice is to pad IT project cost estimates with an additional 25% contingency anyway. By executing the requirements elicitation upfront, before project approval, you’ll provide much more accurate cost estimates, lower your contingency padding and reduce the chance of project overruns.
[1] Systems Development Life Cycle.
No comments:
Post a Comment