Computerworld - As an IT management consultant, I look at a lot of processes. They're everywhere. And so are the misconceptions about what makes them useful.
Through the years that I've been in IT, process has become the
default solution for most technical management problems. Projects failing? We need a new process. Trouble prioritizing work? A new process will solve that. Bad relationship with users and customers? You guessed it: It's all in the process.
I think that our attraction to processes is natural. They feel familiar, and a good process shares many of the virtues of good technical solutions. A good process, much like good code, effectively resolves seemingly complex problems with conceptually simple solutions. There's an element of deterministic instruction. A good process is not just a random collection of good ideas, but a step-by-step approach that provides actionable instructions. All the common issues and options are anticipated, and specific instructions are available. And a good process looks like code, providing guidance on what should be done, by whom and when.
But the similarities between code and process can also lead us astray.
Code is executed by machines, which have no feelings about the tasks they carry out. They have no aspirations, resentments, anger, pride or ambition. A 386 does not envy a quad-core.
Code branches on computable facts, whereas processes must account for subjective experience. No matter how complex the calculation, the decisions about which steps code executes are derived from data. That's true to an extent for processes, but more subjective measures related to the feelings of the people involved also come into play. At some point, facts are not enough.
Code does not care about stakeholders. Processes need to account for the complexity of human politics and relationships. Successfully completing most processes requires building consensus among stakeholders, anticipating and overcoming resistance, and managing expectations.
So whenever I am asked to review a process in order to try to repair or replace it, there are a few key questions I ask about it. They all boil down to different aspects of the fact that processes are designed for humans and not machines.
Obviously, the first question is, will it lead to the desired outcome? No matter how well a process handles humans, if it doesn't manage the work, it's worthless.
Next, how does it balance competing goals? All work is subject to competing demands. Time, scope, cost and quality are the classic foursome. Rigid processes ignore this constant balancing act or presume permanent solutions. Fragile processes place the balancing in the hands of a single individual, usually a sponsor or manager. More robust processes build dynamic balancing among stakeholders into the procedure itself.
Third, does it account for the human needs of the people executing it? Since work is done by people, processes that guide work allocation need to account for the variability in the emotional and personal needs of people.
Fourth, how does it anticipate and channel political concerns? Various stakeholders always have divergent views and emotions. Fragile processes disregard this. Robust ones reflect the likelihood of coalition-building and irrationality.
Remember, an effective process is designed for human usability.
Paul Glen is a consultant who helps technical organizations improve productivity through leadership, and the author of the award-winning book Leading Geeks (Jossey-Bass, 2003). You can contact him at info@paulglen.com.
Read more about Management and Careers in Computerworld's Management and Careers Topic Center.
Free Insider Guide
How does your salary compare with your peers? Find out using our Smart Salary Tool.
Copyright © 1994 - 2012 Computerworld Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of Computerworld Inc. is prohibited. Computerworld and Computerworld.com and the respective logos are trademarks of International Data Group Inc.
