Forced March, not Death March

Posted by Robert Merrill on January 17, 2012 under Software Development, Software teams | Be the First to Comment

For almost exactly two months, from mid-November 2011 through mid-January 2012, I was on a Forced March, meaning lots of overtime and weekend work to get a software system up and running. It’s still not live—the sponsor switched from Date-Driven to Done-Driven and slipped the launch date six weeks, but not after I’d worked pretty hard.

These are sometimes called Death Marches, after Edward Yourdon’s book, in turn named after (I guess) the Bataan Death March. This was nowhere close. First, comparing anything that’s ever happened on a software project to the likes of Bataan shows a terrible lack of perspective. Second, even as software projects go, this was short and not at all harmful for someone in my circumstances of life. Third, “death march” implies at best a selfish motive, at worst a truly sinister one, and most likely just macho stupidity (read about Electronic Arts and judge for yourself). Read more of this article »

Lessons from a Forced March

Posted by Robert Merrill on December 26, 2011 under Software Development, Software teams | Read the First Comment

My primary client is going live in one week (1/2/2012) on an Order Management System that’s been in the works since March 2011 and was selected in August. For me, it turned into a forced march in mid-November—six-day weeks, extra hours, and more stress all around that I would have liked.

It’s part of my professional mission to prevent such things, and I ended up with one anyway. The tuition’s largely paid, so lets at least make sure we get something out of the course.

  • What was the primary cause?
  • What were the contributing factors?
  • What have been the consequences?
  • Could it have been prevented?
  • What can I, and you, learn from it?

Stay metaphorically tuned for a series of blog posts, but not for another week or more. One of the direct consequences was no blogging and very little other marketing activity for uFunctional LLC. The long-term consequences of an empty pipeline are about to become apparent.

Why Big Projects Often Have Problems

Posted by Robert Merrill on April 6, 2011 under Software teams | Be the First to Comment

This popped into my head the other day, and stuck. I need to examine this carefully. Does it really hold up, at least in my experience and that of others? If so, can something useful come out of this idea? So, expect this post to change. I’m thinking out loud a bit.

Big projects cost lots of money.

The presence of lots of money attracts people who love money.

The love of money is the root of all sorts of evil.

Evil causes problems.

I can’t recall reading a software development or management book that didn’t assume that people are trying to Do The Right Thing, and that the problems project teams get into were the result of increased complexity or ineffective ways of working together.

But if I’m trying to help clients’ projects and businesses succeed, and I’m overlooking a critical factor, I need to consider it, even if it is impolitic to do so. As a consultant, that’s sometimes my job—to say what every insider knows but is afraid to say. If I get fired, I’m only losing 1/4 or 1/2 of my job, not the whole thing, so I’m expected to take chances.

It’s generally agreed that big projects are more likely to have problems. But what about this notion of big money, and evil? Let’s look at it, one line at a time, and see if there’s anything useful.

Return often. This is a work in progress. I’m thinking out loud, and I welcome your (useful) participation. Read more of this article »