|
Apr 03
2013
|
 |
The success of IT projects is commonly measured by three metrics: did the project deliver on time, within budget and do what it was asked to do? Although there is some controversy over the scale of the problem, there is little doubt that significant underachievement in one or more of the three metrics wastes vast amounts of money. A glance at some of the high profile examples reported in the press shows just how much.
As might be expected, much effort is spent in trying to identify the root causes of partial or complete failure. It appears that there is no single dominant cause. Factors such as unclear and changing requirements, lack of management commitment, selection of the wrong technology and plain incompetence are variously thought to be the culprits.
However, there is one factor, IT procurement, which may lie behind a number of apparently different causes of problems. Procurement processes include formal procedures to be followed in procuring products and services. Other factors, to do with attitudes and ways of doing things, also influence procurement decisions.
I suggest that although procurement processes are almost always established with the best of intentions – primarily getting value for money – they may perversely achieve the opposite. In particular, I believe they often have negative results because they obstruct essential discussion at project inception, and so compromise the entire project. I’ll try to explain why.
IT projects today can be quite complex, involving new developments and integration with existing systems, both within an organisation and externally. The requirements may not be clear. This is not necessarily anyone’s fault; there may just be uncertainty about what can be done with the technology and budget available.
All this points to a need for extensive discussion early on, before procurement decisions are finally made. People who understand the business requirements and the technology available have to get together to decide the best possible approach. Small proof-of-concept projects may be required to test ideas and gather information, for example to explore what can be done with new technologies.
Procurement processes can make these discussions next to impossible. Invitations to tender may require sealed bids. Questions may have to be posed in writing or in vendor conferences, with the answers made available to all bidders. All this is done in the interest of fairness, to avoid bias.
The result is that procurement decisions may be made without a basis of adequate understanding. In an effort to win business in difficult times, vendors keep prices low in spite of the uncertainty, with a hope of renegotiation later. The result is all too likely to be significant underachievement in one or more of our metrics.
It need not be like this. Here are some suggestions to improve the situation.
First, the need for upfront discussion and experiment is critical. It could at least in part be built into the procurement process, before a contract is awarded, perhaps paying the costs of losing bidders. This is expensive but could ultimately save costs by increasing the success rates of projects. The approach is in fact adopted in some cases, for example for large defence projects.
A second option is to allow greater flexibility at the start of a project, so that the necessary discussion and proof-of-concept projects can take place. An initial fixed price impossible, but subsequent implementation projects could be done at a fixed price. Again, the likelihood of greater success rates, with fewer overruns of cost and time, would make it worthwhile.
But perhaps the fundamental difficulty is that IT and business people do not understand each other well enough – they do not speak the same language. That’s a subject for another time!
-Peter Bye, IT Consultant with Unisys
