10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Amr Elssamadisy on Dec 11, 2007
Contracts are the seam that tie together different organizations. Traditional contracts are based on mistrust and a CYA philosophy. Fixed price contracts don't take into consider the uncertainty of software development. Time-for-money projects are not based on value delivered - a team can work for a long time, burn many hours, and not have much to show for. The Agile community is looking for something better.
Mishkin Berteig put together a quick set of readings for those interested in Agile contracts. In it, he notes that this is based on a post by Chris Sterling, and added a few links of his own.
Reading through the different posts by Mary Poppendieck, Alistair Cockburn, Martin Fowler, you will find many different suggestions and war stories but little convergence.
Mary Poppendieck's presentation focuses on building trust and the monetary value of trust in comparing how Toyota and GM deal with their suppliers, and how Toyota has built much more trust:
Alistair Cockburn summarizes 10 different strategies that one might take to creating contracts. An intriguing idea is one that he quotes from Uncle Bob:
[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let's say you've got a project of 1000 points. Let's also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point.
Martin Fowler presents an example from a ThoughtWorks project where they went in with a fixed bid contract, built trust with the customer, and then moved to a more "flexible charging scheme".
I think the key to this story (and we have half a dozen similar examples) is that from the beginning we sought to put the relationship between our companies on a collaborative note rather than a confrontational note. The biggest problem with the fixed scope contract is it immediately pits the client and contractor on opposite sides where they are fighting each other about whether something is a change and who should pay for the change. An agile approach hinges upon replacing that confrontation with collaboration (customer collaboration over contract negotiation).
So why are Agile contracts important enough that the luminaries above all are discussing it, and difficult enough that there seems to be little consensus about them? None of the traditional contract modes actually fit well with the way Agile development teams work - there is a mismatch in process, and more importantly, a mismatch in values.
Have you worked with Agile contracts or are you using traditional contracts in the way you work? How is that working? Is it 'just fine', or do you sometimes feel that 'something is wrong' ?
Transforming Software Delivery: An IBM Rational Case Study
Agile Maturity Model Applied to Building and Releasing Software
SCM best practices for multiple processes, releases & distributed teams
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
This has been discussed on an XP list recently:
tech.groups.yahoo.com/group/extremeprogramming/...
I'm moving towards the idea of a blended approach:
www.pbell.com/index.cfm/2007/12/13/Managing-Ris...
I think that as developers we should provide a fixed fee for the initial development which is something we can control, but as a client, they should pay hourly for ALL changes required (assuming the delivered software matches the documented story).
As developers, it is reasonable that we take and manage the risk of how long it will take to turn a written description into working code. However, we cannot control how many changes or revisions a client will request or how many additional business rules come up, so if we have to provide true fixed bid we end up padding every quote and good clients get penalized while bad ones get a free ride. I think that charging a fixed fee for working code and then hourly for all discussions, tweaks, new features and support is the least bad solution I've come across to date.
I'd also clarify that where we have a good working relationship, we just fixed bid with a "reasonable" pad (typically 20-40%) and over the course of the project this works out fine. The problem with such an approach are the occasional unreasonable clients.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.
1 comment
Watch Thread Reply