Components of a Good Process

As promised, here is a list of components that make for a great process. While some might think that one component may not be needed or might be redundant, what's important to remember is capturing specific information to the following questions:

1. Is there a reason the document exists?
   
2. Is it clear who owns and maintains the document?
   
3. Are there audit measures in place to ensure the information is managed on a timely basis (Revision Control/Maintenance Schedule)? (Purpose and Intent), (Ownership and Approval for Changes),
   
4. Does it cover all the steps to complete the task? (Process Content).
   
5. Are acronyms and jargon clearly defined?
6. How are revisions and requests for changes handled?

To satisfy these questions, below are some components and their descriptions to make sure you have everything covered.

• Document Control: It's important to have clear and specific information about your document. Your document control should be a table that lists the unique name of the document, the URL/UNC to where the document is stored, date of publication, owner,expiration/review date, and stakeholder approval for the document.
• Purpose: This section should define a clear reason or purpose that the document exists.
  
• Scope: This component should contain a table that details what is In Scope and what is Out of Scope. This helps keep the document focused on the specific task and minimize creep.
  
• Definitions: It's easy in our everyday work lives to throw around and use acronyms as if everyone knows what they mean. Having a Definition section eliminates ambiguity and enables you to freely use the acronym going forward in the document.
  
• Process: This section would contain the steps and sub-steps to complete the task. As we've discussed in previous sections, the process should be logical, complete, and un-interprative - meaning the reader of the process is not left guessing. Read some of my previous posts to learn more about this component.
• Document Change Management: This table should contain the following fields: The Revision Number (Eg. 1.2, 1.3, etc), Date of the change, Section Changed, Author of the change, and a summary of the change.

There are other sections I've come across and used and it depends on your specific needs. As long as the points within each section are covered then you might find that you don't need certain components. Here are a couple more:

• Inputs: This section would contain information and links from processes that are needed in order to begin/initiate the current process. This is good for ensuring you have a tight logical relationship between all your dependancies.
• Output: Like the Inputs section, knowing where your Output goes help keep the logic between your different process documents. The Output section can be placed next to, or as a part of the Inputs section.
• Addendums: This component might contain any relevant information that doesn't seem to fit in any of the other sections, but is helpful and needed for the reader to know.
• Resources: External links to helpful or related documents would be put in this section.
  

Well, that's all I can think of for good components to a help desk process. I might also add that this approach can be taken to all facets of process and document control. If you found this helpful or would like to see examples of how these components look, leave a comment and we can get in touch.

Working with Process Diagrams

If you'll recall in an earlier post, process diagrams are very useful in getting the "10,000" foot view of your operation. Within each process box you can break down what transpires in the form of an itemized set of steps that completes the process box and feeds into the next one. What's important to remember is that all requirements for completion are listed in your process. If not, that's a whole or a gap and leaves the process open for interpretation. Continuing with our help desk process theme, I will demonstrate what might transpire.

Let's look at the first process event - "Analyst Uses Scripted Greeting". The requirements that satisfy this might go something like this:

1. "Welcome the Acme help desk. May I have your employee ID?"
2. Analyst obtains employee ID and enters it into tracking tool.
3. "Is this Joe Blow? And you can be reached at 719-555-1212?"
4. "How may I assist?"
5. Analyst follows "Troubleshooting Process".
   

So basically what we've done here is satisfy two process boxes in our process diagram. The scripted greeting as well as the decision box validating/acknowledging the user's entitlement to service. Bear in mind, the steps listed above do not a complete process make. What I'm talking about here is just the steps required to satisfy those parts of the process diagram.

This part of the process analysis will again lead to more questions relating to detail, providing enough direction, and how far do you drill with specificity. Those are questions you'll have to answer through the exercise of breaking down the detail and determining how far you need to go. It might be a task that no one person alone can answer, so seek help from subordinates and peers alike.