This link has been bookmarked by 78 people . It was first bookmarked on 29 Apr 2009, by Hannu Kokko.
-
22 Nov 14
-
How does it handle changes in scope (requirements)?
-
How does it apportion Risk and Reward between customer and supplier?
-
What model of customer relationship does it foster:
-
cooperative (win-win), indifferent (I don’t care-you lose) or dependent (heads-I-win-tails-you lose)?
-
competitive (my win is your loss),
-
Sprint Contract
-
This is not really a commercial contract, but simply the agreement between the Product Owner and the Team for one sprint.
-
implementation team agrees to do its best to deliver an agreed on set of features (scope) to a defined quality standard by the end of the sprint.
-
The Product Owner agrees not to change his instructions before the end of the Sprint
-
Scrum project can be considered is a series of mini projects with fixed parameters: Time (Sprint Length), Scope (Sprint Backlog), Quality (Definition of Done) and Cost (Team Size*Sprint Length)
-
Confirming Sprint Contract in via E-Mail or posting it on the project Wiki at the beginning of every Sprint is usually good idea.
-
The Sprint contract can be referenced in the commercial contract
-
Fixed Price / Fixed Scope
-
Structure: Agree on the deliverables, deliver it. Send a bill. Customers like fixed price projects because it gives them security
-
The name says it all, doesn't it? The change request game (correction: change request process) is intended to limit scope changes.
-
process is costly, and the changes are usually not preventable
-
customer almost by definition wants more scope, ending the project can be difficult.
-
The supplier wants the customer to be happy, so the supplier usually yields.
-
The words ‘et cetera’ are very dangerous
-
Obvious risk is on the side of the supplier. If the estimates are wrong, the project will lose money.
-
Less obvious risks are the change request game
-
If the supplier had badly underestimated the effort or risk, or quoted an unrealistically low price, the losses can even threaten the existence of the supplier
-
which also presents a problem to the customer.
-
Relationship: Competitive to indifferent.
-
Customer generally wants to have more and the supplier wants to do less
-
The supplier wants the customer to be happy, so usually the supplier yields
-
Tip: Specify the functional requirement with user stories
-
Time and Materials
-
Structure: Work for a month, then send the customer an invoice.
-
Scope: Not a priori fixed. Sooner or later, the customer doesn't want to pay any more, so the project comes to an end.
-
Effort to ensure that only legitimate effort and expenses are invoiced can be substantial.
-
Risks: carried 100% by the client. Supplier has little incentive to keep costs down
-
for projects where the customer can better manage the risk than the supplier. This is often combined with a cost ceiling.
-
Time and Materials with Fixed Scope and a Cost Ceiling
-
Structure: Same as fixed price, fixed scope, except if the vendor gets finished early, the project costs less, because only actual effort is invoiced.
-
Scope: Same as fixed price, fixed scope
-
This appears to represent the ‘best of both worlds’ from the customer’s point of view.
-
once the cost ceiling has been achieved, it behaves like a fixed price project.
-
Dependent. From the supplier’s point of view, the goal is to hit the cost ceiling exactly. There is no incentive for the supplier to deliver below the maximum budgeted cost.
-
customer has probably treated the project internally as a fixed price project, and so has no incentive little renounce scope to save money.
-
Time and Materials with Variable Scope and Cost Ceiling
-
Structure: Same as time and materials except a cost ceiling limits the financial risk of the customer
-
Risks: the budget will expire without achieving the necessary business value for the customer. Customer won’t get everything he asks for
-
Relationship: Cooperative. The combination of limited budget and variable scope focuses both customer and vendor on achieving the desired business value within the available budge.
-
Tip: From experience, I would say this contract form mixes well with Scrum
-
A constructive relationship means that even if problems develop on the way, the emotions are right to come to a mutually agreeable solution
-
Phased Development
-
Structure: Fund quarterly releases and approve additional funds after each successful release
-
Scope Changes: Not explicitly defined by the model. Releases are in effect time boxed
-
The knowledge that there will be another release next quarter makes it easier to accept postponing a feature to achieve the time box.
-
Risk: Customer’s risk is limited to one quarter’s worth of development costs
-
Relationship: Cooperative. Both the customer and the supplier have an incentive that each release be successful, so that additional funding will be approved
-
Tips: Venture capitalists often work on this basis
-
Everything else was determined in the sprint contracts.
-
Bonus / Penalty Clauses
-
Structure: Supplier receives a bonus if the project completes early and pays a penalty if it arrives late. The amount of bonus or penalty is a function of the delay
-
Scope Changes: difficult to accept because changes potentially impact the delivery date, which is surely not allowed.
-
The ROI arguments must be compelling and transparent.
-
Relationship: could be cooperative, but might degenerate into indifferent if the customer does not truly need the software by the date agreed.
-
Often applied for construction projects, e.g. roads, tunnels and runways, for which it works well.
-
Fixed Profit
-
. The parties agree on the profit in advance, e.g. $100,000.
-
Cooperative - both have a clear incentive to finish early. The customer saves money and the supplier has a higher profit margin.
-
“Money for Nothing, Changes for Free”
-
After each sprint, functionality is either complete or not started
-
Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budget.
-
A cancellation fee equal to the remaining profit is due
-
Scope: can be changed. Planned but unimplemented features can be replaced with other stories of the same size. Additional features cost extra.
-
Both parties have an interest in completing the project early.
-
Joint Ventures
-
Two partners invest in a product of joint interest.
-
each party must have an ROI, which may come from revenue sharing or just benefits from using the software
-
Tips: Treat the project as a separate company:
-
phased development contract
-
-
20 Mar 14
-
14 Mar 14
-
03 Feb 14
-
28 Oct 13
-
24 Oct 13
-
04 Sep 12
-
29 May 12
-
08 May 12
-
03 Apr 12
-
A contract is really just a set of written playing rules
-
The right rules increase the chance of success for both parties
-
The wrong rules make cooperation difficult and hinder progress
-
What are the available playing rules and what is the best approach for a agile project?
-
4 points for comparing contract forms:
-
structured
-
it handle changes in scope
-
it apportion Risk and Reward between customer and supplier
-
model of customer relationship
-
possible contracts
-
the relationship between product owner and implementation team
-
the agreement between the Product Owner and the Team for one sprint
-
-
22 Feb 12
-
31 Jan 12
-
11 Dec 11
allruiz“@PCoIP_Guru: Excelled piece on project contract models and commercials for dev http://t.co/ew1h43go”
-
05 Dec 11
-
20 Nov 11
-
15 Jul 11
-
13 Dec 10
-
08 Nov 10
-
12 Aug 10
-
22 Jul 10
-
13 Jun 10
-
10 May 10
-
30 Apr 10
-
25 Apr 10
-
As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. What are the available playing rules and what is the best approach for a agile project
-
-
19 Apr 10
-
17 Sep 09
"As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. A contract is really just a set of written playing rules. The right rules in
programming development agile contracts scrum contract projectmanagement methodology planning management
-
11 Sep 09
-
01 Sep 09
-
01 Aug 09
-
20 Jul 09
-
16 Jul 09
-
31 May 09
Marcos PereiraAs a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. A contract is really just a set of written playing rules. The right rules inc
agile business scrum development management contracts for:gauperes
-
29 May 09
-
22 May 09
-
12 May 09
-
08 May 09
-
06 May 09
-
05 May 09
-
04 May 09
-
03 May 09
-
02 May 09
-
01 May 09
-
30 Apr 09
-
-
29 Apr 09
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.