Managers frequently attempt to develop solutions and processes that can benefit groups outside of their domain. Wide-reaching organizational change is a great goal, but it can lead to a “scope panic” where nothing is accomplished.

Every decent software development manager has a “bucket list” of lower-priority process or tool improvement tasks. These are not typically major initiatives, but shorter items such as:

• Cleaning up/standardizing source control across development teams.
• improving or automating the build/deployment process.
• Creating a better way to handle and prioritize customer requests.

At some point, a project will finish early or the next one will be delayed, and the manager will have an opportunity to address one of the issues. The manager spends a few hours developing a high level plan. The manager sends the idea around for feedback, and prepares to implement the change.

The feedback immediately points out that that plan is not nearly complete or thought out. Why clean up the source code when the company is already looking at a new source control system? The build process idea is fine for 90% of the company, but doesn’t take the database group into consideration. The current client request process generates a fantastic looking spreadsheet every week. Nobody is quite sure what this spreadsheet is used for, but they ARE sure that the new method wouldn’t produce one…

Even if the manager wants to incorporate this feedback, it is almost certain that he or she does not have the resources to handle the increased scope. The change effort will be lost when the new project arrives, the next iteration begins, or the free time simply vanishes.

How can you avoid this trap?

Ensure your plan is focused and direct. 
“This method should cut down on the overhead we have managing bugs during crush time. It isn’t meant to solve every problem he have with defects.”

Keep meetings sharply in scope, and immediately cut off discussion that starts to expand the change. 
“That new build management system seems interesting, and I’d like to hear more about it, but this meeting is to discuss what we can fix before the end of the month.”

Involve as small of an audience as possible. Keep people informed without making them participate.
“QA doesn’t need to be involved in the planning. The QA manager is fine with development adding new fields to the form.”

Once you find yourself able to make the smaller improvements that allow your team to run more smoothly, you will be surprised at how quickly these small improvements add up to noticeable productivity and morale improvements.