What point to make a deal with the client?

[fluxtah]

One thing I can not understand when offering a software solution, is when to propose a deal to the client?

Does this come before or after the Requirements stage?

The Sales team at my work only really care about 'how long it will take'. This is very unhelpful if we do not even know EXACTLY what the client wants...

So when is the best time to say 'This solution will cost X amount of cash and will take X amount of time?'

This is possibly one of the hardest questions bugging me right now

Thanks in advance.

- Fluxtah

[mchiuminatto]

The point in time you can answer that question with an error probability equals to zero is when you get the project finished. (by the end of the construction phase).  Too late, isn’t it? (And too dangerous from your business point of view).  The probability of error in the estimation is related to the risks associated to the project. By the end of this phase risks are zero.

So let’s go backwards for a more adequate point in the time, let's say the end of the elaboration phase. At this point the error probability increases due to the risks associated to the construction phase, but still remains low. Besides, at this point you have a lot of work done and no incomes, so the sales team is near to the collapse. This is a good point but there are betters.

So let’s go backwards, at the end of the Inception phase. What we've got here, a valuable estimation unit: Use Cases. At this point you can estimate the project effort and the project duration based on Use Cases. You should classify your UC's based on the complexity and then assign an approximate amount of effort for each degree of complexity and then make the calculations. Be aware that at this point the risk has increased, so the probability of error too. You have to make an estimation of the effort associated to the risks and add this result to the effort associated to UC’s.

For me this is the best point. But if your sales team put the rope on your neck, go backwards to the point you got a general version of your use case model (actor, use cases and general description, not yet the scenarios). At this point the risk is higher and it’s associated effort.

The sooner the estimation is made, the higher the risks are and it’s associated effort. But this will guarantee the resources needed to keep the "machine" working as soon as possible (sales team are not as bad as they seem)

At a high level of abstraction the effort should be calculated as: Et=Euc+Ersk+Eoth where

Et: Total Effort
Euc: Effort associated to use cases
Ersk: Effort associated to risk
Eoth: Other efforts associated to known organization procedures (promotions to test, prod etc)


Hope it helps

[sargasso]

The following table shows the variance to reality of software development cost estimates made at various points in the design cycle.

Estimation based on	Estimation Technique	Variance
Unclear Requirements	Guess	+-400%
Use case models	Usecase points	+-100%
Signed off reqts	Usecase points	+-50%
Design	Project plan	+-50%
Delivery	Timesheets	+-0%

Show this table to the sales people - tell them its industry standard!

[Oscar]

You could split the solution in two parts:
first propose a deal for the design part and when that is finished propose a deal for the implementation.

You'll still need to estimate the design part, but the risk in the implementation part is reduced.

Oscar

[fluxtah]

Thanks marcello that helped me a bit after discussing your response with my colleagues :]

Thanks sargasso for the table, that rocks and cheers Oscar, that is a great idea to split it into two.

regards

Ian

[Rob_M]

Oscar's approach is similar to that presented by Steve McConnel in "Software Project Survival Guide". Essentially break the funding of the project into two phases. (This can be done for internally, or externally funded projects.) Unfortunately, this only works if your funding agency is flexible enough to fund in 2 stages.

Rob_M

[sargasso]

Maybe I'm blessed, but everywhere I've worked in the last 10 years has preferred to fund a known requirements analysis phase prior to committing to a build phase.
The risk to the consumer in funding a project from go to whoah (woe?) is much higher than doing it in two phases. (refer back to the table).  
Although the developer is at risk in providing a fixed price for a system based on unclear or ill defined requirements the risk to the consumer is much higher.

Consider the construction industry - if I ask a builder to give me a quote and build "a house", what am I likely to end up with.  On the other hand, if I get an architect to consult me on the design of the house that I want, then i'm much more likely to end up with the house I had in mind.

[angel-o-sphere]

I would look into agile development processes like SCRUM or XP (extreme programming).

They do not really differ much (besides terminology) from use case driven approaches.

They both agree that upfront estimations are difficult and try to get the customer into the building process involved.

So the actuall prority of a requirement and wether it is included into the next iteration of development is determined by the customer.

This does not really answer the question, but leads to the point that the customer is involved in the estimatin, planning and conducting and tracking ...

Basicly you have to convince the customer to start a project after an initial ananlysis, likely use case based and pay the iterations ... not the full project. As you deliever during every iteration a functional system, likely allready giving benefit to the customer, the chance to get the project successfull finished increases.

Estimation, before a full in detail analysis, is imposssible.
Conducting a project after such an estimation, is impossible as well, as now allready to much has changed: stuff, environment or requirements.

Analogies to house construction do not realy hold! In a house usually EVERYTHING is planned and determined and never changes during the construction process. If you want changes while the house is under construction it gets REALLY expensive. Thats why an architect, the guy needed in the planning phase, is expensive.

Regards,
  angel'o'sphere

[sargasso]

Analogies to house construction do not realy hold! In a house usually EVERYTHING is planned and determined and never changes during the construction process. If you want changes while the house is under construction it gets REALLY expensive. Thats why an architect, the guy needed in the planning phase, is expensive.

The analogy holds extremely well.  As you say, in construction everything is planned - and that is my point - why do we, in IT, still try to give estimates in the void at all.  It is not difficult - its actually impossible.  Hence my variance factors in the above table.

If construction used the IT approach: -

Client: "Mr Builder, how much will you charge me to build a four bedroom house?"
Builder: (Thinks)Last 4BR I did cost me $45000 and I quoted $38000 for it - so 45 + 7 for the recovery + 30% margin= 66ish(/thinks)
Builder: "Without analysing what you want I'd say in the order of $66000"
Client: "Thats too much - I only want to spend $38000 and I need it finished next week before my mother in law arrives"
Builder: "Not a problem, I'll get started laying the foundations this afternoon"

In my variance based approach:

Client: "Mr Builder, how much will you charge me to build a four bedroom house?"
Builder: "Typically a $BR can cost anywhere between $45000 and $225000 I'd say depending on what you want exactly"

Bruce

p.s. If you reckon house design requirements dont change during construction your obciously not married!