Are you still "negotiating" your project budgets?

Created on 2017-11-17 18:33

Published on 2017-11-17 19:22

If budgets are too low, then projects may over-spend, deliver late. or even fail completely. If budgets are too high, then they may waste valuable funds. At the very least, they hoard resources that could have been used for other projects. In the end, we often "negotiate", but who knows if this gives accurate budgets? The following is a true story...

Elaine was tired, and her third cup of coffee just wasn’t delivering the punch she need for this meeting. She had been up late last night and early this morning poring over the budget details for her new J-Body project. This was her first big project and she really wanted it to be a success story. For days, she painstakingly reviewed the scope and timing and used her experience to lay out a plan with the resources she needed. Her main concern was over-spending her budget. She had seen some of her colleagues go down in flames for exceeding their budget, so she was ‘conservative’ and put away just a little extra for future bumps in the road. She was also concerned about the tight timing and the requirement for 0 defects at launch. 

Across the table from her, Al, the Engineering VP, was nervously watching the clock and waiting for the last participants to show up. He was working on his fourth cup of coffee at 10am. (did I mention we had free coffee then?) Why can’t people get to his meetings on time? He had just come out of a pressure-cooker session with his boss and upper management. Sales were down this quarter and everyone was asked to cut their budgets for the year to “hit the numbers”.  If they could not deliver, then bonuses and jobs were at risk. Al had recently rolled out several initiatives aimed at cost-cutting, but there was little patience to wait and see if they worked. 

Finally, Debbie, the Engineering Controller made it through the door (late from another budget meeting) and quickly found a seat close to the screen so she could read the fine-print. I was the Chief Engineer for Initiatives and I sat across the table from Debbie and next to Elaine as she started to walk us through the details, building up slowly to the total. Al listened for 3 slides, drumming his fingers and then just asked for the total damages. Elaine quickly flipped through three more detailed slides to the final summary and responded, “8.7 million”. 

Al was not happy. He railed about how this was too much for the department budget. He shared his experience with a “similar” project that cost much less. He asked to see how the current improvement initiatives were helping to reduce the cost. He demanded she “sharpen her pencil” on all details. She battled back courageously, but after 30 minutes, the meeting was re-scheduled 2 days later, so she could complete her homework.

When the door shut behind Elaine, Al vented to Debbie and I for another 20 minutes about how everyone kept coming to him for bigger budgets and they just didn’t understand the current business climate and everyone was dragging their feet on implementing his initiatives. 

I caught up with Elaine in the cafeteria and she was really struggling with how to do the project for less. She wanted to try some of Al’s initiatives, but they were unproven, so she was reluctant to bet some of her budget assuming they would work as planned. 

Elaine came back 2 days later with an even more detailed plan, and a new total of $8.4 million. Al drilled into the details and picked out some issues and demanded even more details on quantities of prototypes and testing. The tug-of-war went back and forth over the next few days, and they finally settled on $8.1 million. Neither Al or Elaine were entirely happy with the result. Al felt there was still more opportunity to cut the budget. Elaine felt her project was now at risk with less resources and little room for potential issues. The worst part was she felt less ownership for the success of the project.

Elaine was not alone. The engineering budget was viewed as a department by fiscal year. Every year, leaders were asked for their cost estimates for the year and to bring a list of cost-reduction “opportunities” to reduce their budget reviews, but no one took the bait, so they were interrogated. Where is your list of opportunities? Why is this number so high? What was it last year? Where is your detailed plan for prototypes? Why are you spending so much on testing? Everyone and everything was fair game. You could cut the tension with a knife.

Finally, the department total was added up and compared to available FY funds. In the end, Debbie was usually tasked to dole out “haircuts” of 5-10% reductions across all projects, with the assumption they would still be completed on time and within budget. 

When you know your budgets will be cut unfairly, you don’t feel so bad about protecting yourself with some extra padding. Management quickly becomes wise to this and responds with even bigger cuts. After a few cycles, the budget “game” becomes so full of padding and cuts that no one knows what the real costs should be. Every budget review meeting starts with cries for more resources and management asking for more details and more cuts. In one glaring case, an engineering director slipped in an additional $750,000 exactly in production validation testing into the last year of all his larger projects. His original project budgets included less than $200,000. When challenged, he admitted that he was padding his budget to protect against expected cuts.   

In the meantime, our projects were falling behind schedule and producing low quality results. Test failures required resources to stay on projects that should have been finished instead of moving on to new projects. This created a slow-motion pile-up across our portfolio of projects. New projects started late without all required resources and quickly fell behind schedule and then had big issues before launch. Soon, we were mostly working on late, broken projects in crisis mode. Office lights burned late into the night. Coffee machines were running dry. Some meetings became tense stand-offs as everyone insisted they just did not have the resources needed to fix every problem. We became masters at prioritizing issues based on severity and urgency. Some project managers gave up on making timing plans and used an Open Issues List to run their projects. 

We endured this misery for years. The focus was on cost and we suffered in quality and timing.  Customers were unhappy, and our sales were flat. More cost cutting was always the answer, but it just wasn’t working. Management took out all our color printers to save money on ink, but we ran all reports in red-yellow-green, so this created chaos. The final straw was the end of company-paid coffee. Our blood pressure was no longer dangerously high, but people started falling asleep in meetings!

One day, Al announced a 3 day off-site with his engineering leaders. The goal was to develop a model for estimating project resources based on scope. No one could leave until we agreed to the model and to abide by it. It was an unpleasant 3 days, but we drank lots of coffee and produced a model that we all agreed upon. It became my job to ensure it was used fairly and faithfully across all new projects. 

The model was simple and based on the complexity and newness of the design elements. It was easy to load the data for a project and everyone could see the direct calculation of resources. In the early days, we relied on faith in the model, but after a while, some started to question the accuracy of the model. I had recently run our Six Sigma group, and this seemed like a chance to use some analytical tools.

We plotted the Work Unit values against Actual Hours for several recently completed projects. At first, the correlation was not good, but we dug deeper and found some time-recording errors and other special causes for outliers. Once these were addressed, the results were acceptable (see Chart 1).

Chart 1 – Hours vs Work Units

Here, the dots represent projects and are placed on the grid per their Work Unit values against Actual Hours. The dashed line represents a 'best fit' of the points. The R2 value of 0.8251 shows the line fits the data points well for this kind of process.

Chart 2 - Applying the Model

Chart 2 shows how to apply the model to a new project. First, calculate Work Units (e.g. 11 units), then go up from 11 Work Units to the dashed line, then go across to the y-axis (e.g. almost 300,000 hours).

The true power of the model was that we finally stopped fighting about project cost estimates. Teams followed the model (with some objective assistance) and received a fair amount of resources. Budgets that followed our process were approved in minutes by upper management. The budget cover page included checkboxes for initiatives that were planned for the project and a section to highlight the amount if someone tried to pad the budget over the model. 

If Sales were down in a quarter, and management wanted to save money in engineering, then they could cancel or delay new projects, but they could not cut budgets on projects that were in-progress. Project teams felt more ownership to complete their projects on time, within budget and with good quality.

The model tremendously reduced the noise in our portfolio as new projects started with the required resources. They delivered on time and delivered better results. Customers noticed the improvements and had more confidence in us, so we won more projects. Free coffee was back!

As well as things were going, management still wanted improvements, so we modeled the impacts of the initiatives and built them into the model. For example, if we did more computer-simulations of tests on CAD models, then we could eliminate prototype tools & testing and go straight to production tools. The risk was failing physical tests and scrapping expensive production tools. The insurance policy was the additional simulation work. There was also an opportunity to execute projects faster without the prototype iteration. We showed significant savings in our model and used it to plan future projects. In other words, we cut the fat out of the budget before we spent anything. The savings were locked in. Meeting your model-based budget meant saving money. It also required implementing the initiatives. 

Chart 3 below shows the effect over time. Each colored line is a Product group. This chart helped us finally show measurable improvement to management. It shows most groups made steady improvement. Do you have a chart like this?

Chart 3 – Improvement over Time

This is a true story that took years to unfold. The people involved were stumbling through and learning as they went. The good news is, you can go much faster with experienced assistance.

Please connect with me if you'd like more information at:

Go to the top of the page to Share, Comment, or Like if you found this interesting.

The series continues...

This is part of a series of articles about applying continuous improvement processes to measure and improve the performance of product development projects. Here is the complete list in recommended reading order.

  1. Are you still "negotiating" your project budgets? is a true story about a journey from budget hell to using EQUs to accurately estimate costs of engineering projects.
  2. Engineering Productivity Measures shows how engineering EQUs can be measured and applied to a wide variety of products, globally.
  3. Show me the Money! shares how to leverage engineering EQUs to benchmark performance and set targets to close gaps over time with significant savings.
  4. A fast, accurate way to create project budgets on a large scale, demonstrates a powerful web-based software tool to calculate EQUs and program budgets in just a few minutes.
  5. Applying Continuous Improvement to Product Development explores reasons why more organizations should take this path, but may need help to get started.
  6. Seeing productivity in 3D shows how EQUs can be used to unpack the value of experience, true cost-savings from off-shoring work, and how to better balance resources on a global basis.
  7. "True" Key Performance Indicators vs metrics shows how the right metrics can enable a long-term Continuous Improvement process.
  8. Does Six Sigma = Continuous Improvement? explores how Six Sigma contributes to Continuous Improvement, but does not guarantee it, and may actually harm it if done improperly.
  9. Connecting the Dots shows how to create reliable roadmaps with multiple impacts from multiple initiatives on a complex process used by multiple groups.

Copyright 2018 Richard Crayne