Behaviorally Speaking: CM Top Down Bottom Up

I worked as a build engineer in a group where the maven build was ridiculously over complicated. A smart guy with a PhD (sadly not in computer science) had written it. Every step of the process was more complicated than it had to be, and there were often challenges. Every time something went wrong, the developers checked to see if a particular java archive (jar) file had been created. I modified my scripts to always check for the missing jar early in the build stream. Although this didn't completely fix the process, it mitigated the risk because I knew right away if the jar was missing and could just rerun the build to fix the problem. This is a great example of where I needed to focus on the details of the build process in order to bring about positive change.

Most process improvement enthusiasts will focus on the importance of working from the top down, including a strong focus on getting support from senior management. It is certainly true that buy-in from senior management is essential, but you also need to consider the risks, such as making decisions,  involved with trying to improve your process without all of the essential technical knowledge needed to tackle and complete the task. The most effective approach is to work from the top down and also from the bottom up.