Have you ever been to one of those project management seminars where they preach about the virtues of the latest methodology? You know, the ones where they have extremely expensive consulting services and specially built software to sell to you? I just finished watching an exhaustive set of web-casts from various vendors, so I feel like I went to six of them in one day. An aspirin is definitely in order.
I understand these things are, at their heart, sale's pitches. However, I sometimes wish they would just admit that things like iterative projects have simple, predictable results which occur regardless of how they tart up the management products. After all, the fundamental change occurs not in the reporting product but in the thought cycles surrounding the changes we want to make.
What does that mean? Let's take a quick look at something fundamental to many project management methodologies these days – the “iteration”. No matter how many artifacts we pile into it, how much we write about how to accurately predict how long the activities will take, or how we negotiate around all of the risks, an iteration basically boils down to the following statement:
“Every X weeks we will deliver something tangible to the customer.”
Figuring out exactly what to deliver can look a lot like a full time job However, this is a case where the what actually matters a good deal less than the when. You see, imposing iterations changes the following cycles of thought and communication surrounding delivery:
1) The Panic Cycle
People panic. It's kind of what we do. However, panic is a cycle, related in part to the gravity of the problem we face and in part to the difficulty we feel we will have getting the solution into production. Moving to an iterative approach short circuits the panic cycle by making it clear when work will be moved into production, and establishing understandable boundaries around problem conditions.
I saw this in action at one client. They had the typical mess of developers moving code into production every day, with all the resulting instability associated with it. The clients were constantly panicked, worrying when the IT team would get to resolve their latest issue. I instituted a two-week iteration cycle and, almost like magic, things died down to a dull roar. The client stopped pushing for resolutions “now” and started to ask whether we could get something into “this release cycle, or will it have to wait for the next one?”.
2) The Priority Cycle
No one likes to admit priority exists. Everyone says “it's all the number one priority, and it all needs to be done right now”. Let's just ignore resource constraints, physics, and psychology for a few moments. However, as soon as we have established, continuous release cycles, people almost immediately start clamoring for some kind of realistic ordering. They also know that if they miss the first date, there's another one they can shoot for. It becomes, in a way, a chess game where people negotiate and trade their activities and needs for the good of the business.
Huh. Negotiation and trade in modern business management. Who would have thought that could happen?
3) The “Want” Cycle
It's almost axiomatic that clients want it all and they want it now. The only big difference in client types is cost – internal clients want it all now, external clients want it all now for free. They clamor and shout for everything, constantly pushing established boundaries. It's a lot, in fact, like living with two-year olds.
Instituting an iterative release cycle, no matter how you dress it up, can throw oil on these troubled waters. So long as you deliver something, on time, every time, people feel like there is positive forward motion. That sensation of movement allows them to relax a little, or at least focus on something else which causes them trouble.
I could write this into an in-depth analysis if anyone were interested. To be honest, though, a lot of project management works like this – simple concepts and simple techniques made expensive by consultancies who depend on complexity for a living.