One approach is to get the group together for a story-boarding session. Post-Its on a wall works. Or you could use PIEmatrix to help story-board. Focus on high level process steps first and keep it simple. Ask them to kick start by listing the deliverables. This is the easy part and you may already have this documented. Next is to list all possible failure points (future fires). Most everyone is a critic. So, leverage this. It may not take long to list experience with risk in each project stage. Now, turn the table and ask them to come up with high-level process steps to reduce the risks. This is harder, but at least they have a good starting point. At the end of the session, ask for volunteers to take certain process points to decompose into more detail. You will find the details goes to those who have the depth.

The other option is for you or your firm’s process expert to define the high-level process steps and then outsource the detailed definitions to the front-line team members based on their expertise.

Once you have your new best practice process defined (documented or placed in PIEmatrix) the challenge is to get it to stick. However, you have an advantage. The team who needs to do the sticking has personal stake. They are more likely to better adopt to process change if they helped build it. Over the longer term, keep the best practices fresh with process evoluton workshops.

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. 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.

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. 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. 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.