Minimize
Blogger List

Johannes Ahrends
Toad and Oracle

Ben Boise
Toad SC Discussions

Kevin Dalton
Benchmark Factory

Steven Feuerstein
PL/SQL Obsession

Devin Gallagher
Toad SC discussions

Stuart Hodgins
JProbe Discussions

  Henrik "Mauritz" Johnson
Toad Tips & Tricks on the "other" Toads
  Mark Kurtz
Toad SC discussions
  Michael Lumbard
Toad SC discussions
Daniel Norwood
Toad for Data Analysts,
Toad Extension for Visual Studio
Debbie Peabody
Toad for Data Analysts
Gary Piper
Toad Reports Manager
John Pocknell
Toad for Oracle, JProbe
Kuljit Sangha
Toad SC discussions
Bert Scalzo Indicates Oracle ACE status
Toad for Oracle, Data Modeling, Benchmarking
Jeff Smith
Toad product family
Richard To
SQL Optimization
Jim Wankowski
DB2 - LUW and z/OS
John Weathington
  Toad Data Modeler Opens in a new window
Data Modeling
 
  Real Automated Code Testing for Oracle
Quest Code Tester blog
 
Minimize
Blog Tags
toad for oracle (122)
oracle (62)
plsql (46)
sql optimization (37)
toad for data analysts (28)
code tester (19)
toad for ibm db2 (13)
automation (11)
batch optimizer (10)
virtualization (10)
schema browser (9)
toad for sql server (9)
data grid (8)
sql (8)
sql editor (8)
toad data modeler (8)
benchmark factory (7)
excel (7)
query builder (7)
report manager (7)
toad extension (7)
visual studio (7)
11g (6)
configuration (6)
freeware (6)
health check (6)
vmware (6)
connect (5)
dba module (5)
er diagrammer (5)
F4 (5)
linux (5)
refactoring (5)
spotlight (5)
unicode (5)
compare (4)
debugger (4)
export (4)
formatter (4)
make code (4)
rman (4)
strip code (4)
benchmark (3)
bfscript (3)
bulk collect (3)
code templates (3)
code xpert (3)
database browser (3)
db2 (3)
notebook (3)
oem (3)
RAC (3)
session browser (3)
speed (3)
sql optimizer (3)
toad for mysql (3)
tpc-c (3)
9.7 (2)
alert log (2)
app designer (2)
awr (2)
code insight (2)
code snippets (2)
collection (2)
compare and sync (2)
compliance (2)
data generator (2)
data warehouse (2)
database explorer (2)
database monitor (2)
explain (2)
forall (2)
ftp (2)
group execute (2)
handbook (2)
installation (2)
job scheduler (2)
multi-task (2)
nested table (2)
os command (2)
profiler (2)
recovery (2)
release history (2)
save as (2)
schema compare (2)
sql recall (2)
stats pack (2)
subversion (2)
team coding (2)
trace file browser (2)
while loop (2)
10g (1)
64 bit (1)
7zip (1)
action (1)
addm (1)
alter (1)
ansi join (1)
array (1)
ccleaner (1)
code coverage (1)
code road map (1)
CRON (1)
cursor for loop (1)
data browser (1)
data subset (1)
database probe (1)
dbms_flashback (1)
dbms_profiler (1)
ddl (1)
feuerstein (1)
filezilla (1)
flash drive (1)
flow control (1)
for loop (1)
group policy manager (1)
hints (1)
import (1)
index (1)
inheritance (1)
invoker rights (1)
ipad (1)
java (1)
latency (1)
log switch (1)
logical model (1)
ltrim (1)
master-detail browser (1)
monitor (1)
multi-select (1)
naming standards (1)
network (1)
object explorer (1)
OEBS (1)
package (1)
parser (1)
partitioning (1)
performance (1)
pragma (1)
project manager (1)
RAT (1)
revo (1)
REXEC (1)
schema report (1)
script manager (1)
search (1)
set operator (1)
sga (1)
slow (1)
sonarsource (1)
source control (1)
space projection (1)
sql monitor (1)
sql navigator (1)
sql script (1)
sql tracker (1)
sql*plus (1)
standards (1)
statistics (1)
stored procedure (1)
string parser (1)
sub-model (1)
sub-type (1)
synch (1)
synchback (1)
TELNET (1)
toad (1)
trace (1)
unit test (1)
unix (1)
usb (1)
utility (1)
v10 (1)
v9.5 (1)
version control (1)
waits (1)
workload replay (1)
workspace (1)
xml (1)
 
WELCOME, GUEST
 
 

Blogs
Toad and Database Commentaries

Toad World blogs are a mix of insightful how-tos from Quest experts as well as their commentary on experiences with new database technologies.  Have some views of your own to share?  Post your comments!  Note:  Comments are restricted to registered Toad World users.

Do you have a topic that you'd like discussed?  We'd love to hear from you.  Send us your idea for a blog topic.


Aug 7

Written by: JohnWeathington
Thursday, August 07, 2008  RssIcon

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.

Tags:
Categories:
Search Blog Entries