Delimiter published a piece “Badly designed contracts doom public IT projects to failure”
My comment:
re “IT contracts often obscure objectives…”
I disagree. – IT contracts ALWAYS obscure objectives.
IT contracts are written around requirements. Requirements describe (for better or worse) solutions, not objectives.
That means someone in the public service has decided what the solution should be and have tried to describe it. Most of the time, other than for very simple projects, they get it totally wrong.
The whole government procurement process is fundamentally flawed because of this separation of objectives and solution. And it’s the fault of the government procurement process. Because of probity the government has to describe exactly what it wants to buy so that all potential vendors will be on a level playing field.
Unfortunately that level playing field has unclear boundaries and is full of unseen potholes.
The alternative is to do projects in two phases
1. Address the problem and identify the requirements
2. Issue an RFT based on these requirements.
Unfortunately, because of probity, any vendor who does 1) is usually excluded from 2)
As there is more money in 2) the very vendors who may have the skills in problem solving as well as in solution implementation don’t go for 1). Those who do have little experience in solution implementation and often make a mess of it.
The system is set up for failure. Just don’t blame the vendors.
Robert X Cringely commented on IBM’s role in the Queensland Health IT failure
http://www.cringely.com/2013/08/07/fulfilling-customer-requirements-is-a-weapon-at-ibm/
“The Australian IT project debacle is a classic example of IBM’s unique way of managing projects. The core of project management is “documented deniability.” They will do exactly what you tell them. They will document it. They will work against the documented requirements. When done, you have to pay them because they did exactly what you told them. The key problem to this approach is “does it work?”
The ultimate goal of every project is to build something that produces value or income. A factory makes products. A bridge assists transportation. In IBM’s project management IBM does not care about the ultimate goal. That is their customers concern, not IBM’s. This is very important for IBM’s customers to understand. It is the reason so many big IBM projects are failing.
This is the way IBM historically does its business, even in better times. Remember the mantra has always been to fulfill customer requirements. But somewhere along the line the whole idea went horribly, horribly wrong.”