The Dark Side


There are a number of dark side options. All of these will mean, at least, that you don't get blamed for the project being late. However, they are irrational in the sense that they won't solve the problem.

Dark Side 1: Don't Tell Anyone

This sounds silly but it can be very effective. Faced with the fact that you will be at least six weeks late, you and your team hunker down. You continue to report to your sponsor and stakeholders that everything is fine and begin to drop little hints that there are some small problems that you and the team are currently working on correcting. With luck, this will buy you enough time to put some of the other Dark Side strategies into action. With a lot of luck, one of your team members may leave (so you can blame his or her departure for the delay) or your sponsor will be promoted or moved to a more urgent project before anyone finds out the real situation.

Dark Side 2: Hope It Will Get Better

This is also known as entering the valley of unjustified optimism and it is typically used in conjunction with Option 1. Faced with the deadline blowout, you begin hoping that things will get better: Maybe tomorrow your company will be taken over or there will be a really big requirement change from your key stakeholder that will enable you to hide the 12-week error. My elder brother is a medical specialist and he tells me that in the human body there are a number of "little greeblies" [2] that have no other purpose than to help the body heal. In all our experience, we have never found similar greeblies in a "self-healing" project. However, you can always hope!

[2] My medical terminology is state-of-the-art.

Dark Side 3: Covertly Degrade Quality

This is a very well known Dark Side option. Faced with another 12 weeks of work, you tell the team to drop documentation, the online help screens, and the testing of the system. We discussed this option in Chapter 9, and when the full system is delivered the business people will be so happy with the functionality, they won't need documentation, right? The bugs are just features, after all.

Dark Side 4: Covertly Degrade Functionality

This variation is often called descoping. You drop nonessential functionality (assessed by you, of course) without letting anyone outside the team know. By doing this you can make up the additional 12 weeks of work. Again, by the time you deliver, many of the critical stakeholders may have moved and everyone will be happy to get the basic functionality.

Dark Side 5: Work Harder ”Long- Term

This is a really terrible option. This option involves you and the team trying to work an additional 12 weeks in six elapsed weeks (in addition to the six weeks of work already scheduled). This sounds unbelievable, as we discussed in our article Project Pathology (our Web site, www.Thomsett.com.au, awaits you), but this option results in a suspension of belief known as cognitive dissonance, where the team cannot accept the reality of the situation. This option is often called the "Death March" option (we mentioned Ed Yourdon's [1997] book earlier). With luck, your exhausted team members will turn on each other and, as they tear themselves apart, you can go to your management and complain about your team's behavior and how that'll mean the project will be late!

Dark Side 6: Hire Consultants or Contractors and Blame Them

This is a powerful option. You ask for help to meet the additional work and then as the consultants and contractors arrive , you welcome them with open arms. After a respectable period, you start rumors by making comments such as, "Well, the project was a little in trouble but, since the consultants have arrived we have seemed to find another 12 weeks of work. You know how consultants are always creating work for themselves." Then, the blame can really be shifted.

Dark Side 7: Blame Your "Users"

We discussed this behavior in Part 1. It has been a time-honored practice for IT and other specialists to blame their clients : "Those @@##!!% users. They just didn't know what they wanted. Now look! We have another 12 weeks to go. If only they could have been more specific. Blah, blah ." It is clearly a very powerful option, which is probably why it is so commonly used.

Dark Side 8: Blame Everyone ”A Witch Hunt

This is another powerful option. You send a memo or e-mail to all stakeholders, your project sponsor, your management, and anyone else you can think of. In your mail you gently and politically correctly imply that everyone has not given your project the priority it deserves (which, given the number of projects typically underway, will make sense). Then, everyone gets angry and defensive and the management calls in a consultant to review all projects. You and all your colleagues then invoke Dark Side Option 6.

Dark Side 9: Leave the Project

This is dramatic but effective. There is a time-honored joke about this option. When you leave a failing project, you write two letters, seal them and leave them for your replacement with instructions that, when they find the problems, they should open Letter 1. Letter 1 says, "Blame everything on me, the previous project manager." If that fails, the instruction says open Letter 2. Letter 2 says, "Sit down and write two letters ."

Dark Side 10: Add Lots of People ”The Horde Model

If you can get this option going, you're in the clear. You get management and your sponsor to hire a number of contractors and consultants from different companies. In addition, you get other people from your organization involved. Then, you can implement all of the preceding options at the same time! There are so many people, so much confusion, and so much fighting, politics, and defensive behavior that you could even leave the project and they won't know for some time: "Hey! Where's the project manager? Oh, we haven't seen him for some time. He's always at meetings. You know how it is in busy projects." Wrong! You've left.

Dark Side 11: Stop the Project

You report that the project cannot be delivered because of the frequent changes (including the 12 weeks that your team missed) and that the best action is to stop the project. Management agrees and moves you on to another project because you're one of their best project managers.



Radical Project Management
Radical Project Management
ISBN: 0130094862
EAN: 2147483647
Year: 2002
Pages: 136
Authors: Rob Thomsett

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net