Seven Ways To Make That “Silver Bullet” Work
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 software 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 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 programs 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 I’ve encountered and how we avoided them and achieved some huge successes.
1. You didn’t understand the technology or technique behind the silver bullet. As a manager, you may not be the expert on the thing being implemented. It is great when you are, but you don’t always have that luxury. You implemented the technique almost solely on the “sound bite” that is the silver bullet. “You improve what you measure” so you implemented two dozen metrics and can’t seem to understand why you didn’t see any real benefits.
So what can you do? Find an internal expert. Inevitably in your 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 you 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 you can rely on this person to get you the insights you 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. You implemented it as a unique and separate program. You assigned resources, created an office to manage it, and gave them an implementation checklist. Unfortunately, it is not integrated with any of your other efforts. It stands alone. You did this so the project is not confused with other efforts and so you can clearly see the changes and isolate the budget costs.
Instead, because you now understand the effort – through your own abilities or your experts – you find how to integrate it into what is already going on in your organization. So if it is a metrics effort, you tie it into your SEI CMMI metrics practices or into your Six Sigma efforts. In fact, you may now find that you 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; they are happy to adopt it into their related program. It recognizes and gives value to existing improvement efforts rather than competing with them.
3. You 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 your initiative.
You want to free up folks to be able to take on the new changes. Now that you understand, in detail, the technique and you have integrated it into what is already being done, you need to find an activity, possibly an old initiative, that you can cancel or, better, replace with this new initiative. Figuring out what you can stop doing is as good, if not better, than getting additional staff and money. It can also make you a hero to those folks who get to stop doing the old activity.
4. You were told that just implementing that shiny new software 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. You 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. You had called meetings in the planning phase so folks could highlight the problems in advance. Why had they not seen 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, you 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 you can now implement it with insight, rather than with a checklist or rote training effort.
5. You read that once everyone was trained you would start to see benefits. So the effort becomes a training effort. You arranged classes and showed the percentage of folks trained at management meetings. The glossy brochure said that as a given percentage X% gets trained, then productivity goes up Y%. The Power Point slides 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. You do need training. But with most efforts, you need to train a little, do a little, train some more, and grow expertise. It is never just training that causes the benefits to appear.
6. You fixed the wrong problem. Success! You clearly fixed the problem you 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 you 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 was 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. You were sure that one success would rapidly cascade into success throughout the organization. Let me illustrate with a real example:
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 your 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.
- 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.
- 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.
- 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. Products 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 – increase 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 products. Past performance readily gave us a reason and the data to pick an improved date. 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. You need to understand why things work in a successful effort. 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 me. Good luck when implementing your “Silver Bullet.”
If you enjoyed this post, make sure you subscribe to my RSS feed!Filed Under Change Management | 6 Comments
Tagged With Change Management, Initiative, Productivity, Project Management Tools
Comments
6 Responses to “Seven Ways To Make That “Silver Bullet” Work”
Leave a Reply
[...] Silver Bullets Posted July 14, 2009 Filed under: Brainstorming | Latest update is on making Silver Bullets work: Silver Bullets – Project Management Tools That Work [...]
[...] at your “B” teams. They might be the silver bullet you need now (see related: “Silver Bullets – Project Management Tools That Work“). Thank you for bookmarking and sharing these articles as this tells me which ones are the [...]
[...] [...]
Good day,
As one of the consultant’s who come in to help with organizational improvement, I find your article remarkably true. When a large initiative is getting put into place, I actually tell the client (and usually leading up to that timeframe) about all of these issues. Making sure that everyone knows that we aren’t going to be like the theoretically perfect implementation of any process, technical, or collaboration tool. Instead, we must find the places where the tool is effective and appropriate along with an eye on bigger picture. Instead of just telling the client about these areas they should be aware of, including about a consultant’s role, I will pass along your article since I find that it covers the bases fairly well. Thank you!
Chris,
I started this site in large part to give my customers a place to read about some of the concepts I was using to help them improve. I did this instead of making glossy brochures!
So, I’m glad you find it helpful as a reference. I find I often just need something to get the customer thinking, and then I can supplement and refine the relevant ideas based upon their reaction and comments.
Thanks
Bruce
Another “classic” fix that doesn’t always work as intended is hiring a new CEO for mega-millions. I lived through several of these. The first CEO was lucky and we had unknowingly in the works a killer product that changed our industry. Once that product became old, the company struggled again and he was let go. While we did well, he seemed to get all the credit for the “turn around.”
More on this “luck” factor can be found in the Wall Street Journal, “Why Turning the Page on a CEO Isn’t Always a Panacea” December 5-6, 2009.
Bruce