# Project Cost Estimation – How to Do It the Right Way?

• November 10, 2020
• by Jakub Szyszka

Providing a precise and realistic project cost estimation is not an easy job. It may seem like a no-brainer at first sight, but don’t be fooled. For some companies, it can make or break your services company. A proper project estimation sends a clear message both to your clients and your team that is assigned to that project.

So what happens when it’s not that clear and understandable?

Well, this is where we start.

## How to estimate project costs?

Usually, a project estimation takes into account two crucial factors:

• Time – meaning: how much time will the project last in all of its phases.
• Cost – well, you get it: how much it is going to cost.

That’s a pretty straightforward concept.

However, it doesn’t mean that you’re going to rely on simple math equations.

## The basics of a project cost estimation

The usual bread and butter way of calculating a project estimate is just considering an estimated timespan of certain parts of the project.

Then, you pair it with a relevant set of hourly rates (assuming that your company has an hourly based pricing model).

For example:

A complete web app will keep a team of 3 developers busy for somewhere between 380 and 450 hours.

With an hourly rate of \$80 taken into account, the estimates are at \$30,400 – \$45,000

That, in theory, is a project cost estimate. Now what?

## How are project estimates used in business?

Estimates are usually calculated in the two most popular scenarios:

• A company wants to secure a budget for this project (either from an internal or external source)
• A company wants to win over a client as the estimates are a part of a request for a proposal. In this case, it also serves as an official offer for the prospective client.

Once a client receives this sort of estimate, he’s capable of assessing his budget and match it to the offer.

Case closed. In theory…

## The three problems with project estimates

Although the process of a project cost estimation is here to stay for a long time, they have their fair share of problems and challenges.

Both for project teams as well as the clients.

### 1) A project cost estimate is an opinion.

The most common issue is that a project estimate is somewhat a subjective opinion of a specialist that analyzed the potential timespan of a piece of work.

Meaning:

there’s a risk that, for example, two different software developers can have two different outlooks on how long a part of a project should take.

Why is that?

Well, these two different software developers have the same experience, but they might have had different perceptions of what tasks can be difficult or time-consuming.

### 2) Clients take project estimates for granted.

It’s crucial to understand that in a business context, the client usually is the one sending out a request for proposal (aka RFP) to compare offers from different companies in order to make a decision on who to work with.

Therefore, an official offer will consist of basically project estimates and a forecasted project plan with a set of milestones.

In this context, clients must translate these figures into actual project costs…

Because, well…

They need to assess the budget (assuming they’re not dealing with a fixed budget in the first place).

This means that it is difficult for the client to understand that the provided project cost estimate can vary on both ends as numerous factors can impact these estimates.

### 3) Business and project teams aren’t on the same page.

Well, I hate to break it to you, but this is kind of an agency and software company standard that most of us know, but we’re not as keen on admitting it:

• Business/sales teams want to acquire clients, sometimes going the length of trying to bring a more convenient offer (meaning: a project that is underestimated). Here’s a post where I go into full detail about my experiences.
• Project teams are always demanding an accurate project cost estimation to avoid an unrealistic workload.

## Popular ways of estimating costs

Whether that’s software development, construction, or marketing services, companies always deal with providing estimates in two ways:

1) Bottom up estimating – is often used when a project has its scope fully disclosed and the teams are able to estimate all of the smaller segments and components. This results in the final estimate being a sum of all of the incremental parts.

2) Top-down estimating – used mostly when a project’s budget is set at a fixed number. Then, the teams are able to assess how big of a project scope is possible to be fulfilled.

### Next steps: applying estimates to projects

Once a project is scheduled to start, the previously delivered estimates will serve as general guidelines to prepare a project plan.

These also come in different shapes and forms.

That will indicate how the team should allocate their time towards creating a work breakdown structure.

### Set up milestones

You need to distinguish parts of the project that can be fulfilled separately, like a mobile app’s main menu.

Having that will allow you to set realistic expectations in terms of the scheduled deadlines for delivery.

Can you also describe smaller parts of a particular milestone?

If yes, then…

### Break them down into smaller chunks or tasks

When a project is listed as one big task scheduled for the upcoming weeks, your team won’t like it.

Big tasks have a terrible impact on a team’s motivation.

Why?

Well, it takes a lot of effort and time to deliver, so you don’t have any segments that you could claim as “done,” which is essential for having a sense of progress and accomplishment.

### Plan for different scenarios

I love this part.

How do you call an optimistic estimation?

A letter to Santa Claus

If an estimate doesn’t account for different scenarios, it shouldn’t be considered an estimate.

What happens when someone from the project team leaves?

Okay, you hire a new team member. Fine. But is he/she capable of catching up to speed on what the project is about?

Would you bet on it as a likely scenario? See?

### Set up timeframes

Setting up a work breakdown structure seems like quite a big job to do, but that’s where you definitely should consider some advanced project management software such as Trello, Asana, or Jira.

They’re a charm to work with as they allow you to set up tasks and subtasks, add deadlines and milestones, as well as assign multiple people to ensure that your whole team is on the same page.

### Learn from agile working software companies

Software companies that work in an agile environment are an excellent example of leveraging short yet clearly defined stints of work.

Sprints. Why do they work?

Well, for once, they usually last a week or two, so it’s short enough of a timeframe to have frequent reviews.

In simple terms, agile teams can work on their project entirely focused.

### Crucial to note: collect cost estimates!

On the flip side, most software development companies (based on my own experience) have one pitfall: they don’t store the estimates that they’ve created.

And this poses a severe risk to their processes. There’s a chance that similar projects could be estimated completely different since different people provided the estimates.

Collecting historical data is crucial for optimizing your project workflow as well as the estimation process. Without that, the likelihood of your project is considered a successful project drastically drop.

A good starting point is creating a document or a spreadsheet where every estimated project would be stored.

Then, the tech teams can then evaluate how an estimated project turned out in real life throughout time.

If any differences between the result and the estimate were noticed – what were the reasons and premises.

## Final words

Here you have it, another tough challenge for agencies, software companies, and all other services businesses.

Would be the overall conclusion?

Just as previously, project managers need to implement the right processes to avoid randomness in a very crucial area, which is project cost estimation