People, Practices, Things

My original article People, Practices, Things is no longer available online on the original website. It is reproduced here. I later proposed an alternate model of Community, Activity, Environment.

“People Process Technology” is a popular mantra in IT and for good reason. In any IT implementation these are the three key aspects to consider, and efforts need to be balanced across the three. The author prefers the variation “People Practices Things”, but either way this is a model that does not get enough attention and gets even less implementation.

We are drawn to IT by a fascination with complex technology. This is unfortunate because it blinds many of us to the importance of the People/Practices/Things trilogy.

Reality is of course infinitely-dimensioned (speaking of concepts not physics). There are other similar models. The ITIL books have at least two others: “P4: People Process Product Partners” is a good one. Let us apply the Rule of Threes to simplify, and stick with PPT.


The order is important: People come first. IT folk too often start with the technology, occasionally start with the process, and seldom start with the people.

“People” covers mundane aspects like teamwork and having enough resource for an implementation project, and the more strategic issues of getting executive commitment and approval. Most of all it concerns cultural change. Culture means (in this sense) “how things are done around here; how we approach stuff”. Cultural change is about which behaviours and attitudes need to change and how to effect that change.

Equally important is to consider what cultural aspects cannot or should not change. Organisations have a unique character: often aspects of that character are what makes an organisation competitive or why people choose to work there. Culture in a broader sense intrudes. For example accountability and ownership of process are sometimes seen differently in other countries.

It is often said that we can’t modify staff attitudes, so make the behaviours change and the attitudes will follow. This is an effective approach. The easiest way to change behaviour is to pay people. Remember the Garfield Principle (I got it off a Garfield comic long ago): “Work is so bad you have to pay people to do it”. So change behaviour by linking change to payment. Next best is a variant: measure behaviour. Do so visibly. Preferably publish the results.

On the other hand, consider attitudinal change as well. De-motivated people can be stirred up, and misaligned people re-focused. The author’s technique is to make it personal: explain why they are at risk and what is in it for them to change. Some will get it; some won’t. For the ones who don’t, there are always the behavioural change techniques. Another way to rally people is to frame the changes in terms of the outcome: present the changes as the method to get to a common agreed goal. Training as brain-washing works too, especially multi-day intensive courses. As a last resort: if you can’t change the people, change the people.


Once we understand what will and won’t work culturally and what we need to do to get there, only then are we in a position to design and implement processes (unless of course you like doing it several times, or failing). There is no best practice, only generally agreed practice. So no definition of process is sacred; they all need to adapt to the receiving organisation.

The link between People and Practice is education. Rule of Threes again: inform, train, coach. Sending emails is not informing. One course without follow-up is not training. And why won’t IT departments coach? I think it is that IT machismo thing: “I never had any help. I just grabbed the manuals and jumped in. Think or thwim”. The cost and effort of setting up an effective coaching program will be one of the best investments a manager can make.

So Practice/Process comes after People. It follows naturally. It must be said that not everyone sees it this way: data design comes before coding; buy a tool and let it dictate the process; a good repository is the starting point; you can’t do anything until you have acquired some data. There is an interesting debate in IT between action-oriented thinking and object-oriented (we are talking more generally than the programming-related meanings here). Here is a crude linguistic test for process orientation or technology orientation: do they talk about verbs/actions or nouns/things?

The data/process, technology/process, objects/activities, nouns/verbs arguments are like the nature/nurture one: the reality is somewhere in the middle as both are important. I believe the culture of IT as the first decade of the millennium heads to a close is off-balance, object-centric. IT gets more complex and unstable every day and the solution is not to look at how we do things and the quality and culture of the people doing them. Oh no, it is to introduce yet more technology.


There is a place, well into the process design, when we identify opportunities for tools to help manage the process and in rare cases even help automate the process. Once we understand our people's capabilities and desires, once we understand exactly what we want the process to do, then yes we may build a solid business case to buy a tool.

The IT Skeptic maintains that most business issues IT addresses are process problems. If you have a process problem there is not a technology solution. If you are paunchy and aging, buying a red sports car does not fix the problem (though you may feel better about it). Technology works where it is a tool to assist people and support process, where it has been selected or designed to suit those processes and people, and where the people and process work with or without it. Technology makes people more efficient and processes more reliable. It seldom makes something possible that was impossible without it.

The reason the term “Things” is better than “Technology” is that the fixation is more general: with products, documentation, forms… all kinds of objects. You even find people treating process as a thing (stay with me here). To implement new practices you need to look at the people doing the implementation, and the process for implementing the process (the “meta-process”?), before you capture the process as a document.

Yet some projects start by designing the forms, then work out how the forms will function. Sometimes organisations do nothing but post a form and declare a new process is in place. It is the same old Things-first thinking. And they fail. The forms sit unused.

Likewise we see projects where the process was written up as a document and distributed, and that was the implementation. Once again, they fail. The documents gather dust. Look around: how many flowcharts hang on walls or sit on shared drives without having any instantiation in reality?

People Process Technology. People Practices Things. Whatever the model, please consider the culture first and the things last, and you will find implementations of new services, systems, practices and software go so much better.


premature technology selection

A great phrase for getting these in the wrong order: "premature technology selection"

(originally used in a slightly different context about "enterprise 2.0" (WTF that is) here)

Syndicate content