<?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.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-K8Q26ltxx-Fu7B0UcQWUkg" name="defining_customizing_processes,_E9J1kD9EEd-Xgadv74rzHA" guid="-K8Q26ltxx-Fu7B0UcQWUkg" changeDate="2011-10-13T13:56:12.240-0700" version="7.5.0">
  <mainDescription>&lt;h3>&#xD;
    Defining Processes&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    There are two kinds of process structures available: &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/delivery_process_BCDF50B7.html&quot;&#xD;
    guid=&quot;_ZufeMCO3EdqaNq6Ptg8uyA&quot;>delivery process&lt;/a>es and &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/capability_pattern_F5DDC5F.html&quot;&#xD;
    guid=&quot;_2RUJACO4EdqaNq6Ptg8uyA&quot;>capability pattern&lt;/a>s. The fundamental difference between a capability pattern and a&#xD;
    delivery process is that capability patterns are reusable chunks of process that are intended to reused, whereas&#xD;
    delivery processes are intended to be executed as a whole on projects (a delivery process can be used as a template for&#xD;
    planning and running a project.). Capability patterns are typically used as building blocks which are then assembled&#xD;
    into&amp;nbsp;delivery processes or larger capability patterns ensuring optimal reuse.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Defining a process involves creating the plug-in that will contain the process (if&amp;nbsp;it does not already exist),&#xD;
    naming the process and briefly describing it.&amp;nbsp;Any issues naming an element and briefly describing it may indicate&#xD;
    that the element is not a&amp;nbsp;good element after all.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Defining a process also involves defining the&amp;nbsp;&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/activity_1D028230.html&quot;&#xD;
    guid=&quot;_yoVhMB_IEdq6CKKKq4D7YA&quot;>activities&lt;/a> that make up the process and the relationships (i.e., flow) between the&#xD;
    activities.&amp;nbsp;For information on defining the activities (including &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/phase_6ACBC4E8.html&quot;&#xD;
    guid=&quot;_K9eecMaGEduMlb2cQZNTYw&quot;>phase&lt;/a>s and&amp;nbsp;&lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/iteration_985D797A.html&quot;&#xD;
    guid=&quot;_5vWoEKNcEdyMFYhoCpD11Q&quot;>iteration&lt;/a>s) and milestones that make up a process, see the &quot;Defining Activities&quot;&#xD;
    section below. When you define process, you define a flow through the method content, which validates that you have the&#xD;
    right method content with the right separation of concerns.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Every process must have a default &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/method_configuration_C2B8FA8A.html&quot;&#xD;
    guid=&quot;__V7pAMaEEduMlb2cQZNTYw&quot;>method configuration&lt;/a>&amp;nbsp;that specifies exactly what method elements can be&#xD;
    included in the process.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When defining processes, it is a good idea to capture the source of the information for the process.&amp;nbsp;This&#xD;
    information is important if you ever need to provide source information for the process for documenting ownership&#xD;
    rights. It is also important to maintain accurate change histories, as well as making sure your trademarks and&#xD;
    copyrights are accurate.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When defining processes, you may find that you want to introduce some packages in order to better organize the&#xD;
    processes.&amp;nbsp;For more information, see the topic Packaging Method Elements in&amp;nbsp;&lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../practice.bus.mdev.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html&quot;&#xD;
    guid=&quot;_EXvLwD3NEd-realK_We5vA&quot;>Guideline: Creating Plug-ins, Practices and Configurations&lt;/a>.&amp;nbsp;&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Note: A process can be defined by mimicking an existing process. In that case, you can either define the new process,&#xD;
    using the existing process as inspiration, or actually copy the original process, changing the default configuration&#xD;
    and process contents, as needed.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Descriptors&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The separation of concern between method content and processes is achieved through the use of &lt;em>&lt;a&#xD;
    class=&quot;elementLink&quot; href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/descriptor_D52B7BB3.html&quot;&#xD;
    guid=&quot;_7rS6AB_JEdq6CKKKq4D7YA&quot;>descriptor&lt;/a>s&lt;/em>. Descriptors provide a&amp;nbsp;representation of a method content&#xD;
    element in the&amp;nbsp;context of a process. Descriptors may contain additional information that is only relevant to the&#xD;
    process under construction.&amp;nbsp;Changes to the descriptors in one process do not affect the base definition of the&#xD;
    method content element, nor do they affect&amp;nbsp;other descriptors for that method content element in other&#xD;
    processes.&amp;nbsp;This allows the author to make local changes&amp;nbsp;to a method content element and its relationships in&#xD;
    a specific process.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Descriptors are created in a process when method content elements are added to a process, one descriptor for each&#xD;
    method content element. Such descriptors are linked to their source method content elements.&amp;nbsp; Descriptors may also&#xD;
    be created from scratch and may be left standalone or linked to an existing method content element.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The relationships that a descriptor has to other descriptors is determined by the default configuration of the process&#xD;
    at the time the method content element was added to the process. If the source method content element or the&#xD;
    configuration changes at a later time, the process must be resynchronized to get the latest changes. Only descriptors&#xD;
    that are linked to a method content element are synchronized.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Activity diagrams&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Activity diagrams can be used to represent the flow between activities or task descriptors in a process. The control&#xD;
    flow between elements in an activity diagram are represented as predecessors in the work breakdown structure of the&#xD;
    process. For example, if there is a control flow on an activity diagram from Activity1 to Activity2, Activity1 is&#xD;
    listed as a predecessor for Activity2. Changes in activity diagrams are reflected in the work breakdown structure and&#xD;
    changes to the work breakdown structure are reflected in the activity diagrams.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Activity diagrams may occur at any level in the breakdown structure. For example, there may be an activity diagram for&#xD;
    the overall process (includes the first level of activities in the breakdown structure) or an activity diagram for a&#xD;
    specific activity in the process that&amp;nbsp;includes&amp;nbsp;only the&amp;nbsp;elements in that activity.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Activity diagrams are optional, but it is recommended that they be created whenever you have a specific flow between&#xD;
    elements. It is strongly recommended that for any activity that includes other activities that an activity diagram be&#xD;
    created as having a visual representation of the flow will not only be helpful to practitioners that will be following&#xD;
    the process, but it is also helpful to the process author as it may point out potential problems or complexities in the&#xD;
    process that need to be addressed.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Activity diagrams are more popular for representing the flow between activities, especially for representing the&#xD;
    overall flow of a process. However, they can be used to represent the flow between task descriptors. However, if the&#xD;
    flow between task descriptors is more implied by the flow&amp;nbsp;of input and&amp;nbsp;output work products between the&#xD;
    tasks, then an activity detail diagram may be a better choice. For more information, see the &quot;Activity detail diagrams&quot;&#xD;
    section of this guideline.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Activity detail diagrams&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Activity detail diagrams can be used to provide an overview of an activity that just includes task descriptors (not&#xD;
    activities). Activity detail diagrams include the descriptors for the tasks, their primary performing roles, their&#xD;
    mandatory input and their output work products. They are organized by performing roles and thus provide a great&#xD;
    overview of what a specific role does in a specific activity in the process.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    You cannot create an activity detail diagram for an activity that includes other activities. In such a case, an&#xD;
    activity diagram may be a better choice. Thus, activity detail diagrams only apply at the &quot;bottom&quot; level of the&#xD;
    process. For more information, see the &quot;Activity diagrams&quot; section of this guideline.&amp;nbsp;&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    You also cannot create an activity detail diagram for an activity that contains tasks that do not have&#xD;
    a&amp;nbsp;performing role specified since an activity detail diagram is developed from the role&amp;nbsp;perspective&amp;nbsp;.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Activity detail diagrams are optional, though they are quite popular for those activities where&amp;nbsp;flow of the tasks&#xD;
    in the activity&amp;nbsp;is determined by the flow&amp;nbsp;of input and&amp;nbsp;output work products between the tasks.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Populating a process&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    There are several ways to populate a process with method elements:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Drag individual method content elements onto an activity in a process. A descriptor for the method content element&#xD;
        is created in the process&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Drag individual capability patterns into an activity in a process.&amp;nbsp;A copy of the capability pattern or a link&#xD;
        to the source capability pattern can be created.&amp;nbsp;If a copy is created, a copy of all descriptors in the&#xD;
        process are created.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Drag individual activities from existing process into an activity in a process.&amp;nbsp;A copy of the activity or a&#xD;
        link to the source activity can be created. If a copy is created, a copy of all descriptors in the activity are&#xD;
        created.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Create descriptors directly in the process, which are either unrelated to any method content or related to method&#xD;
        content at a later point in time.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    Options 1 and 2 are the recommended means of populating a process.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Every task descriptor and activity can have predecessors (these are what specify the flow between these elements).&#xD;
    These predecessors can be set by specifying them as part of the work breakdown structure for the process or by&#xD;
    specifying the flow between elements in an activity diagram. For more information on activity diagrams, see the&#xD;
    &quot;Activity diagrams&quot; section of this guideline.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Setting the breakdown element flags&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Every &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/breakdown_element_E6E32412.html&quot;&#xD;
    guid=&quot;_cvdpEB_LEdq6CKKKq4D7YA&quot;>breakdown element&lt;/a>&amp;nbsp;has a set of flags associated with it.&amp;nbsp;Part of defining&#xD;
    a process is setting these flags. The following are some guidelines for setting these flags:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>Planned&lt;/strong>: Set this flag for elements that a project manager would want to include in a project plan&#xD;
        or work items list. Planned elements are intended to be assigned to a specific person for completion by a specific&#xD;
        due date. This flag is used to indicate what elements should be included in the exported project planning template.&#xD;
        It does not impact whether the item is actually performed, but rather is used to show the expected level the&#xD;
        project is to be tracked to.&amp;nbsp;For planning purposes the contents of non-planned elements are rolled up to the&#xD;
        first planned item in the hierarchy. In general, activities, not tasks, are planned. However, not all activities&#xD;
        are planned. Usually the larger-grained activities are planned, whereas the fine-grained activities are&#xD;
        not.&amp;nbsp;However, ultimately the choice of what to plan is based on the style of project management for a project.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Repeatable&lt;/strong>: Set this flag for activities whose sub-activities and tasks are run more than once for&#xD;
        the same subject or content serially (not in parallel).&amp;nbsp;For example, patterns that represent iterations are&#xD;
        generally marked as being repeatable.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Multiple Occurrences&lt;/strong>: Set this flag for activities that are executed more than once for different&#xD;
        areas of concern, but they can be done in parallel to one another and are not restricted to be performed serially,&#xD;
        like Repeatable is.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Ongoing&lt;/strong>: Set this flag for activities that do not have a particular start/stop date, but rather&#xD;
        are scheduled by the amount of time they take up. Support and management activities often are ongoing.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Event-Driven&lt;/strong>: Set this flag for activities that occur when a particular event occurs (for example,&#xD;
        Manage Changing Requirements)&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Optional&lt;/strong>: Set this flag for activities that are considered to be optional (not required). This&#xD;
        flag identifies whether the related element can be removed from the process without a large impact. This is&#xD;
        intended to provide general guidance to those tailoring the process on the likelihood of removing something having&#xD;
        a negative impact on the integrity of the resulting process. It is not intended to show whether the related item is&#xD;
        mandatory in terms of compliance nor is it intended to show what items have to be done while executing the process.&#xD;
        In other words you would not switch this attribute to mandatory for all elements once a process had been tailored.&#xD;
        Just because something is not marked as optional does not mean it has to always used in that process but is rather&#xD;
        intended to be used as a filter when generating reports to alert the user of tailoring decisions they should&#xD;
        validate. The use of this attribute should not be confused with mandatory and optional inputs which are used to&#xD;
        identify which inputs are critical to performing a task versus (i.e. the task can not be performed without those&#xD;
        inputs) those that should be used if available or may prove useful as additional information.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Based on these definitions not all attributes are valid for all types of process elements and in some cases may require&#xD;
    a slightly different interpretation of their meaning.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Depending on the situation, some or all the above properties can have a dramatic impact on how a breakdown element is&#xD;
    understood. It is therefore useful to emphasize the presence of certain of the above properties through a special&#xD;
    naming convention of the breakdown element. For example:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>Repeatable&lt;/strong>: To indicate that there may be more than one execution of an activity, name the&#xD;
        activity with [n] at the end of the name.&amp;nbsp; For example: Inception Iteration [n].&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Multiple occurrences&lt;/strong>: To indicate that there may be more than one occurrence of an activity,&#xD;
        include [within Scope] in their name. Therefore, the only instances of a Multiple Occurrence activity&amp;nbsp;are&#xD;
        those&amp;nbsp; with [within Scope] in their name.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Regardless of what conventions are adopted, it is important that are applied uniformly, as haphazard compliance with a&#xD;
    convention may create more confusion than help.&lt;br />&#xD;
    &amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The following sections provide some process-type-specific guidelines:&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Defining activities&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    An activity&amp;nbsp;allows the method author to sequence units of work described by tasks. Activities are the basic&#xD;
    process element in a method. Activities may be sequenced and nested and so very complex structures can be created.&#xD;
    However, as complexity goes up, understandability goes down.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Consider the following when defining an activity:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Reuse existing activities and capability patterns wherever possible.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        An activity should:&lt;br />&#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                Be a simple building block&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                Address one topic and have a simple internal structure&#xD;
            &lt;/li>&#xD;
            &lt;li>&#xD;
                Be as self-contained as possible with few input work products, that is, the external dependencies are&#xD;
                minimized&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        For each activity, its predecessors and successors should be defined, ideally&amp;nbsp;in an activity diagram. For more&#xD;
        information, see the &quot;Activity diagrams&quot; section of this guideline.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        If an activity contains a milestone, it is normally placed at the end of the sequence of tasks in the activity. A&#xD;
        milestone might mark the completion of the deliverable or some other significant event in the engagement.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Defining capability patterns&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The following provides some guidelines for defining capability patterns:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Make capability patterns relatively small and self contained&amp;nbsp;with relatively&amp;nbsp;few dependencies on external&#xD;
        inputs.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Create capability patterns for workflows that are intended to be reused.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Create capability patterns for sets of tasks are planned as&amp;nbsp;a group on a project, as opposed to being planned&#xD;
        individually.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Create capability patterns if there is a workflow fragment that is shared between two or more capability patterns.&#xD;
        Yes, you can share activities between processes, but it is much easier to find the reusable things if they are&#xD;
        capability patterns.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Resist creating a proliferation of capability patterns because the can get tedious to create and having many, many&#xD;
        capability patterns makes finding the activity of interest even more difficult. Consider organizing processes into&#xD;
        process packages to reduce complexity.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Defining delivery processes&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The following provides some guidelines for defining delivery processes:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Define a delivery process for a particular type of project that reflects the specific planning and project&#xD;
        management needs.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Define a delivery process by assembling existing capability patterns and adding additional process elements as&#xD;
        necessary (for example, milestones, phases, etc.) to tie to capability patterns together.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Customizing a Process&#xD;
&lt;/h3>&#xD;
&lt;div>&#xD;
    When customizing a process, it is important to explicitly identify what process you will actually customize (remember:&#xD;
    a specific process may be defined in one place and &quot;applied&quot; in many other processes,&amp;nbsp;either copied or linked to).&#xD;
    Once you have identified what process to customize, you can execute the scenarios described in this document on that&#xD;
    process.&#xD;
&lt;/div>&#xD;
&lt;div>&#xD;
    &amp;nbsp;&amp;nbsp; &amp;nbsp;&amp;nbsp;&amp;nbsp;&#xD;
&lt;/div>&#xD;
&lt;div>&#xD;
    The following questions can help you decide what process to customize:&#xD;
&lt;/div>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Do you want to change an overall process?&#xD;
    &lt;/li>&#xD;
    &lt;li style=&quot;LIST-STYLE-TYPE: none&quot;>&#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                If so, then that process is the process&amp;nbsp;to be customized.&lt;br />&#xD;
                &amp;nbsp;&amp;nbsp;&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Do you want to change an activity in a process (i.e., the elements it contains or its flow)?&#xD;
    &lt;/li>&#xD;
    &lt;li style=&quot;LIST-STYLE-TYPE: none&quot;>&#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                If so, is the activity you want to change a reference to process/activity that is defined elsewhere (i.e.,&#xD;
                what it created by extending or copying a capability pattern/activity defined in another process)?&#xD;
            &lt;/li>&#xD;
            &lt;li style=&quot;LIST-STYLE-TYPE: none&quot;>&#xD;
                &lt;ul>&#xD;
                    &lt;li>&#xD;
                        If so, do you want to change all instances of the activity?&#xD;
                    &lt;/li>&#xD;
                    &lt;li style=&quot;LIST-STYLE-TYPE: none&quot;>&#xD;
                        &lt;ul>&#xD;
                            &lt;li>&#xD;
                                If so, find the base definition of the process that the activity was created from. That&#xD;
                                process is the process to be customized.&#xD;
                            &lt;/li>&#xD;
                            &lt;li>&#xD;
                                If not, the current process is the process to be customized.&#xD;
                            &lt;/li>&#xD;
                        &lt;/ul>&#xD;
                    &lt;/li>&#xD;
                    &lt;li>&#xD;
                        If not, then the activity you want to change is defined in this process, so this process is the&#xD;
                        process to be customized.&lt;br />&#xD;
                        &amp;nbsp;&amp;nbsp;&amp;nbsp;&#xD;
                    &lt;/li>&#xD;
                &lt;/ul>&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Do you want to change a role, task or work product descriptor in the process?&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li style=&quot;LIST-STYLE-TYPE: none&quot;>&#xD;
        &lt;ul>&#xD;
            &lt;li>&#xD;
                If so, is the descriptor linked to a method content element?&#xD;
            &lt;/li>&#xD;
            &lt;li style=&quot;LIST-STYLE-TYPE: none&quot;>&#xD;
                &lt;ul>&#xD;
                    &lt;li>&#xD;
                        If so, do you want the change to affect all occurrences of the role, task or work product?&amp;nbsp;&#xD;
                    &lt;/li>&#xD;
                    &lt;li style=&quot;LIST-STYLE-TYPE: none&quot;>&#xD;
                        &lt;ul>&#xD;
                            &lt;li>&#xD;
                                If so, you need to customize the method content elements&amp;nbsp; and then update the process&#xD;
                                to pick up the changes (see the &quot;Update a process to include changes made to the underlying&#xD;
                                method content &quot; scenario in this guideline).&#xD;
                            &lt;/li>&#xD;
                            &lt;li>&#xD;
                                If not, you will be making a local process change&amp;nbsp;to the descriptors. For more&#xD;
                                information, see the &quot;Change the role, task or work product descriptors&quot; scenario in this&#xD;
                                guideline.&#xD;
                            &lt;/li>&#xD;
                        &lt;/ul>&#xD;
                    &lt;/li>&#xD;
                    &lt;li>&#xD;
                        If not, you will be making a local process change&amp;nbsp;to the descriptors. For more information,&#xD;
                        see the &quot;Change the role, task or work product descriptors&quot; scenario in this guideline.&#xD;
                    &lt;/li>&#xD;
                &lt;/ul>&#xD;
            &lt;/li>&#xD;
        &lt;/ul>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;div>&#xD;
    Once the process has been customized, you need to decide if you want to customize other processes that were originally&#xD;
    dependent on (or built from) the process that you customized. If so, then you need to perform the &quot;Replace an existing&#xD;
    activity with another activity &quot; scenario for those processes so they reflect the customizations you&#xD;
    made.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&lt;br />&#xD;
&lt;/div>&#xD;
&lt;p>&#xD;
    It is assumed that the process&amp;nbsp;being customized cannot be modified directly. Thus, all process changes must be&#xD;
    stored in a separate plug-in from the process being customized. To see the resulting changes, you need to browse or&#xD;
    publish a configuration that includes the element being customized and the customizations. If&amp;nbsp;you can modify the&#xD;
    process directly, you&amp;nbsp;need to&amp;nbsp;follow the guidelines described in the topic Defining Processes above.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The following are some ways you can customize a process:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Update a process to include changes made to the underlying method content&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the textual descriptions of the process itself or its elements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Add new activities&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Add new roles, tasks or work products&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Replace an existing activity with another activity&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the role, task or work product descriptors&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the process flow&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Add a new, or change an existing, process diagram&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The following sections describe these scenarios in more detail.&amp;nbsp;&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Customizing a process in the UMF&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    When customizing processes that are to existing within the Unified Method Framework (UMF), the UMF plug-in types need&#xD;
    to be considered.&amp;nbsp;These types affect what elements can be placed in what plug-in.&amp;nbsp;For example, customizations&#xD;
    of process elements are defined in Extend plug-ins.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Update a process to include changes made to the underlying method content&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Perform the following steps to customize a process to include changes made to underlying method content:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        If one does not already exist, create a new plug-in to contain the customized process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Make a copy of the default configuration for the process to be customized.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        In the new configuration, add the new plug-in and the plug-ins that contain the method content changes.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Copy the original process and place the copy in the new plug-in.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the default configuration of the new process to the new configuration.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Synchronize the new process against the new configuration.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The method content changes should now be picked up.&amp;nbsp;&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Add a new role, task or work product to the process&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Roles, tasks and work products are represented as descriptors in a process. For more information on descriptors, see&#xD;
    the topic Defining Processes above.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Perform the following steps to add a new role, task or work product (descriptor) to an existing process:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        If one does not already exist, create a new plug-in to contain the customized process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Make a copy of the default configuration for the process to be customized.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        In the new configuration, add the new plug-in and the plug-ins that contain the method content elements to be&#xD;
        added.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Copy the original process and place the copy in the new plug-in.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the default configuration of the new process to the new configuration.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Synchronize the new process against the new configuration.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Drag and drop the role, task or work product to be added into the process. Descriptors are created.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Refine the flow between the new element and the existing element, as needed (for example, adding predecessors to&#xD;
        the new task descriptor, or specifying the new task descriptor&amp;nbsp;as a predecessor to an existing task&#xD;
        descriptor). The method content elements are now part of the process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the definition of the new process to specify that it is to replace the original&#xD;
        process.&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Replace an existing activity with another activity&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Perform the following steps to replace an activity with another activity:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Create a new plug-in to contain the customized process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Make a copy of the default configuration for the process to be customized.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        In the new configuration, add the new plug-in and the plug-ins that contain the method content changes.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Copy the original process and place the copy in the new plug-in.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the default configuration of the new process to the new configuration.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Synchronize the new process against the new configuration.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the definition of the activity to be replaced so that the activity is an extension of the new activity. The&#xD;
        process now includes the new activity.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the definition of the new process to specify that it is to replace the original process.&amp;nbsp;&amp;nbsp;&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Change the role, task or work product descriptors&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Roles, tasks and work products are represented as descriptors in a process. The relationships between the descriptors&#xD;
    are created at the time the elements are added to the process and those relationships reflect the relationships as&#xD;
    resolved in the processes' default configuration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The descriptor text and relationships can be changed directly in the process. If the descriptors are associated with&#xD;
    method content elements, such descriptor changes do not affect the associated method content elements (they are&#xD;
    considered local process changes).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Perform the following steps to change the role, task or work product descriptors directly in a customized process:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Create a new plug-in to contain the customized process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Copy the original process and place the copy in the new plug-in.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the descriptor textual descriptions or relationships directly in the new process. The process now includes&#xD;
        the descriptor changes.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the definition of the new process to specify that it is to replace the original process.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Change the process flow&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The process flow is the flow between the activities or task descriptors in the process. You can change the flow by&#xD;
    changing the predecessors of the activities and the task descriptors. This can be done directly in the work breakdown&#xD;
    structure, or, if there is an associated activity diagram,&amp;nbsp;by changing the control flow between the elements on&#xD;
    the activity diagram. For more information creating a new or changing and existing activity diagram, see the process&#xD;
    diagram section of this guideline.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Even if the elements in the process are associated with method content elements, changing the flow between the elements&#xD;
    in a process does not affect the associated method content elements (flow changes are considered local process&#xD;
    changes).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Perform the following steps to change the process flow of an existing process:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Create a new plug-in to contain the customized process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Copy the original process and place the copy in the new plug-in.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the predecessors in the work breakdown structure, as needed to obtain the desired flow, or, if there is an&#xD;
        associated activity diagram,&amp;nbsp;change the control flow in the activity diagram. The process flow is now&#xD;
        changed.&amp;nbsp;&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the definition of the new process to specify that it is to replace the original process.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h4>&#xD;
    Add a new, or change an existing, process diagram&amp;nbsp;&amp;nbsp;&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    There are two types of process diagrams, activity diagrams and activity detail diagrams. For more information on these&#xD;
    diagrams and when and how they can be used, see the topic Defining Processes above.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Perform the following steps to add a new, or change an existing, process diagram:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Create a new plug-in to contain the customized process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Copy the original process and place the copy in the new plug-in.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Create a new or change an existing process diagram, at the desired levels in the process. The process now contains&#xD;
        the desired process diagram.&amp;nbsp;&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Change the definition of the new process to specify that it is to replace the original process.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Defining a Practice Configuration Process&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Defining a cross-practice process is where you turn your attention to the process/lifecycle side of things. How should&#xD;
    the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html&quot;&#xD;
    guid=&quot;_x459ktnmEdmO6L4XMImrsA&quot;>task&lt;/a>s and/or &lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/activity_1D028230.html&quot;&#xD;
    guid=&quot;_yoVhMB_IEdq6CKKKq4D7YA&quot;>activities&lt;/a> (i.e., &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/capability_pattern_F5DDC5F.html&quot;&#xD;
    guid=&quot;_2RUJACO4EdqaNq6Ptg8uyA&quot;>capability pattern&lt;/a>s) from the individual &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/concepts/practice_F5C8EAAB.html&quot;&#xD;
    guid=&quot;_qhCTAFRREd2CWscN8Mx6rg&quot;>Practice&lt;/a>s &quot;flow&quot; together? Are there any activities that always appear together and&#xD;
    in what order do they appear? Are there specific sets of activities that can be reused together in more course-grained&#xD;
    flows?&amp;nbsp;What does an overall lifecycle look like? Define cross-practice processes to&amp;nbsp;reflect these&#xD;
    decisions.&amp;nbsp;Specifically, define&amp;nbsp;capability patterns for sets of capability patterns that always appear&#xD;
    together and can be reused in other capability patterns, and define &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/delivery_process_BCDF50B7.html&quot;&#xD;
    guid=&quot;_ZufeMCO3EdqaNq6Ptg8uyA&quot;>delivery process&lt;/a>es for overall lifecycles. Defining cross-practice&#xD;
    processes&amp;nbsp;defines an overall flow through the practices and validates that you have the right practice content&#xD;
    with the right separation of concerns.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Perform the following steps to create a cross-practice process:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        If one does not exist, create a Publish Base plug-in to contain the new process.&amp;nbsp;&amp;nbsp;&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Create a Publishable&amp;nbsp;&lt;a class=&quot;elementLink&quot;&#xD;
        href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/method_configuration_C2B8FA8A.html&quot;&#xD;
        guid=&quot;__V7pAMaEEduMlb2cQZNTYw&quot;>method configuration&lt;/a>&amp;nbsp;that includes the the necessary core plug-ins (include&#xD;
        role and standard category definitions), the&amp;nbsp;new Publish plug-in, the practices (including the desired&#xD;
        practice role assignments),&amp;nbsp;and any cross-practice processes you are interested in including in your&#xD;
        cross-practice process (remember all processes must have a default configuration).&lt;br />&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Create the cross-practice process, specifying the new configuration as the default configuration. Assemble the&#xD;
        cross-practice process using the method elements (&lt;a class=&quot;elementLink&quot;&#xD;
        href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html&quot;&#xD;
        guid=&quot;_x459ktnmEdmO6L4XMImrsA&quot;>task&lt;/a>s, &lt;a class=&quot;elementLink&quot;&#xD;
        href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/capability_pattern_F5DDC5F.html&quot;&#xD;
        guid=&quot;_2RUJACO4EdqaNq6Ptg8uyA&quot;>capability pattern&lt;/a>s) from the Process Construction configuration, defining as&#xD;
        many levels (i.e., nested activities) as are needed. In some cases, there may even be reference workflows from the&#xD;
        individual practices that you can use for ideas for the process you are building. When assembling cross-practice&#xD;
        processes, the processes that are used (i.e., the capability patterns that are applied) from the practices must be&#xD;
        &lt;u>&lt;em>copied&lt;/em>&lt;/u> instead of &lt;u>&lt;em>extended&lt;/em>&lt;/u> so that the process descriptors are built using the&#xD;
        default configuration for the cross-practice process.&amp;nbsp;&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    In summary, practices provide the pieces parts (tasks and capability patterns) and may even provide some good process&#xD;
    patterns e.g., reference workflows), but in the end, it is the person creating the a process that must decide the order&#xD;
    and levels (the level of nesting of the activities) of the process, using any and all available method content elements&#xD;
    and/or process patterns.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
