We’ve all heard the tales of projects that enter the throws of despair as they near their “conclusion”. I’m sure we all shudder at the thought of this, shake our heads and say “I hope I’m never on a project like that”. I know I did. Now I am.
For those of you that haven’t heard the term before, Wikipedia has a fantastic definition of it here). The current state of project affairs for me includes all of the desperate attempts to revive it, including long hours (weekends haven’t been ruled out) and more resources (because Brooks’ Law doesn’t apply in the reality-free-zone this company runs it’s project in). The thing that is most disturbing is that nobody ever learns from the last death march that they went through. This isn’t just limited to the management who should be learning how to prevent them, it also includes the people that are suffering through them.
I’ve been on a few of these before and I have seen a number of things that get affected when it becomes apparent that there is a death march. Oddly, this is the first time where I’ve seen one that was openly announced (it even had a special meeting complete with ice cream cake, because that will make it all better you know) with over five months before delivery date. The days following the announcement would have made for an interesting study on human reaction to adverse news.
To set the stage for you I’ll describe a few things. First, the developer team, and a portion of the business analysts, is almost solely comprised of contractors. The second thing is that we’ve been working on this portion of our project since the start of the calendar year and we have approximately 1/6th of it finished. Thirdly, we have the next 2 1/2 months to complete the remaining 5/6ths.
After the announcement that we’d be working in a salt mine for the duration of our rather short, northern summer, the developers took it a number of different ways. A couple took it with a laugh, a head shake and a wise-assed crack like “Yesss….finally overtime to get me out of those nasty evenings of BBQ and beer!” A few asked pointed and concerned questions like “Will we be able to do remote work?” and “Will they actually turn on the air conditioning if we’re working weekends?”. Most just shook their low hanging heads, mumbled under their breath and walked out of the general vicinity of the announcement. It was pretty apparent to me that the mood was somewhere between an optimistic sigh of resignation and a bitterly angry tirade of disbelief.
I’ve decided that, due to a lack of other explanations, the different reactions are to be attributed to the different personalities, but the source of the general disappointment is easy to point determine. First, it’s summer here in the great north and we only get about 4 months of summer and spring combined. If we’re really lucky we’ll get a bonus month to month and a half in the fall, but you can never count on that. This is something that just happens to coincide with the death march. The thing that is most frustratingly disappointing is that we’ve had 6+ months to realize that this was coming. Not only that, but the date was known a year ago and the management decided that it would be okay to schedule the work well past it. I’m not sure the rational behind that. If you have a deadline of October 15th that is hard and fast, why would you schedule development work well into the following January? Putting the information on the schedule in those time frames doesn’t make the crunch miraculously disappear. Instead what you do is project a image of being incompetent in your planning to the whole team, then you turn around and say “Hey, I just had to cut 4 months off of your development time. I hope you guys (and gals) are able to make this work.” With that, you’ve succeeded in kicking the entire development team in the scrotum…..twice.
While they’re feeling like they’re having the rug jerked out from under them, the development team is now doing the math to figure out the current velocity of the project. Quickly they come up with a very close to accurate estimation (probably more accurate then their last story estimation, but desperate times call for more accuracy) showing that the current pace has a completion date that is one year beyond the newly imposed deadline. Now the team starts fuming about the fact that they seem to be the only people capable of coming up with the formula to get the Average Number of Hours Work per Developer per Day. People leave early to research the limitations that they have written into their contracts. Those who don’t leave start openly talking about the fact that they’re contractors and they can, and will, limit the number of hours that they will be available. Some even openly state that it will be a cold day in hell before they consider working those kinds of hours for this company and, especially, this management. Everyone who was on the floor clutching for their tender twig and berries is now standing tall and chanting union slogans while burning effigies of the bosses.
A couple days will pass. If there’s a weekend it may be less. Either way, people slowly start getting back to normal work, but they dread the looming expectation of overtime. The day will arrive when overtime starts occurring and a few will, begrudgingly, force themselves to come in early, or on weekends, and stay late. Others will have stuck to their guns and they will sip mohitos in the sun. Effectively, the announcement of a death march has reduced the list of those working extra hours to a mere handful. That, in turn, has provided the project with little or no benefit.
The next step is to start talking about hiring or transferring people onto the project. If all you have is a couple of months to get the product shipped, hiring newbies is going to be a far larger drain than gain. By the time they get interviewed, hired, show up for their first day and become productive, you will have a couple of weeks to use them. It’s not nearly enough to make up for the time you invested in them rather than the code, but think on the bright side; you now have a maintenance team in place for when the rest of the developers walk off the project.
Once you get into a situation where a death march is inevitable, what is the best course for you to steer? The first thing I suggest is tighten the belt on scope control. If you already have good scope control, tighten it even more. If you have little or no scope control, you have to tighten this area so hard that it feels like you’ve cut off all circulation for the client. This doesn’t mean that you can’t still accept change requests, but they have to have a highly visible price attached to them. The best way I saw this done was where you’d ask the client “Which one of the new features, that we haven’t started, would you like to remove in place of this change?” It’s amazing how quickly the client will prioritize things when you force them to choose.
Do force the client to choose. You don’t have the time to let them waffle on the choice. That decision needs to be made yesterday. Set a date and time for them to have an answer by. Reinforce the decision timeline by clearly stating that the change will no longer be able to fit the schedule if they don’t decide by that date. If you’ve had lax change control up to this point you will find that the client will be like a change-on-a-dime junkie who is going through withdrawals. Let them kick and scream, but never give in. If you do, you’ve just introduced another risk for failure to an already risky project. Control all the risk that is within your grasp.
Eliminate obstacles. If you’re having problems with a developer’s PC, get a working replacement for it immediately. If a developer is having to attend to his vehicle in a surface lot throughout the day, find them a pass to the company parkade. If developers are working long hours and are unable to get home on public transit, get them taxi vouchers. Keeping a development team heads down, and fully effective, for a 12 hour day takes more than a couple boxes of pizza at 5 o’clock. The more non-work things that you can take off of their minds, the more you will get from them.
Remember, you want to have your developers focused. Keeping them focused doesn’t mean that the work place will be quite with the exception of the steady drum beat of keystrokes. There will be talk and, if you’re lucky, even a little laughter. Focusing the team is more about preventing distractions. Stop the meeting requests. No more 1 hour meeting to discuss the current state of every developers code changes. No more meetings to discuss the most effective way to communicate tool rollouts with the networking team. Encourage your developers to block off their entire calendars with one entry for “Coding”.
Once you have your team ticking along for all ungodly hours of the day, it’s time for you to do one last thing……shut up and listen. Just because you got them off on the right foot doesn’t mean that there won’t be bumps in the road. When you hear a rumble from their ranks, get involved and resolve the situation as quickly as possible.
Oh, and never start a death march by telling a Canadian development team that they’d “…rather be doing overtime during the summer than in November.” You’d be amazed at how many will log off their computers upon hearing that, and go for a beer.