This guideline provides general guidelines for defining processes. There are two kinds of process structures available: delivery processes and capability patterns. The fundamental difference between a capability pattern and a delivery process is that capability patterns are reusable chunks of process that are intended to reused, whereas delivery processes are intended to be executed as a whole on projects (a delivery process can be used as a template for planning and running a project.). Capability patterns are typically used as building blocks which are then assembled into delivery processes or larger capability patterns ensuring optimal reuse. 

Defining a process involves creating the plug-in that will contain the process (if it does not already exist), naming the process and briefly describing it. For more information on defining plug-ins, see Guideline: Defining Plugins. For more information on naming, see Guideline: Method Element Naming Conventions. For more information on writing brief descriptions, see Guideline: Writing Brief Descriptions. Any issues naming an element and briefly describing it may indicate that the element is not a good element after all.

Defining a process also involves defining the activities that make up the process and the relationships (i.e., flow) between the activities. For information on defining the activities (including phases and iterations) that and milestones make up a process, see the "Defining Activities" section below. When you define process, you define a flow through the method content, which validates that you have the right method content with the right separation of concerns.

Every process must have a default method configuration that specifies exactly what method elements can be included in the process. For more information on defining these default configurations, see Guideline: Defining Method Configurations. 

When defining processes, it is a good idea to capture the source of the information for the process. This information is important if you ever need to provide source information for the process for documenting ownership rights. It is also important to maintain accurate change histories, as well as making sure your trademarks and copyrights are accurate. For more information, see Guideline: Maintaining Change Histories and Version Numbers and Guideline: Trademarks and Copyrights.

When defining processes, you may find that you want to introduce some packages in order to better organize the processes. For more information, see Guideline: Packaging Method Elements.  

Note: A process can be defined by mimicking an existing process. In that case, you can either define the new process, using the existing process as inspiration, or actually copy the original process, changing the default configuration and process contents, as needed.

Descriptors

The separation of concern between method content and processes is achieved through the use of descriptors. Descriptors provide a representation of a method content element in the context of a process. Descriptors may contain additional information that is only relevant to the process under construction. Changes to the descriptors in one process do not affect the base definition of the method content element, nor do they affect other descriptors for that method content element in other processes. This allows the author to make local changes to a method content element and its relationships in a specific process.

Descriptors are created in a process when method content elements are added to a process, one descriptor for each method content element. Such descriptors are linked to their source method content elements.  Descriptors may also be created from scratch and may be left standalone or linked to an existing method content element.

The relationships that a descriptor has to other descriptors is determined by the default configuration of the process at the time the method content element was added to the process. If the source method content element or the configuration changes at a later time, the process must be resynchronized to get the latest changes. Only descriptors that are linked to a method content element are synchronized.

Activity diagrams

Activity diagrams can be used to represent the flow between activities or task descriptors in a process. The control flow between elements in an activity diagram are represented as predecessors in the work breakdown structure of the process. For example, if there is a control flow on an activity diagram from Activity1 to Activity2, Activity1 is listed as a predecessor for Activity2. Changes in activity diagrams are reflected in the work breakdown structure and changes to the work breakdown structure are reflected in the activity diagrams.

Activity diagrams may occur at any level in the breakdown structure. For example, there may be an activity diagram for the overall process (includes the first level of activities in the breakdown structure) or an activity diagram for a specific activity in the process that includes only the elements in that activity.

Activity diagrams are optional, but it is recommended that they be created whenever you have a specific flow between elements. It is strongly recommended that for any activity that includes other activities that an activity diagram be created as having a visual representation of the flow will not only be helpful to practitioners that will be following the process, but it is also helpful to the process author as it may point out potential problems or complexities in the process that need to be addressed.

Activity diagrams are more popular for representing the flow between activities, especially for representing the overall flow of a process. However, they can be used to represent the flow between task descriptors. However, if the flow between task descriptors is more implied by the flow of input and output work products between the tasks, then an activity detail diagram may be a better choice. For more information, see the "Activity detail diagrams" section of this guideline. 

Activity detail diagrams

Activity detail diagrams can be used to provide an overview of an activity that just includes task descriptors (not activities). Activity detail diagrams include the descriptors for the tasks, their primary performing roles, their mandatory input and their output work products. They are organized by performing roles and thus provide a great overview of what a specific role does in a specific activity in the process.

You cannot create an activity detail diagram for an activity that includes other activities. In such a case, an activity diagram may be a better choice. Thus, activity detail diagrams only apply at the "bottom" level of the process. For more information, see the "Activity diagrams" section of this guideline.  

You also cannot create an activity detail diagram for an activity that contains tasks that do not have a performing role specified since an activity detail diagram is developed from the role perspective .

Activity detail diagrams are optional, though they are quite popular for those activities where flow of the tasks in the activity is determined by the flow of input and output work products between the tasks.

Populating a process

There are several ways to populate a process with method elements:

1. Drag individual method content elements onto an activity in a process. A descriptor for the method content element is created in the process
2. Drag individual capability patterns into an activity in a process. A copy of the capability pattern or a link to the source capability pattern can be created. If a copy is created, a copy of all descriptors in the process are created.
3. Drag individual activities from existing process into an activity in a process. A copy of the activity or a link to the source activity can be created. If a copy is created, a copy of all descriptors in the activity are created.
4. Create descriptors directly in the process, which are either unrelated to any method content or related to method content at a later point in time.

Options 1 and 2 are the recommended means of populating a process.

Every task descriptor and activity can have predecessors (these are what specify the flow between these elements). These predecessors can be set by specifying them as part of the work breakdown structure for the process or by specifying the flow between elements in an activity diagram. For more information on activity diagrams, see the "Activity diagrams" section of this guideline. 

Setting the breakdown element flags

Every breakdown element has a set of flags associated with it. Part of defining a process is setting these flags. The following are some guidelines for setting these flags:

• Planned: Set this flag for elements that a project manager would want to plan for a project, assigning it to a particular person with particular date associated with it. This flag is used to indicate what elements should be included in the exported project planning template. It does not impact whether the item is actually performed, but rather is used to show the expected level the project is to be tracked to. For planning purposes the contents of non-planned elements are rolled up to the first planned item in the hierarchy. In general, activities, not tasks, are planned. However, not all activities are planned. Usually the larger-grained activities are planned, whereas the fine-grained activities are not. However, ultimately the choice of what to plan is based on the style of project management for a project.
• Repeatable: Set this flag for activities whose sub-activities and tasks are run more than once for the same subject or content serially (not in parallel). For example, patterns that represent iterations are generally marked as being repeatable.
• Multiple Occurrences: Set this flag for activities that are executed more than once for different areas of concern, but they can be done in parallel to one another and are not restricted to be performed serially, like Repeatable is.
• Ongoing: Set this flag for activities that do not have a particular start/stop date, but rather are scheduled by the amount of time they take up. Support and management activities often are ongoing.
• Event-Driven: Set this flag for activities that occur when a particular event occurs (for example, Manage Changing Requirements)
• Optional: Set this flag for activities that are considered to be optional (not required). This flag identifies whether the related element can be removed from the process without a large impact. This is intended to provide general guidance to those tailoring the process on the likelihood of removing something having a negative impact on the integrity of the resulting process. It is not intended to show whether the related item is mandatory in terms of compliance nor is it intended to show what items have to be done while executing the process. In other words you would not switch this attribute to mandatory for all elements once a process had been tailored. Just because something is not marked as optional does not mean it has to always used in that process but is rather intended to be used as a filter when generating reports to alert the user of tailoring decisions they should validate. The use of this attribute should not be confused with mandatory and optional inputs which are used to identify which inputs are critical to performing a task versus (i.e. the task can not be performed without those inputs) those that should be used if available or may prove useful as additional information.

Based on these definitions not all attributes are valid for all types of process elements and in some cases may require a slightly different interpretation of their meaning.

Depending on the situation, some or all the above properties can have a dramatic impact on how a breakdown element is understood. It is therefore useful to emphasize the presence of certain of the above properties through a special naming convention of the breakdown element. For example:

• Repeatable: To indicate that there may be more than one execution of an activity, name the activity with [n] at the end of the name.  For example: Inception Iteration [n].
• Multiple occurrences: To indicate that there may be more than one occurrence of an activity, include [within Scope] in their name. Therefore, the only instances of a Multiple Occurrence activity are those  with [within Scope] in their name.

Regardless of what conventions are adopted, it is important that are applied uniformly, as haphazard compliance with a convention may create more confusion than help.
 

The following sections provide some process-type-specific guidelines:

Defining activities

An activity allows the method author to sequence units of work described by tasks. Activities are the basic process element in a method. Activities may be sequenced and nested and so very complex structures can be created. However, as complexity goes up, understandability goes down. 

Consider the following when defining an activity:

• Reuse existing activities and capability patterns wherever possible.
• An activity should:
  
  • Be a simple building block
  • Address one topic and have a simple internal structure
  • Be as self-contained as possible with few input work products, that is, the external dependencies are minimized
• For each activity, its predecessors and successors should be defined, ideally in an activity diagram. For more information, see the "Activity diagrams" section of this guideline. 
• If an activity contains a milestone, it is normally placed at the end of the sequence of tasks in the activity. A milestone might mark the completion of the deliverable or some other significant event in the engagement.

Defining capability patterns

The following provides some guidelines for defining capability patterns:

• Make capability patterns relatively small and self contained with relatively few dependencies on external inputs.
• Create capability patterns for workflows that are intended to be reused.
• Create capability patterns for sets of tasks are planned as a group on a project, as opposed to being planned individually.
• Create capability patterns if there is a workflow fragment that is shared between two or more capability patterns. Yes, you can share activities between processes, but it is much easier to find the reusable things if they are capability patterns.
• Resist creating a proliferation of capability patterns because the can get tedious to create and having many, many capability patterns makes finding the activity of interest even more difficult. Consider organizing processes into process packages to reduce complexity.

Defining delivery processes

The following provides some guidelines for defining delivery processes:

• Define a delivery process for a particular type of project that reflects the specific planning and project management needs. 
• Define a delivery process by assembling existing capability patterns and adding additional process elements as necessary (for example, milestones, phases, etc.) to tie to capability patterns together.