<?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" xmi:id="-3-dQexlo60KWmf-dX660UA"
    name="dsdm_roles,_IWDX4FlnEdu-hcil0jQ6jA" guid="-3-dQexlo60KWmf-dX660UA" changeDate="2006-10-27T03:38:00.957-0700"
    version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    Introduction&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    People working together effectively is the foundation of any successful project. DSDM recognises this and assigns clear&#xD;
    roles and responsibilities to each person in a project, both from the customer and supplier side of the project. These&#xD;
    two communities work very closely together in DSDM projects - there is no &quot;us and them&quot;.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The first part of this section covers the DSDM roles added to OpenUP using this plugin. The rest of the section&#xD;
    describes how teams operate and are organised in DSDM projects.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    People and Roles in DSDM Projects&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The DSDM roles to be filled are listed above. It is emphasised that these roles do not necessarily relate to&#xD;
    individuals on a one-to-one basis. One person may cover one or more roles, and a role could be split between one or&#xD;
    more people.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The roles allow for a large project, split into a number of development teams working concurrently, or at least&#xD;
    overlapping in terms of the development time frame.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span>It is understood that such things as geographical constraints and staff availability can impact the setting up of&#xD;
    the ideal team, but it is strongly recommended that the roles are all considered and their individual responsibilities&#xD;
    assigned as appropriate. They can be used as the basis for personal terms of reference for the project.&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Team_dynamics&quot; name=&quot;Team_dynamics&quot;>Team dynamics&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The main benefits of the DSDM approach arise from users (customers) being closely involved in the development teams. So&#xD;
    what is the best team structure for a DSDM project to maximise the benefit of user involvement? It is important that&#xD;
    the team is not too large, ideally no more than six people including users. The users must be allocated the time to&#xD;
    really get involved, and feel involved, so that they take ownership of the application being built.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;The_anti-fault_philosophy&quot; name=&quot;The_anti-fault_philosophy&quot;>The anti-fault philosophy&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Traditionally in IT/IS projects, the functional specification has been used as the final arbiter of what is or is not&#xD;
    in scope or intended. When the requirements are vague or ambiguous, the way is open for arguments and recriminations as&#xD;
    to whose fault it is, who should pay, and whether the developer should have known &quot;because it was obvious&quot;. Joint&#xD;
    responsibility and development avoid this, but if traditional roles and ideas are allowed to persist, the dangers are&#xD;
    greater. If developers and users do not work together as a team and if they adopt their traditional roles and&#xD;
    positions, there is no detailed specification to refer back to.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is essential that individual responsibility is understood and taken, but also that, as in any team, if problems do&#xD;
    develop, it is seen as a team failure rather than an individual's, and that the team continues to work together to&#xD;
    resolve the difficulty. Users and developers have equal responsibility for the development.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Team_management&quot; name=&quot;Team_management&quot;>Team management&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    In a DSDM team, the issue of how to organise the team structure and management arises. Within a peer team, roles are&#xD;
    discussed and allocated by the team members based on an appraisal of each individual's inherent skills, personal&#xD;
    characteristics and experience.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In general, traditional hierarchical team structures do not encourage the flexible working practices and open&#xD;
    communications so necessary for the DSDM approach to work, but the team members may decide to adopt any structure that&#xD;
    works for them. Since DSDM teams are a temporary social structure that must be effective from the very start, extra&#xD;
    effort in building the team mentality is essential when the team is originally formed. Team-building activities are&#xD;
    strongly recommended early on and whenever it is necessary to bring in a new team member.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The Project Manager can be from the business or the IT department. However, the basic rules are that the Project&#xD;
    Manager must:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        understand the business issues&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        empathise with the users&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        understand the technical issues.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    The last consideration means that usually Project Managers come from an IT background, as their skills in computer&#xD;
    system development have been acquired over many years. It is unrealistic to expect user personnel to understand all the&#xD;
    IT-related issues that have to be addressed, without some direct support from the IT department. &lt;span     style=&quot;FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-GB; mso-fareast-language: EN-US; mso-bidi-language: AR-SA&quot;>On&#xD;
    large projects the Project Manager would not be part of any individual team. The Project manager may also manage more&#xD;
    than one project concurrently.&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    One important aspect of the Project Manager role is that of arbitration. Where there is discussion about the relative&#xD;
    priorities or merits of some aspect of the system under development, the Project Manager does not supply the decision&#xD;
    but assists the parties involved in deciding the best approach for the project.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Motivating the team should not be too much of a problem in the early stages of the project. However if things start to&#xD;
    go wrong the impetus to deliver can disappear. User team members are particularly prone to losing their initial&#xD;
    enthusiasm, since they are not so inured to the many setbacks that can face an IT project. To avoid this, the team&#xD;
    should plan for social activities that enable the team to get together and talk about things other than work.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>