By Andre Griffith
Failure and perceptions of failure are the norm rather than the exception in information systems implementations. This week we will briefly examine some considerations for successfully implementing information systems especially in larger organisations where vastly different expectations among the various stakeholder groups usually leads to at least one vocal set loudly protesting the limitations of the system and much more than occasionally, a truly complete and spectacular failure.
We have already dealt at some length with deciding which systems to implement as part of our discussions on IT governance and to briefly recap this decision, we note that selecting which systems to implement should be viewed as a normal capital allocation decision just like any other.
An oft-overlooked consideration that impacts on the eventual success of a software implementation is the set of all the other non-IT related investments that need to be made in order for the IT implementation to be successful. In many cases, full consideration of these related investments will materially inform the budgetary allocation to the software itself. For example consider the hypothetical case of a gas utility company that has determined that while it delivers a significant amount of its product to its customers, much of this amount is not paid for. The gas utility rightly determines that this is a strategic problem and therefore makes a strategic decision to implement a state of the art customer management and invoicing system with sophisticated technical bells and whistles. This IT system however does not exist in a vacumn. In order for it to function effectively, it has to be fed with sound data and among other things, it is dependent on a physical infrastructure of properly functioning meters, and either a human resource or technological infrastructure for recovering consumption information from those meters in order to feed sensible data into it on a timely basis. If financial resources are scarce, the company may consider it prudent to acquire a less expensive software system that is fit for purpose and elect to invest the rest in the necessary infrastructure or allocate operational expenditure to a force of meter readers. Failure to consider the non software elements of the entire strategy will may lead to the situation where you blame “the expensive white elephant”.
Having selected whatever system, you now need to get the sleeves rolled up and get into the serious work of implementation. Many implementations fall down here as well and one of the more prevalent mistakes in my view is inclusion of detailed functional specification of systems within the framework of a fixed price contract for the entire implementation exercise. I consider blanket fixed price contracts to be inappropriate for most large IT implementations. To see why this is a problem, we need to understand how the vendor commits resources and the fundamental differences between Information Technology implementations and traditional projects.
With respect to vendor commitment of resources, the vendor will usually either assign to your project, staff or contractors who are paid a salary. This means that the vendors costs go linearly with time and are incurred whether or not the project progresses. We shall see shortly, that this is a particularly serious consideration due to the peculiar nature of IT implementations. The fixed cost that is quoted for an implementation therefore (excluding the base software cost which is often a fraction of implementation fees) is for all practical purposes based on the vendor’s assessment of how long it will take to implement the project, and the costs of staffing it for that period.
With respect to the difference between IT implementations and other projects, the fundamental problem is the extremely high degree of uncertainty surrounding the scope that typically exists at the start of the project. To be clear, a functional specification is something that can be taken by a programmer as is and turned into a piece of computer software that can be used for the purpose intended in the same sense, that a civil engineering specification will detail the dimensions and load bearing capacities of a structure and may even specify the exact materials to be used in its construction. Many organisations do indeed attempt to deal with this problem by producing what they believe are adequate functional requirements in a “Request for Proposal”. It has however been my experience that such requirements (sometimes running into a list of hundreds) would probably score close to 1 out of 10 on a scale that measures their adequacy as a guide to programmers. Consider the following example again from our hypothetical natural gas utility.
A “functional requirement” as couched in a typical RFP might read “The system shall be able to create a request for service from a new customer”. Nice you think, that’s pretty definite. Six months later you sit down with your vendor and he gives you his version of that requirement which is a screen that says “new service request” and gives you the ability to input the customer’s name and her address. Wait a minute you say, that’s not all that’s involved. We need the customer’s name (i), we need her address (ii) and we want the system to charge her a standard processing fee (iii) charged to an account for new connection services (iv). And if she lives at some distance from the network we need to do engineering work to build out to her premises and so we will need to charge an engineering fee (v) and that fee should be charged to an account for new connection engineering (vi). We also want the system to calculate the engineering fee (vii) based on the inputs of an engineering service order, especially including the length of the pipes (viii), which by the way we can only specify in metric units (ix) because we are bound by the weights and measures act of 1981. Oh and we have about four years worth of backlogged applications that we need to have in the system (x), and we had two changes of processing fee in that period (xi). In our example here, the vendor came with essentially two components to this requirement, which by the time we really thought it through ended up with eleven components. We can go on with this admittedly contrived (but plausible) example, but the point is that the devil is indeed in the detail meaning that real scope of work is probably a lot more than can be reasonably expected on the face of the RFP, and can contain some nasty surprises for both the client and the vendor. What then is the result ? Right off the bat, an experienced vendor is going to probably impose a premium to cover this uncertainty so in a sense you may end up paying a lot more than the actual value of the work. If the vendor takes the RFP at face value and operates within his typical experience as to the extent of possible variation in practice, more often than not, the client and vendor become locked into an acrimonious relationship since neither had a clue at the start about the true nature of the beast that they have agreed a price on. The client will essentially try to extract the more than is fair out of the vendor for the price of the contract and the vendor will try to deliver the least that can be conceivably (as opposed to reasonably) said to conform again for the committed price. There will be arguments about whether the specifications can reasonably be interpreted to mean X, and as the project continues, the vendor may substitute less qualified, or less experienced staff (thus reducing his cost) or will become increasingly inflexible in cases where your stated requirement was truly deficient and did not do a good job of properly stating all of your business rules. Again as an example your vendor would probably take the position (in this case not unreasonably) that your requirements for detailed engineering costs should come out of a work order system (so he is off the hook for delivering it).
The way out of this predicament is actually not very difficult. If you study the example of requirements specification above, above you will realise that there is absolutely no dependence on technology in stating those requirements regardless of the level of detail. Therefore, you are not bound to tie this activity to any one software vendor. The answer is to see your implementation in two main phases. The first phase ought to be detailed specification of requirements possibly accompanied by some rapid prototyping if necessary. The vendors that participate in this phase should be debarred from providing the actual software package in order to avoid any incentive to deliberately skew the definitions to their offering or to be so vague as to be able to increase a price for implementation afterward. The result of this phase ought to be a set of detailed requirements which while not perfect, will reduce uncertainty to a manageable level such that a fixed price contract can be used if desired for the actual software setup and customisation.
