Fixed Price Contracts With Change Control

XP's idea of open-ended contracts isn't the industry norm, and if your organization is too attached to a FixedPriceContract (and usually fixed-scope contract), this can be a serious impediment to getting true XP adopted.

Therefore,

Add a 'Change Control Management' clause to the contract [yes, there are organizations that haven't heard of this idea!] so that you have some flexibility with the scope.

Here's a bit more detail:

Pick the End-date

The end date is when the project [contract]? is to be completed. Often clients have a date in mind, so you say fine and see what can be done by that period. If the client does not care, you take all the cards, add the points and figure out how long it will take. The client then generally says, "We need it by so-and-so" and you go through the planning game. The end-date is your guideline and used to help define the amount of work can be done and how the change control process will be implemented. It does not mean that you take every project or you do every card to meet a specific deadline. If a client takes 3 months of cards and wants it done in one month you have two choices: a) Don't do the work or b) Have courage and say something. They will listen to good explanations.

You could always say yes to everything but that breaks basic common sense.

Change Control - The XP Way

Change control management is one of the key features in order to implement a fixed-price contract. The change control management process is as follows:

The clause in a contract that says any changes that cause an increase in the timeline will result in a change in price.
A description of the XP change control facilities such as the PlanningGame, the weight or XP Points of a StoryCard, etc.
Adherence to the XP practices from both sides.
Use common (what I call 1950's practices) terminology such as Change Control to get more corporate buy-in although in your mind it's the PlanningGame.

Change Control does not mean that the scope is not flexible - that would be against XP itself. Rather, the amount of work that can be done is fixed. To look at it at a different angle, we might be able to do 42 points of story cards in a given project with end date X. If a user wants to add 6 points of card he can either replace 6 points in the current plan or we add it to the end and the price goes up. As long as the client knows about the process ahead of time and you describe the process they will get on-line with it. The first time I did this was with a very strict organization and they actually loved it.

--BryanZarnett

Evidence/Examples

The practices I have used in order to do fixed price contracts are:

Make sure you use change control
Execute a release plan with the customer
Make sure you have the planning game on each iteration
Pick an end date that you wish to work towards
Determine the number of days * people to get your base price
Follow the XP practices outlined in PlanningExtremeProgramming

-- BryanZarnett

Discussion

Are you thinking of FixedPriceRedetermination??

That depends on what you mean by FixedPriceRedetermination?.

It's a ContractType? where you negotiate an initial fixed price and then agree upon certain factors � priori for adjusting the price. I would say that the above is a description of a possible use of FPR contracts in the case where the contractor uses XP. --DanielSvennberg

Kind of like, "We'll work for you for $X, and here are the conditions (A, B, C) to determine how much work we do."? It sounds like some official name from an economics text book. Where does it come from?

There are several sources that use this term, I don't know its origin. It is intended to be used when the specification of the work isn't firm enough to set a fixed price for the whole project. Instead you agree upon how to adjust the initially agreed upon price as you become more certain about the required amount of work, as I understand it.

I would suggest you can still do possibly do XP within a standard fixed price contract. Go ahead and negotiate your contract using your existing practices, then use XP for the development phase. You may still have problems with getting the OnsiteCustomer, but that is a problem outside of fixed price contracts as well. The bottom line is that if you are going into a competitive bidding situation, I don't believe you can put extra riders onto your contract; that will just cause your contract to be immediately rejected by the contracting office without even getting to technical review. Unless you have a mature customer.

Using XP, or at least an iterative development process, will give you a lot more room for addressing scope changes. You should have a much better handle on where you are at in terms of the required delivery and can either agree to requirements changes or make a very good case as to why the changes would jeopardize delivery.

-- WayneMack

I'm a little confused... how does this address OvercommitmentRecovery? It's all well and good to tell the client they have to pay more for more work... but how does change control work when the developer can't get all the work done in time? Do they simply get paid less for the project? If so, how does change control specify a cost for missed items? Sure, the developer charges what they think is reasonable for new items to be added, based on the estimated time for completion... but who determines the necessary refund for missed work? At this point, it seems like the fixed-price-contract problem of pitting the developer against the customer (see OptionalScopeContracts) rears its head again; the developer doesn't want to lose money, and the customer doesn't want to pay for features they didn't receive. Or might you associate a monetary cost to every User Story in the beginning? Although overcommittment would hurt the income of the company in this case, at least it doesn't damage the client-vendor relationship or result in lawsuits as would a complete failure to meet the contract's requirements...

With regards to the PlanningGame, how do you estimate the initial ProjectVelocity to determine the amount of work to complete by the deadline in the first place? What's to help you if the stack of User Stories you accept was estimated to take six months, but you've only got half of them done at the five month mark? Or a tenth of them done at the one month mark? Sure, the PlanningGame will tell you you're in trouble... but it seems like, best-case, change control simply keeps you out of court, and the developer still eats 100% of the cost of any overcommitment. (Not that that's inherently an unjust thing, I suppose...)

-- JosephRiesen

AdoptingXpPatternLanguage

CategoryPattern | CategoryExtremeProgramming