Project Estimation

When the design outgrows the back of the napkin

Johnnie Foxwww.britesparkz.com                      @johnniefox

Estimating Sucks

Reasons why people don't want to Estimate• Coders hate doing it• Assumption that it won't be correct anyhow

 Benefits of Estimating:  • Builds Reputations• Sets Expectations• Skipping this step is the yellow brick road to Hell• Directly affects customer satisfaction• Good estimates make team members feel productive• There is no pot of gold at the end of the rainbow unless you

put it there• Keeps you from taking bad projects• Leads to good project management

Overlapping Models

1. Understand the problem

What is:o This project anywayo Technologies involvedo Clients side involvement

Hardware Hosting  People Departments/managers

 Importance of Customer involvement o Who are the key contacts?  Could be one or multipleo Need Only ONE Decision Maker!o You know they are participating when they tell you you

have it wrong

2. Mock ups / Wireframes

Should be Low-Fi to begin with bigger than a napkin  - get more napkins

Tools• Photoshop• Google docs/drawing• Napkins• I like Balsamic Mock-ups• Tons of others - just search

Examples :  www.wireframeshowcase.com

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

Mock-ups Mock-ups should be a part of the final design document with call outs to explain what happens where there is action.  • Don't:

o Show mock-ups on screen.  Users think if its on a screen = it's magically done

• Do's:o Print them out on papero Users should mark them up with

a red pen o You  should have a mock up of

each "type" of page.o Each type of widget should be

mocked up 

3. Use the skills of your people

Estimates must be made someone who fully understand the work or its to be a poor estimate.

Avoid potholes by giving your team a look at the project.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 .

4. Estimating Time 

Time only comes in 2 sizes

• 1/2 Day • Full Day

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

You DO NOT understand the steps if your estimate is larger than 2 days.  

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

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

Did I mention that task estimates of over 2 days

are WRONG?

Photo Credit:Bob Fomalhttp://www.flickr.com/photos/fornal/406285615/

5. Customer Must Work• Customers must understand the functionality and

appearance of what is being delivered.• Complaints = Knowledge that they are participating• Do not accept "Ya, thats fine"• I have had customers who had signed a contract in blood

demand additional features because they did not understand the terms

Photo credit: Amanda Slaterhttp://www.flickr.com/photos/pikerslanefarm/4996863774/• If they have made the

compromises themselves, and you documented it, they are far more likely to live with it and be satisfied.

• Pictures are the way to communicate this.  Not books full of text

6. Make a list of tasksModified Delphi Estimation method.Developed by the Rand Corporation in the 40's Fancy word for list:• Work Breakdown Structure (WBS)

Key Points:• Members of the team meake their list of tasks SEPARATELY• Everyone must participate. • After lists are made members meet and compare lists.  • If there is no conflict and you didn't get any additions, then you

are doing it wrong.

Time estimates are like hockey:    It isn't really a game until a fight breaks out

• Estimate separately• Fight out the differences together

Photo Credit:Peter http://www.flickr.com/photos/psmithy/3282607845/

Examples:

Built by the underwear gnomes

Example

About those listsHow do you create a task breakdown for something you haven't done before? • You can't1. Do a prototype2. Find someone who has done it before sub-contract/buy

training Common pitfalls:

1.Undiscovered requirements • Undiscovered requirements• Undiscovered requirements • Overoptimistic/pessimistic team members• Undiscovered requirements • "You don't know how much you do not know"• Uncommitted members of team (includes customer)

 

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

• Since the customer is involved.   o Let them decide what to cut. Or to add budget. 

• 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 cut

• Reality will not change no matter how convenient that might be or how much you need it to 

• Some projects should be avoided.Photo Credit: Anthony Kellyhttp://www.flickr.com/photos/62337512@N00/4335060317/

Putting it all together

1. Understand the problem2. Make a Wireframe.3. Make the Customer tell you why its wrong4. Repeat steps 2 and 3 until you don't get it wrong.5. Make a list of tasks (Work Breakdown Structure)6. Estimate time in fixed amounts7. Use the skill of the people you work with.8. Make a list of declined, deferred and discussed items that

are NOT included.  Put this list in the contract9. Contract should state that only features that are in the

contract are included.  No others.

Further Reading

Extreme Programming by Kent BeckGetting Real by 37 SignalsApplied Software Project Management by Stellmane and GreeneRapid Development by Steve Mconnell

About me:

Johnnie FoxTwitter:  @johnniefoxwww.britesparkz.comwww.johnniefox.com

Cat HerderFire FighterBad DancerProject Manager ResearcherProgrammer