Jiri’s Notepad

Are people more important in than process? This is a great topic, one on which I spent quite some time.

Where’s demand?

I would probably start with the observation that market for process consulting is bigger than that for people consulting. One of the reasons for this is the fact that process is a better subject to talk about with most IT professionals than people. Most IT people tend to prefer solving ‘hard’ rather than ’soft’ problems problems, which is quite understandable considering most of us tend to spent most of the time dealing with systems and structural aspects of management. People who deal with skills, staff, values or strategy are in distinct minority in most IT organisations.

Apart from that, the process can be influenced or changed from the low to middle management level (at which most architects or PMs are operating) but personnel decisions (especially employment-related) are often handled a level up in the hierarchy.

This means that if you are trying to convince your boss or a potential customer about whether she should spend time working on people strategy or process improvement, chances are they will go for the former. This implies a bigger market for process consulting, which in turn means more pages / weblogs are written on this subject.

Scale and process

I find people aspects more enjoyable but there is one real underlying reason why companies need some process. Lack of process can work, when the IT organisation / project is small and all people involved are hand-picked and highly motivated.

It would be great if all our employers had as strict hiring criteria as Joel Spolsky, but there are probably few situations in which the strict hiring criteria are pushed aside. One of them is the need for quick growth. When organisation/project grows, you tend to lose direct control over personnel selection. My guess is that is that you can have direct control as long as the project is mid size (which in my definition would be below 100-150 people). Above that size you need to delegate, which gives space for bad apples to turn up. If you need to grow too quickly, you may be forced to compromise. So you end up with a some people who are brilliant and some, well, less than desirable.

Which is the moment when process comes handy. On its own, it does not assure you will produce fantastic results, but at least it will protect you against the most blatant mistakes. That is why if I had to chose one over the other, I would go for people over process. (You can achieve great things with fantastic people and no formal process. If you have fantastic process and a bunch of mediocre people, the results will always be mediocre.)

As an aside, most mid-size and large projects I’ve seen use some version of the ‘chief surgeon’ model. The way it works in practice is as follows: A small core team of smart, dedicated and motivated people, who have a liberty of dictating or bending the process, part from responsibility for the solution and its delivery.  Then there is a majority of others, who have  some degree of competence in their own area, but in general follow the high level process. It may look pessimistic, but as it is not that easy to hire only the best, the statistics will ensure you get a representative sample of general population and you will have to deal with it somehow.

So to sum this up: you do need some process. The bigger the organisation or project, the more important it is. At the same time, process for the process’ sake is nonsense. This applies to both solution delivery and EA.

Fortunately in real world I don’t have to chose one over another but a little bit of both. So the really pertinent questions to me sound a bit more like this:

1. What type and numbers of people do you need to be successful?
2. How should you approach recruitment and personal selection?
3. How will you ensure that all the fantastic people you hired do not make your solution delivery too expensive?
4. What mix of people and process will allow you to spend more on real innovation and less on business as usual?
5. What is the right level of rigour in process; one which aids your people rather than hinders?
6. What is the practical granularity of the process that will allow you to measure productivity (where productivity matters)