There are many techniques for improving project management in your organization. There are many newer technologies and project management tools that can replace your existing technologies. Why these help is not always because they are inherently better or improved over what you had before. Often, it is just the key act of changing in an orderly and well thought out manner that makes the huge difference.

I was an experienced manager. I had years, actually, decades, of experience in Information Technology (IT) management and software development. This was a new job however. I didn’t know the domain very well. I had not worked on these kinds of products before.

I was now responsible for planning and managing the entire product. Well, at least the software portion of the product. This was the most important part in my humble estimation. Actually, the hardware sold the product and the software was just the enabler.

I had started out working at this company managing a portion of a product’s software. It was our huge mega product that would supposedly catapult our technology to set a new world class standard. It was nine months late to market and we practically had to beg a customer to finally take it so we could declare we had shipped the product (for more background see honesty as a project management tool). Years later, the product would become iconic. It was the product that showed up in ads, television shows, and used by world leaders. It was an inauspicious beginning however.

Now, I had the responsibility to put out the next big product. It was not to be the next big product when we started. No, it was a minor upgrade to an existing product. It was a tribute to our great management (had to slip that in!) that when the company needed the next big thing, they took our effort, tripled it in size, and designated it to be our next killer product line.

The only problem was I had no clue how everything came together. Sure, I could figure it out, but not fast enough to keep up with where we needed to be. My own calculations showed us we had to be much further along than what conventional planning was projecting. In one case, our customer requirements team pushed back hard on my pressure saying, humorously in hindsight, that we had plenty of time and why was I pushing so hard to get the core requirements nailed down?

But, I still didn’t know enough of what I needed to know. My salvation came from a very simple document. Our development team had updated a process document that showed how planning for product development needed to proceed. It was a new process, though it did have many elements of how they had done it in the past.

I happen to stumble upon the document. I didn’t understand all the process steps, except in general. I didn’t understand the planning systems they were using nor the specifics of how the development teams would be using them. I didn’t care. I had something I could use until I could figure things out. You see, I’m the type of person who wants to understand the whole process in detail. Not only the checklists, but also the full understanding behind each process step, why it is needed and why it works to do it that way. I knew none of this, but I was experienced in software development and I now had a document that said how they were suppose to do it.

After an initial kick-off meeting, I blasted out a missive giving everyone a deadline for the first step in the process. As I mentioned earlier, my advantage was I had analyzed the overall schedule and milestones of past products (see Get The Project Management Schedule Right) and knew in high level terms how it was to progress. I also knew where we needed to be in the overall process to hit the market windows we needed with this new product line. I had no clue how we were going to do this first step. If anyone asked me detailed questions about it, I was going to be in big trouble.

They didn’t. They pressed on following their updated process. What I discovered later was the development team really appreciated that I, being on the product management team and not on the software development team, took their new process and was using it. In fact, my missive turned out to be the main impetus for the individual development teams to make the changes in the way they did development. Others in my position on other product teams had to be re-educated and persuaded on the changes. In many cases managers in my position would push their own conflicting process improvements on the development team. I didn’t have any history or assumptions to push upon them. I just needed to get them going and hoped like heck they knew what that meant.

In many ways, techniques such as Six Sigma, Scrum, CMMI, Agile, Lean, PMP, etc. are like this. They are, hopefully, fully baked methodologies that if we follow them, we will do OK. We will certainly do better as we come to understand their deeper meanings and nuances. Folks that only use these systems in checklist or other shallow approaches (see making project management tools silver bullets work), in my experience, rarely see the full benefit of these techniques and technologies. However, they can be great ways to get started while we are still learning (see also The One Perfect Project Management Methodology).

I was very lucky that this process I latched onto turned out to be a good one. It helped us absorb a tripling of the number of products that would be in this product line and an increase of 450% in the number of requirements going into these products. It even stood up well to the firing of the user interface team and the moving of this development function overseas in a cost savings effort (“why now?” was all I could think of at the time). We did not have to replan everything we were doing when these things happened. We just had to reapply the process we already had.

More importantly, for me, it allowed me to survive and to be useful while I was still trying to learn. As I mentioned, we were picked to become the “next big thing” because the project was perceived as being managed so well. A senior manager who would later become a corporate VP and my boss’s boss said to me (I just had to slip this in here) “Bruce, you are a superstar!”

Understanding and following a good technique, methodology or process can make just about anyone a superstar. That is the power in finding and using such technology. I’ve experienced that doing just about any methodology well will show significant benefits. Sometimes however, it works well to just take on a new approach and just do it. It breaks us out of our old habits and energizes the team into improving how they do business.