Menu
Creating a project estimate is often a necessary evil. It’s one of the things that is incredibly important to you and your company but is nearly impossible to do perfectly. We cannot read the future, and projects have a lot of unknowns. So, your project estimates cannot be perfect. Still, they can make wise predictions about the project given the information you currently have available and knowing your past experiences with similar projects.
We live in a world of clients, budgets, timelines, and proposals and most of the time, someone on the client side or internally asks “how long will this take?” and “how much will this cost?”. Regardless of who is asking those questions, everyone should understand that these are estimates and predictions and that things can change along the way.
The goal is to try to make the unknown a little more known, and estimating is a process that helps do that. It forces you to ask questions, make clarifications, split tasks into smaller pieces, and look back at your previous experiences to make good judgments.
Sometimes, an estimate is merely a good idea to gain clarity for a future project. Sometimes these numbers are required for a project proposal or an up-front invoice depending on how your agency is structured.
The first step in estimating a project is to have a solid grasp of the project’s goals. What are you making, or what are you accomplishing? Ideally, your client has already done a good amount of work laying out their vision for the project, and your team has already started adding some ideas on how that vision could be executed. If you still feel like things are too vague, you probably need to circle back with your client or your team to bring more clarity to the project. Try to nail down exactly what you are accomplishing and the deliverables. This article talks about that aspect a bit more.
You may have a high-level idea of what you must accomplish, but you must start breaking those down into smaller steps. Instead of “Make a Website,” start to outline the sub-tasks to accomplish that goal. A website project might start looking something like this:
These steps at least break the idea of “Make a Website” into sub-steps. They are probably still too generic for your project! What unique steps does your project require? What unique steps does your team require?
Now that you have broken the project into steps do it again! Continue breaking down each step into smaller steps until you can’t do it anymore. For example, “Functionality Requirements” is made up of steps like:
As you add hours to these tasks, it will become more obvious to you where things can be broken down even more. Some teams even have a rule that a task cannot be estimated at more than X hours (Maybe 20?). This forces you and your team to split big tasks into more manageable chunks. The goal here is to get tasks down into estimable chunks.
When you “estimate” that “Functionality Requirements” will take “20 hours,” you just pulled a number out of your head with no real evidence from the real world. This approach will cause trouble down the road! But when you look at the list above and decide that “Document Revisions” could take 6-8 hours with 3 people, this is probably a more accurate number collected from your past experiences with revising documents like this.
Now that you have split your tasks into smaller, manageable chunks, it is time to put numbers into them. Hopefully, you are tracking your hours on previous projects so that you can look back at the time spent and use that data to develop a realistic number for your future task. This is not easy. Each project is unique and will have its own set of exceptions. In addition, as people enter their time, it may not be structured in a way that is helpful to you.
If you don’t have past numbers, you will rely on your past experiences. This won’t be as accurate because our minds play tricks on us. You may remember one part of the project going well and another being dreadful. It’s very possible the dreadful part did take longer, but how much longer? To what degree?
Be careful not to overestimate your or your team’s ability to do certain tasks. We often have idealistic views of our capabilities, or rose colored glasses about the last project. You may have done a similar project, but that doesn’t always mean it will go faster this time. Sometimes, there is just a process and time that a task will take and cannot be sped up with additional knowledge. Oftentimes, you will find that previous experience may make the quality higher, but not necessarily faster. Bad assumptions are the killers of project estimates. Become an expert at questioning yourself and determining what might go wrong.
Be aware of red flags like new technologies or new integrations. These sorts of unknowns are often the culprit when projects ballooning in scope and going over budget. What steps could be taken to be more familiar with these unknowns? Could you find an expert who knows them and run your project plan past them? Could you give your developer 1-2 hours to read the documentation and get a feel for the issue?
An estimate is a guess, and it should be treated as such. Giving someone a single number may exude too much confidence in your estimate. Even though you have told them as such, they may still treat a single number as an invoice– a sure thing. It can help to think in ranges. The most common approach is to develop a high and a low number for each task. Some tasks may be more well-known, and the range will be small: 1-2 hours. Other tasks may have more variation: 20-30 hours. Thinking in ranges allows you to admit that you may be wrong.
3-point estimation is a method that adds another number to your range. Instead of only a high and a low number, it adds a middle number. The low would be considered the “optimistic” estimate, the middle is the “most likely” estimate, and the high is the “pessimistic” estimate. Using the NASA developed PERT formula it can weight the middle number more highly and help to make your estimates more accurate.
You are not the expert on every portion of the project, so it should be obvious that you cannot accurately estimate tasks you don’t do. You are not a lone wolf. Part of the estimating process is going to the experts and getting their ideas on how long things will take. You are the guide that helps these subject matter experts break down their tasks into more manageable parts. You are the question-asker, the clarifier. Make sure your whole team participates in scoping and estimating a project. It is valuable to have them start thinking through their process from the beginning of the project.
You cannot know everything that will happen in the course of a project, and so you need to leave room for unknowns. There are different approaches to this. Some project managers add a markup at the end of a project. Maybe it’s 20% or 40%, or even 100% (double!) of the project’s price. This gives you some margin to deal with the unexpected.
While a handy spreadsheet can work fine for some project estimation, it can be helpful to use project estimating software. It can help in several different ways:
Our software is called Simple Estimate. It allows you to create estimates quickly and easily in a structured process that can be used for every new project. It automatically remembers each employee’s hourly rate that they bill for and speeds up entering time estimates. You can easily share an estimate via PDF, Excel, or an online web share. Give it a try!
Once you have the first draft of your estimate done, it is time to get feedback. You may want to consider multiple rounds of feedback. First, follow up with those individuals doing the work and get their 2nd opinion on the estimates. Ask them if they are still comfortable with the numbers they gave you originally. Consider sleeping on the estimate for a day or two, giving yourself more time to think, which is valuable to the process and will allow you to reconsider a few bad assumptions you may have made. After that, you’ll need to identify the project’s stakeholders and show them the estimate. Try to anticipate questions that they will ask before showing it to them.
Project estimates are tricky for new project managers and those who have been making them for years. You can refine your process and give yourself more confidence in your decisions, but they will rarely become easier. Be clear with yourself and your team that this is an estimate, and things may change along the way. That is normal and to be expected. Best of luck!
Simple Estimate is a tool designed for agencies and dev shops to make sense out of the estimating process.