Large corporations, like the one I work for, tend to desire defining heavy project methodologies. Although a heavy methodology (when followed) leads to consistency, it's tedious to follow and dictates many steps which are often not applicable to the project they're being applied to. Furthermore, these drawbacks lead developers to ignore almost all aspects of them except for the minimum tenants necessary to keep the PMs happy. In other words, they often result in adding little appreciable value to the client since most of the documents that a heavy methodology calls for become obsolete almost as soon as they're written and the methodology ends up adding a lot of unproductive time to the overall schedule. Conversely, having no methodology at all leads to almost no consistency and often leads to many critical aspects of project management being only lightly addressed or skipped over altogether.
So the question remains, what level of project methodology definition is appropriate? Influential aspects to answering this question include: will the methodology be applied to a group, department, division or the entire company; what degree of auditing is required to be met (CMMI, ISO, internal auditing); and finally, what is really trying to be accomplished by defining the methodology in the first place?
It's obvious to state, but if the methodology is going to be applied to a small group, then it may be very specific; while if it will be applied to an entire company, it needs to be very flexible. But the problem with being too flexible and generic is that it doesn't really present a useful methodology at all. On the other hand, a methodology that's too specific will only lead to incompatibilities when applied to another project. And with respect to auditing, the methodology may require useless documentation simply to meet the needs of the auditors. (This is a painful reality that regularly needs to be addressed in larger corporations.) But the most important aspect of defining a methodology is determining what the goal of defining the methodology is in the first place. Many methodologies are defined to the nth degree simply because the "suits" in a large corporation seem to be pacified with a feeling of confidence when presented with a 100+ page project methodology; even though it'll never be read by themselves or by the developers. (I don't mean to sound cynical; that's just seems to be a natural occurrence within large organizations.) If the primary goal is really to add value for the client (which it should be) and to deliver projects in the most efficient manner with an expected level of quality, then the defined methodology should be light, flexible, and tailored to the project at hand.
By light and flexible I mean that the methodology should de-emphasize documentation as much as reasonably possible and focus on delivering production-ready code early and often; furthermore, the methodology should be able to adapt to various situations without a lot of overhead. While "seeing the big picture" is very important, especially for those initial estimates and for keeping the overall scope of the project in mind, the defined methodology should also focus on determining the next highest priorities that will deliver immediate business value to the client. In this way, little time is spent defining lower priority requirements that may never be implemented. It also takes focus away from "bells and whistles" and puts attention more on what's most important to the client at the current time. I've never been on a project wherein the project delivered at the end exactly matched what the client described at the beginning. In every case, the project only took its appropriate shape after a number of very short, iterative cycles of prioritizing business needs, translating those needs into working code, and putting the product in front of people frequently.
But all this focus on only the next highest priorities and short iterations makes it more difficult to come up with a good estimate at the beginning of the project. On the other hand, putting too much time into "scope exploration" can actually lead to over fitting of the estimate and skew the estimate further from where it should actually be. There's certainly a delicate balance which needs to be met between forethought and acting in the present moment. Again, each project comes with its own requirements for this balance and needs to be considered on a case by case basis.
So should we abandon defining a methodology altogether? Absolutely not. But on the other hand, we need to define a methodology that's simple, that's applicable across many projects, that will provide true value to the client, and most importantly, that can/will be followed by the team. The best balance I've found is to educate developers on agile development practices and provide a number of very simple checklists that may be employed throughout the project life-cycle. By educating the developers, I imply making them read (yes, actually read) a book or two which discuss agile techniques. The intention is to expand the developer's methodology arsenal so that he/she will be better prepared to use various techniques for different types of projects. Some sample checklists include a project proposal checklist, a project kick-off checklist, a release planning checklist and an iteration meeting checklist - other checklists would most certainly find a place in the project life-cycle as well; but the key is to have only as many that add value to the client and to keep the checklists simple. For an example of usage, the project kick-off checklist would define how long iterations are, iteration and daily meeting times, critical project dates, key stakeholders, what checklists are applicable to the project, etc. For another example, the "iteration meeting checklist" would be physically brought to the planning meeting for each and every development iteration and would include items such as: Review what was completed last iteration, Determine what new requirements have been discovered, Prioritize and estimate items for the next iteration, Review risks for the current iteration, etc. The checklists would usually be one page or less and would simply make sure all the major tenants of project management are followed. Because of their simplicity, the checklists may be tailored to fit the needs of the project at hand. The point is, they're easy to follow (meaning they'll actually be followed), they don't emphasize a lot of documentation, they focus on the highest priorities, and they're light and flexible. Keep in mind that the checklists aren't meant to be permanent artifacts; they simply exist to make sure that critical project management practices are covered throughout the project. (More "permanent" artifacts such as project scope, critical success factors, risk analysis docs are outside the boundary of the checklists...but a checklist may be used to determine what types of permanent artifacts will be created and maintained. For the requirements themselves, a simple tool such as index cards and/or XPlanner are good options.)
A few books that explain all of this much better than I can (and should be read by both PMs and developers) include: Extreme Programming Explained, 2nd Ed. by Ken Beck (you don't have to follow XP to get a lot of value out of this book); Lean Software Development by Mary & Tom Poppendieck; and Agile Estimating and Planning by Mike Cohn.
I welcome your comments, experiences, and even rebuttals!
01-03-2007 6:18 PM