I have followed “best in the class” engineers who simply cannot conduct much easier tasks (such as eg. calculations) than faced to during education. Perhaps because there are no “right answer at the end of the book”. On the other hand I´ve seen lots of cases where the average guy outperforms the “best in class”. To my belief it is a living proof of being able to “do the right things” in stead of doing “things right”.

When implementing and working with new processes on the factory floor I´ve used my own set of measurements, the “4C”; Commitment, constructive critisism and constancy. When these 4 (or actually 3) are in balance I know it is successful. You can have commitment, but without the two other C:s you are not going forward and then the implementation has not succeeded. When any implemented project starts getting constructive critisism it is a good sign. That means that the guys have started to think about improvements and that is a good sign of commitment.

These kind of metrics are, of course, hard to put into a bar or pie chart in a Power point presentation. The best way is to show it in “live action” at the Gemba. It has worked a couple of times for me, but trying to reach 100% compability between management and shopfloor is not easy.

Also the “project goal” should be clearly defined. A project without a goal is like going out driving with our car without a destination. You just drive until the tank run dry.

Thanks for the addition. I think that speaks to the problem of reliability versus validity. Fundamentally, those cost dollars are valid. However, it’s not very reliable because so many things can affect it. Many people will then focus back on a reliable success outcome, such as “the software will do what we said it will do” which is highly reliable but isn’t the real goal. Understanding the variables, as you mention, helps us define where on the reliable / valid line we need to be.

So true that testing in the classroom does not guarantee the learned material will be used and implemented – the validation. Very difficult to measure, therefore something organizations don’t bother with (some don’t even bother with classroom training anymore). Even on those projects that are relatively easy to check results on, many firms don’t look back and ask, “How did we do?” If they did, there is a good chance they would not implement the ‘next great project’ until they understood why the ‘last great project’ was unsuccessful.

The challenge comes in defining success up front. Even those projects that appear fairly straightforward – This project will reduce costs by so many dollars, can become convoluted by changing economics and market conditions. For example, I submit a project to reduce costs in an area over the next year, but 6 months in, a new market opportunity develops in that area, and to meet it, I add resources and costs. The project may have allowed me to minimize the additional resources, but on an absolute level, my costs went up. If I defined success as a reduction in costs in that area, the project was, by definition, a failure.

That doesn’t mean we shouldn’t attempt to define success up front, but we do need to keep in mind the number of variables that can affect our definition.

Great Thoughts!

Glenn