Software Project Estimate Excel Template and Example

on
Free Software Project Estimate Template in Excel / Google Sheets  The template below has been successfully used in dozen of software development project. It calculates total project effort based on development estimates.  You can finetune the template to your project by adjusting corresponding percentages. Please follow the steps below to obtain full and realistic project estimate. Free Excel Software Project Estimate Template Free Google Sheets Software Project Estimate Template How to use this template Please follow the steps below to obtain full project estimate. Fill-in the cover.  It is important to list all the assumptions that make your estimate relevant. They may include the versions of frameworks, agreements with your client or contractors, disputable points in project scope definition, requirements etc. Place them onto Assumptions sheet. Create a WBS for your project. Noun-based WBS is preferable. List the work items in ESTIMATE sheet. Carefully read the contrac...
1

Project Estimation Tips and Tricks

on

  1. Carefully read the contract, RFP or any other document that frames the target scope and your commitments. Do it two times: before and after the estimation.
  2. Treat any estimate delivered to your client as a commitment.
  3. Make sure you have enough time and resources necessary for the estimation. it may not be obvious to many clients that estimation needs significant time and resources.
  4. Never do off-the-cuff estimate. Take time, at least several minutes. It is extremly easy to misestimate when you are not prepared. Moreover, it can make a false expectation that estimation is easy and does not require time or preparation.
  5. Never ever put zero as estimate of a task or project you have not actually estimated. You bet it will be taken as free lunch. Because Zero is not null!
  6. If there is a piece of work you have mot estimated, state it explicitly as NOT ESTIMATED. This will help avoid any confusion and give you more freedom to increase project budget if needed.
    NOT estimated task

  7. If there is a piece of work you consider to be out of scope, mark it as OUT OF SCOPE. 
    task out of scope

  8. Write assumptions and make sure the addressee of your estimate reads and acknowledges them.
  9. Remember that the number of negative risks (that can increase task effort) is unlimited, but the number of positive risks (that can decrease the effort) is typically limited and known.
  10. Agree with your developers what development comprises. Typically a developer will estimate the activities on the left forgetting about work on the right:
    what development consists of

  11. Be more pessimistic when estimating large tasks and more optimistic when estimating small. Overestimation of small tasks is highly visible and undermines the trust in your estimate. Whereas underestimation in small tasks does not bare any risks.
  12. Be extremely careful when you are asked to rewrite an old undocumented system using new technologies. Software system cannot serve as requirements specification, even if you client thinks it is simple and clear. The risk here is that without a written spec, only having an old system you can never tell if you have completed the project. The number of scenarios to verify is potentially infinite. The effort to develop the old system (if known) it can serve as a coarse estimate to develop a new one.
  13. Developers, as most of human beings are optimists. It is not in our nature to think about bad scenarios. It requires special training and experience to see the risks no-one sees. Do not trust your developers in estimation and always challenge them with potential problems. A good exercise is to imagine that you project has completely failed and think about possible reasons that could cause it.
  14. Never tell the estimator any number you expect. If you have more than one estimator, let them estimate as independently as possible. Revealing any numbers prematurely can lead to anchoring problem.
  15. If your estimate is done by senior specialists "as for themselves", introduce proper adjustment for less qualifies executors.
  16. Identify risky requirements like "...this must be done throughout the system" or "the system must support all languages". Such requirement are either not realistic or can increase the effort by an order of magnitude.
  17. It is convenient to user powers of two: 0.5, 1, 2, 4, 8, 16... or Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21... as a scale for estimation.
  18. Round up your estimate to some big number. For example, the estimate of 1586 man-hours can make a false impression of precision rather than 1600 man-hours.
  19. As a rule of thumb, the effort of a typical software development project is three times higher than development effort alone. Interestingly, this coincides with the conclusion of classical book Mythical Man-Month written in mid 70s.


Comments

Post a Comment