There is a lot of discussion about improved processes these days, including everything from
enterprise project management, development methodologies like ITIL and RUP,
project portfolio management. A colleague
complained once: "They are talking about creating a complicated, time consuming process involving spreadsheets and
GANTT charts that could all be done on the back of a cocktail napkin." This reminds one of some of the discussion in the chapter called
"A Culture Of Discipline" in Jim Collins' book
Good To Great:
Lewis's distinction between process and practice makes a lot of sense to me -- while an applications development team might work fine with the accountability framework described above, a group that is managing a 24x7 data center, will find that it makes a lot more sense to spend their creative energy developing replicable processes, not depending on good creative people to remember when they should make different types of backups or patch the servers.
As in most things, both distinctions are also a matter of degree -- some amount of process is almost always necessary and some greater amount is always too much. Process is not the cure for all ills: the overhead of process takes a bite out of an institutions' total available resources. The correct use of process is analagous to the correct use of models in software development -- as Martin Fowler noted: Models are not right or wrong; they are more or less useful." With responsibility for the lives of human beings hurtling through outer space at hundreds of miles an hour it's only logical that NASA's software assurance process is much more rigorous than the requirements for something like a university class enrollment system.
...the purpose of bureaucracy is to compensate for incompetence and lack of discipline -- a problem that largely goes away if you have the right people in the first place. Most companies build their bureaucratic rules to manage the small percentage of wrong people on the bus, which in turn drives away the right people on the bus, which then increases the percentage of wrong people on the bus, which increases the need for more bureaucracy to compensate for incompetence and lack of discipline, which further drives the right people away, and so forth. [p. 121]When weighing whether to lean towards a greater level of process or stressing the amount of discipline and competence, Bob Lewis has some insight in his Advice Line weblog, in which he compares a "practice" versus a "process":
'In a practice, the "well defined steps" constitute more of a toolkit to be used by the practitioner; in a process the steps are more rigidly followed. In a practice, the intelligence remains almost entirely with the practitioner; designers move as much intelligence as possible into processes.Sometimes within the context of higher ed administrative computing organizations, I've seen this corroborated. For example, the infrastructure folks heavily favor processes like maintaining fully resourced Microsoft Project plans, whereas, for an applications development team, I'd much rather establish a lightweight management infrastructure that has work decisions delegated to the lowest levels possible, with developers taking ownership of their project committments, using something like a sharepoint for documenting status and providing accountability.
If you like, bowling is more of a process, baseball is more of a practice.
Which works better and in what circumstances? My opinion, unsupported by any research I'm aware of but richly supported by my personal experience, is that business redesign and application support (integration, development, enhancement and maintenance) are more effectively managed as practices. IT operations (networks, production control and so forth) are more effectively managed as processes.'
Lewis's distinction between process and practice makes a lot of sense to me -- while an applications development team might work fine with the accountability framework described above, a group that is managing a 24x7 data center, will find that it makes a lot more sense to spend their creative energy developing replicable processes, not depending on good creative people to remember when they should make different types of backups or patch the servers.
As in most things, both distinctions are also a matter of degree -- some amount of process is almost always necessary and some greater amount is always too much. Process is not the cure for all ills: the overhead of process takes a bite out of an institutions' total available resources. The correct use of process is analagous to the correct use of models in software development -- as Martin Fowler noted: Models are not right or wrong; they are more or less useful." With responsibility for the lives of human beings hurtling through outer space at hundreds of miles an hour it's only logical that NASA's software assurance process is much more rigorous than the requirements for something like a university class enrollment system.
