The Yellow Brick Road (cont'd)

If the benefits identified in Part 1 appear to be worthwhile, then the project moves into its Feasibility phase. "As is" and "To be" process modeling gets started, as does the definition of detailed Business Requirements, performance objectives, and performance measures. This will provide a view of just how much has to change to get from "today" to "tomorrow", an important indicator of the size of the project. At this point, one should have a good understanding of the most important changes to achieve. Whether it is the ability to process 35% more orders, or to reduce the run time of each billing cycle by 28%, or to improve the utilization of the network by 43%, one should know what "done" should feel like, and why.

At this point, the OSS Architecture team also begins investigation of software application options - build, buy, or outsource. Discussions with vendors are initiated, or an RFI is issued. Based on the preliminary results, Part 2 of The Pragmatic ROI can be completed, adding in the cost estimates gathered from potential vendors. Being rather skeptical of vendor claims (based on my experience of OSS projects in general), I suggest doubling all cost estimates to complete the Part 2 figures.

At the end of Part 2, we will have reached an understanding that: "Something Can be Done, and This is What It Looks Like."

If the project benefits still appear to outweigh the (doubled) cost, then the project moves out of Feasibility and into Definition. This is when detailed analysis of solution options begins, as does rigorous project planning in an effort to reach agreement on: "This is What We're Going to Do". We'll talk more about these areas in future columns.

As the project moves into Design and Implementation, The Pragmatic ROI performs another essential function: it serves as a formal, pre-agreed reference point for every project milestone. Incorporated into the delivery contract, and the project plan at each milestone review, a formal "go/no go" decision can be taken, based on how closely the project is actually conforming to the costs and the benefits agreed. By making The Pragmatic ROI a formal part of the project review, a great deal of emotion and ego is eliminated from the project. It becomes simply an agreed performance objective. Deviations of more than "x" mean formal Executive Review, and deviations of more than "y" mean immediate project suspension with intent to terminate. When drafted into the delivery contract, The Pragmatic ROI helps keeps all parties focused on achieving the agreed results. Using our previous example, if increasing the number of orders that can be processed each day is a critical requirements, then "proven capability to push "x" orders (that 35% improvement number) should be one of the explicit exit criteria stated in the contract. More on this when we explore "contracting for success" in a later column, but the idea is to write down as precisely as possible what the expected achievement, and make sure to agree with the vendors how results will be tracked. This may mean establishing some new performance measures and new reports before starting the deployment, so it is essential to determine early on what information is required, where it will come from, and how it will be reported. With this information in hand, it becomes a cinch at User Acceptance time to know if one should sign off on that Acceptance Certificate, or not!

« Prev    Next »   |   1   |   2   |   3   |   Subscribe 4   |   5

Send Comment

© 2004, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.