An embarrassingly high percentage of IT initiatives fail to deliver. Expectations are not met; opportunities are not realized. That’s an important part of what is fueling the move to outsourcing.
Meanwhile, there has been a veritable explosion of IT procurement options. We have best practices for building and delivering IT services. But what about best practices for procuring them? There have been a number of attempts to define some of these best practices.
The U.K. Office of Government Commerce (OGC) developed one IT procurement guide, The OGC Gateway Process (www.ogc.gov.uk). An external quality assurance process, the guide was designed to cover procurement of “IT-enabled business change,” specific to the U.K. central government. However, the ideas can be applied quite broadly.
The OGC process is divided into six phases: business case development; procurement strategy development; competitive procurement; contract awarding and implementation; contract management; and closure. The Gateway process focuses on the questions that need to be answered at the end of the first five phases. There is also a strategic assessment review before the process begins and after it ends.
To proceed from developing a business case to developing a procurement strategy, there is a business justification review that must be conducted by outsiders. The OGC provides a 10-page outline of areas to probe and of what evidence to expect in connection with each area. Such a review is almost certain to uncover any significant problems with the procurement.
A similar, detailed review guide is provided for use at the end of phases two through five. The OGC is also developing a decision map to help organizations determine the procurement approach that best meets their particular needs. All in all, the OGC has provided a useful and impressive procurement guide, worthy of consideration by anyone concerned about IT procurement.
There is one important and initial question about procurement: is it for an outcome, an output, or an input? An outcome is normally described in terms of delivering a desired business change. What’s being purchased is business change. The way the change is delivered is of secondary importance. In an outcome contract, the vendor will be assuming a large risk.
If an outcome contract isn’t practical, the next step is to consider an output contract. The vendor is on the hook to deliver an IT system or an IT service, but it’s not their responsibility to deliver business change — that isn’t always practical. An input contract commits the vendor to providing people and resources. You’ll get best effort, but no delivery promises. Do you want an outcome, output or input contract?
Procurement may not have a high degree of sex appeal for IT professionals. But since it’s becoming increasingly important, we have a professional responsibility to search out best practices in every important aspect of our work.
Fabian is a senior management and systems consultant in Toronto. He can be reached at robert@fabian.ca.
