I have been asked to develop a process to prove that the business reason for which we undertook the project was valid. If, at the beginning of a project, in order to get funding approved, we said the ROI was X, we would save Z dollars, cut Y positions, etc., then did we really accomplish these things. Single projects are pretty straight forward. However, when you are doing multiple projects in one area, it can get really murky.
Let me give you an example of what I a trying to prove.
I have three projects to install new automated systems (software packages) that were approved based on increased productivity, better speed to market, and better quality assurance that they provide to the way we develop new products. For each project we claim it will save us X days of development time, we will need Y fewer people, and that we will have Z fewer defects in our products.
At the same time we are completely reengineering the business processes used to develop new products. This includes additional check points, new safety checkpoints, and more involvement from stakeholders.
Many of the advantages gained with each of the three software packages being installed builds on the other packages. Some of the steps in the new process takes away from the gains achieved by the software packages.
Once all three projects are completed, how do I know which of my gains were achieved by which software package, which gains came from the new process, and which if any of the packages or the software itself negatively affected how we do business.
Decompose the components of the ROI. That is, you made commitments for savings for each package (if I understand correctly). Measure each commitment separately. You've identified X, Y, and Z. Take the measurement after each install and ask the users to attribute savings or expenditures based on key attributes of the software/or process. Then recompose the ROIs to a total savings. You may not hit the targets in the ROI, but you will have shown some successes. Saving Changes...
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
The best advice I can offer is to roll the software project into the reengineering project. They are intrinsically linked and should be done in the same context. You could have some rough sledding ahead if the reengineering project creates and polarizes on work processes that require major modification to the packages being implemented. Once consolidated recast the ROI and business case. Happy Holidays Saving Changes...
Susan M MorganProject Manager| AMI Inc.Cary, Il, United States
Try using a detailed breakdown on software/systems projects by listing the major features and cost justifying each of them. This helps the executives determine if the complete solution needs to be delivered 'now' or if some functionality can be delayed until 'later'. Additionally, this makes it easier to tie functionality to an individual group (user community) for later analysis to see if the project benefits were as planned. On each feature (major requirement) list the primary group(s) that benefit, the type of cost justification (headcount reduction, shortened cycle time, customer satisfiaction, industry/standards requirement, etc.), and the calculation used. It helps to have each of the user groups to provide their own input because they are, in effect, stepping up the results. It becomes more of a team effort rather than land all on your shoulders. Saving Changes...
ROI (Return on Investment) is a very ambiguous concept for IT projects. Many of the problems you express here with overlapping or interelated effects and ongoing efforts make a true ROI impossible. A Cost/Benefit approach that considers upfront capital costs, operating costs, and change costs against both tangible and intangible benefits along with risk is a a more meaningful approach. For an excellent discussion and examples see "The IT Business Case: Keys to Accuracy and Credibility" http://www.solutionmatrix.com/WP2_811.PDF Saving Changes...
Michael BrownProject Manager| JPMorganChaseDeerfield, Il, United States
If you want to read a very intersting book (after which time you'll beat yourself over the head and ask "WHY am I doing this ??!), get a copy of "Necessary but not sufficient," by Eli Goldratt. You might even end up recommending it to those asking for ROI justification on the project!
