XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Re: XML As Fall Guy


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS