Your SlideShare is downloading. ×
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Project estimation: When the design is bigger than the back of a napkin
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Project estimation: When the design is bigger than the back of a napkin

1,263

Published on

Project Estimation slides from Barcamp Memphis November 13, 2010. A short presentation of strategies for estimating the level of work it takes to complete software projects

Project Estimation slides from Barcamp Memphis November 13, 2010. A short presentation of strategies for estimating the level of work it takes to complete software projects

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,263
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Project Estimation When the design outgrows the back of the napkin Johnnie Fox www.britesparkz.com @johnniefox
  • 2. 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
  • 3. Overlapping Models
  • 4. 1. Understand the problem What is: o This project anyway o Technologies involved o Clients side involvement  Hardware  Hosting  People  Departments/managers Importance of Customer involvement o Who are the key contacts? Could be one or multiple o Need Only ONE Decision Maker! o You know they are participating when they tell you you have it wrong
  • 5. 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/
  • 6. 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 paper o 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 
  • 7. 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 .
  • 8. 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. koppdelaney http://www.flickr.com/photos/h-k-d/
  • 9. Did I mention that task  estimates of over 2 days  are WRONG? Photo Credit:Bob Fomal http://www.flickr.com/photos/fornal/406285615/
  • 10. 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 Slater http://www.flickr.com/photos/pikerslanefarm/4 996863774/ • 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
  • 11. 6. Make a list of tasks Modified 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.
  • 12. 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/
  • 13. Examples: Built by the underwear gnomes
  • 14. Example
  • 15. About those lists How do you create a task breakdown for something you haven't done before? • You can't 1. Do a prototype 2. 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)
  • 16. 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 assumptions o maybe you can re-factor the solution o 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 Kelly http://www.flickr.com/photos/62337512@N00/433 5060317/
  • 17. Putting it all together 1. Understand the problem 2. Make a Wireframe. 3. Make the Customer tell you why its wrong 4. 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 amounts 7. 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 contract 9. Contract should state that only features that are in the contract are included. No others.
  • 18. Further Reading Extreme Programming by Kent Beck Getting Real by 37 Signals Applied Software Project Management by Stellmane and Greene Rapid Development by Steve Mconnell
  • 19. About me: Johnnie Fox Twitter: @johnniefox www.britesparkz.com www.johnniefox.com Cat Herder Fire Fighter Bad Dancer Project Manager Researcher Programmer

×