How does your management team track the progress of engineering projects?

I’ve been asking that question a lot lately. And the more answers I get the more I become intrigued. You see I’ve been looking at how engineering projects are assessed alongside how executives are making the decisions to continue to fund them or not. And over the past few months, I’ve increasingly seen something of a disconnect between the two. Let me explain.

Today’s Deliverable Based Metrics

From what I have seen in the industry, the measure that is used to assess the health or progression of engineering projects are based on deliverables. Such deliverables are things like engineering drawings (or 3D models), specifications and the like.

It’s not too surprising to see how we got here. In the grand scheme of stage-gate, waterfall or just about any other development model, the major milestone for the engineering organization is design release. Of course that’s where the engineering organization hands off the engineering drawings, models, specifications and everything else that collectively defines the product to those that will deliver actual hardware and software to make the product. Namely procurement organizations, their suppliers and other internal manufacturing organizations.

In today’s age of measurable results, managers and executives need some manner to track how an engineering project is progressing. If it’s ahead of schedule and budget, then resources can be reallocated to other engineering projects. On the other hand, it is behind schedule, those managers and executives can take corrective action be reassigning resources and budget from other engineering projects to the one that is lagging. This corrective action approach is a way to mitigate the risk of missing the product launch, which could impact revenues, as well as control costs, which affects profitability.

Decision are Most Important Value-Add

So what’s the big deal? How is that ‘jacked-up’? Well, here’s an immutable fact that’s been pounded into my head over the past year.

Deliverables are what engineers hand off at design release. But it’s not how they design a product.

Now the implications of those two sentences are actually quite important. Engineers design great products by making the right decisions, not by finishing the engineering drawing on or ahead of schedule. In fact, of all the activities in the design phase, creating deliverables is almost a non-value add one. It doesn’t help you make design decisions. It actually doesn’t even communicate design intent. It merely defines what should be procured or manufactured. Compared to creating those deliverables, making the right decisions in a timely manner is on the opposite end of the spectrum. It is the highest value-add activity in practically the entire design phase.

Now, before you paint me crazy, let me say that I’m not alone in this thinking. At the Siemens PLM event back in May, Chuck Grindstaff stood on the main stage and talked about a conversation he at General Motors. He said the GM executives no longer think about how many 3D models they need to create to get a new automotive program into production. They now think about it in terms of how many engineering decisions they need to make. And by their own count, the number of decision is a little above 20,000 on average.

The Implications

So what exactly does that mean? What’s the implication? Let’s talk about a theoretical example. Let’s talk about two engineering projects.

In the first, the engineers are focused on progressing their deliverables. In the days leading up to their project management meetings, they rush to get farther ahead on their drawings and specifications. However this emphasis means they can’t explore as many alternatives and iterations. Just to put numbers to it, let’s say this team has completed 90% of the project’s deliverables and explored 20 design alternatives at varying levels of the product.

In the second, the engineers are focused on exploring design alternatives, gaining engineering knowledge related to the project and fully vetting their decisions. They work on their deliverables but don’t rush forward with urgency to show progress during project management meetings. In comparison with the first project, this team has completed 50% of their deliverables but explored 100 design alternatives.

Now think about those two projects from an executive’s perspective. Considering deliverable-based metrics, the first project would be deemed healthy and on-track. The second one, even though it more mature in terms of engineering decisions and is most likely a better design, would be deemed lagging. The result could be more resourcing or, alternatively, the project might get killed as part of portfolio management oversight.

Overall, my point is this. Deliverable-based metrics in engineering projects are misleading to the detriment of the engineering organization and the company.

Conclusions and Questions

Most of today’s engineering metrics are deliverable-based, leading to inaccurate assessments of the progression of development projects. This inaccurate view can lead to inappropriate resourcing or actually killing the development project.

So here’s where you get to participate. What have you seen at your company? Do they have a good handle on the progress of engineering projects? Do you agree or disagree with my assessments? By all means, I don’t mind being told that I am wrong. This is your chance to sound off.

Take care. Talk soon. And thanks for reading.