Friday, December 19, 2008

Valuating Technology System Delivery

A well-worn but still prevailing theory of system delivery states that a system can be delivered according to three main factors:

- the system is of high quality and functionality (a "good" system)
- the system runs speedily under all conditions and usage loads (a "fast" system)
- the system can be built and delivered inexpensively (a "cheap" system)

The conventional wisdom is that a system can be delivered possessing AT MOST two of the three above factors. In other words:

- a good and fast system cannot be delivered cheaply
- a good and cheap system will not run speedily
- a fast and cheap system will not be a good system

You may or may not hold this view yourself, but many still do. Of course, it is quite possible (and rather beneficial) to have all three factors represented positively in a system delivery. But you need to look at the entire lifecycle of a system to understand this, not just the planning and construction stages.

Many under-weigh, or ignore completely, the usage and maintenance portions of a system's lifecycle when evaluating TCO and ROI. If the system's features, functionality, and construction are underrepresented before the system is delivered, higher costs will be made apparent later in the lifecycle:

- the system's users will invent workarounds to their normal business processing, just to accommodate the system's lack of performance or mis-matched view of the world. This usually leads to weaker controls and gaps in business processing, which leads to anywhere from higher operating costs to lost revenue.

- the system performs poorly or contains only a few compelling features, but just barely enough to be useful. While there could be no justifiable loss in cost, the cost to keep-alive the system plus the cost to improve and re-architect the system could easily be more than double the initial funds promised. Building a more desirable and well-performing system might have cost more up front, but still could have been less than the funds needed later for repairs.

- the system performs so poorly, or contains such a lack of compelling features, that it will not be used at all. This represents a loss equal to the cost of construction of the system, plus the difference in current operating costs that may have been saved, plus the cost of lost opportunity to improve and be competitive.

So how do you deliver a system that is good, fast, and cheap? Stating the system's costs and its benefits over the ENTIRE system lifecycle, both with equal precision, will help you arrive at acceptable definitions for "good", "fast", and "cheap" for your organization. But without the equality in precision, someone is bound to be disappointed upon delivery of the system.

So which lifecycle phases and cost factors are you accounting for in your system delivery analysis? Do you feel that you have all the bases covered? And how is the precision measured?

No comments: