On Tuesday, July 4, 2006, at 3:05:41 AM, Vickydhiman wrote:
> Hello Ron and Group:
>>>If the team is spending time with the customer, surely that
>>>should be billed. If the team is spending time planning and
>>>designing, surely that should be billed. Tell us more about how
>>>you account for your time?
> Historically, we have only billed developer time to the clients.
> The communication/ interaction/ project management time has not
> been billed. Analyst team time is billed however for all the
> solution framework work.
I thought you said this was a fixed-price contract. Is time
accounting more than just an internal accounting mechanism?
>>> My favorite estimation technique is to put all the features on
>>> cards, have experienced team members estimate the cards as to
>>> how long they'd take to do in a perfect world, then multiply
>>> that number by three.
> And you provide these cards for the custom for an estimate of how
> much an iteration would cost the client?
Well, actually, the way I do Agile, the customer is supposed to
provide the requirements ... so they would be her cards.
>>> So it's the manager / Scrum Master who is actually jerking the
>>> project around, not the customer?
> Its basically the client. Scrum Master just follows the brief -
> discusses with the client and then provides the milestone for
> modules completion.
Well ... it sounds to me as if the SM is talking to the client and
then bringing changes / extensions back to the team. He would /not/
be doing that using your previous method? If that's the case then he
must be doing something different.
>>> It sounds to me as if that feedback loop, relating cost to
>>> value, is broken in your project. If that's the case, probably
>>> no estimation technique is going to help.
> I am not sure if I even understand what cost to value loop means.
> Probably Google around a bit.
I suspect you won't find it. I am referring to this loop, which
appears to be broken in your situation:
1. Customer has a fixed amount of money she wants to spend.
2. She has estimates of how much all the features will cost.
3. She proposes an enhancement, grand and glorious and overblown.
4. The team tells her how much it will cost.
5. She decides whether she can afford it, based on the cost of all
remaining work, and the value to her of this idea.
By agreeing to a fixed-price contract, you have relieved your
customer of the responsibility to make rational decisions about the
value of items given their cost. It is now to her advantage to
demand all kinds of things: the more she demands, the more she gets.
That's why Agile practitioners, in general, do not recommend
> I am sure that business must generate profits and despite
> everything we are able to generate profits but probably not enough
> profits. We routinely offshoot our project estimates but probably
> because of other factors [low taxes, low salaries etc.] we are
> able to generate profits. And we all agree that there is scope for
There always is. ;-> Better estimation would help, but can lead to
lost contracts because your prices will be higher.
What is your present policy on "change control" in your contracts?
>>> I would like to hear more about the communication loop between
>>> team, manager, customer, as regards changes and costs.
> We have switched to using BaseCamp PMS over past one year or so.
> All project milestones, to-do lists, messages, documents are
> posted there. The team and client have access to this account
> where all project discussions are done.
Interesting that you would respond to a question about communication
by referring to a tool. Although Basecamp does bill itself as a
project collaboration tool, I was actually interested in what the
actual discussions were like:
Customer has some wild new idea. I gather that the manager / Scrum
Master has this conversation. How does that conversation go?
I would think that part of the manager's interest would be the
cost of the feature proposed. How does he find out what that cost
will be? Does he involve the team? What does he do with the
Does he just commit to whatever the customer says? How does the
cost of a proposed feature enter into the conversation? Is he
looking at the effect of some exotic new feature on the time and
money burndown? Is he calculating the effect of that feature on
the project time and money budget? Does he share that information
with the team? With the customer?
> The basic document which governs the discussion on changes and
> costs is the basic proposal document [specification and
Yes ... what does it say?
> Let's revisit our sign-in page functionality:
> We drew the two text boxes and buttons and some links. Now the
> client says that what you showed me was obviously a basic page and
> what I require is an aesthetic looking web page which has a fancy
> faded background image [he would point out and say Graphics Design
> this is the first time a client has made such a request [you had
> no historical data for this]. How would we handle this request?
The first time ever? I hope that the requests that surprise you are
rather more exotic than this one.
I would think that I might be tracking Graphics Design separately,
having called it out. If I could write the project proposal, I'd be
budgeting a specific amount of money for graphics design, and
allowing the customer to manage the tasks. "The creation of that
image, if we do it, will cost one graphics design day of the twenty
days you purchased. You've already used nine days. We'll be happy to
create the image if you want us to."
Or, if I were any good at Web design -- I'm not -- I would think I'd
have discussed the overall look and feel of the design, and written
it into the proposal. Then we could say "This goes beyond the look
and feel we agreed to. Let's look again at the watercolor pictures
in the proposal. We can go to the next level if you want us to, at a
cost of $X, or, of course, we'll be happy to proceed on the
You have your finger on the reason why I'd not want to bid a
fixed-price contract and then give the client a free hand in asking
for anything she wanted. I don't see how it could work, because as
soon as I relieve her of the responsibility to manage the price, her
best strategy really is to ask for everything in the world.
What I might do, as a tactic "in the interest of time" would be to
insist on building out the whole product with simple features first,
coming back to address frills later. This would get the customer
impatient to deploy the system, and would ensure that all the
promised functionality was there, if not as fancy as they might
like. I might focus on getting a good, clean, but simple version of
everything up, and then revisit tarting it up, after the system was
ready to deploy.
It might be necessary to hold back actual deployment until after the
contract term was up, which I wouldn't usually want to do. We
haven't talked about the payment terms, nor do we need to, but if we
were only going to get the money at the end, or after specific
milestones, that might change things.
In the whole thing, I'd be very uncomfortable, though, because what
I consider to be a critical project feedback loop, the link between
cost and value, is broken in a fixed-price situation.
I could be wrong. I frequently am.