Everyone Thinks Their Problems Are Unique
If there’s one thing I’ve learned by talking to product owners, agency owners, freelancers, and software developers over the last two decades – it’s that we all know others must be experiencing what we are, but we feel like we’re the only ones.
The dissonance between our heads and our hearts is strong and it’s almost impossible to believe we’re all in the same boat.
Nevertheless, the truth is that we all face the same challenges that others are facing. And it helps to shine a light on it, so that we can get better at it.
Estimating – The Problem We All Face
Look at the biggest challenges you’ve faced at work. Had you estimated things more effectively, would they still have been big deals?
If you’re struggling with profitability as an agency, you know what I’m talking about. Simply having estimates that are more accurate eliminates a ton of problems, right?
If you’re a freelancer with the wrong clients, you know that a better and more accurate estimate would have pushed your price up, which would have changed your clientele, which would have saved you tons of time and drama. Right?
If you are a shop trying to get products launched, you know how much work it is to hit dates when estimates aren’t accurate and timelines slip.
In other words, we all struggle with getting estimates done accurately. But getting this right helps all of us!
Can I Tell You a Horror Story?
I was working on a set of projects where I was doing the estimating. The execs I worked with wanted to free me up, so they invited others to do the estimating.
I’m never someone who demands to do more work, so I let this strategy move forward, watching to see what would happen. I expected issues after all, because estimating is hard.
What I didn’t imagine is what would happen next. They asked one of the developers to estimate a new project. He did and sent back the estimate. Our account folks sent it to the client and got the fastest approval ever.
That should have been a red flag right there. But it took a couple weeks for us to realize the problem. The front end developer had only estimated the front end work. In other words, the estimate was only for 50% of the project.
We’ve all had those kinds or problems, even if they’re not that bad.
There are Multiple Approaches to Estimating
When we’re talking about estimating, there are multiple models that you could be using.
Top Down Estimates, Time-Constrained
One of the most common approaches to estimating is to build tops down estimates. This approach starts with the constraint – time. When a supervisor or a customer tells you that the effort has to be completed in 4 months, the top down approach gets everyone looking at what they can accomplish in the timeline. It asks a slightly different question than, “how long will this take?” and instead focuses on, “How would we carve up the time we have and what can we get done in that time?”
Bottoms Up Estimates, Task-Oriented
Another approach to estimating that is common is bottoms up estimating. This approach often starts with a work breakdown structure. Think of this as the entire list of tasks that need to be completed, with estimates for each task. The result is often an aggregation of all the task estimates. It often answers the question, “How long could this take?” but may not always take into account risk elements that change the entire estimate.
Metric-Based Estimates, Experience-Driven
I learned another approach when I first started working. It comes from doing similar projects over and over again. You create a shorthand for building estimates. If you were building a custom home, the builder might tell you that it will cost $150 per square foot. When I first started, my boss told me to create estimates based on the database schema we were creating ($500 per table), and it was very effective.
Three Point Estimates, Risk-Driven
Years ago I wrote a post about three-point estimating (which included a video). This approach has you create pessimistic, standard and optimistic estimates and weights them in a way that helps you get a number that takes into account the risks you might face. It's another helpful strategy for creating an estimate that is closer to reality than if you do single point estimates.
None of These Are Great When You're Doing Something New
While the strategies above can be helpful, the challenge comes when you're asked to quote something that you've never done before. That leaves us with a few questions that we need to handle.
How Do You Estimate Work That's Brand New?
A few months ago a friend of mine reached out to me. His agency was being asked to quote a project that he'd never done before. His move was exactly what I recommend to others – reach out to someone who is an expert and ask for help. You will find that there are lots of ways to engage an expert.
- Invite them to tell you what questions you should be asking.
- Bring them to the interview (in case they have follow up questions).
- Ask them to do the estimates for you and explain their rationale.
- See if they're willing to define the risks and how they impact things.
When you bring someone else into the situation, you skip the several attempts where you learn things the hard way (by making mistakes and learning from them).
Experts accelerate your learning while lowering the chance that you'll make a major mistake that will cost you.
How Do You Get Your Team Involved?
That horror story I told you about? It came from a good place. The exec team was looking to get more people learning about estimating. The challenge is that if you do it the wrong way, it can be costly. So don't go throwing your staff into the deep-end.
So how do you get your team involved?
I think there are two or three things you can do to help them get better and better at estimates.
Invite them to review tasks using 3-point estimating
Getting your team involved in thinking about the work that needs to be done is good. But not if it doesn't stretch them to think about things the right way. Optimists stay optimistic. Pessimists think everything will fail. Teaching them to use a 3-point estimating approach will help everyone contextualize risk.
Invite them to a meeting to discuss their estimates
It's not enough to invite people to give you their break down on effort for every single task in the WBS or 3-point template. You have to meet with them to understand why they put down what they did, and give them feedback when they're thinking is immature.
I'm not trying to be mean. I simply mean, for a lot of people, this is the first bit of feedback they've ever gotten about their own ability to think critically about effort. So you'll see a ton of immaturity in the spreadsheet. Your job is to create feedback loops that help them learn.
Invite them to meetings with executives to hear the presentation
Lastly, invite some of your team to join you when you present the pitch (whether it's to internal execs about new product development, or to customers for service projects). People will never magically get good about talking about efforts and costs. They need to see others do it. (This is one of the only cases with more exposure is better.)
Each of these approaches will take time. But your team is worth the investment. So plan for that time and make it a priority.
How Do You Communicate Risks with Clients?
Even if you pull in an expert, there's no guarantee that you've mitigated every risk involved with doing work that's never been done before. So what do you do then?
Here's my take. And I know it won't work for every situation, but I've used it on product-oriented projects and customer-facing service projects.
Clear Communication Up Front
First, I explain to a customer or our internal team that there are things in our project that we've not done before and that they bring their own risk.
Second, I suggest we burn a bit of money to dig in deeper and explore the risks we don't know about. This is a time-boxed effort which means it has a fixed financial budget. It can be a few hundred or few thousand dollars, depending on the overall project and the unknown risks.
Create a Flex Budget
The last thing I do is create a separate flex budget. I don't mean that I add margin to all the efforts so that I can handle the risk of the project. I know people do that, but it's not aligned with helping others understand the risks of the project. This is a line item in the project. It's clearly delineated as a Flex Budget.
The Flex Budget has multiple benefits.
By allocating some money in a budget that we can apply to issues when they come up, it eliminates the need to do a change order (on service projects) at the first tweak requested by a customer. It also encourages customers (on service projects) to choose between several items they want since the budget isn't unlimited.
Lastly, it creates a regular discussion about risks as the project moves forward. You'll discover that having a regular conversation about risk is helpful for the work you're doing.
A Common Pain Means We Should All Work on Getting Better
Given that we all deal with this challenge all the time, this is one of those skills that is worth improving. But that means getting more people involved, more often, learning how to do estimates well. I hope this helps, and you can always reach out if you want to talk more.
Sign up for free content. People still do that.
Thousands of folks (7000+) regularly get my posts in their inbox. For free.