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


On Thu, Nov 28, 2013 at 3:19 AM, Thomas Passin <list1@tompassin.net> 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.

When we look inward we come up with bad answers or potentially good answers that come with caveats which are ignored.

Looking outward - how do others do complex projects - the first thing that occurred was Systems Thinking and I came across this

http://www.triarchypress.co.uk/pages/book5.htm

from which I quote

"John Seddon here dissects the changes that have been made in a range of services, including housing benefits, social care and policing. His descriptions beggar belief, though they would be funnier if it wasn't our money that was being wasted.

In place of the current mess, he advocates a Systems Thinking approach where individuals come first, waste is reduced and responsibility replaces blame. It's an approach that is proven, successful and relatively cheap - and one that governments around the world, and their advisers, need to adopt urgently."

Without a framework of professional standards constraining those on the consultant side of the equation there will never be an end to the malaise because the procurers will continue to be able to find consultants willing to accept and run with seriously deficient specifications which in turn provide the contractor with a ready made excuse/rebuttal for accountability for deficient systems.








[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