A Self-Referential Safety Net
"The release plan
used to be called the commitment schedule ...
A useable, testable system that makes good business sense delivered
early is desired"
There are, of course, many different types of project contract.
Some project bids are won on the basis that "we'll do it more
cheaply, and in less time than X, Y and Z competitors." This
usually means that both the cost and deadline are set before we
know exactly what needs to be delivered. The result is that post-bid
negotiations take the form of an almost desperate wrangling of the
project scope, where the customer wants as much as possible out
of the deal, and the supplier (that's us) tries to cut down the
scope as much as possible - at least to a sensible amount. What
if the customer wants to fix scope as well as time and cost? Then
you've got a problem.
XP attempts to counter this by using "Optional Scope Contracts".
The theory is that the customer will be prepared to sign up for
a project that runs for a fixed amount of time for a fixed price,
without any commitment as to what is actually delivered. This premise
is central to XP. Without an Optional Scope Contract, where scope
is the biggest variable, XP cannot function.
However, there are potential pitfalls in contract negotiation.
The customer may regard your sales team as "slippery",
refusing to commit to any sort of concrete plan whilst apologetically
explaining that "our software process won't allow it!"
Of course you can commit to a fixed scope contract anyway, but
then that isn't really XP, and you would then be better off using
a process that is tailored to fixed scope projects. Back to Extreme
Programming Explained (Chapter 26):
"XP can accomodate the common forms of
contract, albeit with slight modifications. Fixed price/fixed
scope contracts, in particular, become fixed price/fixed date/roughly
fixed scope contracts when run with the Planning Game."
Reality XP Forum
Back to XP Central