Last month’s post showed how, with some planning, you can establish a baseline to help you extract hard ROI data for any major IT project, our focus being on change control of course. With a baseline, you can compare “before” data with what you gather after the first 100 days or so and there’s your ROI.
With hard ROI data, you can show that a project did indeed deliver as expected – and back it up. Most chief executives complain that IT projects don’t provide dependable ROI data. When you do provide it, you’ll find that your later projects are that much easier to gain approval for because management is confident you know how to deliver on your promises.
For the second post of our ROI series, let’s look at before and after process configuration issues that may not be obvious or even open to direct measurement, and how they can affect a project’s “real” ROI. Intangible benefits or connections can be as important as hard data results, but harder to identify.
For an extreme example, let’s say one of your ROI values was user satisfaction and the hard data baseline you established was the number of user inquiries about work in progress (addressing slow response) or user complaints about how requested changes were delivered (addressing QA issues or user buy-in). In this case, you can improve your ROI data by providing more timely change delivery or by inviting requester buy-in during the QA phase, when problems are most effectively resolved. You can also improve this ROI data metric by simply automating a wider range of FYI notification emails to ensure everyone is well informed each step of the way. Keep in mind too that you can change the user interaction process to make it harder for users to make queries, request changes or register complaints and this see improvements too. Good for the numbers but not really an accurate data point.
Either approach will shrink the number of inquiries or complaints from users and give you solid ROI data to report when asked, but clearly the intangible value of user satisfaction is actually only enhanced by improving the process, not by raising barriers against user input.
Disconnects can always occur between what you thought you measured and the intangible benefit or value you sought as your goal. In change control, how you configure your project can make all the difference to how well your hard data actually reflects what you want to measure.
I cited an obvious “user inquiry” example in order to prove the point, but there are more subtle ways to miss the mark while still showing good hard data results. For example, an improved economy may contribute to fewer rejected credit transactions in a retail operation but if you just tightened approval processes to eliminate problems – how do you then interpret hard data showing that fewer transactions were rejected?
You need to keep a sharp eye on how you configure your change control automation processes for each new project to keep from accidentally stacking the deck to deliver the data you want, rather than configuring it to meet the objectives you set for the project.
Next month, look for part three of this series on determining ROI. We’ll cover pilot group enforcement and how it can affect your project ROI.