Writing best practice or process content from scratch can sometimes feel like writing a book. You have that blank page starring back at you, waiting, waiting. Oh, can't start now, gotta deal with this new fire. I'll get back to it later.

As mentioned in my previous blog, fires can easily keep you from figuring out how to avoid them in the first place.

At some point (hopefully), you will find time so here are some ideas.

1. First, try to find best practice content already defined. Think of it as chunks stored here or documented there. Working with existing deliverables is a great start. Let's say your whole process contains a dozen or so standard deliverable files. Open up the first file and review its parts. Each of these deliverable components can be turned into a process step. For example, a charter document could have a scope section.

2. Let's turn this into a process. Ask yourself what's the high-level stage for implementing this deliverable? Planning. What's the mid level process? Define Charter. What's the process step? Identify project scope. Now, you know where it belongs in the process schema.

3. Next is to write the details of the step. Ask yourself what is the best way to identify the project scope. This is the "gold" of your best practice. Start with a simple sentence. You can add more later.

4. Then ask what role is responsible for this step (i.e., project manager, business owner). You may expand that step or add steps to cover each role's responsibility.

5. Finally, your step will then refer to the physical file (charter.doc) and where to find it.

There you have it, from high level to detail level, covering process, people, and deliverables.

You can easily do the same with the other charter document components and then move on to your other deliverable files. I call this "reverse process decomposition" since you are starting with the end result.

Once you get the process covering your major deliverable documents, you can use it as is as a "quick win".

Over time, you can expand on your methodology as easily as a writer would add an extra paragraph in his or her novel.

Written by Paul Dandurand, Pie CEO/Founder