> 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.
