Vesa Purho
Development Manager, Nokia

A process description typically has the following parts: tasks, inputs, outputs, and actors. In more complex descriptions, you may have additional information like the instructions related to the task, templates, and good examples related to the outputs. Some of the outputs or tasks may have been defined as exit criteria, meaning that one cannot proceed with the next task unless the exit criteria are met. Process development seems to be easy. You just describe the tasks that need to be done to create the output using the inputs, and explain who does them. However, in practice, things may get a bit more complex.

What if you are creating a process for an organization where there are several groups that have different job titles and responsibilities although they do the same tasks, for example, creating documentation? How do you explain who the actors are without confusing everybody since they might have people with the same title doing different jobs or people with different titles doing the same job? Rule number one in process development is to remember that the actors are just roles in the process; in reality, the tasks can be performed by whoever has the needed skills. In some cases, one person can serve in several roles in one project, while in other projects, each of the roles is served by a different individual.

In developing a sound process description, keep the process actor names generic: Author, Project Manager, Editor, and so on. Explain what each actor’s responsibilities are. For example, you might define “Author” as “A person responsible for creating the content in a document.” When the process is applied in a real project, a Technical Writer, a Senior Technical Writer, an Information Developer, or even a Software Engineer could all perform this task.

Avoid using organization-specific job titles. They change too often, requiring the process descriptions to be updated even though the work remains the same. And, if the names are generic, they are not so easily seen as a requirement for having a separate person for each task.

This meaning of the roles in a process should be taught to the people using the process. Too often I have heard the complaint “We don’t have people for all these roles; in our department one person is responsible for all these tasks.” My standard answer to this situation: “The process roles are just roles, you can have one person doing all those tasks, there is nothing wrong with that.” Naturally, this approach also has its downside. Sometimes the process is not transparent enough that you can readily see who is responsible for each task.

Inputs and outputs can be documents, but they can also be decisions or checks. Documents are typically easy to define, and you can provide people with templates to use. Sometimes the inputs have to be a bit vague. For example, an input to a “Creating content” task can be “Software Design documents.” Design documents can include all kinds of material that get your hands on. If you can be more precise, list all the design document types so that those who perform the process need not figure out for themselves what material is meant. The outputs and the state in which they should be delivered must be clearly defined. For example, if the output is a “Project plan,” does it mean that it is approved, ready for approval, or just a draft? Furthermore, be careful to use the same name for the same document throughout the process. If an output of a task is “Content Specification,” don’t use the term “Content Plan” as an input in the following phase. Seems trivial, but it happens surprisingly often and confuses people.

Decisions and checks can be more difficult. It is easiest to define a decision point as an input “Project plan approved” or as an output “Documentation approved for distribution.” However, what does it mean when you say “Language checked”? Is it only “checked” or corrected. If the same person doing the checking is not doing the correcting, you may need to add other tasks or other actors to the same task. What is included in the checking? Typically with checks, you should have some additional material to support the process, like checklists, which list the details of what is being checked. Supporting materials should not be put to the process description itself because they make it too cumbersome to read.Just link to them.

Last, use existing processes. If your company already has a process for handling requirements, doing reviews, or maintaining the product after release, see if they match your needs as well. If not, suggest that they be modified so that they meet your needs. It is waste of resources to create your own processes instead of using existing ones. It also makes you less integrated with product development or other corporate activities. Your process should handle only tasks specific to what you do. By including the decisions or tasks that the product development team must make concerning your activities, for example approving documentation budget, in their general product management process, you gain visibility and reduce the “us vs. them” thinking among all parties.

This article is the personal opinion of the author and does not necessarily reflect the opinion or practice of Nokia.