Identifying features of these projects often contain wildly unrealistic goals, crazed unrealistic timelines, a lack of adequate requirements or supporting technical infrastructure, and often, a combination of all of those things.
These projects are affectionately termed 'Death March' projects. I know the name sounds a little extreme, but that's really what they are called. (Here's the wikipedia link to prove it.) I've just survived a project that has had me working crazy hours, weekends, public holidays, and basically any time that I wasn't asleep in an effort to pull one of these off. It all wrapped up today, and in the end, it wasn't that bad. Well, it was actually pretty bad in some ways. For example, my kids haven't seen me in 36 hours, and my wife hasn't actually kicked me in the balls , (but to be honest I wouldn't blame her if she did), so for the purpose of this article, I'm defining "not bad" in the sense that the project itself didn't fail.
So, I thought I'd share my thoughts of how to survive one of these projects, keep your team's reputation intact, and emerge with some semblance of dignity. (Even though the resulting bags under your eyes and disheveled appearance may very well scare young children.)
I'm going to leave out the concept of how to identify if your project is a death march or not - I'm assuming you already know if your project qualifies. So without further ado, here are my 5 tips for death march survival:
1) Cut the right corners
One of the hallmarks of death march projects is that things get left out. In an effort to make the deadline, all kinds of smart, sensible things that Joel tells you to do, like bug tracking and spec writing get abandoned in favour of getting it done. This makes sense - a Death March project has to take shortcuts if you want to have any chance of making it. What's crucial is that you make each one of these 'discard' decisions intentionally, and really carefully. Everything you skip will result in some level of risk - and you need to determine if you're willing to accept it.
Things we abandoned included source control (we had a small team in the same place), code reviews, major re-factoring, and most of the formal bug-tracking (we used a tadalist). We abandoned any written technical architecture, Object modeling, and coding standards, like variable naming or commenting. We didn't do unit-tests, or any other automated testing.
Pretty much all we did have, were a great requirements document with use case analysis, and a great functional spec, both signed off by the customer. This left is in the position that we didn't have any idea of how we were going to technically implement the thing in three weeks, but we did know what it was we had to deliver.
The most important point, in my experience, is that you might be able get by without most of these otherwise (extremely sensible) things, but I don't think you can abandon accurate requirements analysis. If you aren't sure exactly what ridiculous thing you are going to build in this ridiculous timeframe, you're pretty much hosed. Which leads on to:
2) Find the one true measure
When (and if) your death march project finishes, it will be judged on one thing - the way the product meets the original project goals. (Again, some projects don't have these, which makes it nigh impossible to pin down whether or not your project is a success or a failure).
Early on in the march, you need to identify precisely what it is that will determine your project's success (or it's failure.) Often, this is tied directly to the customers expectations.
Sometimes, the customers expectations are also too fuzzy to determine. In this case, I'd recommend that you look through the expected functionality and find the one or two use cases that will either:
(a) be used most often; orSuch obvious bias and prejudicial treatment is a little unethical, but hey, it's your ass on the line, right? Optimize your application for the one true thing that will give you the best chance of looking like a success, even if your project is largely smoke and mirrors...
(b) be used most by the user who can most influence the success or failure of the project.
3) Single Thread
The team needs to be able to focus only on the project. Don't try to maintain any persistent contact with a regular day job, or other people who want to ask questions about that other application that was built last year. Isolate the development team, and cut them off from any further distractions.
If possible, remove access to email - it's a huge source of distraction. Even better, move them off-site, and have them work from a relaxed environment, free of regular workplace hassles, where they can get all scraggly and unshaven and wear t-shirts.
Let the PM take care of any brewing issues with the customer or deadline or finances or anything else. If you don't have a PM- you need to appoint one immediately. Make him or her solely responsible for the success of the project. And they can't be on the development team - Single thread per brain, remember? - The team will have the best chance of success if it never has to look up or deal with anything but the application itself.
4) Do what you know
Software Developers love to play with new stuff. Lucky for them, the world delivers an endless stream of mysteriously named technologies that are really exciting and fun to play with. Things like Xaml and WPF and Indigo and RoR and REST and SOAP are all very interesting, but if they are peripheral to the core skill set of the team members, then abandon them all immediately.
If your developers are not bona fide experts in the technology you are building your software in, then either pull them off the project, or re-build the project in technologies that they really know.
If this means writing your death march program in Visual Basic 5, then, so be it.
The last thing you need is for your team to be trying to deliver a project armed with technological tools that they don't understand. In the death march, Low Tech is King - pick the one true measure, and deliver that, regardless of 'coolness'. An overwhelming focus on results, rather than method, should be the focus for the team at all times - not playing with weird toys.
5) Heroes
This one goes without saying, but you just can't pull a death march project off unless you have a really, really great team. You need to make sure that everyone has the hero mentality - that the project can't be delivered unless they all give everything they've got.
It's worth noting that these kinds of projects are generally not good places for young, inexperienced kids who are trying to learn something. You need seasoned, skilled developers in order to even have a chance of making it. That means hardworking people who are dependable, and not easily distracted.
If you've got people who just can't cut it, you will need to either do some really aggressive hiring - and be prepared to pay premium cash, because most of the folk you really need to hire will be able to identify a death march project really quickly, and hey, nobody wants a gig like that..., or you'll need to restructure the project to meet the skills you've got, which might simply result in not being able to get there. Failure is never far away...
In short, the most important thing you can have with you on these projects is a stark and often terrifying focus on reality. If you keep your head in the clouds, you'll find that when you emerge, everyone will be screaming and yelling and pointing fingers.
On the other hand, if you carefully monitor what it is you really need to get done, match the application technology with the skills you've got, and you have an amazingly dedicated team, and the planets align just right, it is actually possible to make it out the other end (relatively) unscathed.
Posts
Not really the advice I was looking for. It seems like you really just bent over and took it. I was hoping for a more political innovative approach such as tactics to get pulled off the project while still being employed.
ReplyDelete