| <?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="-qyfAeChj5qzBMDwwd23uRw" |
| name="facilitated_workshops,_CCwbMFkiEdul8L-IGeA7TA" guid="-qyfAeChj5qzBMDwwd23uRw" |
| changeDate="2006-10-27T03:31:06.047-0700" version="1.0.0"> |
| <mainDescription><h3>
 |
| <a id="Introduction" name="Introduction">Introduction</a>
 |
| </h3>
 |
| <p>
 |
| Facilitated Workshops have been used in business and systems development in particular for years. Initially they were
 |
| used for JRP (Joint Requirements Planning) and JAD (Joint Application Design) but their usefulness was quickly seen in
 |
| other areas.
 |
| </p>
 |
| <p>
 |
| They are a core technique in DSDM for speed and efficiency as a way of making high quality team-based decisions in
 |
| short timescales.
 |
| </p>
 |
| <p>
 |
| <span>&#160;Whether they are used for DSDM or any other business project, they are run in the same way. This section
 |
| examines how the approach maps directly onto DSDM and where in DSDM they can be used. It seeks to show the potential of
 |
| possible use of Facilitated Workshops in a DSDM project, rather than mandate their use at any particular point. It is
 |
| up to the project members themselves to decide whether a workshop is necessary, or whether another technique, such as
 |
| interviewing or research is more applicable.</span>
 |
| </p>
 |
| <p>
 |
| Used properly, Facilitated Workshops are a useful tool for effecting cultural change in an organisation because they
 |
| promote buy-in from and empowerment of participants. When used effectively, they can set the tone for the whole
 |
| project.
 |
| </p>
 |
| <p>
 |
| Note: It is not intended to explain here how to set up and run facilitated workshops but to show how the technique can
 |
| be applied to DSDM projects.
 |
| </p>
 |
| <h3>
 |
| <a id="What_are_Facilitated_Workshops" name="What_are_Facilitated_Workshops">What are Facilitated Workshops?</a>
 |
| </h3>
 |
| <h4>
 |
| Definition
 |
| </h4>
 |
| <p>
 |
| A facilitated workshop is a structured approach to ensure that a group of people can reach a predetermined objective in
 |
| a compressed timeframe, supported by an impartial facilitator.
 |
| </p>
 |
| <h4>
 |
| Benefits
 |
| </h4>
 |
| <p>
 |
| Using Facilitated Workshops brings both direct and indirect benefits to a project.
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Rapid, quality decision-making.</strong> Because all stakeholders are present at the same time, there is
 |
| great confidence in the result. The group is focused on the objectives to be achieved in the session so that the
 |
| information gathering and review cycle is performed at a greater speed. Also, misunderstandings and disagreements
 |
| can be worked out at the time. Any concerns should therefore have been raised and resolved or noted by the end of
 |
| the workshop.
 |
| </li>
 |
| <li>
 |
| <strong>Greater user buy-in.</strong> Workshops, run effectively, lead to participants feeling more involved in the
 |
| project and decisions being made. They build and maintain enthusiasm.
 |
| </li>
 |
| <li>
 |
| <strong>Building team spirit.</strong>&#160;Facilitated workshops&#160;are a controlled way of building rapport as
 |
| well as delivering the primary objectives of the workshop.&#160;They can promote understanding and co-operation
 |
| between departments, which is particularly important when a development involves many groups.
 |
| </li>
 |
| <li>
 |
| <strong>Process redesign by the user community</strong> If practices are reviewed as a result of a workshop,
 |
| participants gain a greater understanding of the inputs and implications of their work. This leads to improved
 |
| efficiencies that are&#160;driven by the participants themselves, giving greater buy-in and commitment and
 |
| therefore a greater chance of successful implementation.
 |
| </li>
 |
| <li>
 |
| <strong>Clarification of requirements when they are unclear</strong> Business users can be led through their
 |
| objectives and processes to define what they may require. In the facilitated environment, participants can explore
 |
| and model ideas. This is successful through a combination of structured discussion and the presence of
 |
| knowledgeable participants.<br />
 |
| </li>
 |
| </ul><br />
 |
| <br />
 |
| <table class="mainframe" cellspacing="0" cellpadding="0" width="100%" summary="markup" border="0">
 |
| <tbody>
 |
| <tr>
 |
| <td class="margin" valign="top" align="right" width="88">
 |
| </td>
 |
| <td class="content" valign="top" width="100%" colspan="2">
 |
| <h3>
 |
| <a id="Aligning_Workshops_to_the_DSDM_framework" name="Aligning_Workshops_to_the_DSDM_framework">Aligning Workshops to the DSDM framework</a>
 |
| </h3>
 |
| <h4>
 |
| Aligning Workshop Roles to DSDM Roles
 |
| </h4>
 |
| </td>
 |
| </tr>
 |
| </tbody>
 |
| </table><br />
 |
| <br />
 |
| 
 |
| <p>
 |
| This section gives some guidance on which DSDM roles would fill the roles of a workshop. These are defined as being
 |
| Workshop Owner, Facilitator, Participants, Scribe and Observer.<br />
 |
| <br />
 |
| </p>
 |
| <h5>
 |
| Workshop Owner
 |
| </h5>
 |
| <p>
 |
| This is the owner of the problem that the workshop is set to solve. It is up to them to set the objectives and
 |
| deliverables of the workshop, although these should also be agreed by the participants.
 |
| </p>
 |
| <p>
 |
| The owner of a Feasibility Study workshop could well be the Executive Sponsor whereas the owner of a timebox planning
 |
| session could be the Project Manager or Team Leader or even the Ambassador User.
 |
| </p>
 |
| <h5>
 |
| <a id="Facilitator" name="Facilitator"></a>Facilitator
 |
| </h5>
 |
| <p>
 |
| The Facilitator should be impartial, with no stake in the outcome of the workshop, and therefore should come from
 |
| outside the project. The Facilitator maps directly onto the DSDM role.
 |
| </p>
 |
| <h5>
 |
| Participant
 |
| </h5>
 |
| <p>
 |
| Participants represent the views of the project stakeholders (e.g. the business and software development community).
 |
| They are the individuals who are knowledgeable in the areas under consideration. They manage and operate the system and
 |
| include managers, supervisors, clerical staff, and IT staff.
 |
| </p>
 |
| <p>
 |
| A participant could be one of many roles within the business or IT side. They could be a business user, a customer, a
 |
| supplier, a business analyst or data modeller or systems architect, a member of the financial staff, an auditor, or
 |
| indeed any of the core DSDM or specialist roles.
 |
| </p>
 |
| <h5>
 |
| Observer
 |
| </h5>
 |
| <p>
 |
| Observers are not allowed to contribute towards the output of the workshop. If they need to take part at all, they
 |
| should be Participants. Examples of the use of an Observer are therefore limited but could include someone auditing the
 |
| workshop process or the facilitator's ability, or a trainee facilitator who would want to observe the group dynamics
 |
| without being part of the group. Observers could also be development or support staff gathering useful background, but
 |
| in these cases it should be checked whether they should really be contributing to the session.
 |
| </p>
 |
| <h5>
 |
| <a id="Scribe" name="Scribe"></a>Scribe
 |
| </h5>
 |
| <p>
 |
| The Scribe records what is happening within the workshop. The role could be held by a co-facilitator, a business
 |
| analyst, developer or user so long as the individual has the required understanding of the issues in order to know what
 |
| to record. There may be two Scribes in a workshop. For example, one of the Developers might use a CASE tool to directly
 |
| model what's being discussed while another scribe takes down the discussion notes for later reference.
 |
| </p>
 |
| <h4>
 |
| Applying the DSDM principles
 |
| </h4>
 |
| <p>
 |
| Facilitated Workshops are like a DSDM project in miniature with defined deliverables in a tight timescale and empowered
 |
| users. Early workshops can build the foundation for this approach to continue throughout the project. This list below
 |
| shows how the DSDM Principles apply in Facilitated Workshops.
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Active user involvement is imperative.</strong> Workshops provide an ideal format for the business to be
 |
| directly involved in planning, designing and implementing a solution.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <strong>DSDM teams must be empowered to make decisions.</strong> Workshop participants need to be empowered and
 |
| have the right level of knowledge and authority within the scope of the workshop, so that decisions can be made
 |
| without delay.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <strong>The focus is on frequent delivery of products.</strong> It is good practice to structure a workshop so that
 |
| there are intermediate deliverables. It helps to order participants' thinking as they progress in logical steps.
 |
| This enables them to work towards an ultimate goal and gives them a growing sense of achievement as the workshop
 |
| progresses.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <strong>Fitness for purpose is the essential criterion for acceptance of deliverables.</strong> The Facilitator
 |
| checks that fitness for purpose is achieved by keeping participants focused on delivery against an agreed set of
 |
| objectives. They ensure all are involved in decision-making.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <strong>Iterative and incremental prototyping is necessary to converge on an accurate business solution.</strong>
 |
| One of the strengths of workshops is the synergy achieved by the group. Ideas do not have to be born fully
 |
| developed but can grow during discussion. In effect, they are being prototyped. It is an ideal setting to try out
 |
| ideas with all stakeholders and it is up to the facilitator to provide a safe environment in which this may
 |
| happen.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <strong>All changes during development are reversible.</strong> Information and decisions should be recorded as
 |
| necessary by either one or both of the facilitator and scribe so that ideas can be backtracked where necessary.
 |
| Often what happens in practice is that an idea or decision is redeveloped.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <strong>Requirements are baselined at a high level.</strong> Objectives must be set during the preparation for a
 |
| workshop. As the workshop progresses, information is gathered, analysed and interpreted so that discussion can be
 |
| effective and a decision reached as a result of an increased understanding of the issues involved.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <strong>Testing is integrated throughout the lifecycle.</strong> Because all stakeholders are present, this
 |
| provides the quality control approach of testing ideas and deliverables as they are discussed. Participants have
 |
| the opportunity to challenge or agree.<br />
 |
| <br />
 |
| </li>
 |
| <li>
 |
| <strong>A collaborative and co-operative approach between all stakeholders is essential.</strong> The facilitator
 |
| is responsible for creating the climate of co-operation within the workshop and enforcing any ground rules for the
 |
| group to behave effectively. This is only possible with the co-operation and commitment of all stakeholders. It is
 |
| an effective way of achieving either compromise or consensus.
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| <a id="Workshops_in_the_DSDM_lifecycle" name="Workshops_in_the_DSDM_lifecycle">Workshops in the DSDM lifecycle</a>
 |
| </h4>
 |
| <p>
 |
| The list below gives suggestions for the types of workshop that could be run during a project. Some of them could be
 |
| combined and become sessions within a longer workshop. Depending on the size and complexity of the problems being
 |
| addressed, it may not be necessary to obtain answers and decisions through a formal workshop although workshop
 |
| techniques could still be used in an interactive session. The duration of workshops varies from project to project.
 |
| </p><br />
 |
| <br />
 |
| <table class="inline" bordercolor="#990000" cellspacing="0" cellpadding="2" width="95%" border="1">
 |
| <tbody>
 |
| <tr valign="top">
 |
| <td>
 |
| Business case<br />
 |
| Context setting<br />
 |
| Configuration management strategy<br />
 |
| Contingency planning<br />
 |
| Cutover plans<br />
 |
| Data conversion requirements<br />
 |
| Data modelling<br />
 |
| Escalation procedure definition<br />
 |
| Estimates<br />
 |
| Feasibility prototype<br />
 |
| Feasibility prototype review<br />
 |
| Functional modelling<br />
 |
| Implementation plan<br />
 |
| Outline planning<br />
 |
| Development planning<br />
 |
| Prioritisation<br />
 |
| Problem definition<br />
 |
| Problem resolution<br />
 |
| Process and roles<br />
 |
| Process modelling<br />
 |
| Increment review
 |
| </td>
 |
| <td>
 |
| Prototype design<br />
 |
| Prototype review<br />
 |
| Prototyping strategy<br />
 |
| Requirements change control<br />
 |
| Requirements gathering<br />
 |
| Risk mitigation planning<br />
 |
| Roles and responsibilities<br />
 |
| Scenario modelling<br />
 |
| Solution options evaluations<br />
 |
| Suitability/Risk List<br />
 |
| Support level definition<br />
 |
| System architecture definition<br />
 |
| Test plans<br />
 |
| Test reviews<br />
 |
| Test strategy<br />
 |
| Timebox planning<br />
 |
| Timeboxing strategy<br />
 |
| Training needs analysis<br />
 |
| Training plans<br />
 |
| User classes<br />
 |
| User documentation requirements
 |
| </td>
 |
| </tr>
 |
| </tbody>
 |
| </table>
 |
| <h3>
 |
| <br />
 |
| <span><a id="How_to_achieve_successful_workshops" name="How_to_achieve_successful_workshops">How to achieve successful
 |
| workshops</a></span>
 |
| </h3>
 |
| <h4>
 |
| The Facilitator<br />
 |
| <br />
 |
| </h4>
 |
| <table class="mainframe" cellspacing="0" cellpadding="0" width="100%" summary="markup" border="0">
 |
| <tbody>
 |
| <tr>
 |
| <td class="margin" valign="top" align="right" width="88">
 |
| </td>
 |
| <td class="content" valign="top" width="100%" colspan="2">
 |
| <p>
 |
| Workshops should be run by skilled facilitators. They should be impartial to the issues under
 |
| discussion with no stake in the outcome. An ineffective facilitator can bias a workshop or at worst
 |
| lead to its failure. It is a highly skilled role requiring sensitivity, diplomacy, quick thinking and
 |
| highly developed communication skills. The role of the Facilitator is not one to be taken lightly. It
 |
| is a skilled job and is instrumental in ensuring a workshop is successful. One way to ensure an
 |
| effective facilitator is to use one who has been accredited by&#160;GlobalNF (<a href="http://www.globalfn.org/" target="_blank">www.globalfn.org</a>).
 |
| </p>
 |
| </td>
 |
| </tr>
 |
| </tbody>
 |
| </table>
 |
| <p>
 |
| The role of the Facilitator is to concentrate on the workshop process so that all participants have an equal
 |
| opportunity to contribute. The main task of the Facilitator is to deal with all of the "people" aspects of the
 |
| workshops by getting participants to work as a team. The Facilitator documents results and decisions on flip-charts,
 |
| for example, that act as "group memory". The Facilitator does not contribute to the content of the workshop.
 |
| </p>
 |
| <h4>
 |
| Objectives
 |
| </h4><br />
 |
| <br />
 |
| <table class="mainframe" cellspacing="0" cellpadding="0" width="100%" summary="markup" border="0">
 |
| <tbody>
 |
| <tr>
 |
| <td class="margin" valign="top" align="right" width="88">
 |
| </td>
 |
| <td class="content" valign="top" width="100%" colspan="2">
 |
| <p>
 |
| Objectives should be set for the workshop and checked for their alignment with the scope of the whole
 |
| project. They should be set by the Owner and agreed by Participants, but the Facilitator should check
 |
| for measurability and any priority.
 |
| </p>
 |
| <h4>
 |
| Scope
 |
| </h4>
 |
| <p>
 |
| Along with the objectives, the scope of the workshop should be defined. This could be described in
 |
| terms of business functions, organisational lines or other defining limits.
 |
| </p>
 |
| <h4>
 |
| Participants
 |
| </h4>
 |
| <p>
 |
| Without the right people present for the workshop, a quality solution cannot be reached. The Owner
 |
| should suggest who the participants should be but this should be reviewed by the participants
 |
| themselves. They need to be committed, empowered and prepared.
 |
| </p>
 |
| <h4>
 |
| Intermediate deliverables
 |
| </h4>
 |
| <p>
 |
| <span>If the workshop is structured so that the road to the final deliverable is staged, it will make
 |
| it easier to review progress is in the right direction.</span>
 |
| </p>
 |
| <h4>
 |
| Workshop reports
 |
| </h4>
 |
| </td>
 |
| </tr>
 |
| </tbody>
 |
| </table>Workshop outputs should be produced as soon as possible after the workshop. An efficient Scribe, working with a
 |
| computer during the sessions, may be able to provide outputs for participants to go away with.<br /></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
