Tired of your project? Can’t wait until it’s over? Ready for a change? Or maybe you just like chaos. We’ve all been stuck with projects that we didn’t want anymore. If you’re really interested in killing the project—if you’re really committed to making it fail—nothing could be easier. Whether you’re a drone or a queen, you have the power to turn a thriving hive into a sticky mess. The key is to have a strategy.
10. Keep business experts away– far away—from integrators and developers. If the people building the solution don’t talk with the people who need the solution, then the project will fail every time. Admittedly, driving a wedge between creators and users is a lot easier when you’re a manager, but even average workers can keep the experts at bay, for example by scheduling meetings that include only developers or the business side—never both in the same room.
9. Keep management in the dark. The people actually doing the work have the skinny on what’s going poorly. We know when the server is overloaded, the screen shots used in training don’t match the application, or the data model doesn’t conform to enterprise standards. That knowledge gives us real power. Just keep all those juicy tidbits to yourself, and watch management scramble as the project falls apart, apparently for no reason at all!
8. Keep your customers in the dark. Putting blinders on your customers is even more effective for killing a project than spoofing managers. Don’t tell users or customers anything, especially about your deliverables. Don’t let them see anything until the last possible second, and then make sure it’s too late in development to change anything. Codify this strategy across your program by selling it to management as the best method of controlling user expectations.
7. Don’t document anything. This is one of the most subtle and insidious methods of killing a project. Take advantage of human laziness– urge people to do the fun stuff and not to worry about documentation; say “we’ll get it later, after we’re done.” Then as the natural process of project turnover occurs, enjoy the fun of watching new team members struggle to figure out what their predecessors accomplished or how they arrived at certain decisions.
6. Don’t train or allow for training. This strategy is doubly effective, because you can de-emphasize training for your project team, and this will lead to a consequent dearth of training for your users. Say things like, “you can read a book and pick that up in a weekend” or, “we don’t have the budget for that class right now; let’s wait until later” or, “our customers are savvy enough to pick this up without a guide.” (With project members, however, the best thing to say is “Training? I thought we brought you on the team because you were already qualified!”)
5. Don’t use the best technology for the job. Convincing your teammates and managers that the best-fitting technology is unnecessary can be a very efficient way to ruin a project. Think chewing gum and baling wire–build an enterprise-wide, high-volume, heavily used knowledge management system with an MS Access back-end. Or manage documents destined for multichannel publishing using WordPerfect and the LAN. Kludges always eventually fall apart, sometimes even before the first scheduled rollout.
4. Change project scope frequently. This is hard to achieve unless you’re a manager, but a scope shell game can bring a project to its knees—change early and often. Customers, consultants, integrators, developers, tech writers—everyone hates working on a piece of the puzzle only to discard or significantly change their work because of a sudden, inexplicable change in scope.
3. Control scope pathologically. Oddly enough, overmanaging scope can be as effective as undermanaging it. A great example is finding a “hidden” key business need during an evaluation and choosing not to address it because “it’s out of scope”—even if it’s easy to fix. Then publicly throw the responsibility for managing the core need back on the customers and watch them rebel.
2. Start writing code before gathering requirements. Unless management is really on the ball, this is a piece of cake, and the less developers know about the goal, the better. Get as many sexy features as you can up and running as quickly as possible. In just about every case, the person who creates a neat interface, training document, or data model has to throw out nearly everything once real requirements are gathered. And redoing the effort often throws the project off schedule significantly, which usually leads to the project death you so desperately desire.
1. Hire great people and micromanage them. While this technique is way beyond the average worker bee, and requires some finesse to achieve, I’ve seen it often enough in practice to know that it is far-and-above the most effective way to kill a project. If you can set up an environment in which every team member is afraid to make a decision without management input, you’ve achieved project-killing Nirvana.
Of course, if you’re one of those people who are really interested in making a project succeed, please throw away this list immediately. Use this article for the intended purpose only. And especially don’t try to reverse-engineer it to avoid the pitfalls that beleaguer a project; that’s just not fair for those of us who need your project to go away!
Robert H. Wallace is a consultant specializing in authoring and editorial systems for small- and medium-sized companies. You can reach him here
