How to Survive a Death March

NOTE: This originally appeared on this date at Quest Software's ToadWorld, on the expert blog "John Weathington's Quest for Compliance". The link to the actual ToadWorld article is at the bottom.

Edward Yourdon, in his classic book “Death March” ( Prentice Hall PTR ), describes a death march project as a project “whose ‘project parameters’ exceed the norm by at least 50 percent.” In other words, this is a project that is doomed to fail.

The reason I bring this up, is because if you’re going to be a resource on a compliance project, there is a very good chance that you will be placed on a death march. The odds are highly stacked against you. The first problem is that as a database professional, you will by definition be part of an IT project. It may not necessarily be IT compliance, however there will obviously be an IT component to it. There have been numerous studies done on IT projects, and the grim reality is that IT projects usually fail. In fact, the Standish group did a study around the turn of the Millennium, that showed that IT projects fail to meet all the business objectives on budget and on schedule -- 99% of the time. I’m hoping things have improved since then, but based on my experience, probably not that much.

As if the odds weren’t stacked against you enough, now throw in the compliance factor. As you’ve probably heard me say before, compliance projects are arguably one of the worst types of projects to be involved in. Things are getting better with the current awareness, however still today a good majority of compliance projects are reactive – in response to some real bad news. Your executive sponsor, and all your stakeholders will invariably adopt a “wishful” attitude about the your “project parameters”, as Mr. Yourdon puts it.

So, here comes the death march ( sound the music of doom ). This has to be done yesterday, and we weren’t planning on this showing up, so we don’t have any people or money to work on it – but it has to be done.

Of course there are strategies that can be employed at the program and project level to avoid the death march, but that’s not what this article is about. This is a survival guide for the team member that recognizes that they’re stuck in one of these.

Tell Tale Signs of a Death March

It should be obvious, but how can you tell?

You may not believe this, but I’m generally an optimistic person. I like to approach situations with an open mind, and even with those glaring statistics staring me in the face, I tend to give projects the benefit of the doubt to start with. It doesn’t take very long however, when the tell tale signs of a death march show up. Here they are:

• No Project Charter. This isn’t a deal-killer, but it’s a strong warning. A project that has no charter is a project that is probably being run by an inexperienced project manager. If there’s no project charter, there should at least be some document that clearly states what the objectives of the project are, and why you’re doing the project.

• No Project Plan. This is the biggest indicator, and a sure sign that you’re on a death march. If your project manager cannot show you a project plan, either he doesn’t know what’s going on, or he doesn’t want to share with you what’s going on. In either case, you’re certainly in trouble. The only exception to this is project that’s following some sort of Agile methodology. But even in this case, there should be some evidence of a planning exercise.

• Static Project Plan. This is project plan that never gets updated. This is almost as bad as having no project plan at all. Projects don’t execute that way. As the project progresses, reality takes over, and adjustments need to be made.

• Right to Left Project Plan. This is a plan that starts with an end date and works backwards. These are usually unrealistic because they probably started with an unrealistic end date, and fudged the activities back to the starting date. These are sometimes subtle and hard to catch, but if you study the project plan, you can usually see glaring problems ( like a 2 day deployment that you know will take at least 2 weeks ).

There are other signs, but the bottom line reason why a death march shows up, is poor project management. Even if the stakeholders are unrealistic, it’s the project manager’s job to demonstrate how unrealistic they are, and hold ground. If you sense that your project manager is not qualified to take on the project, you’re probably on a death march.

Death March Survival Tactics

So, now that you know you’re on a death march, what do you do? In 3 Key Tips for Surviving a Firefight, I shared with you some techniques for bracing in on a hot compliance project.  To review, here’s what we came up with:

• Get good tools and learn them well
• Don’t take it personally
• Keep grounded in reality

This is all good and well, but in that article we were assuming you still had a chance to succeed. In this case, we know you won’t. Keep these points in mind and do the best you can. In addition, because of you’re impending doom do the following:

Tip # 1: Understand the Doom Timeline

The doom timeline can be deceiving, so it’s good to be aware. On a project slated for doom, attitudes will be fine until the very end, and then everything will explode. The reason why there’s no concern until the very end, is because ignorance is bliss. But at some point, everybody will “suddenly” realize that the project is not going to make its objectives. When that happens, look out!

Tip # 2: Keep a Daily Journal

This is a defensive move. The instant you recognize that you’re on a death march, start a daily journal. Hopefully, this will be early in the blissful segment of the doom timeline. It’s important to understand the doom timeline, because it won’t feel like you need to take a defensive position, as everybody is still happy about everything. Don’t let this fool you. You need records. When things blow up, they will come looking to justify the time that was spent. You need to have detailed records — not only of what you did, but how the project’s direction has moved over time ( i.e. decisions made by the project manager ).

Tip # 3: Insist on Feedback Meetings

In Six Sigma, these are called “Plus Deltas.” These are meetings to explore what you are doing right ( Plus ), and ways you can improve ( Delta ). Insist on doing one of these every couple of weeks, and take good notes on the feedback from your project manager. Poor communication is a killer, and if the project isn’t being run correctly, most likely there are communication problems. These usually manifest as ambiguities caused by lack of communication. When things blow up, you don’t want to be wedged in one of these corners of equivocalness.

A death march is not a fun place to be, but if you’re a database professional on a compliance project, chances are you’re in one. Look for signs of poor project management like a missing project charter or project plan. Once you’ve determined you’re on a death march, be sure to keep the doom timeline in mind, keep a daily journal, and insist on getting feedback on your performance from your project manager. Keep these things in mind, because when things blow up – and they will – you want to make sure you have on your protective gear.

...read the article on ToadWorld