Over the last 20 to 30 years, we continue to read about companies blowing their IT-enabled transformation budgets and schedules. At least one new study comes out each year showing that 30% – 60% of all large projects exceed their expected budgets by 25% or more. Consequently, purchasing departments have been implementing tighter contracts with system integrators in hopes of reducing the amount of budget uncertainty.
In response, systems integrators have redrawn (in the initial contract proposal) from areas of the contract that they cannot predict with sufficient precision. In effect, they have assured that any unquantifiable risks associated with their budget and schedule are solely the responsibility of the client. These risks, if realized, will most likely end up as additional fees that can be pocketed from the customer.
Over the last decade, system integrators have honed their contracting ability to assure that these hard to quantify risks are buried, but clearly identifiable in their fixed price consulting agreements. Here are five ways that consultants assure that the client is carrying the risk:
It is almost a certainty that there will be functional scope changes. An initial blueprint of a process and system design is just that, a “blueprint”. As the system and business process is configured there are a number of points at which the process design will need to be altered or improved upon. Specifically, changes will be required:
- Following blueprint and business value validation
- At the completion of the first round of testing after specific process gaps are identified
- Following integration testing when interfaces that were not discovered in the initial phases of the project will be identified, and
- Following business simulation after users discover that key pieces of information are not available and new reports are required.
The identification of functional scope gaps is a natural part of the process and should be planned for. System integrators will protect themselves by clearly identifying the exact scope they have included in the bid.
The client will not understand the effort required to prepare data. Data has been a critical success factor from the days of the first IBM punch card system. Yet clients continue to get tripped up by this point. From my perspective, there are three reasons that clients continuously understate the effort required to complete the work on data:
- Underestimating the scale of the problems with the data in the current legacy system
There is an inherent bias that the data must be in decent shape given it is used to operate the business today. What clients often fail to grasp is that the data in the legacy systems carries with it the history of organization changes, the remnants of long forgotten initiatives, a lack of completeness, and the ever-favorite user inventiveness. Combing through your data is like an archaeological dig — each new layer reveals new issues.
- Overestimating the ability of technology or technologists to fix the problems unaided by the business
It is typically true that technology can be used to clean up data. Rules can be written to fill in the gaps where data is missing. Old data can often be identified and eliminated. However, between 10% — 20% of the information is going to require limited to intense collaboration from the business to fix and correct. When you are dealing with 20 years of data, the participation and effort required from the business becomes significant.
- Poor prioritization of the work
Project teams often experience long lead times from the business to fix problems and there is a failure on the project team’s part to warn the business of the volume of work required. These signs indicate a lack of prioritization by the project team and a poor relationship with the business.
System integrators will often simply take responsibility for the last mile of data migration (the process of actually loading the data). This leaves the heavy lifting to the client. Of course, once the client has discovered that it is in trouble with data, the system integrator will respond with resources to support on a T&M basis.
The client will not be prepared for the speed of decision-making required to support the schedule. Cross-functional business processes are rare at companies that are not operating with an already existing ERP. Even rarer is the ability to rapidly make cross-functional process decisions. Years of operating a company in an organizational hierarchy leaves companies ill-prepared to address cross-functional issues. Keenly aware of this risk to decision-making, system integrators will include assumptions in their estimates that outline specific timeframes required to make decisions and accept deliverables. If companies sign agreements and cannot comply with these assumptions, then this is grounds for a change order.
The client will not confirm that the business process solution is going to work until simultaneously testing training, data, and technology. Typically, system integrators will advocate keeping training, technology, and data streams separate for a large portion of the program and then bringing them all together at the end. What most clients fail to understand is that you really don’t know if the solution is going to work until you bring them all together. Given that the system integrator is taking responsibility for the technology and the client owns the data and training, guess who owns 2/3 of potential issues and who gets to submit a change order for schedule delays?
The client will not be able to flex business user capacity just prior to go live. There will inevitably be an enormous demand placed on the business in the two months prior to going live. Testing, data cleaning, training, and final cutover preparations will place significant participation requirements on the business. With their own priorities of organization operational continuity at the forefront, often businesses will fall short on providing the needed resources. This opens the door for system integrators to issue more schedule delay change orders, or the opportunity to bring in additional capacity to assist the business.
- A Hazardous Waste: An Overview of ICL’s Failed SAP Implementation
- When is it Time to Say Goodbye to Accenture, Deloitte, IBM or KPMG?
- 5 Mistakes to Avoid When Developing a SOW With Accenture, Deloitte, and IBM
- Is Your SAP SI Partner Evaluation Missing the Mark?