DDK's Guide to the Estimation of IT Projects

As an Architect and the .NET Principal at Oakton NSW, I have to do my fair share of Estimates and Proposals. I am also often asked to review and revise other peoples estimates - to "Quality Stamp" them so to speak. There are some common things that I pick up on - hence the driver behind this blog post.

Summary Diagram of the DDK Estimation Technique:

Here are some of the important things you should consider when developing estimates:

1. Estimate from the bottom up rather than from the top down. The focus and detail of this approach helps you to substantiate your estimates to others and show you've used due diligence in arriving at your estimate. A detailed function point analysis (FPA) is ideal when trying to minimise risk as much as possible (especially for fixed cost projects).
2. There are 2 critical variables which can make a project take much longer than expected and estimated. If you have these components, you need to increase your estimate to more than you expect:
  a. The larger and more complex the project, the more likely it is to take longer than expected.
  b. The more new technologies or new techniques involved, the more likely it is to take longer than expected

3. Communicate with and update the client regularly – Don’t be afraid to re-estimate your tasks and let the client know if things will take longer or shorter than expected. The earlier they know, the earlier corrective action can be taken.

4. Larger projects are harder to estimate. Only estimate small components of a project if possible – don’t estimate all releases. Deliver and estimate in increments if the client/contracts allow.

5. Make sure you consider the following components in your Estimation Checklist before giving it to the client:
  a. End User Documentation
  b. System Documentation
    i. Rollback Plans
    ii. Non Functional Requirements (NFR)
    iii. Technical Design & Specifications
    iv. Functional Design & Specifications
    v. Establishing Metrics (e.g. what performance is expected on what servers and with what data load)
    vi. Test Plans
    vii. Test Scripts
  c. Testing
  d. Training and Change Management (you can't just give someone an application and expect them to start using it effectively!)
  e. User Acceptance Testing
  f. Integration Testing (esp when integrating with Legacy Systems)
  g. Deployment Activities and Productionizing Systems
    i. Especially with complex deployments. These deployment activities are typically ongoing rather than once off.
  h. Meetings Drag Factors such as regular Meetings and Discussions. Team leaders and architects need a drag factor SCRUM meetings and requirement gathering meetings.
    i. Triage Meetings
    ii. Code Reviews
    iii. Level 2 Reviews by Testers e.g. For one of our projects, it took an average of 45 minutes per TFS work item/ticket.
  i. Focus Groups
  j. Licenses
  k. Configuration
    i. Third Party Components
    ii. Firewall Configuration
    iii. Database Configuration
  l. Data Migration
  m. Handovers (Including Warranty Periods)
  n. You need to anticipate who is developing it.
    i. Offshore Models/Engagements – have to spend 2-3 times the effort in non-development activities such as coordination, “hand-holding” and quality assurance when your team is overseas. You also need to spend much more time on specification documents to avoid communication issues.
  o. Temper your Optimism by considering different scenarios
    i. Best Case
    ii. Worst Case
    iii. Likely Case Scenario
  p. If uncertainty on a project is High, add an uncertainty multiplier to your estimate
  q. Don’t estimate more than 8 hours per day.
  r. Budget time for Performance Testing
    i. Time for Load Tests

6. If possible, do a Proof of Concept (PoC) before providing the estimates (or just estimate the PoC) – especially when using new combinations of technologies.

7. Learn from Historical Data. Try to learn from similar projects and how the estimates compared with the actuals. Use your company portal to discover estimates and ask other people in your company for similar estimates that they did.

8. Sanity Check your estimates. i.e. Have your estimates peer-reviewed to help you ensure consistency and coverage in your estimates.

9. Cross-Check your estimates. If you can convince all stakeholders that the estimate is valid and establish buy-in to that estimate, you have the basis of a good estimate.

10. Don’t underestimate Non-Programming/Infrastructure activities.

11. Don’t change estimates if possible if they are based on a solid agreement or understanding. Instead, try and change the commercial arrangements surrounding the estimate. E.g. don’t change the estimates unless they are proven unreasonable – change the rate if possible.

12. All estimates are guesses – try and reduce the uncertainty – but you cannot remove uncertainty completely.

13. Try to make your estimates from a fully informed standpoint - the same as a General shouldn't make strategic decisions in the fog of war. Request and Review as many materials (including scribbled diagrams and requirements documents) as time allows. The more you discuss your understanding of the project and talk to the end users, the more likely you are to make an informed estimate. Again, this allows you to back up your estimates to all stakeholders. If there are factors in the project that are particularly unclear or uncertain, add an "uncertainty" multiplier on the item. Encourage the client to help you clear up this uncertainty if possible.

14. Use the right tools. Microsoft Project is a good start. Learn how to use it properly - plus it can then create and update developer work items for you in Microsoft Team Foundation Server (TFS)  when you are ready to start work.

15. Don't forget that external dependencies (e.g. a 3rd party is creating web services for you, waiting on documentation) will slow the project down. Ideally start the project when work you depend on is complete - otherwise you'll need to factor downtime into your budget, estimates (an expected "downtime" item) and estimate assumptions.

Any thoughts or comments on this guide and checklist are welcome - I will update the list based on feedback.

DDK