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:
-
Drag individual method content elements onto an activity in a process. A descriptor for the method content element
is created in the process
-
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.
-
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.
-
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.
|