I had done everything “by the book.” Sold management on the great project management technique and tools (i.e., the “Silver Bullet”). Called all those planning meetings. Got approval and funding. Ran a zillion implementation meetings. Got lots of good press from management on how much this was going to solve our problems. The vendor said we would improve productivity by five times and deliver our products on time. Everyone in the industry is doing it the consultant said. We even had “countdown” displays in the hallways and on all PC screen savers for when we would complete implementation and hence rocket us to new levels of performance!

Six months later, few people seem to be talking about the improvement project. Yeah, it is still going on in places. Other more exciting initiatives are currently getting visibility from senior management. The vendor is happy to be hanging around a bit longer to help us get over the “last few” implementation details. Our checklists and terminology are still being used in most projects and in status reports. Things don’t look too much different, however. Certainly there has not been the revolutionary improvement in productivity. There are a lot of explanations and reasons offered for why we’ve not yet seen the benefits. Mostly, we are just not talking about it much anymore.

Actually, I’ve been very lucky. While I’ve observed or been part of many of these less than successful improvement efforts, I’ve also been able to lead many that worked out very well. Here are the typical missteps we’ve encountered and how we avoided them and achieved some huge successes.

1. We  didn’t understand the technology or technique behind the silver bullet. As a manager, we may not be the expert on the thing being implemented. It is great when we are, but we don’t always have that luxury. We implemented the technique almost solely on the “sound bite” that is the silver bullet. “You improve what you measure” so we implemented two dozen metrics and can’t seem to understand why we didn’t see any real benefits.

So what can we do? Find an internal expert. Inevitably in our group there will be one person who is, in fact, an expert. This person loves to dig in and understand a technique or tool. They possibly have been studying or using it for years before we got around to announcing that it is the solution to all our woes. This expert is not the project manager however. You, as the project manager, are the one who must balance everything that is going on to make things successful. So while we can rely on this person to get us the insights we need, be wary of turning it over to the “expert.” Sometimes they are too much into the technique or tool and not into the success of the overall project. Don’t rely solely on the vendor or consultant as the expert either.

2. We  implemented it as a unique and separate program. We assigned resources, created an office to manage it, and gave them an implementation checklist. Unfortunately, it is not integrated with any of our other efforts. It stands alone. We did this so the project is not confused with other efforts and so we can clearly see the changes and isolate the budget costs.

Instead, because we now understand the effort — through our own abilities or our experts — we find how to integrate it into what is already going on in our organization. So if it is a metrics effort, we tie it into our SEI CMMI metrics practices or into our Six Sigma efforts. In fact, we may now find that we need only to tweak an existing effort to get this silver bullet into full use. Leverage what already exists. It saves money. It builds ownership by those who help implement it as they are often happy to adopt it into their related program. It recognizes and gives value to existing improvement efforts rather than competing with them.

3. We just added this new activity on top of all the existing activities. People are already busy. Too many people are just not spending enough time on our initiative.

We want to free up folks to be able to take on the new changes. Now that we understand, in detail, the technique and we have integrated it into what is already being done, we need to find an activity — possibly an old initiative — that we can cancel or replace with this new initiative. Figuring out what we can stop doing is as good — if not better — than getting additional staff and money. It can also make us a hero to those folks who get to stop doing the old activity.

4. We were told that just implementing the shiny new management tool would make the difference. Just put the tool in place, the glossy brochure said, and all will be well. However, it didn’t seem to work out that way. Getting the tool to work was hard enough. We dictated that everyone would start using it on the first of the month. It turned out that no one really had enough experience on it to use it well. Many others listed dozens of things that were wrong with it or that didn’t work as needed. Productivity plummeted. We had called meetings in the planning phase so folks could highlight the problems in advance. Why had they not noticed these problems earlier?

Pilot the silver bullet. Give it to someone.  Better yet, find someone who is already using it or something like it, and let them run with it. Tell them to put it to use and report regularly on what works and what doesn’t work. Not all tools work well with every feature they have. In the pilot we need to find those features that make a true difference and those that need to be ignored or sometimes banned as they caused more harm than good. Also, this is a way to generate the expertise needed so we can now implement it with insight, rather than with a checklist or rote training effort.

5. We read that once everyone was trained we would start to see benefits. So the improvement becomes a training effort. We arranged classes and showed the percentage of folks trained at management meetings. The Powerpoint slides said that as a given percentage X% gets trained then performance goes up Y%. The white paper pointed to research showing companies who have Z% of their folks trained see an average Y% increase in productivity.

Training is another of those checklist approaches. We do need training. But with most efforts, we need to train a little, do a little, train some more, and grow expertise. In our experience it is never just training that causes the benefits to appear.

6. We fixed the wrong problem. Success! We clearly fixed the problem we intended to fix. Everyone should be cheering and senior management should be seeing productivity shooting to the moon. Instead, many folks actually appear to be unhappy that we succeeded in fixing that well known issue that caused so many problems.

Too many technology silver bullets are being used to try and fix cultural or unrelated organizational problems. I once took over an organization that always got their budget submission in late. My new organization had the biggest budget and we were considered the “big” problem that caused late budgets. So, when budgeting time came around, I got it in — on time. Boy, nobody in finance wanted to see that. It messed them up totally. They had all sorts of other problems that also needed fixing. Getting the “big” problem fixed did not result in an on time budget for the whole division.  The following year, before submitting my budget, I asked the Finance Director if he needed me to “review” my own budget for another week. He said “yes!’ with an audible sigh of relief. Here the “big” problem was just a convenient cover for a much more pervasive organizational problem. Fixing it didn’t solve the stated problem.

7. We were sure that one success would rapidly cascade into success throughout the organization.  We delivered our premier product on time, the first time in the memory of our biggest customer. Our customer commented on it numerous times. Our team got a quality award for setting “A New Standard of Excellence.” We used a lot of improved management techniques and took a lot of heat, but we succeeded!

Great, so everyone runs off to do the “same” thing.  What was the silver bullet technique? It was to make a good estimate of our schedule by looking at previous results and seeing how long things really took. That was it. Easy, yes?

Well, almost. This is what appears to have happened:

1. The development teams started using past performance based schedules. I was startled and elated when rolling onto a new product and seeing the technique being used in planning. Woo Hoo! My job was going to be much easier.
2. This resulted in schedules at the ragged edge of when the product was needed — when it would still be competitive. The product teams were not happy with this. Oops, we are confronting reality on how long things really take and don’t like what we see.
3. When a problem comes up, and there are always problems in planning new development, the development team would — as they always did in the past –- immediately try to push out the schedule.  Such a schedule when pushed out was now clearly non-competitive.  Product projects were then canceled. Uh, oh -– something is not right here.

What went wrong?

• Development lacked understanding of the technique. They used the “sound bite” description of “use past performance” to guide their implementation. A past performance based schedule already takes into account all the typical things, and many of the non-typical things, that go wrong. So once a problem was encountered the schedule already took it into account.  Development, not understanding this, used an existing habitual behavior — slip the schedule — that was no longer appropriate.
• The silver bullet didn’t address the root cause. The reason the past performance based schedule made a difference in the first place was that we were always late with our projects. Past performance readily gave us a reason and the data to pick an improved date and break the cycle of late products. The cultural belief, however, was that the development team could not deliver on time. The reality was that the product team could not deliver a new product proposal on time. They were consistently three to four months late, based upon past actual performance, in proposing the product to development. The development team always started with a significant schedule deficit. After all these years of “development is always late” the product team did not readily take to the notion that they were at least half of the systemic problem.
• There was a lot more we had done than just the one silver bullet. We achieved our on time delivery using a six shooter of silver bullets. Our development team only latched on to one of them.  It is rarely just a single silver bullet.

Almost any good technique or project management tool will reap ample benefits, if successfully implemented. It just has to be implemented in the right way and for the right reasons. But you knew that. Here I supplied some examples of techniques that consistently worked in practice for us.  Good luck when implementing your “Silver Bullet.”

What silver bullets have you tried and how have they succeeded or failed?