| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-UOT3NdbL4E3lsaVCiKFOtw" |
| name="defining_processes,_Y_JroEyDEdu4NY1n_hCY0w" guid="-UOT3NdbL4E3lsaVCiKFOtw" |
| changeDate="2008-11-17T22:47:35.421-0800" version="1.0.0"> |
| <mainDescription><p>
 |
| This guideline provides general guidelines for defining <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html"
 |
| guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>es. There are two kinds of process structures available: <a
 |
| class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/delivery_process_BCDF50B7.html"
 |
| guid="_ZufeMCO3EdqaNq6Ptg8uyA">delivery process</a>es and <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/capability_pattern_F5DDC5F.html"
 |
| guid="_2RUJACO4EdqaNq6Ptg8uyA">capability pattern</a>s. 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&nbsp;delivery processes or larger capability patterns ensuring optimal reuse.&nbsp;
 |
| </p>
 |
| <p>
 |
| Defining a process involves creating the plug-in that will contain the process (if&nbsp;it does not already exist),
 |
| naming the process and briefly describing it. For more information on defining plug-ins, see <a
 |
| class="elementLinkWithType" href="./../../../core.mdev.common.base/guidances/guidelines/defining_plugins_CF19789C.html"
 |
| guid="_OIOSQF_zEduYvI5nsNyVYA">Guideline: Defining Plugins</a>.&nbsp;For more information on naming, see <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/method_element_naming_conventions_4A4F743B.html"
 |
| guid="_lAphAF5-EduT-Px7fh0LSg">Guideline: Method Element Naming Conventions</a>. For more information on writing brief
 |
| descriptions, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/writing_brief_descriptions_D01D2F53.html"
 |
| guid="_cJbBkCAhEdy1y5bWsXfCCg">Guideline: Writing Brief Descriptions</a>. Any issues naming an element and briefly
 |
| describing it may indicate that the element is not a&nbsp;good element after all.
 |
| </p>
 |
| <p>
 |
| Defining a process also involves defining the&nbsp;<a class="elementLinkWithUserText"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/activity_1D028230.html"
 |
| guid="_yoVhMB_IEdq6CKKKq4D7YA">activities</a> that make up the process and the relationships (i.e., flow) between the
 |
| activities.&nbsp;For information on defining the activities (including <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/phase_6ACBC4E8.html"
 |
| guid="_K9eecMaGEduMlb2cQZNTYw">phase</a>s and&nbsp;<a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/iteration_985D797A.html"
 |
| guid="_5vWoEKNcEdyMFYhoCpD11Q">iteration</a>s) 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.
 |
| </p>
 |
| <p>
 |
| Every process must have a default <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_configuration_C2B8FA8A.html"
 |
| guid="__V7pAMaEEduMlb2cQZNTYw">method configuration</a>&nbsp;that specifies exactly what method elements can be
 |
| included in the process.&nbsp;For more information on defining these default configurations, see <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/defining_method_configurations_2B25CEA5.html"
 |
| guid="_l77zcIB-EduaS6LQ8n6xUQ">Guideline: Defining Method Configurations</a>.&nbsp;
 |
| </p>
 |
| <p>
 |
| When defining processes, it is a good idea to capture the source of the information for the process.&nbsp;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.&nbsp;For more information, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/maintaining_change_histories_and_version_numbers_B83271.html"
 |
| guid="_k91OkFpBEdutiI3y4Hpy9Q">Guideline: Maintaining Change Histories and Version Numbers</a>&nbsp;and <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/trademarks_and_copyrights_F14EB70C.html"
 |
| guid="_OxsfkH8MEdu_ipWWZJimvQ">Guideline: Trademarks and Copyrights</a>.
 |
| </p>
 |
| <p>
 |
| When defining processes, you may find that you want to introduce some packages in order to better organize the
 |
| processes.&nbsp;For more information, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/packaging_method_elements_E4EC8A32.html"
 |
| guid="_bAjgIIAhEd2RgsZLwhqsAA">Guideline: Packaging Method Elements</a>.&nbsp;&nbsp;
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h3>
 |
| Descriptors
 |
| </h3>
 |
| <p>
 |
| The separation of concern between method content and processes is achieved through the use of <em><a
 |
| class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/descriptor_D52B7BB3.html"
 |
| guid="_7rS6AB_JEdq6CKKKq4D7YA">descriptor</a>s</em>. Descriptors provide a&nbsp;representation of a method content
 |
| element in the&nbsp;context of a process. Descriptors may contain additional information that is only relevant to the
 |
| process under construction.&nbsp;Changes to the descriptors in one process do not affect the base definition of the
 |
| method content element, nor do they affect&nbsp;other descriptors for that method content element in other
 |
| processes.&nbsp;This allows the author to make local changes&nbsp;to a method content element and its relationships in
 |
| a specific process.
 |
| </p>
 |
| <p>
 |
| 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.&nbsp; Descriptors may also
 |
| be created from scratch and may be left standalone or linked to an existing method content element.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h3>
 |
| Activity diagrams
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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&nbsp;includes&nbsp;only the&nbsp;elements in that activity.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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&nbsp;of input and&nbsp;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.&nbsp;
 |
| </p>
 |
| <h3>
 |
| Activity detail diagrams
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.&nbsp;&nbsp;
 |
| </p>
 |
| <p>
 |
| You also cannot create an activity detail diagram for an activity that contains tasks that do not have
 |
| a&nbsp;performing role specified since an activity detail diagram is developed from the role&nbsp;perspective&nbsp;.
 |
| </p>
 |
| <p>
 |
| Activity detail diagrams are optional, though they are quite popular for those activities where&nbsp;flow of the tasks
 |
| in the activity&nbsp;is determined by the flow&nbsp;of input and&nbsp;output work products between the tasks.
 |
| </p>
 |
| <h3>
 |
| Populating a process
 |
| </h3>
 |
| <p>
 |
| There are several ways to populate a process with method elements:
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| Drag individual method content elements onto an activity in a process. A descriptor for the method content element
 |
| is created in the process
 |
| </li>
 |
| <li>
 |
| Drag individual capability patterns into an activity in a process.&nbsp;A copy of the capability pattern or a link
 |
| to the source capability pattern can be created.&nbsp;If a copy is created, a copy of all descriptors in the
 |
| process are created.
 |
| </li>
 |
| <li>
 |
| Drag individual activities from existing process into an activity in a process.&nbsp;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.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| </ol>
 |
| <p>
 |
| Options 1 and 2 are the recommended means of populating a process.
 |
| </p>
 |
| <p>
 |
| 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.&nbsp;
 |
| </p>
 |
| <h3>
 |
| Setting the breakdown element flags
 |
| </h3>
 |
| <p>
 |
| Every <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_element_E6E32412.html"
 |
| guid="_cvdpEB_LEdq6CKKKq4D7YA">breakdown element</a>&nbsp;has a set of flags associated with it.&nbsp;Part of defining
 |
| a process is setting these flags. The following are some guidelines for setting these flags:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Planned</strong>: 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.&nbsp;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.&nbsp;However, ultimately the choice of what to
 |
| plan is based on the style of project management for a project.
 |
| </li>
 |
| <li>
 |
| <strong>Repeatable</strong>: 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).&nbsp;For example, patterns that represent iterations are
 |
| generally marked as being repeatable.
 |
| </li>
 |
| <li>
 |
| <strong>Multiple Occurrences</strong>: 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.
 |
| </li>
 |
| <li>
 |
| <strong>Ongoing</strong>: 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.
 |
| </li>
 |
| <li>
 |
| <strong>Event-Driven</strong>: Set this flag for activities that occur when a particular event occurs (for example,
 |
| Manage Changing Requirements)
 |
| </li>
 |
| <li>
 |
| <strong>Optional</strong>: 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.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Repeatable</strong>: To indicate that there may be more than one execution of an activity, name the
 |
| activity with [n] at the end of the name.&nbsp; For example: Inception Iteration [n].
 |
| </li>
 |
| <li>
 |
| <strong>Multiple occurrences</strong>: 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&nbsp;are
 |
| those&nbsp; with [within Scope] in their name.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| 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.<br />
 |
| &nbsp;
 |
| </p>
 |
| <p>
 |
| The following sections provide some process-type-specific guidelines:
 |
| </p>
 |
| <h3>
 |
| Defining activities
 |
| </h3>
 |
| <p>
 |
| An activity&nbsp;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.&nbsp;
 |
| </p>
 |
| <p>
 |
| Consider the following when defining an activity:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Reuse existing activities and capability patterns wherever possible.
 |
| </li>
 |
| <li>
 |
| An activity should:<br />
 |
| <ul>
 |
| <li>
 |
| Be a simple building block
 |
| </li>
 |
| <li>
 |
| Address one topic and have a simple internal structure
 |
| </li>
 |
| <li>
 |
| Be as self-contained as possible with few input work products, that is, the external dependencies are
 |
| minimized
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li>
 |
| For each activity, its predecessors and successors should be defined, ideally&nbsp;in an activity diagram. For more
 |
| information, see the "Activity diagrams" section of this guideline.&nbsp;
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Defining capability patterns
 |
| </h3>
 |
| <p>
 |
| The following provides some guidelines for defining capability patterns:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Make capability patterns relatively small and self contained&nbsp;with relatively&nbsp;few dependencies on external
 |
| inputs.
 |
| </li>
 |
| <li>
 |
| Create capability patterns for workflows that are intended to be reused.
 |
| </li>
 |
| <li>
 |
| Create capability patterns for sets of tasks are planned as&nbsp;a group on a project, as opposed to being planned
 |
| individually.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Defining delivery processes
 |
| </h3>
 |
| <p>
 |
| The following provides some guidelines for defining delivery processes:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Define a delivery process for a particular type of project that reflects the specific planning and project
 |
| management needs.&nbsp;
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
