Home » Change Management » Project Managers, How To Stop Making The Same Old Mistakes

“Yet study after study, analyst after analyst, say that developers are making the same mistakes they made in 2000. That they made in 1990. And earlier.” Stop making the same old mistakes, SD Times, Oct 2011.

This quote brought to mind a Google TechTalk on Scrum I watched some years ago. One of the founders of Scrum was answering questions about this software development management method. What was most fascinating was his examples of some of the things that typically go wrong in an implementation. It included not following close enough the Scrum process and not believing and using the numbers that represented the team’s performance (e.g., velocity metric). Gee, I recall thinking, that could describe just about any team struggling to implement any new method or technique.

Project Managers How To Stop Making The Same Old MistakesThe editors of SD Times in their article go on to describe different approaches to help people stop making the same old mistakes. This included the automation of tasks and other tools, “teach, inspire, wheedle and cajole programmers” to not introduce errors in the first place, and reward programmers for coding things right the first time. Again, I don’t see much new here. These are management techniques we’ve known and used for years. Have we not been using these? The editors of SD Times don’t address if any of these suggested techniques are actually known to work well or not (i.e., no “study after study” reference in the article).

What might really be going wrong? Was it those programmers consistently doing subpar jobs or was it management motivating those programmers with subpar techniques:

  • “Get it done by tomorrow!”
  • “Here is more to do, but no you don’t get any more time to do it!”
  • “We need to improve testing to catch all those errors!”
  • “Today we’ll do Scrum, tomorrow Lean, next week Kanban, then we’ll try out TSP and if that doesn’t straighten out the programmers, we’ll reintroduce Waterfall!”

So, is it the computer programmers (or any individual contributor) or is it management or is it both?

As much as saying “it is both” would be safe, my experience puts the problem directly in management’s lap. I always loved the notion by Dr. Edward Deming that “management owns the process” and the Software Engineering Institute’s often stated corollary that the “quality of the process determines the quality of the product.” So does that mean the solution is for management to take charge and fix things? Not necessarily. In many cases, the solution may be for management to back off micromanagement and instead empower the folks doing the work to improve based upon their own insights and knowledge. Management stays involved but is focused on helping these teams to be self-managing AND by providing overall strategic direction.

My career in helping organizations to improve has been successful in large part because the folks doing the work generally knew how to do a good job. When we removed the impediments to doing a good job, which were generally bad management habits, the existing teams dramatically improved in quality and productivity. It was also the case that once we reduced the bad management habits existing improvement efforts started to have an impact.

Does that mean we don’t need to help the individual contributors do a better job? No, of course not. But very often in my experience the “low hanging fruit” for rapid improvement is centered first on management practices and then on methodologies and individual practices.

Our improvement projects can make a huge difference in the performance of our organization if they help folks to stop making the same old mistakes. Just include in our thinking that removing management bad habits can have as much — if not more — an impact on performance than just trying to fix all those mistakes seemingly made by our individual contributors.

What same old mistakes can you see that your team or organization is making?

Thank you for sharing!

1 thoughts on “Project Managers, How To Stop Making The Same Old Mistakes

  1. Bruce Benson says:

    Comments from around the web:

    Tomas Schweigert • Concentrate on identifying opportunities to make new and interesting mistakes

    Andrea Herrmann • Bruce, this question you should rather ask in anonymous surveys, not in a public place.
    In the public, you rather could ask for Best Practices. 🙂

    Bruce Benson • Andrea,

    I find that openly saying “the Emperor has no clothes” is an effective change management technique. I’ll regularly get a lot of push back “don’t say or mention that!” and it can make people uncomfortable to start, but as we hear the forbidden words (notions, concepts,, facts) said — with time their sting is not as painful. It them becomes something we can talk about, and until we can talk about a situation it is very hard to change/improve the situation.

    When I was doing SEI CMM improvements, we did away with the “sign a nondisclosure/nonattribution statement” that were used to “protect” people so they could say things without fear of a backlash. What we found instead was that a comprehensive and balanced review of what needs to be done easily paints everyone (individual contributor, manager, senior manager, CEO/CIO) with things they need to do differently. When everyone had something to change/update, there was a lot less “find a culprit” mentality. Plus, it helped to motivate a climate of open discussion that helped the organization to continue improving.

    Not saying it is easy to do, but it is worth the effort and pain 😉 of doing it.

    Thanks for the feedback.

    Bruce Benson • Tomas,

    “Concentrate on identifying opportunities to make new and interesting mistakes” – I love it!

    But we do usually have to concentrate on fixing old mistakes. I’ve told people that once we got things going well with whatever we are already doing, then we’ll have the time and resources to make new mistakes while doing new and interesting things.

    Great thought.

Comments are closed.