Here’s a cycle I’ve observed many times in my career. Frankly, I’ve gone round and round this thing many times as I try to apply successful patterns/approaches to broader problems than they were initially used.
Incidentally, there are no arrows on this cycle because Apple’s KeyNotes software can’t draw curved arrows. Aargh. I’m going to have to break down and buy office on the mac, or learn more about OpenOffice. Sigh. At any rate, the cycle moves clockwise.
This cycle is really the application of Virginia Satir’s model for change to the problem of how processes evolve.
I made this up yesterday as I contemplated the usefulness of process in the context of software development. I’ve really lost faith in the idea of the repeatable development process, an idea that seems to be the holy grail of many IT professionals. Is it myth? I think so. I don’t believe process can do much, if anything, to guarantee a development project will be a success. That’s like saying anyone can invent flight by following a certain process, or discover the so-called Northwest Passage using another defined process. It doesn’t make sense. Process can help you keep track of financial expenditures, staff allocation, other peripheral (but important) aspects of a project, but it can’t guarantee success. And heavyweight processes often guarantee failure because they put an unmanageable burden on project participants.
I believe there is an irrational association between project success and process adherence on the part of many IT professionals and pundits. I don’t see a correlation, and I’ve been on lots of projects in the past ten years. In fact, the successful projects I’ve been on were usually not encumbered by stringent processes. Instead, they were comprised of smart, motivated people who were flying by the seat of their pants. I don’t mean they were just making it up as they went along. Quite the opposite. They always had a plan, and they revisited it constantly, sometimes everyday. They were focused on making progress, getting rid of obstacles, and adjusting plans to use resources as effectively as possible. They were planning every day – but not for long. Brief, daily planning coupled with focused activity toward an immediate goal is the only “process” I feel comfortable with today.
Even then, I want to bring up a point. I don’t necessarily believe this process will guarantee project success either – no process could have helped Lewis & Clark find a Northwest Passage, because there isn’t one. Some things are impossible, and process, even lightweight ones, won’t make it possible.
IT is one of the few places where process has such a religious ardor to it. Contrast the way many IT pros feel about process with the way scientists feel about the scientific method, for example. Do researchers believe the scientific method GUARANTEES they will be successful at finding a cure for cancer? Heck no. They believe the scientific method will help ensure that whatever they learn through research and experimentation is credible and authentic. But they can still fail, and usually do.
So, where does process really belong? I think it belongs on the sidelines. It should be tools we use to ensure certain aspects of project management are done properly (like tracking finances, billing customers, and selecting vendors). It doesn’t belong in the driver’s seat. It shouldn’t show up in a project plan template as defined phases or activities. It won’t help you get wherever you are going. Put a smart PERSON in the driver’s seat, and let them find the way from where you are to where you want to be. It’s the only way to get there, because process will never get you there on its own.