Help! Your Project is Done and Execs Want to See ROI

Redefining Benefits and Value in Retrospect

By Robert Birdsall, Director SCMO₂

First – don’t panic. Generating a positive ROI is the whole purpose for your project in the first place, right? A proper assessment of benefits realization requires that you employ five key disciplines in the development of your new process design.

1. Define what you are trying to improve or achieve as a part of your design.
2. Quantify how the functions and features of the new or revised solution contribute to those goals.
3. Establish metrics in the old processes and systems as a baseline.
4. Identify metrics in the new solution to compare with that baseline.
5. Schedule regular review and validation points to track progress and take corrective action.

But your team didn’t do that, right? Many more projects today are requiring a clearly defined business-case justification to gain budget approval for the effort. Still, it is common for project teams to jump immediately into the design and move right into building the solution out of urgency or enthusiasm. Establishing these important benchmarks is often pushed aside for later evaluation, if at all.

Now (after the fact) you’ve just been tagged to come up with some answers. Even with all the new documentation created during the project, you can most likely still find the original justification or kick-off documents that helped sell the effort in the first place. Going back to the beginning of the process will allow you to refresh that directive with the benefit of hindsight.

There are quite a few pieces of information you can use from those documents to start quantifying expected return. Some of the most commonly defined benefits include:

• Financial (e.g. cost savings)
• Process (e.g. transparency, consistency, flexibility or efficiency)
• Functional Enablement (e.g. new opportunities provided by the solution)
• Functional Compliance (e.g. meeting legal or legislative operational obligations)
• Functional Avoidance (e.g. Y2K recoding or end-of-life for your current solution)

Your design document should also list a host of processes, functions and features to be implemented. Identify and assign these items to each of the benefit areas listed in your project’s charter. By aligning tasks and efforts with expected outcomes, you can begin to rebuild an ROI document that can demonstrate the improvements your project has achieved.

If you still can’t find any stated, quantifiable benefits in those documents (or they’re just really relevant anymore), don’t give up yet! You can reverse engineer each advertised process, function and feature by answering one key question: “What does our organization gain from X, Y or Z?” After completing this task, it’s time to look at metrics.

If recreating the expected benefits was tough, trying to determine your benefits realization may be more difficult especially if your old process, system or solution has gone away. Some creativity may be needed. Assemble your team and ask a few poignant questions.

• How are things different between the two solutions?
• Do any metrics still exist from the old solution that map to the benefits from the new one?
• Does an environment still exist where we can model or quantify the old processes?
• Is qualitative evidence (e.g. testimonials from users, vendors or customers) sufficient?

It may require some analytical connecting of the dots, and perhaps even a few educated assumptions. But once you’ve established your benchmarks, you can now define the comparative data from your new solution or system. Make it a team effort that engages all stakeholders to identify any measures that may have been missed.

While not the optimal approach, with these additional steps (and several days of effort) you can get the answers you need to satisfy your executive team. Even if you did not work with SCMO2 originally, we can help you through this retrospective study, or support your considerations for any extensions or additions to your new solution.