Would you like some process with that project, sir?

I work in software development, where process is a hotly-debated topic (some think there should be little, some a lot, some think it should be of this type, some of that). Some people can’t even spot a process when it’s staring them in the face, and, to be fair, the definition of processes is not exactly cast in stone.

Scott Berkun understands processes well. He makes an accurate analogy between a good process and the white lines separating lanes on a highway: they restrict the (intended) movement of vehicles, but help everyone to travel faster and more safely. They don’t intrude, they help. Perhaps a slightly more tenuous extension of this analogy to bad processes would be where the lines are constantly shifting about or the lane schemes being re-arranged, in an attempt to improve matters, but actually confusing everyone and slowing them down.

So the important thing to understand is that more process is not necessarily bad, more bad processes are bad (for example, in software products of any significant size, some level of source control is a good thing - but awkward source control will annoy people and encourage them to find ways round it). Over lunch I was listening to some colleagues talking about process, and I came to an important conclusion:

• People whose sole job is to invent and maintain processes will almost certainly come up with bad ones.

This is because they have no motivation to help, only a motivation to keep their job going, and that means more process (and probably ill-thought-through process). Processes should, with some minor exceptions, be invented with participation from those they affect, as they have a motivation to get it right. If there isn’t a strong enough motivation for them to help come up with a process, they obviously aren’t being bothered enough by the status quo and the process probably isn’t necessary.