Re: Use Cases -- A minimalist's view.
Posted: Jul 4, 2003 9:10 AM
> So, I let the scope creep. I let the customers make any
> changes they want. I let them know how much each change
> will cost and I encourage them to make as many changes as
> they need.
> But how do you know to charge them more if you don't
> already know what the baseline is?
<li>Charge by time and materials.</li>
<li>Charge a low time and materials rate punctuated by large milestone payouts.</li>
<li>Negotiate at the time of the change.</li>
> Customer: "This is supposed to be included."
> Developer: "But it's not in the original scope."
> Customer: "Of course it was in the original scope. I
> shouldn't have to pay any more for that feature -- I've
> already paid for it!"
If you have a fixed bid contract with a customer that you don't trust, then you have to have the tightest requirements document you can get. i.e. those documents need to be in the form of automated tests.
On the other hand, if you trust the customer, and if the customer trusts you, then you don't need nearly the precision and formality. You can negotiate each misunderstanding in situ.
Here's another conversation.
"The system doesn't do what I want."
"Yes, but the system does what you specified."
"True, but it's not what I wanted, so I need it fixed."
"You'll have to pay for the change."
"Like hell I will. You're the expert. You should have known."
Getting a client to sign in blood for his requirements is no guarantee that you will build the right system, or that you will please the customer in the end. Pleasing the customer is a matter of establishing on-going trust.
> 1. Is the CFO (either client or provider) going to sign
> off on a contract for $100,000 if the scope is not known?
> What is he/she signing that $100,000 for? Is it for $50K
> of work or $150K of work? Does it solve a real business
It is not uncommon for companies to sign T&M contracts, or contracts that have small T&M payments coupled with milestone payouts.
> 2. What role do use cases play? My experience is that
> they are a tool to help define the scope of the system and
> find what was missing in the requirements document.
They can be very good for that.
> Sometimes, a price is decided upon, and then negotiation
> happens in the follow-up stages to decide how much that
> price really buys.
> As a side note, do you know that Myers-Briggs personality
> type indicator test? The one with the four letters (e.g.
> I'm INTJ)? I think some of the aspects of deliberation in
> this thread are due to the last letter. P is perceptive,
> J is judgemental, which don't mean perceptive and
> judgemental. P tends to feel, "I don't want to decide
> now, because I limit my options.". J tends to feel, "I
> want to have things planned out and decided.". Things are
> usually okay with 2 Ps working together (though I think
> they would tend to be late), or with two Js working
> together (though the result would tend to be appealing
> feature-wise), but with a mix of the two ... there is some
> Imagine a P and a J going on vacation. J: "We should stop
> at place X on this day, see the sites A, B, C, go to place
> Y the next day." P: "But what if we find out something
> cool in place X? Does that mean we have to go on to place
> J: "Plan the work. Work the plan."
> P: "Flexibility is king."
I hate these systems that put people in labeled cubby holes. There are things I like to plan, and there are things I like to be flexible about. My wife and I usually want to plan different types of things and be flexible about different types of things. That makes for a good combination since we balance each other.