Methodologies versus Strategies

After running a series of successful projects, it is tempting to extract the success factors from those projects and declare them policies for future projects. This is a dangerous thing to do, for three reasons:

• We may have extracted the wrong "success" factor and might now be setting as policy something that was either incidental or even detrimental to the success of the project (which is what I suspect happened with waterfall development).

• Even if we extract the correct success factor for a given set of projects, there is no guarantee that that factor will be the success factor on the next project (see the discussion of balancing strategies on page 101).

• The project manager or the team on the ground in the situation is probably best suited to judge what is the best strategy to apply at any given moment.

Strategies that generated success on a small set of projects should not be cast as global process or methodology policies. Yet this is exactly what most people think methodologies are for.

A methodology is just the set of conventions that a group of people agrees to follow (less optimistically: the rules they are told to follow). These conventions can touch on any topic at all, from clothing to seating to programming to documentation to workflow.

The group's conventions are likely to shift over time. This is proper. And, as simply a set of conventions, it is quite possible that the group will never write down the full list of conventions.

At some point, someone may decide to write down a selected subset of the conventions to apply to other projects. At this point the methodology becomes a formula, a theoretical construction that abstracts projects and people. Necessarily, the people and the situations on the next project will be different.

Knowing all of this, the highly experienced leader may still decide to cast as policy selected conventions that usually work well or that are likely to work well for most projects as a way of training and guiding less experienced project teams. This is sensible as long as experienced leaders are around to tell when the conventions are a misfit to the situation at hand.

However, the experienced leader is likely to move on, leaving the organization with an outdated set of strategies hardening into corporate policies. At this point, the social conventions become ritualized procedures. The organization has a Shu type of description for a Ri class of activities, and, as Russ Rufer quipped, "One Shu doesn't fit all."

If project management policies, practices, and strategies do not belong in the methodology, where do they belong?

They belong in a strategy manual, a collection of project stories and strategies (see, for example, Appendix A of Surviving Object-Oriented Projects (Cockburn 1998) for a sampling of such strategies). The organization can use such a collection to train junior project managers and development teams. This training will highlight the strengths, weaknesses, and limitations of each strategy. The strategies, taken away from the process policy handbook, are placed where they belong, as part of the project management craft.

Project managers should be evaluated, in part, on how well they adjust their strategies to the situation.

It may seem to certain skeptical readers that the situation I am describing is unique to software development. It is not. In Simultaneous Management (Laufer 1997), which deals primarily with civil engineering projects, Laufer describes how project managers have to move from cost-prioritized to flexibility-prioritized strategies from one day to the next (and indeed, between any priorities that may arise). That book is good reading for project managers in any field.