Time and materials contract for other activities?

Time and materials contract for other activities?

Post by Kent To » Sat, 28 Jun 2003 10:33:16



Hi all,

XP works well only if it is a time and materials contract. However,
most business people are used to fixed contracts. To help convince
them, are there any activities for which the people are used to time
and materials contracts?

Thanks!

 
 
 

Time and materials contract for other activities?

Post by John Rot » Sat, 28 Jun 2003 10:45:36



Quote:> Hi all,

> XP works well only if it is a time and materials contract. However,
> most business people are used to fixed contracts. To help convince
> them, are there any activities for which the people are used to time
> and materials contracts?

I wonder if time and materials is the correct analogy? I usually
think of time and materials as a contract form for a fixed result,
and the ideal XP contract is to engage a team until such time as the
next "nice things" to add to the system aren't worth the expense.

I'm not sure I've ever seen an analogous situation, though.

John Roth

Quote:

> Thanks!


 
 
 

Time and materials contract for other activities?

Post by Malte Finsterwalde » Sat, 28 Jun 2003 18:04:54



Quote:>XP works well only if it is a time and materials contract. However,
>most business people are used to fixed contracts. To help convince
>them, are there any activities for which the people are used to time
>and materials contracts?

I don't know of an analogy.

But I can tell you how we did the contract for our current project.

It's fixed price, somewhat variable scope and it's staged.

In the beginning we evaluated what the customer wants. Then we fixed a
rough scope of the application. Not many details here. Just enough to
give the customer a rough feeling of what they are getting. We agreed
that the details will be worked out during the project. From the rough
scope we did a fixed price estimate and a finish date-projection.

So we have fixed price contracts for a certain period of time and a
roughtly specified functionality. After this part of the project is
delivered, a new fixed price contract is negotiated for the next
chunck of functionality.

During the project the details are worked out. We meet in more or less
regular intervalls (usually every 2-3 weeks) to discuss the next
requirements in more detail. We then write or continue to refine a
requirements document that is handed to the customer for agreement.
It's not a planning game, as written in the books, but it works very
well for us.

We also renegotiated the rough scope during this phase, because the
customers changed their mind. So this is also no problem.

But I think the most important part is trust.
The customer sees our regular, fairly fast progress and trusts that we
deliver as fast as we can. And we trust the customer that they don't
turn around on us and exegerate on the roughly specified requirements
and that they don't try to stuff more and more functionality into the
fixed price contract.
Our advantage is, that the customers focuse is on time to market and
not on complete functionality with all the details.

Greetings,
   Malte

 
 
 

Time and materials contract for other activities?

Post by Tim Breitkreu » Sat, 28 Jun 2003 22:08:59


Hi,

I believe time and materials is more common for "knowledge work" (such
as legal, accounting, consulting, investigations) more than
"construction work".  Software development is a combination of both,
so perhaps a fitting analogy is:

A architectural/construction contract where the buyer reserves the
right to change fundamental architectural requirements and design
specs at any point up to completion of the building.

I suspect that an architect would refuse to do this kind of project on
a fixed cost basis but would insist on time and materials to
compensate for the added risk.

Tim




> > Hi all,

> > XP works well only if it is a time and materials contract. However,
> > most business people are used to fixed contracts. To help convince
> > them, are there any activities for which the people are used to time
> > and materials contracts?

> I wonder if time and materials is the correct analogy? I usually
> think of time and materials as a contract form for a fixed result,
> and the ideal XP contract is to engage a team until such time as the
> next "nice things" to add to the system aren't worth the expense.

> I'm not sure I've ever seen an analogous situation, though.

> John Roth

> > Thanks!

 
 
 

Time and materials contract for other activities?

Post by Robert C. Mart » Wed, 02 Jul 2003 12:57:48



on (or about)  26 Jun 2003 18:33:16 -0700, :

Quote:>Hi all,

>XP works well only if it is a time and materials contract.

No, it works for fixed bid contracts too.  How do you bid?  You do a
few iterations on T&M (or on spec) and then you use the data from
those iterations to estimate and bid.  

Quote:>However,
>most business people are used to fixed contracts.

Many are used to T&M contracts too.  Indeed, there are probably more
T&M contracts than fixed bid.

Quote:>To help convince
>them, are there any activities for which the people are used to time
>and materials contracts?

Contracts are about trust.  As a service provider I'd be happy with
either kind so long as I trusted my client.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Time and materials contract for other activities?

Post by Kent To » Thu, 03 Jul 2003 18:53:48




> on (or about)  26 Jun 2003 18:33:16 -0700, :
> >XP works well only if it is a time and materials contract.

> No, it works for fixed bid contracts too.  How do you bid?  You do a
> few iterations on T&M (or on spec) and then you use the data from
> those iterations to estimate and bid.  

As a lot of details are not specified on the user story
cards, the estimation can be very far away from the truth.
The customer can significantly enlarge the scope by adding
a single sentence (eg, "it should support a web-based
interface in addition to the desktop GUI"). They may not
be doing it on purpose. Just that they may not think it
is that hard to do or it simply didn't come to their mind.

Are you considering doing a formal spec first?

Quote:> >However,
> >most business people are used to fixed contracts.

> Many are used to T&M contracts too.  Indeed, there are probably more
> T&M contracts than fixed bid.

Any examples? In particular, it would be cool if there
are certain similarities between them and software
development.
 
 
 

Time and materials contract for other activities?

Post by Robert C. Mart » Fri, 04 Jul 2003 01:43:43



on (or about)  2 Jul 2003 02:53:48 -0700, :



>> on (or about)  26 Jun 2003 18:33:16 -0700, :
>> >XP works well only if it is a time and materials contract.

>> No, it works for fixed bid contracts too.  How do you bid?  You do a
>> few iterations on T&M (or on spec) and then you use the data from
>> those iterations to estimate and bid.  

>As a lot of details are not specified on the user story
>cards, the estimation can be very far away from the truth.
>The customer can significantly enlarge the scope by adding
>a single sentence (eg, "it should support a web-based
>interface in addition to the desktop GUI"). They may not
>be doing it on purpose. Just that they may not think it
>is that hard to do or it simply didn't come to their mind.

If the customer is allowed to change the cards, then a fixed bid
becomes less feasible unless the contract also outlines how the
developer gets paid for changes.  Most fixed bid contracts have such
stipulations.  

Quote:

>Are you considering doing a formal spec first?

No.  I'm considering a batch of stories.  Estimate them.  Develop two
or three iterations, and then calculate what it's going to take to get
the rest done.  Make sure that the contract makes provision for how
you get paid when the customer makes changes.

Quote:

>> >However,
>> >most business people are used to fixed contracts.

>> Many are used to T&M contracts too.  Indeed, there are probably more
>> T&M contracts than fixed bid.

>Any examples? In particular, it would be cool if there
>are certain similarities between them and software
>development.

In fact I have never worked on a completely fixed bid contract.  All
the contracts I have worked on have been either T&M or they have been
some combination of fixed and variable.

The most interesting contract I worked on was half fixed, and half
variable.  We worked for a very low T&M rate, and were paid very nice
balloon payments for achieving certain milestones.  Upon acceptance,
the customer would then pay straight T&M for any changes requested.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Time and materials contract for other activities?

Post by Kent To » Sat, 05 Jul 2003 18:44:24



Quote:

> If the customer is allowed to change the cards, then a fixed bid
> becomes less feasible unless the contract also outlines how the
> developer gets paid for changes.  Most fixed bid contracts have such
> stipulations.  

The customer doesn't need to change the cards, since the cards
only have a few words written on them. For example, one card
may say "Manage orders". It can be interpreted as something
very simple or something very complicated.

Quote:> No.  I'm considering a batch of stories.  Estimate them.  Develop two
> or three iterations, and then calculate what it's going to take to get
> the rest done.  Make sure that the contract makes provision for how
> you get paid when the customer makes changes.

Would you consider changing the interpretation of the
cards a change that should be paid for?
 
 
 

Time and materials contract for other activities?

Post by John Rot » Sat, 05 Jul 2003 19:39:51




Quote:

> > If the customer is allowed to change the cards, then a fixed bid
> > becomes less feasible unless the contract also outlines how the
> > developer gets paid for changes.  Most fixed bid contracts have such
> > stipulations.

> The customer doesn't need to change the cards, since the cards
> only have a few words written on them. For example, one card
> may say "Manage orders". It can be interpreted as something
> very simple or something very complicated.

I wouldn't accept that as a story. At least, not as a story I
could write a contract from. A story (plus the supporting
conversation) has to have enough detail to develop reasonably
accurate estimates *and* acceptance tests.

In general, a fixed time, fixed cost, fixed function contract
comes with a hefty requirements document, or a high
probability of a lawsuit.

Quote:> > No.  I'm considering a batch of stories.  Estimate them.  Develop
two
> > or three iterations, and then calculate what it's going to take to
get
> > the rest done.  Make sure that the contract makes provision for how
> > you get paid when the customer makes changes.

> Would you consider changing the interpretation of the
> cards a change that should be paid for?

Yes.

John Roth

 
 
 

Time and materials contract for other activities?

Post by Robert C. Mart » Tue, 08 Jul 2003 08:21:49



on (or about)  4 Jul 2003 02:44:24 -0700, :


>> If the customer is allowed to change the cards, then a fixed bid
>> becomes less feasible unless the contract also outlines how the
>> developer gets paid for changes.  Most fixed bid contracts have such
>> stipulations.  

>The customer doesn't need to change the cards, since the cards
>only have a few words written on them. For example, one card
>may say "Manage orders". It can be interpreted as something
>very simple or something very complicated.

The developers and customers have had numerous conversations about
that card.  The developers have put an estimate on the card as well.
If the customer decides to re-interpret the meaning of the card then
the developers are allowed to change the estimate.  Indeed, the
developers can change the estimate any time they learn something new.

Quote:

>> No.  I'm considering a batch of stories.  Estimate them.  Develop two
>> or three iterations, and then calculate what it's going to take to get
>> the rest done.  Make sure that the contract makes provision for how
>> you get paid when the customer makes changes.

>Would you consider changing the interpretation of the
>cards a change that should be paid for?

Yes.  Again, since we have had conversations about the story, and
since I trust the customer (I don't take jobs with customers I don't
trust) I doubt that this problem will happen very often.  In my
experience, when it does happen, we negotiate an extra fee without
severe consequence.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Time and materials contract for other activities?

Post by Robert C. Mart » Tue, 08 Jul 2003 08:24:34



this on (or about)  Fri, 4 Jul 2003 06:39:51 -0400, :

Quote:>In general, a fixed time, fixed cost, fixed function contract
>comes with a hefty requirements document, or a high
>probability of a lawsuit.

Change that 'or' to 'and'.  Nobody is that good at estimating.  And no
customer is that good at writing requirements.  

Every fixed contract I've ever seen had a T&M contract inside it to
deal with changes.  I've seen many of those projects completely
convert to the T&M portion before they were over.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Time and materials contract for other activities?

Post by Kent To » Wed, 09 Jul 2003 10:28:35




> on (or about)  4 Jul 2003 02:44:24 -0700, :

> The developers and customers have had numerous conversations about
> that card.  The developers have put an estimate on the card as well.
> If the customer decides to re-interpret the meaning of the card then
> the developers are allowed to change the estimate.  Indeed, the
> developers can change the estimate any time they learn something new.

Let's assume that there is trust between you and the customer
and both are honous individuals, the following cases can still
happen:

1) Because the conversations are not recorded, they are not
part of the contract. What if later the customer remembers
that he said XXX, but you remember that he didn't say XXX
but said YYY, while XXX takes a week to do, but YYY takes
only a day? Will the contract you signed allow you to revise
the estimate and charge more?

2) No one ever said XXX or YYY but during implementation you
find that it must be specified. The customer might have had
XXX in mind (but didn't say it because you didn't ask). Will
the contract you signed allow you to revise the estimate and
charge more?

3) The customer did say XXX but you estimated as one day. But
later you realize that it would take one week. Will the contract
you signed allow you to revise the estimate and charge more?

 
 
 

Time and materials contract for other activities?

Post by Robert C. Mart » Wed, 09 Jul 2003 13:52:13



on (or about)  7 Jul 2003 18:28:35 -0700, :



>> on (or about)  4 Jul 2003 02:44:24 -0700, :

>> The developers and customers have had numerous conversations about
>> that card.  The developers have put an estimate on the card as well.
>> If the customer decides to re-interpret the meaning of the card then
>> the developers are allowed to change the estimate.  Indeed, the
>> developers can change the estimate any time they learn something new.

>Let's assume that there is trust between you and the customer
>and both are honous individuals, the following cases can still
>happen:

>1) Because the conversations are not recorded, they are not
>part of the contract. What if later the customer remembers
>that he said XXX, but you remember that he didn't say XXX
>but said YYY, while XXX takes a week to do, but YYY takes
>only a day? Will the contract you signed allow you to revise
>the estimate and charge more?

Of course.  However, since I trust the customer, and since I know that
there will also be conditions where I overestimated certain aspects of
the project, I'm probably not going to charge him for the extra.   I'd
only charge him if it started happening too much.

Quote:>2) No one ever said XXX or YYY but during implementation you
>find that it must be specified. The customer might have had
>XXX in mind (but didn't say it because you didn't ask). Will
>the contract you signed allow you to revise the estimate and
>charge more?

Of course.  On the other hand the are probably also cases where we
thought we needed QQQ but found out later that we didn't.  So again,
I'd only ask the customer for extra money if there were a *lot* of
unexpected new things to do.

Quote:

>3) The customer did say XXX but you estimated as one day. But
>later you realize that it would take one week. Will the contract
>you signed allow you to revise the estimate and charge more?

Of course.  Yet there are probably stories that I overestimated too.
So I wouldn't ask the customer for more money unless there were a lot
of underestimated stories.

Contracts aren't about agreeing to everything up front, because
agreeing to everything up front is simply impossible.  Contracts are
about establishing a framework within which the parties can trust each
other.  There will *always* be exceptions and oversights.  If the
relationship is built on trust, then these situations are dealt with
accordingly.  If the relationship is not built on trust, then the
contract should not be signed.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Time and materials contract for other activities?

Post by Kent To » Wed, 16 Jul 2003 18:55:38




> on (or about)  7 Jul 2003 18:28:35 -0700, :

> Of course.  However, since I trust the customer, and since I know that
> there will also be conditions where I overestimated certain aspects of
> the project, I'm probably not going to charge him for the extra.   I'd
> only charge him if it started happening too much.

> Of course.  On the other hand the are probably also cases where we
> thought we needed QQQ but found out later that we didn't.  So again,
> I'd only ask the customer for extra money if there were a *lot* of
> unexpected new things to do.

> Of course.  Yet there are probably stories that I overestimated too.
> So I wouldn't ask the customer for more money unless there were a lot
> of underestimated stories.

Then by conventional thinking, the contract is putting
the customer in disadvantage, because the developer
has the right to charge him almost at wish because
there is no written spec. I suppose the only resort
the customer has is to terminate the contract.

If there is so much trust that the customer agrees to
such a contract, it seems that there is no need for the
contract at all. What does it bring to the table?

Quote:> Contracts aren't about agreeing to everything up front, because
> agreeing to everything up front is simply impossible.  Contracts are
> about establishing a framework within which the parties can trust each
> other.  There will *always* be exceptions and oversights.  If the
> relationship is built on trust, then these situations are dealt with
> accordingly.  If the relationship is not built on trust, then the
> contract should not be signed.

What make software so unique that we can't agree on the
spec upfront and the amount of the payment? I know that
it is very difficult to get the spec "right" upfront. But
even for very large projects such as the contruction of
an airport, the spec and the payment (and time) and are
all fixed. In addition to software, is there anything
like that?

OTOH, how do you build up that trust?

 
 
 

Time and materials contract for other activities?

Post by John Rot » Wed, 16 Jul 2003 19:26:53





> > on (or about)  7 Jul 2003 18:28:35 -0700, :

> > Of course.  However, since I trust the customer, and since I know that
> > there will also be conditions where I overestimated certain aspects of
> > the project, I'm probably not going to charge him for the extra.   I'd
> > only charge him if it started happening too much.

> > Of course.  On the other hand the are probably also cases where we
> > thought we needed QQQ but found out later that we didn't.  So again,
> > I'd only ask the customer for extra money if there were a *lot* of
> > unexpected new things to do.

> > Of course.  Yet there are probably stories that I overestimated too.
> > So I wouldn't ask the customer for more money unless there were a lot
> > of underestimated stories.

> Then by conventional thinking, the contract is putting
> the customer in disadvantage, because the developer
> has the right to charge him almost at wish because
> there is no written spec. I suppose the only resort
> the customer has is to terminate the contract.

> If there is so much trust that the customer agrees to
> such a contract, it seems that there is no need for the
> contract at all. What does it bring to the table?

> > Contracts aren't about agreeing to everything up front, because
> > agreeing to everything up front is simply impossible.  Contracts are
> > about establishing a framework within which the parties can trust each
> > other.  There will *always* be exceptions and oversights.  If the
> > relationship is built on trust, then these situations are dealt with
> > accordingly.  If the relationship is not built on trust, then the
> > contract should not be signed.

> What make software so unique that we can't agree on the
> spec upfront and the amount of the payment? I know that
> it is very difficult to get the spec "right" upfront. But
> even for very large projects such as the contruction of
> an airport, the spec and the payment (and time) and are
> all fixed. In addition to software, is there anything
> like that?

It may look like the specs are fixed up front for large
construction projects. The ones I've been close enough
to see, though, that simply wasn't true. The specs wound
up getting changed almost to the final day. In one building
I worked in for several years, they decided to move the
entire four floor data center from one level to another -
after they had put the steel in for the level that the data
center's final location.

You might take a look at the Denver airport and the
recent extension of the SF Bay area Bart to the SF
Airport for other enlightening examples.

The only rule of thumb I can come up with is that
the bigger it is, the more likely that there will be
substantive changes requiring renegotiation of the
contract. Everyone associated with projects of this
size knows that - except the "good government"
idiots that insist on fixed price contracts and the
press.

John Roth

- Show quoted text -

Quote:> OTOH, how do you build up that trust?

 
 
 

1. Network Activity and UI activity

   Hello all,

   I have been able to capture network activity .That is packets to my local
machine and those leaving my machine.Now i need to find out the UI activity
in my local machine responsible for the network activity.If I use hooks I
can find the UI activities.But how to match that this UI activity Mouse or
KeyBoard activity caused Network activity.

Plz help

Many thanks in advance.

"Wish u a happy new Year"

-Regards

Arun

India

2. Creating directories from a makefile

3. Use Case Activity Diagrams: <<include>> use case activity?

4. New, free BETA interpreter (GPL)

5. Hi Andy/others - Is VS.NET 2003 Final Beta Time limited ?

6. messenger service

7. How do you do background downloads during minimum Winsock activity time

8. DNS on DSL or LAN NIC?

9. Real-time modem ports activity monitor

10. Egroups mail list for C ++ Jobs, contract and full time positions

11. Unlimited C ++ Jobs, contract and full time positions