Guideline: Defining and Customizing Processes
This guidelines outlines defining, structuring and scaling method elements
Relationships
Related Elements
Main Description

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. 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) and milestones that 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. 

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. 

When defining processes, you may find that you want to introduce some packages in order to better organize the processes. For more information, see the topic Packaging Method Elements in Guideline: Creating Plug-ins, Practices and Configurations.  

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 include in a project plan or work items list. Planned elements are intended to be assigned to a specific person for completion by a specific due date. 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.

Customizing a Process

When customizing a process, it is important to explicitly identify what process you will actually customize (remember: a specific process may be defined in one place and "applied" in many other processes, either copied or linked to). Once you have identified what process to customize, you can execute the scenarios described in this document on that process.
      
The following questions can help you decide what process to customize:
  • Do you want to change an overall process?
    • If so, then that process is the process to be customized.
        
  • Do you want to change an activity in a process (i.e., the elements it contains or its flow)?
    • If so, is the activity you want to change a reference to process/activity that is defined elsewhere (i.e., what it created by extending or copying a capability pattern/activity defined in another process)?
      • If so, do you want to change all instances of the activity?
        • If so, find the base definition of the process that the activity was created from. That process is the process to be customized.
        • If not, the current process is the process to be customized.
      • If not, then the activity you want to change is defined in this process, so this process is the process to be customized.
           
  • Do you want to change a role, task or work product descriptor in the process? 
    • If so, is the descriptor linked to a method content element?
      • If so, do you want the change to affect all occurrences of the role, task or work product? 
        • If so, you need to customize the method content elements  and then update the process to pick up the changes (see the "Update a process to include changes made to the underlying method content " scenario in this guideline).
        • If not, you will be making a local process change to the descriptors. For more information, see the "Change the role, task or work product descriptors" scenario in this guideline.
      • If not, you will be making a local process change to the descriptors. For more information, see the "Change the role, task or work product descriptors" scenario in this guideline.
Once the process has been customized, you need to decide if you want to customize other processes that were originally dependent on (or built from) the process that you customized. If so, then you need to perform the "Replace an existing activity with another activity " scenario for those processes so they reflect the customizations you made.        

It is assumed that the process being customized cannot be modified directly. Thus, all process changes must be stored in a separate plug-in from the process being customized. To see the resulting changes, you need to browse or publish a configuration that includes the element being customized and the customizations. If you can modify the process directly, you need to follow the guidelines described in the topic Defining Processes above.

The following are some ways you can customize a process:

  • Update a process to include changes made to the underlying method content
  • Change the textual descriptions of the process itself or its elements
  • Add new activities
  • Add new roles, tasks or work products
  • Replace an existing activity with another activity
  • Change the role, task or work product descriptors
  • Change the process flow
  • Add a new, or change an existing, process diagram

The following sections describe these scenarios in more detail.  

Customizing a process in the UMF

When customizing processes that are to existing within the Unified Method Framework (UMF), the UMF plug-in types need to be considered. These types affect what elements can be placed in what plug-in. For example, customizations of process elements are defined in Extend plug-ins. 

Update a process to include changes made to the underlying method content

Perform the following steps to customize a process to include changes made to underlying method content:

  • If one does not already exist, create a new plug-in to contain the customized process.
  • Make a copy of the default configuration for the process to be customized.
  • In the new configuration, add the new plug-in and the plug-ins that contain the method content changes.
  • Copy the original process and place the copy in the new plug-in.
  • Change the default configuration of the new process to the new configuration.
  • Synchronize the new process against the new configuration. 

The method content changes should now be picked up.  

Add a new role, task or work product to the process

Roles, tasks and work products are represented as descriptors in a process. For more information on descriptors, see the topic Defining Processes above.

Perform the following steps to add a new role, task or work product (descriptor) to an existing process:

  • If one does not already exist, create a new plug-in to contain the customized process.
  • Make a copy of the default configuration for the process to be customized.
  • In the new configuration, add the new plug-in and the plug-ins that contain the method content elements to be added.
  • Copy the original process and place the copy in the new plug-in.
  • Change the default configuration of the new process to the new configuration.
  • Synchronize the new process against the new configuration. 
  • Drag and drop the role, task or work product to be added into the process. Descriptors are created.
  • Refine the flow between the new element and the existing element, as needed (for example, adding predecessors to the new task descriptor, or specifying the new task descriptor as a predecessor to an existing task descriptor). The method content elements are now part of the process.
  • Change the definition of the new process to specify that it is to replace the original process.     

Replace an existing activity with another activity

Perform the following steps to replace an activity with another activity:

  • Create a new plug-in to contain the customized process.
  • Make a copy of the default configuration for the process to be customized.
  • In the new configuration, add the new plug-in and the plug-ins that contain the method content changes.
  • Copy the original process and place the copy in the new plug-in.
  • Change the default configuration of the new process to the new configuration.
  • Synchronize the new process against the new configuration. 
  • Change the definition of the activity to be replaced so that the activity is an extension of the new activity. The process now includes the new activity.
  • Change the definition of the new process to specify that it is to replace the original process.  

Change the role, task or work product descriptors

Roles, tasks and work products are represented as descriptors in a process. The relationships between the descriptors are created at the time the elements are added to the process and those relationships reflect the relationships as resolved in the processes' default configuration.

The descriptor text and relationships can be changed directly in the process. If the descriptors are associated with method content elements, such descriptor changes do not affect the associated method content elements (they are considered local process changes).

Perform the following steps to change the role, task or work product descriptors directly in a customized process:

  • Create a new plug-in to contain the customized process.
  • Copy the original process and place the copy in the new plug-in.
  • Change the descriptor textual descriptions or relationships directly in the new process. The process now includes the descriptor changes. 
  • Change the definition of the new process to specify that it is to replace the original process.

Change the process flow

The process flow is the flow between the activities or task descriptors in the process. You can change the flow by changing the predecessors of the activities and the task descriptors. This can be done directly in the work breakdown structure, or, if there is an associated activity diagram, by changing the control flow between the elements on the activity diagram. For more information creating a new or changing and existing activity diagram, see the process diagram section of this guideline.

Even if the elements in the process are associated with method content elements, changing the flow between the elements in a process does not affect the associated method content elements (flow changes are considered local process changes).

Perform the following steps to change the process flow of an existing process:

  • Create a new plug-in to contain the customized process.
  • Copy the original process and place the copy in the new plug-in.
  • Change the predecessors in the work breakdown structure, as needed to obtain the desired flow, or, if there is an associated activity diagram, change the control flow in the activity diagram. The process flow is now changed.  
  • Change the definition of the new process to specify that it is to replace the original process.

Add a new, or change an existing, process diagram  

There are two types of process diagrams, activity diagrams and activity detail diagrams. For more information on these diagrams and when and how they can be used, see the topic Defining Processes above.

Perform the following steps to add a new, or change an existing, process diagram:

  • Create a new plug-in to contain the customized process.
  • Copy the original process and place the copy in the new plug-in.
  • Create a new or change an existing process diagram, at the desired levels in the process. The process now contains the desired process diagram.  
  • Change the definition of the new process to specify that it is to replace the original process.

Defining a Practice Configuration Process

Defining a cross-practice process is where you turn your attention to the process/lifecycle side of things. How should the tasks and/or activities (i.e., capability patterns) from the individual Practices "flow" together? Are there any activities that always appear together and in what order do they appear? Are there specific sets of activities that can be reused together in more course-grained flows? What does an overall lifecycle look like? Define cross-practice processes to reflect these decisions. Specifically, define capability patterns for sets of capability patterns that always appear together and can be reused in other capability patterns, and define delivery processes for overall lifecycles. Defining cross-practice processes defines an overall flow through the practices and validates that you have the right practice content with the right separation of concerns.

Perform the following steps to create a cross-practice process:

  • If one does not exist, create a Publish Base plug-in to contain the new process.  
  • Create a Publishable method configuration that includes the the necessary core plug-ins (include role and standard category definitions), the new Publish plug-in, the practices (including the desired practice role assignments), and any cross-practice processes you are interested in including in your cross-practice process (remember all processes must have a default configuration).
  • Create the cross-practice process, specifying the new configuration as the default configuration. Assemble the cross-practice process using the method elements (tasks, capability patterns) from the Process Construction configuration, defining as many levels (i.e., nested activities) as are needed. In some cases, there may even be reference workflows from the individual practices that you can use for ideas for the process you are building. When assembling cross-practice processes, the processes that are used (i.e., the capability patterns that are applied) from the practices must be copied instead of extended so that the process descriptors are built using the default configuration for the cross-practice process. 

In summary, practices provide the pieces parts (tasks and capability patterns) and may even provide some good process patterns e.g., reference workflows), but in the end, it is the person creating the a process that must decide the order and levels (the level of nesting of the activities) of the process, using any and all available method content elements and/or process patterns.