Problems for projects; projects for problems

I don’t know a lot about what’s ‘under the hood’ of technology but I’m generally pretty good at driving. So why is my email still broken?

I’ve had a horror run of communication issues this year, and I will tell you, hand on heart, that none of it is my fault. For reasons I won’t go into, I have seven official work email addresses. I think there has only been one week where all of them have been working as they should.

It all started when one of them decided to move servers. Then, in a strange, coincidental succession, they all eventually migrated to bigger, better servers. My inbox hasn’t been the same since. I used to have beautiful colour-coded folders that would automatically receive mail for its given address. Now my life is a jumble of newsletters mixed with business correspondence, calendar invites clashing with spam. Emails have gone missing after I’ve read them, and deleted items in my archive seem to return like zombies after the apocalypse.

Of course I’ve complained about this. But IT doesn’t really know what I’m talking about: nothing is wrong. The settings are all correct and I’m able to send and receive emails, what’s the fuss? But IT doesn’t know what it used to be like; nothing is wrong but it is not all right either.

Then it struck me. The communication problem was not the one lurking in the account settings of my inbox but in the way I was presenting the issue to the people who could potentially fix it. It turns out that half the solution is knowing the problem. My inbox is recovering, albeit slowly.

How many times do you find that a project doesn’t know what ‘problem’ it is trying to fix? Real—as opposed to tokenistic—business cases are much rarer than they should be because too often someone hasn’t bothered to scope and define the problem. I’ve shown you my problem, what’s yours?