Unrealistic maybe, I am looking in as an outsider mostly. But very interested to learn what can be done.

If the cost of projects can blow out to 10X the initial quotation, as seems the case in Qld and also locally too, something is very,very wrong with the system. My theory is that the idea of issuing tenders, which is based on defining requirements up front, is just plain wrong for complex software systems, that are essentially part of the culture of an organisation.

The only solution is to get people with the expertise to do ALL the work, including writing a specification if necessary, and to take ALL the risk. Financial markets are good at eliminating poor performers, just try getting reinsured after a project failure in the $M category. Risk markets (insurers) get very good at judging what is a reasonable price for something that involves risk. I once worked for a business called 'Objective Risk Management' briefly, that name came from managing risk in mining projects I think.

My 2c worth.

On Thu, Nov 28, 2013 at 2:19 PM, Thomas Passin <list1@t...> wrote:

Somehow most of the risk needs to be transferred to the vendor.

That is a very unrealistic and simplified notion.  It is common for the client - such as but not only a government agency - to

1) Manage a project badly;
2) require frequent changes to requirements;
3) Write poor quality requirements;
4) Not perform adequate systems or integration testing.

In this environment, the vendor *cannot* accept most of the risk, nor end up the only one to be blamed for failures.

In addition, many vendors themselves do a relatively poor job of managing the projects and admitting (even to themselves) when things are going badly.

I have worked on development contracts (not software) where cost overruns were shared between the government and the vendor up to a maximum, over which the vendor paid for all subsequent overruns.  That may be the best model.

I worked on a government software acquisition project where there were some 21000 disorganized requirements.  A vendor can't function well in circumstances like that.  We helped them toe simplify and organize the requirements to become more manageable.

I worked on a government software project where the vendor's database team tried to develop their own object-relational database system.  It got too complicated, and the vendor was unable to deliver.  The government team was unable to force the vendor to meet testing and other deliverable phases to demonstrate that their code would work right. Eventually the whole project was scrapped and a much less capable backup system (really a demo system) was proclaimed to be the final system. This was a joint disaster between the government and the vendor.

The fact is that large complex systems are *really hard* to develop, and both the client and the vendor need to be on top of their game.  Few are.  But this never seems to get taken into account in the planning and execution.

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l....org
subscribe: xml-dev-subscribe@l....org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php