Project Estimation Techniques. Successful Methods ★ Inspeerity

Have you heard about #YesEstimates and #NoEstimates movements? There is a huge debate since 2012 in IT World.

Woody Zuill, Vasco Duarte and Neil Killick are three of the most shouting proponents of the #NoEstimates approach. On the other side of the fence, there is an old school #YesEstimates business-friendly movement with a lot of followers. Let’s check both sides theses.

#NoEstimates:

Estimates are always inaccurate and therefore pointless.
Estimates are a waste of valuable time. Instead of beginning the work, developers are involved in the useless estimation process.
Estimates exist in IT world because they have been a part of the process for so long that all community assumes that is necessary.
Estimates lead to project dysfunctions like low quality, overtime or wasting time.

#YesEstimates:

It is possible to do the correct and valuable estimation.
The cost estimation is very crucial for project success.
The lack of estimation isolates business people – they are not able to allocate budget.

In this blog post, I will not follow the #YesEstimates nor #NoEstimates debate because theses of both sides are very reasonable. I would like to describe my experience and thoughts.

Ready to start?

Have you ever thought about your own house with garden, or have you built your dream house from scratch? I did it!

Now, imagine the situation that you have a meeting with house developer who says:

Hey! I don’t know how much it will cost, we will see. Let’s start with the most valuable things like walls, a roof, windows, and we will finish when your budget is exceeded.

Are you brave enough to agree with him? I am not, because I have to know how much money it will cost, how big the mortgage should be, or even I don’t know if the developer is not cheating me. The answer could be different if I would be a millionaire.

The same case is in IT project. There is always an investor who has to pay for the product and the developers’ team who has to deliver the system. If you had a chance to be on the business meeting with investors and if you had proposed the Scrum or Kanban methodology, you know what I mean 🙂 In 99% of cases, the last question on this meeting is: HOW MUCH IT WILL COST?

Let’s talk about custom software development now!

Instead of fight a losing battle, just try to understand business people and prepare a good estimation. You can find below the list of potential techniques:

Work Breakdown Structure
3-Point Software Testing Estimation Technique
Wideband Delphi technique
Function Point / Testing Point Analysis
Use-case Point Method
Percentage distribution
Planning poker
Ad-hoc method.

Project Estimation Techniques. How to do it?

During my 15 years of experience in IT, I elaborate on my technique being a hybrid of Work Breadown Structure, 3-Point Software Testing Estimation Technique and Use-Case Point method.

In order to prepare a good technical estimation, I always follow these steps:

Understand a business need. No matter if it is a small feature or the whole system to create, the rule is always the same – think about this requirement from a business perspective and try to discover business drivers such as feature importance, innovation, target group, what type of problem it will solve. As a result of this step should be a short project description understandable for your untechnical friend and the list of similar products found on the Internet.
Evaluate the business specification and client knowledge. In this step, you should determine the project risk, especially
- your knowledge gaps,
- customer knowledge gaps.
As a result of this step should be the list of questions to the customer about unclear requirements. It can be also a suggestion to organize a meeting to collect all the requirements. The event storming technique is a good way to collaborate with the customer.
Identify the integration points, especially extract input and output interfaces in the system, for example, integration with payment gateway or export data to another system. As the result should be the list of integration interfaces and also risk prediction especially if the newly created feature waits for other vendor’s development.
Decompose the business requirements to small chunks, like login feature, user registration feature, the shopping cart, and others.
Go through the requirements from point 4 and assign one of the following knowledge categories to each point:
- FULL if the whole team did similar feature and everyone knows how to do it.
- PARTIAL if someone from the team members did similar feature.
- RARE if someone from the company did similar feature, and you can ask him.
- NEW if no one did similar feature in your organization.
Follow the requirements one more time and try to roughly decompose each requirement into technical steps. At this point, you should collect all technical ideas and potential frameworks/libraries to use. At this point, you should also describe the complexity from one of these values:
- SIMPLE,
- MEDIUM,
- COMPLEX.
Now it is time for your estimation! My favorite technique is PERT weighted average formula. Go through your document, analyze one-by-one each technical step and check the answer from point 5:
- if your category is FULL or PARTIAL, you will be able to precisely estimate the duration
- if your category is RARE, you will be able to roughly estimate the duration with a risk. Add 10-30% of the time for the knowledge transfer.
- if your category is NEW, try to convince the customer or your manager to implement a simple Proof of concept to validate some idea, framework or solution. If it is not possible to do a PoC, add extra time to your estimation.
Validate the estimation and forward it to the project management board, who will review it, add extra time for management and tests. Discuss with the project stakeholders your doubts and found risks.