<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription 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:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-wBOoiWwZUP1LDeCTqoNMBQ" name="new_artifact,_2CEzsLrREd-0rKmWr1vEGQ" guid="-wBOoiWwZUP1LDeCTqoNMBQ" changeDate="2010-09-07T15:48:43.389-0700" version="7.5.1">
  <mainDescription>&lt;p>&#xD;
    A project process typically describes or references the following items:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        what organizational processes and policies must be adhered to.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        what standard process, if any, is being adopted by the project.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        any tailoring of the standard process, or deviations from policy mandates.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        rationale for tailoring and deviations.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        approvals for deviations.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        which work products are reviewed at which milestones, and their level of completion.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        guidelines and information that the project wants to use in addition to the information contained in the main.&#xD;
        process&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        what reviews will be performed, and their level of formality.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        what approvals are required, by whom, and when.&#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
  <purpose>The purpose of the project process is to provide guidance and support for the members of the project. &quot;Information at your&#xD;
finger tips&quot; is a metaphor that aligns well with the purpose of this work product.</purpose>
  <impactOfNotHaving>&lt;br />&#xD;
&lt;p>&#xD;
    All teams have a process, although it may be ad-hoc. A defined process helps team members understand their&#xD;
    responsibilities and capture lessons learned. A team that follows an ad-hoc process is at risk of being confused in&#xD;
    terms of responsibilities, may miss opportunities to learn from experience, and is at risk of violating organizational&#xD;
    process requirements.&#xD;
&lt;/p></impactOfNotHaving>
  <reasonsForNotNeeding>An ad-hoc process may be acceptable when there are no organizational process requirements, the team members understand&#xD;
their responsibilities and are comfortable working without a defined process.</reasonsForNotNeeding>
  <representationOptions>Processes can be captured informally in documents, formally captured in a Method Composer configuration, or specified by&#xD;
configuring tools. Typically a project will use a combination of these: start with a Method Composer configuration, create&#xD;
a document to describe variations from this configuration, and configure tools to support the process being followed.</representationOptions>
</org.eclipse.epf.uma:ArtifactDescription>