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

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.

14 thoughts on “The problem with process”

  1. It’s always a balance I feel. Too much process and it stifles everybody but the process people; too little and things get missed and messed up. What many parts of some organisations process need to be replaced with is a quality culture. Testing does matter, great user documentation should always be written as you go along and you should always check-in your changes before you depart for three weeks on holiday.

    I guess you are right in your view that ‘enterprise’ needs to become more light weight and more focused on creating the right environment for good practises to flourish.

  2. Great point, especially about the balance between process and culture.

    I guess we’ve all been bitten by lack of documentation, unsynced changes and so on. I always wonder though (and I’m not sure many organisations measure this) how these problems stack up in terms of time and effort next to the stifling bureaucracy that is often used to mitigate them.

  3. @Tim – great links, thanks. I think where I’ve seen the biggest problems are when it isn’t just the dev team who control the process. Often, they’re the most flexible and open to new ways of working. It’s the Prince2 PM’s, the managers and the board who become the blockers. Then the devs live in fear of not following The Process.

  4. Mike, most of the time when this happens I get the feeling that it’s about people at the top (who aren’t directly involved) not wanting to relinquish control, either because they need to cover their backs, worry about money, or answer to someone else higher up who knows even less about the project. The problem is that so many things are set up this way. Smaller organisations have a lot more flexibility in the way they run things, which is why sometimes you can have a person-to-person conversation instead of raising a ticket. Too bad it doesn’t always work that way, but big projects = big money = big chances to go wrong = impersonal, inflexible juggernaut.

  5. I completely and utterly agree with you all the way. The thing is it ain’t gonna change – ever (or at least not in yours or my life time).

    Having started networking with my local geek community in my own time I have begun to experience extreme cognitive dissonance between what I experience in the corporate sphere vs what happens outside in the socially and creatively driven developer community.

    Needless to say I have decided that I want out of big the organisations. They are personally and professionally stifling. And, as you say, rarely if ever make good IT.

  6. @Nadia – absolutely. I guess my BHAG is to find ways to challenge the status quo. You’re 100% right, but why? And what can we do to change it? For starters, does stuff *have* to be as big as it is?

    I’m particularly interested in this at the moment as I’ve just co-authored a paper for the 2009 Museums and the Web conference which challenges the institutional/big/bottom-up/juggernaut by suggesting a lightweight approach to something that has always traditionally been painful and big. I’ll blog about it when the paper has been published…

    @DPEITCS – I’d like to think we can change it, probably by stealth and maybe by embarrassing the funders by demonstrating that small (and usually is) more beautiful than big… Shame you’re off out. This is gonna be interesting 😉

  7. It would be great if we could demonstrate that stuff doesn’t have to be big – I think changing the traditional approach will require us to go through layers and layers of institutional policy and will take quite a while. I’m glad, though, that it’s being challenged! Looking forward to reading the paper.

  8. I do agree with you on this entirely. Until this moment, I had a residual sense of utter professional failure because I had so often failed to get specifications or a project schedule completely accurate before the real work had got underway. Ironic because we specialise in helping cultural organisations to scope new projects before they begin. What we do, though, is to ensure clarity of vision and purpose, and propose an iterative process to check that you are meeting real needs.

  9. @Bridget – glad it rang true with you..

    I think your line about spending less time chasing specification and more time looking for a solid strategy and vision is absolutely right and makes sense on many different levels, from creative to user experience..

  10. Hi,

    I came across this discusison and found it interesting. I’ve been trying to think of what is good and bad about having process and how it should ultimately be adaptable to fit the organisation to meet their goals. I’m coming at this from an IT perspective as many other contributors have so I’m interested in re-opening the discussion if anyone’s interested, it has been a while.
    My view is that process is a good thing and generally speaking your friend so long a it is applied appropriately. I also find using an iterative approach is the best way to keep a project progressing and more likely to succeed. All of these technique can be wrapped into a process whether it be lightweight of bureacratic.

    Get back to me to discuss further…

  11. very well said. I see this particularly in information security field where i work where there is a constant tug-and-pull between Risk vs Compliance. (The compliance part being heavy on process). This equates to the cost of doing business vs protecting the information assets, and when you have too much compliance (process) i see it detrimental to both the business and information security, because to achieve perfect state (unfeasible) you need infinite capital expenditure. Trying to achieve this state by tying down the business in process is a common problem in an organization that claims it understands risk management but really doesn’t.


Leave a comment