Software Project Estimation Survival Guide


Published on

Software Project Estimation Survival Guide.
A practical approach to making estimates that both you and your clients can live with.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Project Estimation Survival Guide

  1. 1. Project Estimation When the design out grows the back of the napkin Michael Cummings     @realtimemichael
  2. 2. Overlapping Models
  3. 3. Estimating is Important <ul><ul><li>Your customer asks for an estimate to make decisions </li></ul></ul><ul><ul><ul><li>Hire you? </li></ul></ul></ul><ul><ul><ul><li>Fire you? </li></ul></ul></ul><ul><ul><li>Typically, the project specifications are bad </li></ul></ul><ul><ul><li>You must question the specifications </li></ul></ul><ul><ul><ul><li>Look for holes – missing pieces </li></ul></ul></ul><ul><ul><ul><li>Look for bad design </li></ul></ul></ul><ul><ul><ul><li>Make sure it really is a Drupal project </li></ul></ul></ul>
  4. 4. Your Customer's Job <ul><ul><li>To get a low estimate </li></ul></ul><ul><ul><li>Leave lots of room to add stuff later </li></ul></ul>
  5. 5. Your Job <ul><ul><li>Give an accurate estimate </li></ul></ul><ul><ul><li>Leave NO room to add stuff later </li></ul></ul>
  6. 6. Who Wins? <ul><ul><li>If you win: </li></ul></ul><ul><ul><ul><li>You can get more money later </li></ul></ul></ul><ul><ul><ul><li>You can actually complete the project on time and on budget </li></ul></ul></ul><ul><ul><ul><li>Your customer wins too </li></ul></ul></ul><ul><ul><li>If your customer wins: </li></ul></ul><ul><ul><ul><li>You will be working all day and all night for no pay </li></ul></ul></ul><ul><ul><ul><li>It will be your fault </li></ul></ul></ul><ul><ul><ul><li>He will be mad about a late / over-budget project </li></ul></ul></ul><ul><ul><ul><li>He won't really win </li></ul></ul></ul>
  7. 7. What is an Estimate? <ul><ul><li>Your customer thinks an estimate is a price </li></ul></ul><ul><ul><li>An estimate is not just a price </li></ul></ul><ul><ul><li>An estimate without a specific, limited list of functionality is the road to developer hell </li></ul></ul>
  8. 8. How to Estimate? <ul><ul><li>Estimate based on specific list of items (Scope of Work) </li></ul></ul><ul><ul><li>Also list items discussed but not included </li></ul></ul><ul><ul><li>Your Scope of Work is your Fortress Walls </li></ul></ul><ul><ul><ul><li>Resist adding additional items </li></ul></ul></ul><ul><ul><ul><li>OR Get additional money and TIME for additional items </li></ul></ul></ul><ul><ul><ul><li>OR Agree to push additional items to version 2 </li></ul></ul></ul>
  9. 9. 1. How Strong is Your Fortress? <ul><ul><li>Can you defend against: </li></ul></ul><ul><ul><ul><li>“ But, I just assumed xyz feature was included.” </li></ul></ul></ul><ul><ul><ul><li>“ We talked about xyz feature, where is it?” </li></ul></ul></ul><ul><ul><ul><li>“ The project is useless without xyz feature, you should have known that was in there.” </li></ul></ul></ul><ul><ul><ul><li>“ The business changed, and we really need xyz feature now.” </li></ul></ul></ul>
  10. 10. 1. Understand the problem <ul><ul><li>Skip this step – you die </li></ul></ul><ul><ul><li>Pretend you understand when you don't – you die </li></ul></ul><ul><ul><li>Your customer does not understand the problem either </li></ul></ul><ul><ul><li>Customer participation is key </li></ul></ul><ul><ul><ul><li>If your customer looks at your very first draft and says “It looks fine to me.” Run for your life! </li></ul></ul></ul><ul><ul><ul><li>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 </li></ul></ul></ul>
  11. 11. But I Don't Get Paid for Writing Documents! <ul><ul><li>Nobody will pay you for writing an “Estimate” </li></ul></ul><ul><ul><li>Good customers will pay for “Project Design” </li></ul></ul><ul><ul><li>You decide what you call this work. </li></ul></ul>
  12. 12. 4. Mock ups /  Wireframes <ul><li>Should be Low-Fi to begin with  </li></ul><ul><li>Using full Photoshop mockups will take much too long and spend time on pixels too early in the process. </li></ul><ul><li>Tools </li></ul><ul><ul><li>Google docs/drawing </li></ul></ul><ul><ul><li>Paper </li></ul></ul><ul><ul><li>I like Balsamiq Mock-ups </li></ul></ul><ul><li>Examples : </li></ul><ul><ul><li>Print them out. Users should mark them up </li></ul></ul>photo credit:
  13. 13. 2. Use the skills of your people <ul><li>An estimate made by anyone that does not fully understand the work that is to be done is going to be poor. </li></ul><ul><li>Giving your team a look at the project can help you avoid potholes </li></ul><ul><li>Don't Poison the well - don't give leading information </li></ul><ul><li>It is better to ask how long did this take you the last time than &quot;How long will this take&quot; </li></ul><ul><li>Use caution with developer estimates  </li></ul>
  14. 14. 3. Estimating Time  <ul><li>Time only comes in 2 sizes: </li></ul><ul><ul><li>1/2 Day  </li></ul></ul><ul><ul><li>Full Day </li></ul></ul><ul><li>Round up to nearest ½ day – it forces developers to be more realistic </li></ul><ul><li>Beware of estimates for a single item that are larger than 2 days </li></ul><ul><li>You DO NOT understand the steps if you make it larger than 2 days.   </li></ul><ul><li>Our experience is that an estimate of 3 days will be 5 days to weeks. </li></ul>Photo Credit: h. koppdelaney
  15. 15. 5. Customer Must be Involved <ul><ul><li>The customer must understand the functionality and appearance of what is going to be delivered. </li></ul></ul><ul><ul><li>You know they are participating if you get complaints </li></ul></ul><ul><ul><li>Do not accept &quot;Ya, that's fine&quot; </li></ul></ul><ul><ul><li>I have had customer who had signed a contract in blood demand additional features because they did not understand my text only description </li></ul></ul>Photo credit: <ul><ul><li>Involving the customer and frequent interaction helps both of you keep the expectations in check </li></ul></ul>
  16. 16. 6. Make a list <ul><li>Modified Delphi Estimation method. </li></ul><ul><li>Developed by Rand Corporation in the 40's </li></ul><ul><li>Fancy word for list - Work Breakdown Structure (WBS) </li></ul><ul><li>Members of the team make their list of tasks SEPARATELY  </li></ul><ul><li>After lists are made members meet and compare lists.   </li></ul><ul><li>Everyone must participate.  If there is no conflict and you didn't get any additions you are doing it wrong. </li></ul><ul><li>Team should agree on a list of tasks then go back and  and add time to the items </li></ul>
  17. 17. Examples: <ul><li>Built by the underwear gnomes </li></ul>
  18. 18. About those lists <ul><li>How do you Estimate something you haven't done before? </li></ul><ul><ul><li>You can't </li></ul></ul><ul><ul><li>Do a prototype </li></ul></ul><ul><ul><li>Find someone who has done it before sub-contract/buy training </li></ul></ul><ul><li>Common pitfalls </li></ul><ul><li>     </li></ul><ul><ul><li>overoptimistic/pessimistic  team members </li></ul></ul><ul><ul><li>undiscovered requirements </li></ul></ul><ul><ul><li>&quot;you don't know how much you do not know&quot; </li></ul></ul><ul><ul><li>uncommitted members of team (includes customer) </li></ul></ul>
  19. 19. Example
  20. 20. If I add up all the time..its too much <ul><ul><li>Add up all the time then decide if you want to buy/discount the project </li></ul></ul><ul><ul><li>Check your assumptions </li></ul></ul><ul><ul><ul><li>maybe you can re-factor the solution </li></ul></ul></ul><ul><ul><ul><li>some features may have to be cut </li></ul></ul></ul><ul><ul><ul><li>Since the customer is involved.   Let them decide what to cut. Or to add budget.  </li></ul></ul></ul><ul><ul><li>Reality will not change to no matter how much you need it to or how convenient that might be.  </li></ul></ul><ul><ul><li>Some projects should be avoided. </li></ul></ul>
  21. 21. Real Time Estimation Method <ul><ul><li>Understand the problem </li></ul></ul><ul><ul><li>Use the skill of the people you work with. </li></ul></ul><ul><ul><li>Estimate time in fixed amounts </li></ul></ul><ul><ul><li>Make a Wireframe. </li></ul></ul><ul><ul><li>Customer must be involved </li></ul></ul><ul><ul><li>Make a list of tasks (Work Breakdown Structure) </li></ul></ul>
  22. 22. Source books Extreme Programming by Kent Beck Getting Real by 37 Signals Applied Software Project Management by Stellmane and Greene
  23. 23. Further Contact: <ul><li>Michael Cummings </li></ul><ul><li>Twitter:  @realtimemichael </li></ul><ul><li> </li></ul><ul><li>[email_address] </li></ul><ul><li>Project Manager, Programmer .  </li></ul>  This Slide Deck at: