When the projected ROI eclipses the costs, the business is happy to take on a new project. That is the long and short of it, whether talking an IT project or any other kind. That means CIOs and other IT leaders must stress hard numbers and overall benefits when creating their business case for a new technology project. In an article for CIO.com, Rebecca Wettemann cites five mistakes to avoid along the way:
- Death by spreadsheet
- Seeking the perfect ROI
- Ignoring internal personnel costs
- Double-counting benefits
- Thinking you’re finished
In spite of having just said how important hard numbers are, there is still such a thing as too many numbers. Wettemann believes that even listing too many benefits of a project (five or more) can be exhausting. Picking out two or three major benefits to discuss in deeper financial detail is simpler and easier to digest. And about the danger of seeking the perfect ROI, this is said:
The goal of a business case is to justify a project and provide a roadmap for achieving value—but not necessarily in that order. Rather than focusing on the percentage ROI or the precise payback figure, focus instead on having a structured understanding of the costs and benefits, and the big moving parts where you want to spend more time on those estimates and understanding how much variability (how far off could you potentially be) they have.
Regarding internal personnel costs, it is dishonest at worst or naïve at best not to factor these into project accounting. Executives will appreciate the project crafters’ wide-reaching vision for including those numbers, and it will also yield the obvious benefit of producing more useful and realistic estimates to compare against during the project. It is important not to fudge costs, and along those same lines, it is important not to fudge benefits either. Project benefits can be direct (financially speaking) or indirect (owing to productivity increases, for instance), but Wettemann believes a project should only count one or the other.
Lastly, the finished business case should be used to help build milestones and all manner of other things regarding the project. It should not just be shelved the instant it does its initial job of getting a project green-lit. Smoke-and-mirrors strategies like that never work out well in the long term.
You can view the original article here: http://cio.com/article/3134545/best-practices/5-mistakes-to-avoid-when-building-the-business-case-for-it.html