Recipe for a Death March

| Comments
Skull and Crossbones!

My software death march recipe.

1. Big-Ass Requirements Documents

Business owners, take heed. The first whiff the developers get of an incomplete requirement, they’ll sit and hold their breath until someone acknowledges their collective awesomeness and the failings of such a poorly defined specification.

Take the time to create a monolithic testament to verbosity and complexitude. It will pay off in spades.

2. Lots of Approvals

Once the massive requirements doc is done, be sure to have it approved. By everyone. Take lots of time for minor tweaks to language and debate over everything. This will take as long as it takes. You can’t rush approvals.

Oooh, and also get a bunch of visual aids and pixel-perfect mockups. Have those approved, too.

Do not, under any circumstances, plan for what might happen if things aren’t approved. That’s crazy talk.

3. Lots of Big Meetings

If the sacred Requirements Document doesn’t provide some detail, stop all work and call a meeting. The more people in the meeting the better. It should break down like so:

  • 5 minutes to clarify the feature
  • 10 minutes of re-hashing that same point
  • 45-65 minutes of wild divergence to other gripes since people feel guilty cutting such a well-attended meeting short.

4. Shorten Testing Time as Needed

Remember, testing is the most flexible phase of your project. If development runs long, don’t change the live date, just squish the QA time. This always works.

5. Don’t Change Scope

If things aren’t going too well, DO NOT even hint that some features could be dropped, or that the live date move. Just ask everyone to work harder, work weekends, or perform some kind of digital miracle.

6. Complain

Developers, take the necessary time and effort to complain to whoever will listen about the weak-assed requirements, and how it’s impossible to work with them. Do not find any product owner. Do not engage them in informal face-to-face meetings. They have their own cubes for a reason.

7. Never Look Back

No two projects are the same. Anything you might learn from this one is useless on the next. Don’t waste time with silly retrospectives, improvement ideas, or a dumb “lessons learned” document. Move on and be thankful this thing launched and is done with.

[photo courtesy Chris Flemming. Some rights reserved]

blog comments powered by Disqus