Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>

Stop normalizing failure: How to estimate projects (and how not to)

Estimates are the foundation of every project. You can’t build a relationship on a shaky, incomplete foundation and you can’t build a solid project plan on a crappy, half-baked Estimate. I’ve lived through enough estimating and sales handoff madness enough times to know that we keep getting the estimating process wrong—yet, so many shops do it this way, doing it wrong has become the status quo.

Too often, firms care more about clients than about their own staff. Too often, project managers are last on the list of priorities when scoping or estimating new projects. Too often project teams suffer (stress, frustration, resentment, unpaid overtime) for the sake of getting a poorly-estimated project out the door. A study published in the Harvard Business Review analyzed 1,471 IT projects and found that the average overrun was 27% while one in six projects had an average cost overrun of 200% and a schedule overrun of almost 70%.

That’s not me complaining about my personal experience. That’s Harvard talking about the status quo in our industry.

Bad estimates put your project teams in a position where it is impossible for them to succeed. So I’m here to propose an alternative: a more honest, empathetic, and sustainable approach to estimating. I know, change can be scary. But you know what’s even scarier? Allowing fear or ignorance to guide your choices—to stop you from moving forward and running a more profitable, sustainable company.

Estimates are the foundation of every project. You can’t build a relationship on a shaky, incomplete foundation and you can’t build a solid project plan on a crappy, half-baked estimate. I’ve lived through enough estimating and sales handoff madness enough times to know that we keep getting the estimating process wrong—yet, so many shops do it this way, doing it wrong has become the status quo.

Too often, firms care more about clients than about their own staff. Too often, project managers are last on the list of priorities when scoping or estimating new projects. Too often project teams suffer (stress, frustration, resentment, unpaid overtime) for the sake of getting a poorly-estimated project out the door. A study published in the Harvard Business Review analyzed 1,471 IT projects and found that the average overrun was 27% while one in six projects had an average cost overrun of 200% and a schedule overrun of almost 70%.

That’s not me complaining about my personal experience. That’s Harvard talking about the status quo in our industry.

Bad estimates put your project teams in a position where it is impossible for them to succeed. So I’m here to propose an alternative: a more honest, empathetic, and sustainable approach to estimating. I know, change can be scary. But you know what’s even scarier? Allowing fear or ignorance to guide your choices—to stop you from moving forward and running a more profitable, sustainable company.

Bad estimates: normalizing failure

There are many reasons why things need to change. Obviously, an inaccurate estimate loses you money. After all, the whole point of an estimate is to ensure that the work scoped is covered by the price being quoted and will mean profit for the company. But the repercussions of an incorrect estimate—of giving project managers an unworkable budget from day one—reach much further than the bottom line and are far more insidious than a list of red line items:

  • Developers, QA, designers, and everyone else assigned to the project receives inadequate hours to complete the work.
  • Project managers struggle to keep morale up as everyone realizes that the project is set up for failure.
  • Everyone from the PM to the QA engineer runs the risk of being chastised for not completing their work on time.
  • Clients (internal or external) get frustrated about substandard work or at change requests for agreed-upon functionality.
  • Management gets frustrated at a project constantly in the red.
  • Resource allocation gets thrown off because people are booked elsewhere and are not available to do the work (this is a big and upsettingly common problem).

Ultimately, the project fails whether or not you get it out the door. It fails because the client is unhappy, or because it’s over budget, or because the quality suffered, or because the team is completely frustrated and will carry that frustration over to the next project, and the one after that. Forcing PMs to manage according to a terrible estimate not only creates disastrous and terrible habits, it normalizes them.

If the status quo doesn’t change, your staff will keep fudging timesheets and budget reports to cover up overages; they will learn to cut their own hours to create space for other resources; they will adopt defensive attitudes when reporting on progress; they will look for someone to blame and express animosity toward the sales team or management (and their discontent will spread to others); they will burn out, or lose sleep over the stress of a doomed project; they’ll give up on future projects before they start. Heck, if they’re anything like me, they may even toy with the idea of leaving project management altogether and getting a retail job because it would be less stressful (yes—really).

The worst habit that gets normalized is the compulsion to create a “success” out of utter failure in order to save face. Your staff will learn to sell a complete mess as a home run and management will learn nothing from the whole ordeal and assume, yet again, that their estimate was correct. And then they’ll apply the same approach to the next project, starting the cycle again. This has created a culture where failures masquerade as successes because no one wants to deal with the big ugly truth.

Except, I do.

Bad estimates: normalizing failure

There are many reasons why things need to change. Obviously, an inaccurate estimate loses you money. After all, the whole point of an estimate is to ensure that the work scoped is covered by the price being quoted and will mean profit for the company. But the repercussions of an incorrect estimate—of giving project managers an unworkable budget from day one—reach much further than the bottom line and are far more insidious than a list of red line items:

  • Developers, QA, designers, and everyone else assigned to the project receives inadequate hours to complete the work.
  • Project managers struggle to keep morale up as everyone realizes that the project is set up for failure.
  • Everyone from the PM to the QA engineer runs the risk of being chastised for not completing their work on time.
  • Clients (internal or external) get frustrated about substandard work or at change requests for agreed-upon functionality.
  • Management gets frustrated at a project constantly in the red.
  • Resource allocation gets thrown off because people are booked elsewhere and are not available to do the work (this is a big and upsettingly common problem).

Ultimately, the project fails whether or not you get it out the door. It fails because the client is unhappy, or because it’s over budget, or because the quality suffered, or because the team is completely frustrated and will carry that frustration over to the next project, and the one after that. Forcing PMs to manage according to a terrible estimate not only creates disastrous and terrible habits, it normalizes them.

Dear Owner,

This is my resignation letter. I’m leaving because of your unrealistic expectations—This company is supposed to be my project team’s advocate. This estimate was never validated with the client and the team after the scope was adjusted and now we are going to exceed budget. You know we’re going to exceed the budget. And I am the one that’s going to take the fall for it. My job is to manage, alert, and mitigate when I see risks like this. But now I also have the job of shouldering the guilt of this impending failure and I refuse to do that.

PM from Phoenix, AZ

If the status quo doesn’t change, your staff will keep fudging timesheets and budget reports to cover up overages; they will learn to cut their own hours to create space for other resources; they will adopt defensive attitudes when reporting on progress; they will look for someone to blame and express animosity toward the sales team or management (and their discontent will spread to others); they will burn out, or lose sleep over the stress of a doomed project; they’ll give up on future projects before they start. Heck, if they’re anything like me, they may even toy with the idea of leaving project management altogether and getting a retail job because it would be less stressful (yes—really).

The worst habit that gets normalized is the compulsion to create a “success” out of utter failure in order to save face. Your staff will learn to sell a complete mess as a home run and management will learn nothing from the whole ordeal and assume, yet again, that their estimate was correct. And then they’ll apply the same approach to the next project, starting the cycle again. This has created a culture where failures masquerade as successes because no one wants to deal with the big ugly truth.

Except, I do.

The new status quo

There are better ways to estimate projects but they require hard work, clear communication, and company overhead. If the way you estimate and manage products doesn’t change, something else will: your staff will quit or lower their standards, your clients will leave, your revenue will drop—project failures manifest in many different ways.

Let’s break the cycle of bad estimates. Here are some changes you can make that will improve the way your agency estimates. They may be daunting at first, but they will show you care as much about your project teams as you do about your clients. And that will pay dividends in the long term.

Put your PM in charge

Why? Because project managers know projects—they know red flags, and they remember nuances others won’t. They deserve to be part of the project at the estimating stage if they are the ones that are going to be held accountable for its launch. If you don’t include a PM in the estimating, you can’t, in good conscience, hold them solely responsible for overages, delays, or failure. Plus, involving your PM at the earliest stages will make sure all of the other boxes in this list get checked.

The people doing the work should estimate it

Maybe you don’t want to ask people to estimate projects that haven’t yet been sold—your cost of sale might go up. Maybe you think you know how to do everything because, at one time, you did know how to do everything. But times have changed. You can’t estimate work you don’t intimately know how to do. It’s just guessing at that point. You hired good people for a reason, and you need to both let them do their jobs and to understand that they might do that job differently than you would have.

If I’m hiring contractors to fix the roof on my house, I don’t estimate their budget for them. If I’m hiring a designer to create a new visual identity for my company, I don’t tell them how long it will take and how much to charge me. I may have ideas about how much I want to pay, but taking that control away from the people doing the work sets everyone up for failure.

We need to make sure that the work to be done is considered and estimated by someone who understands the work and who knows the capabilities and competencies of the team that will be doing the work.

Maybe this person is a department head, or a development lead, or a very savvy PM (who checks with her project team that she’s on track). You can choose who it is, but let me tell you who it isn’t. It’s not someone who hasn’t coded in years. It’s not someone from sales. It’s not a senior developer who estimates based on what they can do themselves. It’s not someone from a C-suite office whose last hands-on project was 10 years ago. If you’re reading this and you’re not doing project work, it’s not you, either.

Plan out the entire project and account for every piece

Too many estimates fail to take Quality Assurance and User Acceptance Testing into consideration—these things require time, too. QA and UAT mean bug fixes and you have to build in time to triage, fix, retest, and manage them.

What about unexpected issues or extra requests? Does the client require people to be on site for presentations? Your PM should make sure that those hours (including travel time) make it into the estimates. Do you need to take out the clients for lunch? Make sure that’s a part of the estimate. Let your PM think of everything. If you don’t include it all in the final estimate, at least your PM can help you be better prepared to manage and mitigate the unexpected.

Realize that there will be snags and account for them in the estimate

Someone’s going to get sick and throw the hours off. Someone else is going to uncover a missed task that can’t be charged to the client. Someone else is going to miscommunicate and take things off course.

These things happen because we’re humans and we have to accept and plan for them. Make sure your PM thinks about the specific risks for each unique project. They should factor in stakeholder changes, unplanned resourcing issues, and communication breakdowns. For example, does your lead developer need to be on calls? Does this pose a risk for you? If so, make sure your PM includes necessary time.

You also need to build in wiggle room for requirements that haven’t been scoped to cover you for the unexpected things your team hasn’t considered.

Include senior resources into your estimate

There’s going to be tasks that your team can’t tackle and they’re going to need input from senior staff with more expertise. Sometimes a PM or a developer just needs a quick check-in with a higher-up to make sure their reasoning is sound. Unless you strictly look at this kind of mentoring/consulting as overhead (and know that these people are never going to book time against your project), add some consultation hours into your estimate for every single discipline. Trust me on this.

Make sure your SOW is airtight

Understand that your Statement of Work needs to be written extremely well complete with details, contingencies, and assumptions. It needs to reflect what’s in the estimate. Otherwise, you’re going to have to make hard decisions about what items you’ll later bring to the client with change orders or reduced scope. A crappy SOW can undermine even a fantastic estimate and puts a strain on the client relationship, the project team, and especially your project manager.

The new status quo

There are better ways to estimate projects but they require hard work, clear communication, and company overhead. If the way you estimate and manage products doesn’t change, something else will: your staff will quit or lower their standards, your clients will leave, your revenue will drop—project failures manifest in many different ways.

Dear Owner,

I can’t be a part of your dishonesty anymore. It’s toxic for the client, and it’s toxic for me and the people I’m working with. I care too much about everyone involved (including me) to be a part of this anymore.

PM from Portland, OR

Let’s break the cycle of bad estimates. Here are some changes you can make that will improve the way your agency estimates. They may be daunting at first, but they will show you care as much about your project teams as you do about your clients. And that will pay dividends in the long term.

Put your PM in charge

Why? Because project managers know projects—they know red flags, and they remember nuances others won’t. They deserve to be part of the project at the estimating stage if they are the ones that are going to be held accountable for its launch. If you don’t include a PM in the estimating, you can’t, in good conscience, hold them solely responsible for overages, delays, or failure. Plus, involving your PM at the earliest stages will make sure all of the other boxes in this list get checked.

The people doing the work should estimate it

Maybe you don’t want to ask people to estimate projects that haven’t yet been sold—your cost of sale might go up. Maybe you think you know how to do everything because, at one time, you did know how to do everything. But times have changed. You can’t estimate work you don’t intimately know how to do. It’s just guessing at that point. You hired good people for a reason, and you need to both let them do their jobs and to understand that they might do that job differently than you would have.

If I’m hiring contractors to fix the roof on my house, I don’t estimate their budget for them. If I’m hiring a designer to create a new visual identity for my company, I don’t tell them how long it will take and how much to charge me. I may have ideas about how much I want to pay, but taking that control away from the people doing the work sets everyone up for failure.

We need to make sure that the work to be done is considered and estimated by someone who understands the work and who knows the capabilities and competencies of the team that will be doing the work.

Maybe this person is a department head, or a development lead, or a very savvy PM (who checks with her project team that she’s on track). You can choose who it is, but let me tell you who it isn’t. It’s not someone who hasn’t coded in years. It’s not someone from sales. It’s not a senior developer who estimates based on what they can do themselves. It’s not someone from a C-suite office whose last hands-on project was 10 years ago. If you’re reading this and you’re not doing project work, it’s not you, either.

Don’t rely on market value alone to dictate your estimate values. You have a team, and you know their capabilities (or at least you should). It’s always going to be more accurate if you use in-house knowledge and information rather than the numbers Company B happens to be charging.

Plan out the entire project and account for every piece

Too many estimates fail to take Quality Assurance and User Acceptance Testing into consideration—these things require time, too. QA and UAT mean bug fixes and you have to build in time to triage, fix, retest, and manage them.

Dear Owner,

I am putting in my resignation today because the project you’ve given me is set up to fail. I can’t deliver this project in the estimate that’s been provided—in fact, no developer, project manager, or designer could deliver this project in that time. Not only does my team deserve more respect, but our client deserves it too. This project is not possible within these constraints.

PM from Austin, TX

What about unexpected issues or extra requests? Does the client require people to be on site for presentations? Your PM should make sure that those hours (including travel time) make it into the estimates. Do you need to take out the clients for lunch? Make sure that’s a part of the estimate. Let your PM think of everything. If you don’t include it all in the final estimate, at least your PM can help you be better prepared to manage and mitigate the unexpected.

A checklist for things you typically forget to include in your estimates can be invaluable. You can create and refine a template so you can continue to improve project by project. For example, pharma projects are going to have unique things that have to be accounted for (e.g., medical testing, legal or regulatory issues, FDA reviews). A quality project retrospective—or post-mortem—means updated checklists reinforce a healthy habit of continuous improvement.

Realize that there will be snags and account for them in the estimate

Someone’s going to get sick and throw the hours off. Someone else is going to uncover a missed task that can’t be charged to the client. Someone else is going to miscommunicate and take things off course.

These things happen because we’re humans and we have to accept and plan for them. Make sure your PM thinks about the specific risks for each unique project. They should factor in stakeholder changes, unplanned resourcing issues, and communication breakdowns. For example, does your lead developer need to be on calls? Does this pose a risk for you? If so, make sure your PM includes necessary time.

You also need to build in wiggle room for requirements that haven’t been scoped to cover you for the unexpected things your team hasn’t considered.

Consider adding what I like to call the Asshole Upcharge. Tack on a surcharge if a client is notorious for eating up PM hours because they want status updates twice a week, or want to have a presentation for each milestone, or want a full team on site multiple times, or constantly questions your reports, or requires each stakeholder to have their own status updates. I charge a percentage of wasted time; I might jack up my PM hours by 10% if I know I am dealing with a difficult client.

Include senior resources into your estimate

There’s going to be tasks that your team can’t tackle and they’re going to need input from senior staff with more expertise. Sometimes a PM or a developer just needs a quick check-in with a higher-up to make sure their reasoning is sound. Unless you strictly look at this kind of mentoring/consulting as overhead (and know that these people are never going to book time against your project), add some consultation hours into your estimate for every single discipline. Trust me on this.

Make sure your SOW is airtight

Understand that your Statement of Work needs to be written extremely well complete with details, contingencies, and assumptions. It needs to reflect what’s in the estimate. Otherwise, you’re going to have to make hard decisions about what items you’ll later bring to the client with change orders or reduced scope. A crappy SOW can undermine even a fantastic estimate and puts a strain on the client relationship, the project team, and especially your project manager.

Better estimating

I know you’ve never done estimating like this before. When you put all of these things together, your estimate is going to look huge. It’s going to be larger than anything you’ve done before. You’ll be appalled and you’ll have an important decision to make.

You can bill the client based on an estimate with a defined scope (which you should do). Or you can say: “Hey, this is totally above market value, so we’re going to charge $xxx instead and let the chips fall where they may.”

If you choose the latter, it is imperative that you let your PM track the project to the original budget—not to the new, reduced budget. In other words, charge whatever you want. You’re the boss. But know and understand that the hours take as longs as the hours take. There is no excuse for knowing the full level of effort required and then willfully disregarding it.

The bottom line is that the estimate drives everything. Your project teams won’t be effective if your terrible estimates won’t let them. How can you expect them to succeed if you don’t give them enough tools and resources to do so?

I have cried over budget breakdowns on projects that were estimated poorly. I’ve seen the spirits of entire teams—brilliant, passionate, hard-working teams—broken by projects that were set up to fail. Sure, we got it out the door but at a cost far greater than the estimated project revenue.

The future of estimating can be different. It can beam client satisfaction, team satisfaction, happiness, health, and the well-being of everyone involved. It can look like sustainable profit. Take the time to do estimating right. Make these things a habit, a way of life. Make them the new status quo. Tell your project teams you’re committed to doing better and then actually do it. They are going to love you for it—and keeping them happy is worth far more than you can imagine.

Better estimating

I know you’ve never done estimating like this before. When you put all of these things together, your estimate is going to look huge. It’s going to be larger than anything you’ve done before. You’ll be appalled and you’ll have an important decision to make.

You can bill the client based on an estimate with a defined scope (which you should do). Or you can say: “Hey, this is totally above market value, so we’re going to charge $xxx instead and let the chips fall where they may.”

If you choose the latter, it is imperative that you let your PM track the project to the original budget—not to the new, reduced budget. In other words, charge whatever you want. You’re the boss. But know and understand that the hours take as longs as the hours take. There is no excuse for knowing the full level of effort required and then willfully disregarding it.

Dear Owner,

I’m leaving. You forgot to include me in the scoping and estimating process for a project with multiple partners and now I’m responsible to deliver things that are 100% out of my control. My entire team’s morale—including mine—has tanked and my client is terrified. I’m working 70 hours a week just to understand someone else’s convoluted project plan that has no possible way of succeeding. Mind your own scope.

PM from Grand Rapids, MI

A word on time tracking. In order to make sure your new, honest estimate (the estimate you created so carefully and with the right people) is successful, you must make sure that people accurately book their time. People hate tracking time. I hate tracking time. If you’re estimating fairly and honestly, encourage other good habits like tracking time fairly and honestly.

The bottom line is that the estimate drives everything. Your project teams won’t be effective if your terrible estimates won’t let them. How can you expect them to succeed if you don’t give them enough tools and resources to do so?

I have cried over budget breakdowns on projects that were estimated poorly. I’ve seen the spirits of entire teams—brilliant, passionate, hard-working teams—broken by projects that were set up to fail. Sure, we got it out the door but at a cost far greater than the estimated project revenue.

The future of estimating can be different. It can beam client satisfaction, team satisfaction, happiness, health, and the well-being of everyone involved. It can look like sustainable profit. Take the time to do estimating right. Make these things a habit, a way of life. Make them the new status quo. Tell your project teams you’re committed to doing better and then actually do it. They are going to love you for it—and keeping them happy is worth far more than you can imagine.



This post first appeared on Louder Than Ten, please read the originial post: here

Share the post

Stop normalizing failure: How to estimate projects (and how not to)

×

Subscribe to Louder Than Ten

Get updates delivered right to your inbox!

Thank you for your subscription

×