Introducing Mobile Museum

I’m ramping up to launch a sister site to this one. It’s called Mobile Museum and will be a series of semi-structured written interviews with people who have developed, authored or project-managed mobile solutions. Some of these people will be museum people, others won’t…

If you’re interested you can find out more over on where there’s a link to a signup form. Expected launch date – end September 2011.

The problem with process

This blog post has been lurking as an idea in my drafts folder for a long time, waiting for me to write something about the issues of “enterprise” and “lightweight”. 

If you haven’t gathered it already you’re either new here or have been seriously thick skinned when I’ve ranted on about why I think IT is crap and what we need to do about that. In a nutshell: IT should help people. It usually hinders them. We should try harder. 

That’s the general thrust of what is actually a very straightforward argument. I seem to spend far too much of my time looking at failed potential and not enough looking at astonishing goodness.

From this you’d probably gather – and you’d be mainly right – that I understand, and have much more time for, “lightweight” than I do “enterprise”. I think you can get closer – much closer – to the true horizon of “good IT” with rapid, lightweight approaches than you ever can with heavy, expensive ones. 

More process, please

Process hell. Thanks johnbullas / Flickr (click for bigger)

I do, however, also understand the need for control, for backups and safety, for security. The problem I have is that so, so often these processes are over-specified. And the problem with over-specification is that it flies in the face of the way we normally go about our lives.

It’s much more natural for us to turn to the person next door or call a friendly web guy and ask “is there any chance you could just…”. It’s what us social animals are good at – a bit of sharing, communal back-scratching, wheeling and dealing. Look at specifications. The fact is, no one knows how the damn thing is going to work, so how the hell are is anyone going to write it down on week one of the project? Project Management is a similar veil we draw into the process mix and pretend is useful, but find me one person who can accurately forecast their time on a task, and I’ll show you a liar.

This is how we end up tied into a sterile, personality-free wasteland where every item has to be built into a specification or you have to raise a ticket with a “service desk” (generally an oxymoron, IMO) to get, say, Google Analytics code pasted into the footer of your website or redirect a URL.

The problem is: this isn’t how people do things. That’s why it bugs the shit out of every poor sucker who gets tied up in it.

Here’s the question: why can’t we ring the guy up? Why can’t we call in favours, buy the dev a pint, tell him we’ll help him out with some CSS he’s struggling with? This is the way, after all, that most business gets done – someone you know puts in a good word for a friend of yours, he does you a favour, you remember it the next time around. I’m not suggesting that goes too far – there’s a horrific cronyism at the other end of the scale – but I’m just unsure how anyone gets anything creative or effective done when there is no personality in the system. The reason we can’t do this (usually) is that there’s another process (“change control”) underneath. And under that, somewhere, hiding in the dark, is fear

Mitigating risk is one thing. Being over-cautious is quite another. It’s also a rapidly shrinking spiral where your systems and processes begin to close down on each other because of fear that “things might go wrong”. Lock it down, prevent the changes, project manage it to death. Kill the project before – gasp – something goes awry.

I think “lightweight” consistently shows that creativity can only come out of flexibility. I also believe that this can – with some creative, human thinking – be translated into “the enterprise”. Maybe I’m naive. Maybe it isn’t turtles all the way down, but Process.

I hope not.