h1

The Problem with People and Process

January 6, 2011

Regularly, I am confronted with badly implemented processes, processes that focus on explanation, clarification, demonstration and documentation. Somehow, the impression that appears to come out of models such as CMMI, ITIL, etc is one that is justifiable when working with public services, such as the US Department of Defense (who commissions the CMMI) and other government bodies. But, when working in a different context, such as that of a private company seeking to offer rapid service to customers, the approach needs to be considered in light of the people, not the standard.

People working in creative, intellectual jobs, such as the ones we are considering when performing this kind of model based improvements are selected based on their intelligence and ability to perform the work with minimal supervision. Yet, when we start talking process improvement, management appears to lose all confidence in their staff and require them to create mountains of documents justifying every choice made. With a little experience, any professional can start identifying the “right” solution or approach to problems based on instinct and very little information. When allowed to do its work, the human subconscious can process information we do not consciously think about and identify what is the most appropriate reaction. This can be demonstrated very simply by catching a ball.

When forcing the documentation and explanations about the rationale of the choices, we tend to have a lot more difficulty. For instance, if I was to ask you to describe how you caught the ball, what measurements you took, how did you calculate velocity and parabola, how did you estimate the position at which the flying ball was at a future moment in time, how you determined which hand would be most appropriate to catch and what instructions you gave to muscles and sinews in order to place your hand at the right place… Suddenly this all breaks down. When catching a ball, you trust your subconscious to do the calculations. Most of the work performed is right-brained: visual and graphic; when asked to describe how you caught it, even if you do understand the mathematics involved, you are forcing the instinctive reaction into the left-brain, where the language centres are found. The result is that not only do you take ten times as long to explain what you did, but you probably will not be able to do it while thinking.

The same is true in engineering work. We make a number of instinctive decisions and choices. These choices are largely dependent on our state of mind and our abilities. If you make the choice in the wrong context, you may make a choice based on incomplete data or based on prejudice. A significant number of experiments have been made in which the mental status of a person has been changed by the context, making people act in different ways. There are even a number of people who make a living out of forcing people to choose a pre-determined answer to a question – this is a popular stage trick in which the performed “reads the mind” of a spectator, when in fact the spectator was subonsciously prompted to make the predetermined choice.

A similar phenomenon is true in the world of business. The focus of the “process improvement” effort should be to create an environment in which the people doing the work are encouraged and management can trust them to do the right thing. In fact, the opposite is frequently the result: management puts in place procedures and documentation which demonstrate their lack of trust in people, then bombard them with requirements to do tasks that do not help in the actual work, creating a bureaucracy that slows people down and demotivates them.

By focusing on the right things, we can make the people doing the work make the right decisons. By creating top-heavy bureaucratic processes we only kill off staff motivation, and therefore negatively impact productivity and quality.

6 comments

  1. Hi Peter,

    I understand your point of view. I do agree that often, the people aspect is indeed given too little emphasis when trying to improve organisational maturity.

    However, the situations you describe is in my experience often a result of a poor process improvement approach. Rather than improving bottom-up, starting from how people actually work on the floor and gradually distill incremental improvements, organisations try to impose big chunks of improvement top-down.

    This type of top-down improvement is very often a result of management not showing enough authentic interest in the topic of “process improvement”. They engage in a process improvement initiative for reasons like: because some good people in the company have been asking for it for a long time, or because they really have problems surviving, or because our competitors are doing it, or because it will be great to have this certificate, …

    And of course, they don’t want to spend too much money on it, it should not disturb our ongoing business and it must show measurable benefits as soon as possible and … . As a result, they forget the people aspect, which eventually and certainly will lead to the failure of the PI programme.

    Unfortunately, this gives feed to the (many) people that have always been against process improvement; “you see, I always said this would not work here, and by the way, people are more important than processes anyhow!”

    Even though, after having been for many years in this business, having seen many poor process improvement initiatives, I still believe it can be done and I still believe it can benefit the organisation. But, in order to succeed, it is essential to give enough attention to the people aspect and most of all to avoid “model fundamentalism”!

    Nico


    • The improvement programme should not be top-down or bottom-up, but a combination of both. The management role, which needs to kick start the movement is to create a facilitating environment in which the people “doing the real work” can initiate the improvements that generate the change. The top-down approach typically means enforcing a bureaucratic approach created by theoreticians, while the bottom-up approach will rapidly get derailed by contradictory expectations or demands from management.


  2. Fully support this article! Process improvement is not about dictating processes, but about creating an environment and organizational setting where trained professionals can do their work efficiently. And to provide feedback on what works good, and what could be improved; providing the professionals with the means to continuously improve their skills.

    We call it process improvement, but it is all about people!


  3. Today we seem to be sitting on a swinging pendulum: “process is the leverage point” (CMMI) -swing-> “people over process” (Agile manifesto) -swing-> back to Deming and SPC again (Kanban for software engineering).

    The pendulum will keep swinging as long as we think about this in terms of motherhood and apple pie statements. Nobody can object the fact that “good” processes must bring out the best in people … what else …; and that people need “good” processes to be at their best … of course … To make a step forward in this discussion we need a better understanding of what “good” process really means in this context.

    Some suggestions:

    * Dealing with conflicting/contradictory business requirements: in a complex environment we can not expect that all goals are unambiguous and independent. We need processes that can cope with conflicting goals. The kanban for software engineering community is – to my opinion – setting an example here.

    * Putting projects central: there is no one-size-fits-all process; projects can be very, very different and thus have different process requirements. It would be nice to see that, as a community, we exhibit the same enthousiasm in discussing project differences as we exhibit in discussing model differences. Dave Snowden’s Cynefin model has laid the foundations for this discussion.

    * End-to-end perspective: A chain is as strong as its weakest link. In most projects most of the time the weakest link is the communication between those that want the product and those that are asked to develop it. So we need processes for delivery as well as discovery and be fully aware of the fundamental difference between the two.

    So, yes, there is a better way to design and manage work (to quote John Seddon) … but the current problems cannot be managed away within the prevailing view.
    The key words of the new paradigm may well be lean, adaptive, end-to-end.


    • The problem with pendulums is that they swing between extremes. The focus needs to be clearly on having processes that support and are supported by the people. This is unfortunately rarely the case, possibly because we live in a culture that seeks maximum rewards with minimum investment. The concept of “implementing CMMI” is the engineering equivalent of living on credit.


  4. I am not sure that i agree about the point that the cause is that we live in a culture that seeks max reward with min investment. I think it is just damn hard.
    The kanban (for software and systems engineering) community has choosen resolutely for a bottom-up approach for improvement. It does not start with a big appraisal upfront telling how big the gap is in the current process. Noop, it starts with the current process and gives the instruments to incrementally improve it (by means of WIP limits, visualisation of the work, control charts, …). Why? Because its about people. People that do the work also own the process and improve it. People resist big changes. People are not likely to be motivated when they are told that their way of working is wrong.
    CMMI as it is positioned today is heavily biased towards top-down improvement. If not in theory, then at least in most practice today. CMMI based improvements are initiated by management, goals are set by management, policies are defined by management (or worse, some proxy of management), …
    Both the kanban-style bottom-up and cmmi-style top-down improvement have value. Its damn hard to combine, and avoid the “implementing cmmi” or “cmmi window dressing for kanban” trap.

    BTW. Do not misunderstand, ii am a big believer in the kanban-cmmi combo.



Leave a reply to Peter Leeson Cancel reply