blob: 9fbba2cd000378f6bed7aa44e67e05f28fe42849 [file] [log] [blame]
<?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="-ebKPqn9bWfbh1K2spgOwWQ"
name="project_lifecycle,_nSfVwCNYEdyCq8v2ZO4QcA" guid="-ebKPqn9bWfbh1K2spgOwWQ"
changeDate="2010-05-10T09:11:56.360-0700" version="7.2.0">
<mainDescription>&lt;h3>&#xD;
Overview&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
Although the entire purpose of a project is to produce a product, the specific goals of the team will vary&#xD;
substantially throughout the project. In the beginning, there usually is considerable latitude in the requirements for&#xD;
the product. It may not be clear whether the project is feasible or even if it is likely to be profitable. At that&#xD;
time, it is critical to bring an answer to these questions and of little to no value to start developing the product in&#xD;
earnest.&amp;nbsp;Toward the end of the project, the product itself is usually complete, and issues of quality, delivery,&#xD;
and completeness then take center stage. At different points in time, tasks are undertaken in new ways and work&#xD;
products will have new content.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
To coordinate the team's efforts in a manner that takes these fundamental observations into account, the project&#xD;
lifecycle should be divided into a sequence of phases. Each phase has a defined set of goals, a particular iteration&#xD;
style, and customized&amp;nbsp; &lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html&quot;&#xD;
guid=&quot;_x459ktnmEdmO6L4XMImrsA&quot;>tasks&lt;/a>&amp;nbsp;and&amp;nbsp;&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
href=&quot;./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html&quot;&#xD;
guid=&quot;_H4JXwB_SEdq6CKKKq4D7YA&quot;>work products&lt;/a> to address the unique needs of the project at that point. The project&#xD;
lifecycle provides &lt;em>stakeholders&lt;/em> with oversight, transparency, and steering mechanisms to control project&#xD;
funding, scope, risk exposure, value provided, and other aspects of the process.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
It helps to organize iterations into phases. Each phase ends with a milestone aimed at providing oversight by raising&#xD;
and answering a set of questions that are typically critical to stakeholders:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
&lt;li>&#xD;
&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
href=&quot;./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase_C4456871.html&quot;&#xD;
guid=&quot;_0hmKgBOMEduCNqgZdt_OaA&quot;>Inception&lt;/a>. Do we agree on project scope and objectives and whether or not the&#xD;
project should proceed?&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
href=&quot;./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase_BE880435.html&quot;&#xD;
guid=&quot;_2plxwBOMEduCNqgZdt_OaA&quot;>Elaboration&lt;/a>. Do we agree on the executable architecture to be used for&#xD;
developing the application, and do we find that the value delivered so far and the remaining risk is acceptable?&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
href=&quot;./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase_873B6559.html&quot;&#xD;
guid=&quot;_48EKsBOMEduCNqgZdt_OaA&quot;>Construction&lt;/a>. Do we find that we have an application that is sufficiently close&#xD;
to being released that we should switch the primary focus of the team to tuning, polishing, and ensuring successful&#xD;
deployment?&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
href=&quot;./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase_DD5986E5.html&quot;&#xD;
guid=&quot;__ca5UBOMEduCNqgZdt_OaA&quot;>Transition&lt;/a>. Is the application ready to release?&#xD;
&lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
If the answer is Yes to those questions at the phase review, the project continues. If the answer is No, the phase is&#xD;
delayed (usually by adding an extra iteration) until a satisfactory answer is received, or the stakeholders may&#xD;
determine that the project should be cancelled.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
Within each phase, you might have one or several iterations, where the iterations aim at producing the results required&#xD;
to answer these questions. As an example, to answer the question for Elaboration, we typically need to implement and&#xD;
test key aspects of the system so that we understand what architecture we need, what commercial, off-the-shelf (COTS)&#xD;
components we may need, what key risks we face and how to address them, the effectiveness of the team, and so on. These&#xD;
needs will steer how we prioritize what is to be done in an Elaboration iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
One of the objectives of the project lifecycle is to focus on two key stakeholder drivers: &lt;b>risk reduction&lt;/b> and&#xD;
&lt;b>value creation&lt;/b>. As figure 1 shows, the&amp;nbsp;four phases here described focus the team on risk reduction related&#xD;
to the questions to be answered at the end of the phase, while tracking value creation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
&lt;img height=&quot;268&quot; alt=&quot;Risk goes down and value goes up as project progresses.&quot; src=&quot;./resources/project_lifecycle.jpg&quot;&#xD;
width=&quot;500&quot; />&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
&lt;strong>Figure 1 - Risk reduction (red curve) and value creation (green curve) during the project lifecycle&lt;/strong>&#xD;
&lt;/p>&#xD;
&lt;p dir=&quot;ltr&quot;>&#xD;
&lt;i>Risk&lt;/i> is a manifestation of the likelihood of unexpected things happening to the project, and risk stands in the&#xD;
way of value creation. Risk is directly proportional to uncertainty in estimates, and stakeholders typically want to&#xD;
know sooner rather than later what value the project can deliver in the stipulated time. In many cases, you reduce risk&#xD;
when you create value by implementing and testing the most critical capabilities. However, there are situations where&#xD;
risk reduction and immediate value creation are at odds with each other, requiring careful balancing of these competing&#xD;
priorities to maximize stakeholder value.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>