Estimating Project Timelines

Most engineers feel uncomfortable when asked to report timelines to their boss for the first time. They are not sure how to communicate, what to do when a deadline is impossible, or how to explain how long something really takes. I was asked about this recently, so I thought I'd write up what I've learned from experience.

Being able to lead a project independently — analyzing requirements and estimating timelines — is one of the most important skills in a software engineering career. Early on you might be estimating for just yourself; later you'll be coordinating a team, discussing with leadership, and seeking help from others. Without this skill, projects quickly spiral out of control.

An Interesting Natural Phenomenon: Meteorites Are Always Falling

After nearly ten years in software development, every engineer dreams of finding a company with no "meteorites" — unexpected urgent requests that derail everything. But the longer you work, the more you realize every company has them to some degree. Meteorites are like a fact of nature; they happen constantly, you just don't always see them coming. There's always a more important, last-minute business goal, or a boss who wants to slip in a new request, which reshuffles the team's priorities.

The real measure of progress isn't eliminating meteorites — it's how well you can absorb and coordinate around them, reducing the impact on the team. Going from getting hit every day to getting hit once every two weeks is a huge improvement.

Most senior leaders come from a sales or business background, so they care most about the business value a project delivers. Their instinct is to ship as fast as possible: the sooner a feature goes live, the sooner the company earns money. Their approach tends to be "set a target, then figure out how to hit it" — which means the go-live date comes first.

Engineers, on the other hand, need to understand the requirements first, break them into tasks, and only then know how long things will take. That means engineers must produce a Work Breakdown Structure (WBS) before they can estimate anything meaningful.

A Quick Review of the Software Development Process

The textbook software development flow looks like this. In practice, the pace of product requirements today is so fast that many in-house engineers end up handling everything from requirements gathering through deployment on their own.

• Requirements Interview — deliverable: requirements document or sign-off
• System Analysis — deliverable: analysis document or functional specification
• Development — deliverable: codebase, feature implementation
• Testing — deliverable: bug reports or test reports
• Go-Live
• Operations & Maintenance

First: When Faced with an Impossible Goal or an Unrealistic Deadline

Don't refuse outright. Instead, take the time to plan and analyze, then come back to the stakeholders with a discussion about possible compromises — or escalate to get additional resources.

Step 1: Understand the Requirements

What is this project supposed to do? Confirm that your understanding matches what will actually be built, and clarify what outcome the requirement is trying to achieve.

Step 2: Analyze the Requirements

Once you understand the requirements fully, explore your options: is there a better approach? Are there open-source libraries that could speed up development? Take stock of available resources, identify who you need help from, figure out how many people are needed, and assess whether there are major technical challenges. For anything particularly complex, consider running a proof-of-concept (POC) at this stage.

Step 3: Break Down the Work

List every work item by module, page, and component, and estimate the time for each.

Step 4: Estimate Hours

A workday is 8 hours, but after meetings, breaks, and buffer time, a realistic estimate is 6 productive hours per person per day. Using 6 hours instead of 8 tends to produce more accurate estimates in practice.

Step 5: Testing

For larger projects, reserve two weeks before the go-live date for testing.

If the Deadline Is Fixed

Take stock of your options:

• Phase the work — Users always have a long wish list, but a few things matter most. Identify the must-have features, split the project into phases, and assess whether the critical features can be delivered on time.
• Add headcount — Propose bringing in more people. Keep in mind that new team members don't immediately add capacity; they need time to ramp up, and the team needs time to onboard them. It's usually best to assign simpler tasks to new hires so you're not both rushing to ship and trying to train people at the same time.
• Overtime — Only if the company provides overtime pay and team members are willing. Alternatively, negotiate a compensatory time-off arrangement with your manager.

Negotiate and Discuss

Bring your prepared task list, timeline, and proposed solutions to your manager. Having concrete data makes the conversation far more productive.

Final Thoughts

Project estimates are rarely perfect, but that's okay. What matters is delivering what users care about most before the deadline, splitting the rest into follow-up phases, and being able to explain your reasoning clearly. When you put in the effort and communicate well, most stakeholders and managers will understand.

The rise of AI is a bit like a slowly heating pot — it has quietly taken over a lot of the foundational and mid-level engineering work, reducing the number of entry- and mid-level roles while making each individual engineer more productive and opening up new opportunities. There is still much to learn in every project: the underlying logic, the system thinking, the fundamentals. These cannot be automated away. Don't be an engineer who only writes code — because when the tools replace that work, you need to have already found your next path.