| <?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><p>
 |
| A project process typically describes or references the following items:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| what organizational processes and policies must be adhered to.
 |
| </li>
 |
| <li>
 |
| what standard process, if any, is being adopted by the project.
 |
| </li>
 |
| <li>
 |
| any tailoring of the standard process, or deviations from policy mandates.
 |
| </li>
 |
| <li>
 |
| rationale for tailoring and deviations.
 |
| </li>
 |
| <li>
 |
| approvals for deviations.
 |
| </li>
 |
| <li>
 |
| which work products are reviewed at which milestones, and their level of completion.
 |
| </li>
 |
| <li>
 |
| guidelines and information that the project wants to use in addition to the information contained in the main.
 |
| process
 |
| </li>
 |
| <li>
 |
| what reviews will be performed, and their level of formality.
 |
| </li>
 |
| <li>
 |
| what approvals are required, by whom, and when.
 |
| </li>
 |
| </ul></mainDescription> |
| <purpose>The purpose of the project process is to provide guidance and support for the members of the project. "Information at your
 |
| finger tips" is a metaphor that aligns well with the purpose of this work product.</purpose> |
| <impactOfNotHaving><br />
 |
| <p>
 |
| All teams have a process, although it may be ad-hoc. A defined process helps team members understand their
 |
| responsibilities and capture lessons learned. A team that follows an ad-hoc process is at risk of being confused in
 |
| terms of responsibilities, may miss opportunities to learn from experience, and is at risk of violating organizational
 |
| process requirements.
 |
| </p></impactOfNotHaving> |
| <reasonsForNotNeeding>An ad-hoc process may be acceptable when there are no organizational process requirements, the team members understand
 |
| 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
 |
| configuring tools. Typically a project will use a combination of these: start with a Method Composer configuration, create
 |
| a document to describe variations from this configuration, and configure tools to support the process being followed.</representationOptions> |
| </org.eclipse.epf.uma:ArtifactDescription> |
