I write a lot about taking what we are already doing as project managers and being successful with it.  Gee, we think, if all we have to do is use what we already know and do what we already do then there is no reason to improve, we are already perfect! If it were only that easy.

When I was managing software engineers I’d often get a programmer coming to me with a proposal. The programmer would have a task to fix a defect or add a feature to a program. After looking over the code, they would propose that instead of just fixing the bug or adding the feature, they would also re-write the code. It would be better they say, to re-do all the code then trying to make the current code work as needed.

In every case, my answer was the same. OK, no problem. First, go fix the bug or add the feature. Then, come back to me with a proposal to re-write that portion of the code.

What do you think happened? Once they fixed the bug or completed the upgrade they almost always lost interest in re-writing the code. Their interest in doing the re-write was because it seemed easier than figuring out what was already going on — until they finally figured it out. Then, the existing code was no problem.

The same, I will argue, exists with how we go about our jobs each day. Too often, I hear a call for “let’s do it differently” as a method of fixing the problems in what we are doing. Now, I like to change things — to improve things. I hate inefficiency. Yet, I’ve learned that too often the desire to change is rooted in the lack of desire to do or understand the hard things found in the job. Now, again, if the proposed change actually resulted in a new process where those hard things were no longer hard, then that would be a perfectly good motivation. Too often however, once we’ve undertaken a new approach — and after the initial enthusiasm, we start to discover the hard things in the “new” approach. Often, what was hard in the old approach is still hard in the new one.

I learned this the … hard way. You see, I was once that programmer who decided to re-write the code rather than fixing it. Off I went, coding madly away. In the process of designing and coding, I started to discover things. One thing I discovered was that I finally figured out why the old code did it the way it was done. The original programmer had to solve some hard problems and had to balance between an elegant solution and an efficient solution. After a little thought, I came to realize that it was not a bad compromise. Gee, I just spent hours of time relearning what was sitting right in front of my face. I discarded my attempt at a new design, fixed the problem following the now understood design approach of the original author, and never again felt motivated to re-write code as a method of fixing a problem.

Later, when I became a manager of IT departments, I also came to realize that for many things, such as project management, we had the same challenge. When something wasn’t working, we would go look for a new tool, technique or method to replace it. Gee boss, if we can just buy that new project management tool, we would improve our schedule estimating and project communications! Just read the ad and see how the tool uses the new “agile estimation module” and allows everyone to collaborate “socially on line” and we’ll no longer have all the communications and information disconnects that we’ve had in the past. Things will now just work, with the new tool. Gee boss, can we buy it?

Did it ever work that way for you? I’ve never seen it happen that way. Instead, what has worked well at improving things was always finding the root cause of the problem and fixing it. Often the root cause was that we were no longer following our methodology or process with understanding and fidelity.

Estimating is not working well? Look at our existing methodology. Really look at it. Re-read and re-learn. Are we really doing it the way it was intended? We say people just don’t seem to stay in sync with the changes in the project? Why is that? When was the change made and how was it communicated? If we didn’t communicate it well with the current plethora of meetings, e-mails, and SharePoint postings, what makes us think that having a new tool for everyone to use will work any better if we again forget to publish the change (or the right version of the change) to all the right people?

I once used the trick of saying “hey, I got a great idea, let’s do X, Y, and Z!” Everyone got excited and we had a new and finally effective approach to this task. Where did I get the new approach? I just read through the original description of our current technique and realized that we were no longer doing very much of it. Once we started to do it fully again, it worked just fine.

Many solutions to our problems can be found just by rediscovering the techniques and tools that we already have. Too often, practices get dropped or forgotten with time, to where the original benefits are lost. We think the technique is no longer effective, until we take the time to again understand the technique. Such an approach is just as good as a shiny brand new project management tool, but without the additional cost.

Do you really understand the full intent and techniques behind your project management methodology?