The Fly on the Window and “Best Practices”

A colleague, Gary Lundquist of Market Engineering, has a great analogy for understanding barriers to improvement.

Imagine a fly on a sunny window.  The fly knows where it wants to go, but spends a lot of energy banging its head on the glass without ever getting there.  The problem is that the fly doesn’t understand the barrier it’s facing.  Flying feverishly toward the light works for other flies in other situations, but not for this fly.

Some product development organizations (not yours, I’m sure) act like the fly on the window.  Managers seeking improvements feverishly try solutions that worked for other managers at other companies, without making much real progress.  They call these solutions “best practices.”  

Best practices may work for someone else, but are they best for you?  The first step to improving product development is an honest diagnosis of the barriers that you are facing currently.  This is where a good consultant can be critical to getting you off the window.  A consultant can perform an impartial diagnosis of your barriers, and then work with you to explore solutions and design an improvement program that’s tailored to your specific situation and company culture.

Here’s an example:  At a semiconductor company, a newly hired executive from a strong command and control culture wanted to improve schedule performance.  Based on past experience, he raised himself to his full height and pronounced that henceforth engineers would meet their schedules or face serious consequences. 

Schedule performance did improve, but other problems cropped up.  Expensive post-release design changes increased when developers cut corners to meet deadlines.  Time to launch increased as developers padded schedules.  Throughout this activity, real new product results declined as the fly bounced around on the window.

The manager’s initial “solution” was based on what worked at another company–Increasing schedule pressure only works in the unlikely case that engineers don’t understand the importance of schedules.  A diagnosis of performance barriers might have shown that resources were being spread too thinly across too many projects.  Or the company’s development processes may have been too cumbersome to keep up with increasingly dynamic markets.

Addressing the real barriers would have provided real improvement sooner than applying “best practices” from another company.

My point here is that to avoid acting like a fly on a window, don’t start an improvement initiative without first understanding your performance barriers.  They won’t likely be the same as another company’s, and what worked at that company probably won’t be best for you.

Comments are closed.