It was a simple bug, or so we thought. The product should work with plug-in memory devices. It seems that we worked with some, but not all the available devices on the market. Engineering management said that to work with more devices it would be a NEW requirement and that needed formal and NOISY approval to point out how project management constantly undermined the project by adding new requirements!

Luckily, the engineering team, looking hard at the specifications they had already implemented, determined that the specs should have directly supported more devices. After some time and an investigation, while the “new” requirement for supporting these devices was disapproved, the problem was resolved by correcting the implementation of the specification. This allowed the product to work with all current devices on the market.

I really wanted to give the engineering team a financial reward, as it was a huge fix for a problem that was misunderstood and would have limited sales, but I decided not to. Why? Because it would alert the engineering management team to the fact their engineering team fixed the problem and it would appear to be rubbing it in their face. Of course, they finally figured it out, but by then everyone was focused on the next “big problem” and they didn’t want to complain about something that helped so much.

In another situation, I had a Requirements Director say, after I challenged a product change asked for by an account manager, that she would not let her approval process be used to burden down “obvious” changes that were needed. Wow, I thought — where did that come from? If the request was an “obvious” change to her, then no formal process was necessary it seemed, it was just approved. It finally struck me that she was well aware of and practiced exactly this. She used the process to block things she didn’t want and expedited (i.e., ignored the process) for the things she did want. Everyone took their cues from her, and the processes were “optional” depending upon what she wanted.

These kind of undisciplined processes, in my experience, are often found in organizations that are consistently having challenges (e.g., not delivering projects on time, low quality). They regularly implement new processes or process steps to fix what they intuitively thought were the problems (e.g., requirements creep, poor project management, bad estimates, etc.). Inevitably, these questionable new processes become this way — selectively applied — because the real problems had not been addressed and hence the new processes didn’t really add value. Management then just picks and chooses what it wants to do when it wants to do it. “It is just the way things work around here,” it is said. No one sees it for the undisciplined improvement practices and bad management habits it encourages.

How effective and disciplined are the management practices surrounding your project?