Self-defense professionals are used to saying that the best self-defense tactic is running away. (not always true, and should be seen as a metaphor).

The same goes for estimates, the best is to not do them.

But what if you have no choice….

I'm in the IT business for more than 20 years. I've made hundreds of estimates for projects going from 5K$ to 3M$.

I was running a development shop of more than 300 developers, sold it in 2018, and worked for my acquirer, a company of more than 2000 developers.

I'm running code.store now, where we build robust digital platforms using no-code, low-code, and SaaS tools.

Let me share with you how you can get estimates right, within a 10% margin. But first, let's see why software project estimates are so often dismissed as useless or wrong and why it's such a painful process for such smart people.

Why software project estimates are often wrong?

There are a set of reasons that makes your estimates wrong and mostly underestimated :

• Accidental complexity: is a complexity that comes from the system itself, not from the feature. For example: adding a "contact us" form to a WordPress site is easy, but adding a contact form to a large ERP system is way more complex (where you have 10 roles in your app, who can access the form? who will receive the contacts? you need to log every single outgoing email sent by the platform, you'll need a security audit as soon as you implement a form, you'll need to add a set of automatic tests to pass the deployments, and you'll need code-review the feature, your project rules imply a fully specified and UX approved form…). Simply put: in a large codebase adding any feature has a minimum cost.

• Estimates are done by non-developers or juniors. Famous Dunning-Kruger effect (psychology, a cognitive bias whereby people with limited knowledge or competence in a given intellectual or social domain greatly overestimate their own knowledge or competence in that domain relative to objective criteria or to the performance of their peers or of people in general). They simply don't know what they don't know
• Poor scoping: To get estimates right, you need to go deep into details. You need to build a mental map of the entire project with all its implications, hidden features, and complexities.
• Changes. If not re-estimated, changes may have a huge impact on the project timeline and budget. The cost of the change strongly depends on when the change occurs (it's easy to change a Figma layer, but it's way more complicated to change a live app).

Should we estimate at all?

As I said, try to avoid estimates as much as you can. But there are often situations when you simply can't :

• In RFPs you're often required to provide a budget for the project
• In large organizations working with annual budgets, you need to plan costs of your IT projects
• When launching a start-up with limited funding, you need to carefully plan ahead your MVP cost.

How should you estimate an IT project?

First: How good is your team?

From my experience, a good team can be several times faster than a bad team. But what makes a good or a bad team?

You need a good team to avoid :

• bad architectural decisions (avoid costs of rework)
• programming silo (reusability)
• focusing on tech stack (vs focusing on fundamentals)
• too many assumptions, often wrong (vs gaining clarity by asking the right questions)
• clinging to implementation (vs clinging to solution)
• misunderstanding (vs clear communication)
• random methodology (vs sticking to strict SCRUM for example)

A good team has strong motivation. They know why they will do this project, they are interested in fulfilling the project and they understand the vision.

A good team has a senior and a coding team leader. It's key.

A good team communicates through ceremonies, in an organized way, without day-long Slack-blather.

A good team takes accountability for the project, without designating a scapegoat.

A good team provides valuable and regular feedback to stakeholders.

A good team has ideas to get around obstacles and provides clear questions to decision-makers and gives the impacts of each choice.

You need to be able to honestly estimate the quality of your team on a scale of 1 to 10, let's call this parameter Team Quality.

There is another important factor: how many projects the same team has already done together? The more, the best: they know each other flaws, and they can read between the lines.

They know when John says a task will be ready in 2 hours, they should expect it by tomorrow actually. Team Quality will play a role in the uncertainty factors, described below.

Who is your client? Or the importance of knowing your stakeholders

Before starting estimation you absolutely need to know as much as possible about your stakeholders :

• How important the project is for them? (a strategic project means fewer workarounds, more eyes, validations, and tests, …)
• What is their budget? (You can create an e-commerce site for 5000 USD or 30.000.000, it will play on the assumptions and tech stack selection)
• What are the meta-data of the project? Besides the scope and features, what is the hosting environment (Serverless functions? CI/CD? Containers?), expected traffic, CDN…
• Are there any hard deadlines? (Super Bowl finale cannot wait for your project)
• What team do stakeholders set up to follow the project on their side?
• How experienced is the Product Owner?
• How shitty is your client?

About the last point…

Imagine a client that runs a successful business, but knows nothing about IT. After the first meetings, you see that every single team member on the client's side is always waiting for approval from the boss. All your questions about the projects are immediately answered by him, interrupting his employees.

Once the project has started, all decisions are questioned weeks or even days later. Validations are made by phone, and never written down.

Every time you need to implement a workaround when facing unforeseen obstacles in the project, the client sticks to the original idea, even if the idea was a stupid one and would cost you tons of hours.

Well, that's a bad client. You will need to be extremely pessimistic in your estimates or avoid the project globally.

You should be able to rate your client on a scale of 1 out of 10. Let's call this variable Client Quality.

How to read IT project requirements?

I used to classify client's requirements into 4 categories :

• The "mockup": client worked with a UX to create more or less detailed mockups of his project.
• The "novel": you receive 50 pages word document packed with Times New Roman 10 text, full of internal business terminology.
• The "idea": 10 lines email from the CEO sent at 2 AM
• The "copycat": It's like Tinder mixed up with Uber (often a variation of the 'Idea' one)

You should dismiss the last two, and try to sell a discovery & design phase where you will do the design and create the backlog working with the client's teams. Let's focus on the Mockup and Novel ones.

Mockup based requirements analysis

In mockups, you have a clear understanding of user journeys and the UX. You need to imagine the back-end and business rules that are disseminated all across the screens.

It's the most dangerous as you need to focus on each small button or text, each can hide workflow, notifications, and data manipulations that may require a lot of work. Try to annotate mockups with your assumptions, data structures, and involved features.

Novel-based requirements analysis

The process of analysis here is quite different. You know what has to be done, but you don't know how it will look. How many screens will have to support a particular feature? How large are your data sets? How complex might be the front-end work?

Example from a real project :

The tool will allow preparing the supplier file for the integration of the different products indicated in the file in our product database. To do this, it will have to modify the column headings of the supplier file with the existing headings in our product database, following the information entered by the buyer. This will allow the tool to integrate afterwards data from the supplier file in the right place in the product database.

This short paragraph presents a quite complex feature where you'll have to manipulate the structure of XLS files. You'll need to modify and map columns, and present the contents of each file. You will need to integrate complex javascript libraries to load and show XLS files. It will require a lot of days for your team.

A good way to analyze "Novel" requirements is by trying to visualize the user journey they describe. Imagine the screens and buttons and try to mentally navigate inside your app.

How make assumptions while making project estimates?

Imagine the following user story :

"As a visitor, I can subscribe to a newsletter"

You can assume a variety of questions and unknowns :

• How newsletter content should be created? (manually? automatically based on the site's content? single contributor or multiple teams?)
• How and by who newsletter template can be changed? (by developers once a year or weekly by content creators?)
• Can we use an external tool?
• How many newsletters do we have?
• Do we need to migrate subscribers from an existing tool?

On each feature of your project, you'll have to either get the answers from the client or make some assumptions.

While making assumptions you actually take explicit decisions about features or architecture. The more you know your client, the better will be your assumptions.

A media site will probably create newsletters more or less automatically based on the content they produce, while a corporate client will have a team working exclusively on the newsletter content. That means an external tool like Mailchimp or Sendgrid is probably involved, while the media client would probably need the Newsletter feature to be fully integrated within their CMS.

Each assumption must be clearly described in your estimates to avoid the famous "why you did this, it was obvious we needed that" objections.

There are parts of digital projects that will usually see a lot of assumptions :

• Integration with legacy systems ("API should be documented, with working endpoints, test data, and available support from maintenance team")
• If the design is not ready yet ("the whole front-end estimates will be updated upon design reception")
• Data migration ("Data will be presented in JSON files, cleaned from unnecessary elements, with a documentation provided by the client about each object and mappings src/dest")
• Complex features like 3D, AR/VR, OCR, Machine learning, IAM, authorizations, blockchain integrations, etc…
• Front-end complexities: animations, transitions, gestures
• SEO & analytics: it might be as simple as adding a JS or as complex as 100 pages of tagging technical specifications.

Uncertainty factors in project estimates

How long would it take for you to go to the nearest groceries store?

You'll probably answer with a +/- 60-sec error. You know each step towards the store. You know how long it will take you to dress, go outside, ride there. You can have unforeseen events aka broken car, but let's assume everything goes as planned.

Now, if I ask you, how long it would take you to read Marcel Proust's "Remembrance of Things Past" you'll give away a less accurate response. You don't know the book, how many pages it has (actually it's the longest novel in the world with more than 4200 pages), or how complex is the subject.

When doing estimates you should assign for each task an uncertainty factor, based on the following definition :

• 1 — Unknown scope, technologies, and domain
• 2 — Slightly described scope, basic knowledge of the tech stack
• 3 — Good understanding of scope, lack of details
• 4 — Several details need to be described precisely
• 5 — Good understanding of scope, almost all details are clear
• 6 — 100% complete scope, perfectly clear architecture

Based on the previous, it's easy to calculate estimate ranges automatically. Imagine you estimated our newsletter example by 3 days of dev time. Using uncertainty factors you can now create a min/max range as follows :

• 1 : [Min = x0,17 ; Max = 6] means your task would take between 0,5 and 18 days (Scary. Not really working for a simple Newsletter example but if I ask you to estimate a tool that automatically generates an entire newspaper using AI, you would probably assign a 1UF to this one, right?)
• 2 : [Min = x0,25 ; Max = 4] gives you [0,75–12 days]
• 3 : [Min = x0,5 ; Max = 2] gives you [1,5–6 days]
• 4 : [Min = x0,67 ; Max = 1,5] gives you [3–4,5 days]
• 5 : [Min = x0,8 ; Max = 1,25] gives you [2,4–3.75 days]
• 6 : 3 days ;)

All tasks will not have the same level of uncertainty, make sure you add this factor for each line of your estimates. Don't worry, I've shared with you my estimation Google Sheet, keep reading, you'll find the link at the end of this article.

Detailed analysis of a single feature estimate

So how do you actually estimate a feature? I'll try to explain how my over-trained mind goes when analyzing requirements.

Let's take a real-life example from the latest complex ERP-like project I had to estimate a few weeks ago:

"In this screen, the buyer will be able to compare the prices between the different responses for the same product and will be able to ask a supplier to review the prices he has indicated. The result will have to be exported in Excel format."

A little bit of context first: the project is an ERP system manipulating classical business objects like contracts, invoices, quote, price-list, products, deliveries, customers, and suppliers. The feature is included in tender process management, where purchasers ask a set of suppliers to provide quotes for a specific product.

Assumption: I already have implemented suppliers, products, and quotes management. That means I have in my database a table with quotes from different suppliers linked to products with prices.

Let's go :

1. "the buyer": means I'll probably need to set some sort of authorization to show this screen to buyers only
2. "compare the prices": how many quotes do I have to compare? Probably 2 to 5 max, there is no reason to do more, because it's a manual process and I know my client well, I know how they work. But I still need to present quotes in a simple way to help buyers compare them line by line. This also means I need to take a look back at the quote object to make sure it's structured in the right, standard way. I take note that I'll need to validate that point with the client, I mark it as an assumption.
3. "for the same product": What happens if the quote has multiple products? I should be able to navigate between different products. There might be more complexities arising in the case of a supplier that doesn't have all the products. More logic to code here.
4. "a supplier to review": That means a lot. I need to notify the supplier (automatic mail generation, mail template). I'll need a specific workflow status for supplier quotes. I should be able to notify back the buyer once the prices were updated and probably highlight the changes (assumption here).
5. "exported in Excel format": XLS file generation, how should we structure it? It might be tricky with complex quotes, I'll also need to pull supplier details.

Based on the first high-level analysis of this feature, I'm ready to imagine the overall architecture. I split the feature into smaller tasks:

• Design the screen elements (UX & UI) (1 day)
• The front-end team has to work on a beautiful table showing lines from supplier quotes. (2 days)
• I need some action buttons to ask for a price revision, product selection, and export (0,5 days)
• I'll need to code XLS export and design the file format (1 day)
• I'll need to write a small workflow for the supplier's prices revision (1 day)
• I'll need to write the email notifications logic (or adapt the existing one) (0,5 days)
• I'll need to update the design of the supplier's "My Quotes" page with a status icon/color for prices revision (0,25 days)

The total initial estimate for this feature is 6,25 days.

I know the client has its own development team, perfectly knows his business, and has a legacy system that is already working. The project is strategic to him, no workarounds will be possible. There will be code and security audits. Client quality: 6.

Using the client quality is easy, I combine UF and CQ to get multipliers of my estimates :

The scope is quite clear, I set the UF to 5.

My 6,25 days turn into a range : [min 5 days, max 7,8 days]. Applying client quality scores gives me a new range. [6,5–10,1 days]

Quality assurance and project management activities

Each project will involve two parallel activities: quality assurance or testing, and project management. Do not dismiss those because you'll do SCRUM or Kanban. Your team will need to test your product, regardless of who will do the job developers themselves or dedicated quality assurance engineers. The same goes for project management. Even if you do SCRUM, you still have non-coding time being spent on the project to communicate with the client, do the sprint grooming, retrospectives, demo days, calls with external teams and partners, etc.

One good thing is that those activities are directly correlated to development time. But not only. The project complexity and size, client quality, and the number of involved parties will strongly impact numbers. Let's give some examples :

• A simple project, with static content and few pages would require 10% of dev-time for QA
• A medium-sized project with some basic transactional features (aka a simple e-commerce platform) will need 20% of QA time.
• A large and complex project like an ERP will require at least 40% of QA

A rule of thumb: 30% of QA is quite normal.

Concerning the project management time :

• Good client, simple project, everything is clear: 10% of Project management activities
• Annoying client, several external 3P services to integrate, 6 months project, 5 pax team size: 15% of Project management
• Terrible client, unclear scope very complex project of 18 months, dozen of stakeholders, and 3P services: 25 to 35% of Project management time.

So what does this means for our previous example?

As you remember we had estimated our task with a range of [6,5–10,1 days] of dev time. I estimate that I'll need at least 30% of QA and 20% of Project management. That means [2–3 days] of QA should be added, my range is now [8,5–13,1 days] on top of which I'll have to add PM time : [1,7–2,6 days]

Final tips: hidden activities, profiles, and budgets

A team working on your project will have different roles and rate cards. I suggest you split each feature or task into several profiles: UX, UI, Architect, PO, front-end developer, back-end developer, quality assurance, project manager, project director, CTO, etc.

Try to split your project into the smallest possible tasks, to get a more accurate picture of the budget.

Top-down validation

Once you've done your bottom-top estimate (split the project into smaller tasks, estimate each, and sum up) you should make a top-down control estimate. This time you roughly estimate the overall timeline of your project and provisioned team size and you simply multiply the costs.

If you estimate the project last for 6 months with a team of 5 pax, you should get something around 30 man-months. Do the numbers align? If not, you have a problem either with the planning, either with your estimates or assigned uncertainty factors, or team size.

Hidden activities.

Stakeholders usually focus on business value and corresponding features. But a project is not just a bag of features, you need to estimate time for activities like :

• Documentation
• Tools set-up
• Deployments
• User testing
• Environments setup
• Training
• Performance tunning
• SEO
• Synchronization with 3P services
• The learning curve of your team on new technologies

What if your estimates are 3 times higher than the stakeholder's budget?

If you do your job professionally and provide accurate estimates, it's probable that they will be higher than expected by your client. They simply didn't spend as much time as you did and they don't have your expertise.

It's time to review your estimates with the stakeholder and validate all your assumptions :

• How the project team will be organized on their side?
• Can they take care of all 3P communication and provide a central source of truth?
• Analyze in details features with low UF (1–3)
• Take your estimates line by line and add a priority column (Version column in my document)
• How accurate is your client quality guess?
• Can you onboard a team with a higher seniority budget
• Finally, go through the requirements and try to simplify the most complex features.

I put you a link to a fully functional estimation Google Sheet, enjoy: https://docs.google.com/spreadsheets/d/1XLusJGVqL8DLBNq67E8S-pfIrZpYAi9ckX-w6XnVFrI/edit?usp=sharing

By the way, if you want a professional team working on your next digital project, you can hire code.store :)