Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

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: