Project Estimation

When the design out grows the back of the napkin

Michael Cummingsdevelopment.realtimedata.com    

@realtimemichael

Overlapping Models

Estimating is Important

• Your customer asks for an estimate to make decisions• Hire you?• Fire you?

• Typically, the project specifications are bad

• You must question the specifications • Look for holes – missing pieces• Look for bad design• Make sure it really is a Drupal project

Your Customer's Job

• To get a low estimate• Leave lots of room to add stuff later

Your Job

• Give an accurate estimate• Leave NO room to add stuff later

Who Wins?

– If you win:• You can get more money later• You can actually complete the project on time and on

budget• Your customer wins too

– If your customer wins:• You will be working all day and all night for no pay• It will be your fault• He will be mad about a late / over-budget project• He won't really win

What is an Estimate?

• Your customer thinks an estimate is a price• An estimate is not just a price• An estimate without a specific, limited list of functionality is

the road to developer hell

How to Estimate?

• Estimate based on specific list of items (Scope of Work)• Also list items discussed but not included • Your Scope of Work is your Fortress Walls

• Resist adding additional items • OR Get additional money and TIME for additional

items• OR Agree to push additional items to version 2

1. How Strong is Your Fortress?• Can you defend against:

• “But, I just assumed xyz feature was included.”• “We talked about xyz feature, where is it?”• “The project is useless without xyz feature, you should

have known that was in there.”• “The business changed, and we really need xyz feature

now.”

1. Understand the problem

• Skip this step – you die• Pretend you understand when you don't – you die• Your customer does not understand the problem either• Customer participation is key

• If your customer looks at your very first draft and says “It looks fine to me.” Run for your life!

• If your customer looks at your first draft says you are wrong, this is the first step to a good understanding – he is working with you

But I Don't Get Paid for Writing Documents!

• Nobody will pay you for writing an “Estimate” • Good customers will pay for “Project Design”• You decide what you call this work.

4. Mock ups / Wireframes

Should be Low-Fi to begin with 

Using full Photoshop mockups will take much too long and spend time on pixels too early in the process.

Tools• Google docs/drawing• Paper• I like Balsamiq Mock-ups

Examples :  www.wireframeshowcase.com

• Print them out. Users should mark them up

photo credit:http://www.wireframeshowcase.com/wireframes/detail/medstars/

2. Use the skills of your people

An estimate made by anyone that does not fully understand the work that is to be done is going to be poor.

Giving your team a look at the project can help you avoid potholes

Don't Poison the well - don't give leading information

It is better to ask how long did this take you the last time than "How long will this take"

Use caution with developer estimates 

3. Estimating Time 

Time only comes in 2 sizes:

• 1/2 Day • Full Day

Round up to nearest ½ day – it forces developers to be more realistic

Beware of estimates for a single item that are larger than 2 days

You DO NOT understand the steps if you make it larger than 2 days.  

Our experience is that an estimate of 3 days will be 5 days to weeks.

Photo Credit: h. koppdelaneyhttp://www.flickr.com/photos/h-k-d/

5. Customer Must be Involved• The customer must understand the functionality and

appearance of what is going to be delivered.• You know they are participating if you get complaints• Do not accept "Ya, that's fine"• I have had customer who had signed a contract in blood

demand additional features because they did not understand my text only description

Photo credit:http://www.flickr.com/photos/marine_corps/

• Involving the customer and frequent interaction helps both of you keep the expectations in check

6. Make a list

Modified Delphi Estimation method.Developed by Rand Corporation in the 40'sFancy word for list - Work Breakdown Structure (WBS)

Members of the team make their list of tasks SEPARATELY 

After lists are made members meet and compare lists.  Everyone must participate.  If there is no conflict and you didn't get any additions you are doing it wrong.

Team should agree on a list of tasks then go back and  and add time to the items

Examples:

Built by the underwear gnomes

About those listsHow do you Estimate something you haven't done before?• You can't• Do a prototype• Find someone who has done it before sub-contract/buy

training

Common pitfalls    • overoptimistic/pessimistic  team members• undiscovered requirements• "you don't know how much you do not know"• uncommitted members of team (includes customer)

Example

If I add up all the time..its too much

• Add up all the time then decide if you want to buy/discount the project

• Check your assumptionso maybe you can re-factor the solutiono some features may have to be cuto Since the customer is involved.   Let them decide what to

cut. Or to add budget. • Reality will not change to no matter how much you need it to

or how convenient that might be. • Some projects should be avoided.

Real Time Estimation Method

1. Understand the problem2. Use the skill of the people you work with.3. Estimate time in fixed amounts4. Make a Wireframe.5. Customer must be involved6. Make a list of tasks (Work Breakdown Structure)

Source books

Extreme Programming by Kent BeckGetting Real by 37 SignalsApplied Software Project Management by Stellmane and Greene

Further Contact:

Michael CummingsTwitter:  @realtimemichaelDevelopment.realtimedata.comMichael@RealTimeData.com

Project Manager, Programmer. 

 

This Slide Deck at:

SlideShare.com