One of the hardest things to do in any IT project (and for that matter, probably any sort of project) is to face up to the fact it's gone off the rails. Things have gone wrong. It's time to stop the madness. There are a range of reasons it can be hard to face up to this: fear of failure, inertia, being so busy with details that you lose sight of the "big picture", corporate pressure to keep going no matter what.
All the reasons and variations for failing to acknowledge that a project is in trouble usually have one thing in common: denial. Many people seem happy pretend that so long as nobody says out loud that the project is in trouble then there isn't actually a problem. Nobody want to burst the illusory bubble for fear of being branded negative or, worse still, being targeted as the source of the problems (some twisted variant of "first who smelt it, dealt it"). The denial of the obvious is so widespread it's a wonder that heads aren't exploding from cognitive dissonance in IT departments all over the world.
I was working at a large construction company recently to help them procure and deploy a project management software tool. The company was rapidly expanding and was managing about $200 million worth of projects each year. The paper based processes that had worked fine when the company was smaller (around $40 million per annum) weren't scaling well and the pressure was starting to tell on everyone involved.
If someone in management asked the type of questions people in management like to ask (pesky things like "Is the project on schedule?" "How much money have we spent?" "How much money is still in the budget?") the short answer was "nobody knows". The longer answer was some poor bastard spent about a week out of every month chasing pieces of paper that were filed god-knows-where and desperately calling around to find someone who might know the answer.
In short, you didn't want to be involved if there was an audit at this company.
So the decision was made to go to market and find a solution. All of the big hitters in this market responded to the tender (thankfully we didn't go with the German company whose acronym rhymes with CRAP - I would have quit if they'd won the tender). The early ball-park estimate for defining requirements, sending out a tender and picking a winner was 9 months. It ended up taking 12 months to finalise but that's pretty damn accurate for a ball-park estimate.
The initial estimates for getting the software configured and deployed was eight months. Two months into the design phase the timeline had been pushed out to 12 months but nobody was panicking. At the three month mark I realised that while maybe panic wasn't called for, we needed to stop what we were doing and seriously re-assess our approach.
One of the positives of this job was that I was generally treated very well. By that I mean I was treated like a professional. My experience and expertise were respected. I was actually listened to. Most IT people who have worked in non-IT environments (especially something as nuts-and-bolts as construction) will tell you how rare that is. This had a kind of downside in that I was the "lead analyst" and it was down to me to make hard calls like "we're going off the rails."
Hard as it may be to believe from reading this blog, in a work situation I don't really revel in being the centre of attention. And saying that there are problems with a multi-million dollar project is a great way to REALLY be the centre of attention. From this and other experiences I have learned a few things about how to be the bearer of potentially bad news. So here are Mr Angry's tips for dealing with a project that's running off the rails:
1. Voice your concerns sooner rather than later Trust your instincts - if you think something's wrong, it probably is. Problems rarely fix themselves magically - they usually get worse if left unresolved. While it can be daunting to admit to having problems it is usually far easier to fix them early when they're first making themselves felt rather than later when they've spiralled out of control.
2. Have a plan There's identifying problems and then there's complaining. One platitude I'm a big believer in is "if you're not part of the solution, you're part of the problem." If you're going to say there's a problem you should be proposing a solution or at least a strategy for reaching a solution. At the very least identify clearly why you think the project is running off the rails. Don't say "this sucks," say "if we don't address this problem we're going to face nasty outcomes x, y and z."
3. Accept responsibility when appropriate I'm not saying be a sucker or be everyone else's whipping boy. But I am saying it's transparent and bloody annoying when someone sprays blame in every direction while claiming total innocence. If there's something you need to cop to, then cop to it. But this is a situation where you really need a solution ready. Be prepared along the lines of "Look, I didn't catch this earlier so we've actually been developing the project in the wrong direction. But if we do this and this then we can get things back on track."
4. Don't let the problem be ignored In many cases, when you report an issue the response from management can be along the lines of "That isn't your responsibility, just do your job." The following piece of advice is aimed at anyone and everyone who considers themselves an I.T. professional: you're a professional. You have a professional responsibility to not allow important issues to be swept under the carpet. Plus, you need to cover your butt. Don't kick and pout and scream but if you're being told to let something go, DOCUMENT IT. Whether it's the minutes of a meeting or an email to your manager, make sure your concerns as well as the instruction to let it go are clearly documented.
5. Recognise when the problem is institutional There are cases when the problem simply isn't going to go away and isn't going to be dealt with effectively. The workplace is institutionally dysfunctional. If you're stuck somewhere that punishes people who identify problems then you have to accept that reality. I recommend a two-pronged course of action: first, cover you butt (see point 4, above). Second, GET OUT! Seriously, this type of workplace damages your mind and soul.
Making the call that a project has gone off the rails is rarely going to be easy (especially if it carries the connotation of "we're pretty much going to have to abandon the last year's work.") While the Chinese don't really use the same word for "crisis" and "opportunity" (crisitunity!) in a perfect, or even pretty good, world identifying a problem is the first step to solving it. If you or your workplace are to scared to face up to the reality of a project that's run off the rails, all I have to say is enjoy your death march.
No comments:
Post a Comment