Vicky wrote:
> Once the project is approved, the project is run largely on SCRUM
> principles. From all the screens - various modules are identified.
> Based on modules selected by the clients and dependencies [GUI
> design must proceed integration of GUI with backend] sprints
> [generally 2 weeks] are identified.

> For the sprints - tasks are written in detail over the first two
> days. Client is involved in these tasks [written more like
> acceptance tests]. This is the phase where trouble actually
> creeps in. Some of the clients [we work with dedicated clients]
> can indulge in long discussions on what is in scope and what is
> not.

> After everything what it comes down to is even lengthier proposal
> document which outlines more "what is not in scope" than "what is
> in scope".

> Another problematic area is the top management starts viewing
> estimates [proposal estimates] as the metric and the teams which
> exceed that metric are categorized as under performers.

> Perhaps a more possibly question can be - how can we provide a
> fixed price estimate for all the sprints/ iterations up front? Or
> even can we?


Vicki,

I understand your frustration. The "big fixed price project"
situation happens in most large companies, and in many small and
medium ones is not uncommon.

Here are some ideas that may help you:

1) Estimate for the Overhead Upfront (Bloat Upfront)

To "Estimate Upfront" we respond with "Large Estimate Upfront".

Make the client pay for the unknowns.

If the only way you have to get the business is by bidding
for the whole project at "fixed cost", but then "loosing money"
by babysitting the client; well bloat the estimates, knowing
everthing you do with them will involve overhead, babysitting,
and creeping requirements.

Example:

Your developers and technical lead come with a "technical estimate"
of 20 hrs to do something, then you adjust the estimate by
analyzing, how much overhead will be involved in the tasks? who will
we be working with you? How many groups are involved? Who is the
business manager? etc.

This is where the magic factor of 2.5, 3.3, or even 4, comes from.
Developers are terrible at estimating this factor because in most
cases they don't see the politics, the babysitting, the
communication overhead, etc.

If the customer complains, then tell them about how hard is to get
things done at their company, and use well-known examples for this.
(You may want to do this at lunch when you are with a manager by
yourself, not a group meeting.)

Politically this works better than the following alternatives,
but unless your "planned overhead" is very large, be aware there is
still a lot of exposure for your company:

You don't want to braek even of loose money on ANY project!

In the back of you mind, you should always be thinking in some
of those lengthy pointless meetings: "They are paying for this!".

Be aware this is an "averaging game".. some tasks will be longer
than estimated, some shorter than estimated, some just right, but
on the average, if you picked up the correct factors, you will
still make money.

If the client tells you "we only use 5 hrs for this", then tell them
"yes, but we used X hours for that" -- use real examples.

***

2) Use the "Fixed Bid" to your advantage aka stong Change Management

This is similar than the above, but you hold every number as true,
and then adjust per Product Backlog item. Here you will manage the
customer with the "fixed cost" for the specifed Product Backlog item
to your advantage. As once they pass their estimate, you will
charge them extra for ANY time spent if you blow the estimates
for individual Product Backlog items.

This is to force the client to tell their people:

"Don't waste any time in extra or lengthy meetings --
we are paying for them".

Example:

We had 10 hours for implementation of XYZ, since we spent 20,
we 10 hours are from the fix bid, and 10 are for change mangement.


3) Do "Fix Bid" as "Fixed Number of Hours"

This one is almost a contracting trick. When you sign the contract
make sure somewhere in the contract says that it is a "fix bid for
X number of hours".

When the team runs out of time, then they get as much as they
could do with the bucket of time.

This is where the magic email to the client manager goes as
something like:

"Joan, We are at 900 hrs, and I getting concerned that the 1200 hrs
for which we fixed bid for the project will not be enough to
finish all the tasks. What tasks should we leave out? Or
alternatively, can we secure more budget to finish all of them?"

The manager may come to you and say, "no this is a fixed bid
project", that's when you pull the contract and say: "yes, it is
fixed bid for 1200 hrs". Touche!

***

If at all possible, however, convince your customer not
to work on "fixed price projects". It is so much better
when the customer pays for what they get every time.

This is good for them, because they can build the software
and change directions easier if necessary -- making compromises is
almost universal, and it is better for you -- you won't have
to play all of the "games with hours" above.

Good luck,

- Mike

* I am watching Brazil vs. France still 0-0 at half time, and
Roddick vs. Murray at Wimbledon. Roddick is up 6-5!!!