Can Do considered harmful

I come from a family of pessimists, but I think I got off lightly… I’m just slightly on the ‘doom and gloom’ side of centre. I expect this probably accounts for my attitude to risk. I assume bad things will happen. I want to know what the worst case scenario is. I ask difficult questions in meetings. Just be thankful that you don’t end up in a meeting room discussing your project with my sister…

It amazes me that so many software development efforts go about their business assuming that everything will be just fine: Pick a date from thin air? Don’t worry, we’ll probably hit it. Use a new, untried, technology on an important project? No worries and it’ll be fun! Pile pressure on to your employees? That’s OK, they won’t leave. Select your programmers without really understanding what it is that they do or how good they are? They’ll pick it up, and they’ll be writing code while they do… All of these things are fine if you accept the risks involved. To just ignore any potential downside is simply delusional. That may be fine for you, personally, but it’s a disaster for your project.

I’m not a “Can Do” guy. I ask too many questions. I’d much rather spend time discussing why you require something done than simply jump up, salute and dive into a coding frenzy. Perhaps our discussion might discover what’s really required is something slightly different. Maybe we can’t hit your deadline with full functionality, but we can deliver slightly earlier with reduced functionality and then incrementally deliver the rest in the order that it’s most important to you…Too often “Can Do” means “Can’t Be Bothered To Think About It So I’ll Just Say Yes”.

I’d rather upset you early on than keep you happy right up until the day I fail to deliver your software on time. I’ll upset you by asking questions that you might not know the answers to: Why is that date so important to you? If we give you this and this, but not that, is the solution still valuable to you? Are you aware that doing this or that will increase the risk of us not delivering on time?

I find this approach works well. I often come away from these initial meetings leaving you less happy than you’d hoped to be. After all, I’ve just pointed out that we’ll never hit your date, the design you suggested will never fly, and that using technology X rather than technology Y might reduce risk, or whatever… It’s unfortunate that you’re less happy than you could be, but it’s good that hopefully you now have a more realistic idea of what needs to be done to solve your problem. I’ve started our relationship by being truthful and open. If you don’t like what they hear then I’m quite happy for you to walk away and find someone who will tell you what you want to hear. And you can even come crying back to me when it doesn’t work out…

What I find is that as the project moves on (and it invariably does, I’ve yet to have a client actually walk away after I’ve shattered their dreams) the honesty and openness remains. If we’re going to miss a project milestone then I want that flagged up early on. As soon as we think there is a risk. I’d rather we were 2 days late on a milestone after raising the possibility of being 3 days late 2 weeks ago than just fail to deliver and surprise you. As we deliver quality software on time you start to believe. You believe that if I say we’ll slip a week then I actually believe that it will be a week: I’m not just saying it’s a week because I know you won’t allow me to say it’s a month… As long as you believe then the risks don’t seem too scary and we can talk about them.

Unfortunately it’s hard to do this in some organisations. After an abundance of “Can Do” types regularly promising the moon on a stick and failing to deliver even the stick on time, project sponsors are severely lacking in trust. What’s strange is that these places keep going back for more of the same; they obviously didn’t push people hard enough last time… Even investment banks, where the core business is risk management, seem to be nervous to face up to an honest approach to project risk.

It doesn’t have to be this way… Don’t shoot the “No Can Do” messenger. Accept your risks and work with them.