I love doing ROI calculations. I suppose if I had started out in something that had less compelling returns, it might not be the case. Then again, I turned down some early job offers after college when I could not at least napkin out their ROI on what I would be selling. There is a funny thing about ROIs in corporate America today though: when was the last time you saw an ROI that did not pay back? Now ask yourself how many times you have seen a project your company undertook that did not pay back?
So I can’t say that I have ever seen someone else’s initial ROI calculation that did not show a sure pay back. So is every project considered or undertaken a good one? Doubtful. I suspect the first opportunity for error is simple human nature. What vested interest does the person doing the ROI calculation have? Why would they fudge the numbers? It is not like they are getting a kickback from the vendor (if they are you have bigger problems). In most cases, people tend to dislike cognitive dissonance (wiki definition). Many times, very early in a project the influencers (real decision makers who don’t have authority) already have their mind made up as far as what direction to go (build / buy / outsource) or what tools to use (vendor selection). When that is the case, it is tough to get objective ROIs.
To get to the solution that they already believe in, they stack the deck a bit. I don’t know that it is conscious or a determined effort. I suspect it is more benign. The numbers DON’T lie; they are just not all there. So what is the easiest line item to leave out? Internal impact on employees is the single most common cost that is underestimated or ignored when costing projects. Ignoring needed hardware, software licenses, set up fees or marginal costs per transaction are tough to ignore. But what will your existing employees have to do to see this project succeed? How will this workload affect current duties? The underestimated impact will likely be found in all cases, but tend to show up in the following order from heavy to less heavy.
- “Buy” Solutions – Usually consisting of licensed software and some amount of outside programming, training, set up, project management etc.
- “Build” Solutions – Primarily consisting of in house programmers and expertise with or without some off the shelf components
- “Outsource” Solutions – Someone else will build it, run it and maintain it on an ongoing basis
Outsourced Solution ROIs still underestimate internal impacts (if they list it at all), but typically the total impact compared to the size of the solution is far less. The most common misunderstanding is that internal resources will still be needed in some way to “manage” the outsourcing partner. The impact at the beginning of a project are far heavier as communications are set up and tested. Ongoing daily communications are typical though even if it is line of business people (non-technical) working with vendors on normal issues.
“Build” solution ROIs have an internal component to them that can be underestimated, however this is more likely to manifest as project overruns or scope creep problems rather than traditional hidden internal impacts. I will cover scope creep and project overruns in another article.
“Buy” solution ROIs are where the true hidden danger is. Vendors are often afraid to point out what impacts will be on your staff. Sometimes this is as simple as sales people not understanding what is involved in the project management aspect. Other times however, they don’t want to expose the customer to things that are not easy to categorize or don’t show up in their numbers. Vendors may also assume without specifically saying it that your staff is sitting around twiddling their thumbs in between major roll outs with no existing workload. The information from the vendor is then added to your internal architect’s assessment that this project should be undertaken. Later in the project, a crossroads is might be reached. At that crossroads, we can decide to see the project fail, be delayed or invest resources needed. More often though, the crossroads is not “marked” and this or other projects begin to suffer. Projects that are seemingly unrelated are delayed across the board without a connection made.
How do we make sure this does not happen? Asking a couple questions should help.
- Is the technology being used similar to what you already have?
- Imaging, workflow and capture technologies tend to need experts dedicated full time to them.
- How many resources you already have with this specific area of expertise?
- Do these resources have any existing bandwidth?
Future ROI articles will cover things like scope creep, vendor management, project management and post project analysis. Have any comments, experiences or suggestions on ROI? How about horror stories? Let us know.