Use this outline when creating a Project Management methodology

Don't waste your time and resources putting together a massive methodology template that no one will ever read. Here are some tips for creating a meaningful methodology.

In his column of July 30, Project management methodology is more than just documentation, Shannon Kalvar discussed the problems IT pros have in generating organizational methodologies (which are, basically, documents describing why we do what we do). He wrote from personal experience—he'd once been asked to create a methodology for his consulting company so that they "wouldn't just run forward forever, trusting luck and the good intentions of the crew."

What he ended up creating was an enormous document that contained a massive set of templates and forms that no one read. Having learned from that lesson, Kalvar wrote, "The problem doesn't rest with the quality of thought put into those documents. Nor, for that matter, does it reside in their volume. Instead, it originates in the junction between theory and application that leaves so many of us uncomfortable… the deliverables and processes that we focus on are not the methodology. Instead they are the products of the methodology, what we create to turn the world of theory into something practical."

He decided that methodology acts as a guide, but must be applied through developed process and (later or concurrently) procedure to specific situations.

The next time he was asked to create a methodology, his crew again produced reams of pages with diagrams and charts. This time, though, they stepped back to plan out what they were really trying to accomplish. The result was a one-page document that carried the organization's goals and statements of method, followed by a four-page explanation of the principles and further elaborations that would help other people recreate the process by which they derived the documentation.

"The resulting methodology was easily understood and explained by our sales force. It also moved into the operations side of the business, creating a shared language among multiple groups who traditionally had difficulty communicating," Kalvar said.

Many members posted comments after the article asking for examples of the kind of methodology he was talking about. Could he show them where to start on creating such a methodology? Could he provide a template?

Though Kalvar believes that "the best template is not using one at all," he provided a short outline that you can use to get started.

Here's the outline for a one-page document:

Title of process

First sentence: Briefly tell what the process is for.

Second sentence: Briefly tell who the process applies to and when the process is used.

Rest of the document (5-10 sentences) This is a description of the process, in plain English, either as a bulleted list of steps, or spelled out in sentences. It does not need to include a bunch of contingencies—just a basic outline of the process.

Here's a quick example:

Standard QA process

This process shows how bugs are transferred between user groups as they get resolved. QA finds the bugs, developers fix the bugs, and QA confirms that the bugs are fixed.
  • QA finds a bug in the software and documents it in their tracking program as a bug report.
  • QA e-mails the bug report to the developer responsible for that area of the software.
  • The developer receives and reviews the bugs. If he finds it faulty, he returns it to QA for further explanation. Otherwise, he marks it as in progress.
  • The developer fixes the bug in the software and checks it back in to the source.
  • The developer marks the bug report resolved and e-mails it to QA.
  • QA checks the build to see if the bug is resolved.
  • QA marks the bug report fixed and closes it.

This is a brief methodology. Keep in mind that the process document would have this information, plus the contingencies and key definitions and options, spelled out in a few pages. The full procedure will have instructions on how to write the bug report, full lists of different options with each option's definitions (such as severity levels), response times, and evaluation factors, as needed.

This outline will make the creation of methodologies a simpler process for you.

About Toni Bowers

Toni Bowers is Managing Editor of TechRepublic and is the award-winning blogger of the Career Management blog. She has edited newsletters, books, and web sites pertaining to software, IT career, and IT management issues.

Editor's Picks

Free Newsletters, In your Inbox