Sunday, May 17, 2009

Stop Persevering, Start Thinking

Consulting and software projects do funny things to incredibly smart people - they make them dumb and irrational. I've experienced it first hand (though I don't admit in public that I rate as incredibly smart).

So what's the deal? We've all used some variation of the phrase 'you can't see the wood for the trees'. That's what tough projects can do to people. They get so involved in the details of the project that they either don't notice that the project is starting to fall apart, or don't notice that it was never really together enough in the first place to fall apart. Then disaster strikes - the shit hits the fan - the customer starts ranting (more than before) and the incredibly smart people fall into the worst trap possible; they keep doing what they were doing before, just now at nights and weekends.

There are only three people or roles of people that I think can help prevent, or at least fix this when it happens:

1) The project manager or leader - the person who is falling into the trap and taking the project with them

2) The project manager's boss, mentor, or someone close to the project - preferably someone the leader trusts

3) The client - the guy who is being the biggest pain in the ass that there is right now

As a project manager, how do you prevent this? Well, I don't know that you can, but try following your own rules maybe and put in some checks or balances for your own personal behaviour, independent of the project.

  • How many hours have you worked this week? Is it significantly greater than the average project you run?
  • Have you started to find excuses why you can't do things differently in the project (the client will say no to everything you suggest, its just impossible, etc)?
  • Have you made your team members miss personal events, weekends, etc?

As a project manager, when you really feel you can't take an hour off, do just that. In fact take two. One hour, complain and moan to yourself, go for a walk, do something that forces you to get away from the PC. The second hour, start brainstorming about how you can change the project; what is the stuff that is unnecessary, what can you do differently. This is brainstorming. Nothing is impossible. You can work out in the third hour (three hours, impossible!) what is going to be most effective at getting back on track with minimal impact to the value of the project.

As the person the leader trusts, have you seen this issue getting bigger? How can you help? I'm no counsellor in this stuff, and have always enrolled in courses of 'tough love'. Painful for everyone involved, unfortunately, though often gets the job done. Help the leader brainstorm, and visualize where the value in the project comes from, which is often not the individual details. Help them understand how they might sell some of the changes to the client.

Then there's the client. Why in the world would you want to put your project at risk, along with the potential risk to your business and credibility? So maybe its time to start compromising a little. Screwing the vendor or consultant out of every last bullet point rushed into the last draft of the contract or scope may just lead to a valuable, expert team becoming so overwhelmed that your aim of getting the perfect system may result in you getting nothing. Or worse still, a vendor that provides a system that looks great until its put into practice (cos those little features and design points you bullied them into were actually meaningless or of minimal value). Finally you could end up with a system that is functional, but nobody wants to go near it, in-house or external, because its tainted with bad-project vibe.

So, when you find that you just need to persevere a little more (beyond the 70 hours a week you already are), or need to shout at the vendor beyond the point that its fair sport, its possibly time to stop, put down your tools, and do the hardest thing of all. Start thinking about what you can change, and what you can ask the client or vendor to be changed, to get the project back on track.

A post from the Improving It blog

Download the podcast of this blog post

No comments: