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