Instrumental Success Factors, DSDM Process and Products Flashcards

1
Q

Embracing the DSDM Approach’?

A

This means that success is much more likely when all the stakeholders understand and accept the DSDM project approach.

This involves understanding the DSDM philosophy that ‘best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people.

It’s also important that the stakeholders understand that to deliver the right thing at the right time whilst handling change dynamically, may require the project to deliver less that the 100% solution.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
1
Q

what does ISFs stand for and what does it mean?

A

Instrumental Success Factors or ISFs help to ensure DSDM projects have successful outcomes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

People are at the heart of a DSDM project and the Solution Development Team is key to

A

developing the right solution

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Building a successful team depends on:

A
  • Empowerment
  • Stability
  • Skills, and
  • Size
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Each role in the team should be empowered to make decisions based on their

A

expertise and the whole team should be empowered to make decisions within the boundaries specified in the Foundation phase.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

The senior business and technical stakeholders appoint people within the Solution Development Team who have the

A

desire, authority and knowledge required to make the decisions on a day-to-day basis.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

As well as being empowered the team should be

A

stable, this means people in the team should stay there for the duration of the project

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

DSDM suggests that the ideal team size is

A

seven plus or minus two people. If more people are required then they should be split into multiple Solution Development Teams.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

If your DSDM project is going to be successful then the commitment and engagement of the business is essential, this relies on three elements:

A
  • commitment of business time throughout
  • day-to-day collaboration involving business roles in the Iterative Development of the solution, and
  • A supportive relationship between the customer and supplier organisations
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

In the early stages of the project business engagement and business time is needed to

A

get the project off to a good start.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

In the later stages this ongoing commitment is needed to help guide the

A

detail of the solution development.

This means that the business roles should be frequently involved with the team to help guide the evolution of the solution.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

it is very important that the sponsoring business and the supplier organisation both support collaborative working.

A

This improves the efficiency of the development of the Evolving Solution without any onerous overhead associated with change at the detailed level.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Every Timebox should ideally deliver a

A

complete and potentially deployable increment of the solution, and this should include integrated testing.
This testing ensures that the development is acceptable before moving on, any errors can be found early in the cycle of development and corrected.

This helps to reduce the costs associated with rework which would be excessive if these tests were left until later in the development cycle.

Finally, if the organisation is happy to deploy increments of the solution into live use it will benefit from an early return of investment.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

The final two ISFs are Transparency and the Project Approach Questionnaire - Assessing Options and Risks

Transparency ensures that …..?

A

progress on ongoing work is clearly displayed to all.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

At the end of each Timebox demonstrations provide

A

physical, objective and unquestionable proof that the Evolving Solution is fit for purpose.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Additionally Team Boards and Daily Stand-ups provide

A

clear and up-to-date information about the work in progress.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Finally, the Project Approach Questionnaire, or PAQ, provides a

A

simple checklist to assess whether the factors we have just discussed are likely to be met or whether action is needed to encourage them or mitigate the risks of them being undermined.

The PAQ is established in the Feasibility phase to help shape the work of the Foundations phase.

Towards the end of the Foundations phase it is used to finalise the approach to be taken for the development and delivery of the project and it also helps to drive active management of the project risks.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

what is Feasibility?

A

where we decide whether the project is viable from both the technical and business perspective

18
Q

During Feasibility we create ………. evolutionary products and one milestone product.

A

6

19
Q

During Feasibility we create six evolutionary products and one milestone product.

Two of the evolutionary products are

A

business focussed and coloured orange and they are the Business Case and the Prioritised Requirements List.

20
Q

The business vision tells us what

A

the changed business will look like both incrementally as we release the solution and in its final state.

21
Q

The justification typically documents the investment appraisal and tells us

A

why the cost and effort is worthwhile.

22
Q

Feasibility Phase:

A

Definition: The phase where the viability of the project is assessed from both technical and business perspectives.

Duration: Short and sharp, similar to the Pre-Project phase.

Purpose: Focuses on justifying the Foundations phase.

23
Q

Evolutionary Products in Feasibility:

A

Products Created: Six evolutionary products and one milestone product.

Business-Focused Products: Business Case and Prioritised Requirements List (PRL).

Color Code: Business-focused products are colored orange.

24
Q

Business Case:

A

Definition: Provides vision and justification for the project.

Business Vision: Describes the changed business incrementally and in its final state.

Justification: Documents the investment appraisal, explaining the worth of the cost and effort.

Baseline: Baseline at the end of Feasibility, updated at the end of each phase.

25
Q

Business Case Review:

A

Frequency: Reviewed at the end of each Project Increment.

Purpose of Review: Decides whether further work is justified.

Baseline Update: Updated at the end of each phase when new baselines are created.

26
Q

Prioritised Requirements List (PRL):

A

Description: Describes high-level requirements at a glance.
Timeline: Considered in Feasibility, detailed in Foundations.
Baselining: Baselined in Foundations, forming the project’s scope.

27
Q

Requirements Management:

A

Development Stage: Requirements are thought about in Feasibility and explored further in Foundations.

Change Control: Formal change control for any changes to high-level requirements’ breadth, such as additions or removals.

28
Q

Delivery Plan

A

Contents: Schedule of Project Increments and Timeboxes.

Focus: Task level details considered, especially for external contributors.

Usage: Guides the execution of the project.

29
Q

Management Approach Definition

A

Contents: Guidelines for project management.

Includes: Organization and planning, stakeholder engagement, progress monitoring, control, and reporting standards.

Evolution: Created in Feasibility, evolves and may be baselined in Foundations if circumstances change.

30
Q

Feasibility Assessment

A

Type: Milestone Product

Contents: Snapshot of evolving products.

Purpose: Decision-making for project continuation into Foundations phase.

Role: Informs decision-making and contributes to governance processes.

31
Q

Foundations Phase Overview

A

Purpose: Establish fundamental understanding of project’s business rationale, potential solution, and management approach.

Requirements Detail: Postponed to Evolutionary Development phase.

Main Aim: Understand scope and project lifecycle application of DSDM process.

32
Q

Feasibility and Foundations Phases

A

Small Projects: Often combined Feasibility and Foundations.

Larger Projects: May revisit Foundations after each Deployment phase.

33
Q

Foundation Summary

A

Type: Milestone Product

Contents: Snapshot of evolving business, solution, and management products.

Purpose: Decision-making for project continuation.

Role: Informs decision-making and contributes to the governance process.

34
Q

Evolutionary Development Overview

A

Phase: Evolutionary Development

Role: Major phase for solution development.

Practices: Involves Iterative Development, Timeboxing, and MoSCoW prioritization.
Key Activities: Modelling and Facilitated Workshops.

35
Q

Practices in Evolutionary Development

A

Used Practices: Iterative Development, Timeboxing, MoSCoW prioritization.

Purpose: Evolve the solution to meet business needs and ensure correct technical implementation.

Upcoming Topics: Modelling and Facilitated Workshops.

36
Q

Solution Increments in Timeboxes

A

Key Activity: Within each Timebox.

Role: Solution Development Team creates Solution Increments.

Focus: Explore low-level details of requirements.

Testing Approach: Iterative testing as progress is made.

37
Q

Evolving Products in Evolutionary Development

A

Products:
Evolving Solution
Timebox Plan
Timebox Review Record

Purpose: Products evolve the solution and facilitate iterative development.

38
Q

The Evolving Solution is made up of the

A

components of the final solution together with any intermediate deliverables that we need to explore the details of the requirements.

At any particular time these components can be complete, a baseline of the partial solution which is called a Solution Increment or a work in progress.

We often use models, prototypes, supporting materials and testing and review artefacts as part of the Evolving Solution.

At the end of each Project Increment the Solution Increment is deployed into live use and becomes the Deployed Solution.

39
Q

Timebox Plan

A

This product describes the work of the Solution Development Team and there is one plan for each Timebox defined in the Delivery Plan.

It tells us what work has to be done, who will do it and any other resources we need and most importantly what the deliverables are.

It’s used as the basis for the Daily Stand-Ups where we update the Timebox Plan.

Normally we use the Team Board to display the plan showing work to do, work in progress and work completed.

40
Q

Timebox Review Record

A

This tells us about the feedback from each review we’ve completed during the Timebox, the achievements to date and any feedback that may affect future plans.

This document can be a formal auditable record in more regulated environments for example and if this is the case then it becomes an important governance product

41
Q

The next phase is Deployment where we bring a baseline of the Evolving Solution into operational use.

This could be a subset of the final solution or the final solution itself.

There is only one product created in this phase which is

A

the Project Review Report.

This is a milestone product which is updated incrementally after each Project Increment.

The Report has three main purposes.

Firstly it captures feedback from the review of the delivered solution and confirms what has, and hasn’t been delivered.

Secondly, we use it to capture lessons from the review or retrospective of the increment and finally we use it to describe the business benefits we expect through the proper use of the solution.

After the final Project Increment a full review, or retrospective, of the entire project is carried out and this is informed in part by the Project Review Report.

42
Q

so we come to the final phase called Post-Project.

A

The purpose of this phase is to discover whether the expected business benefits have been delivered or not.

We will produce a milestone product called a Benefits Assessment which describes which benefits have accrued following a period of live use.

In larger projects we may undertake a number of benefit reviews and produce a number of assessments.