Approach

The Project Approach

The following Project Approach Questionnaire (PAQ) is a simple checklist used to assess whether the success factors described are likely to be met or whether action needs to be taken to counter the risk arising from any of them being undermined. The PAQ is first used during the Feasibility phase of the project to help shape the work of the Foundations phase and again towards the end of Foundations to help finalise the approach to be taken by the project for development and delivery and to drive active management of the project risks.

Use the Project Approach Questionnaire to indicate the closest collective opinion by marking each one and, where appropriate, comment on issues and risks related to more negative response to this aspect of the DSDM approach.

 

AgilePM (DSDM) - A Full Lifecycle overview from Pre to Post Project

All members of the project understand and accept the DSDM approach (Philosophy, Principles and Practices)

A project team will not function effectively if they do not understand DSDM, or are not given appropriate support. Organise training and briefings as required.

The Business Sponsor and the Business Visionary demonstrate clear and proactive ownership of the project.

There is no work-around for a weakness in business ownership and vision. If all engagement efforts fail, the only option is to make it clear that the solution delivered will not have business input and will be determined by the Solution Development team. This may force engagement.

The business vision driving the project is clearly stated and understood by all members of the project team

Without common understanding of a clear vision, there is a risk that time will be wasted on things with little value. Speak to the Visionary, or arrange for him/her to share their vision. Place a simple poster in the Team area to ensure the vision is visible to all. Use the Vision by asking questions such as : “Does what we are doing move us closer to achieving the vision”?

All project participants understand and accept that on-time delivery of an acceptable solution is the primary measure of success for the project

Focusses everyone on the business drivers and on-time delivery. Also discourages a quest for perfection. If no genuine deadline exists, use the PRL and estimates to derive a delivery plan that creates a target end-date.

The requirements can be prioritised and there is confidence that cost and time commitments can be met by flexing the scope of what's delivered

Challenge priorities to ensure they are realistic. Decompose requirements to create lower priority ones if possible. If insufficient feature-contingency exists, create time-contingency by adding one or more ‘contingency’ timeboxes to the plan.

All members of the project team accept that requirements should only be defined at a high level in the early phases of the project and that detail will emerge as development progresses

Defining detail too early risks it being inaccurate when work starts, does not allow the correct solution to evolve, and imposes a change-control overhead. Hold discussions with the team on why this is important. Ensure that requirements capture the business need and not an implied or suggested solution.

All members of the project team accept that change in requirements is inevitable and that it is only by embracing change that the right solution will be delivered

The Solution Development team needs to embrace change in order to deliver the optimum solution.  If  the commercial reality is “fixed price for fixed specification” the  client should prioritise the requirements, and provide the supplier with timeboxed ‘work packages’. Any changes needed should be able to be traded off against work planned for later.

The Business Sponsor and Business Visionary understand that active business involvement is essential and have the willingness and authority to commit

If the business members of the team are not always available, negotiate times when they will be available.If even this is not possible, consider the “Specification-led” approach (see white paper at dsdm.org)

It is possible for the business and solution development members of the Solution Development Team to work collaboratively throughout the project

‘Instant access’ to business roles minimises the risk of the solution evolving in the wrong way, and ideally business and technical roles should be co-located.
If access to business resources is limited, structure the timebox to maximise the use of available business time. Consider modelling and other communication tools to assist.

Empowerment of all members of the Solution Development Teaam is appropriate and sufficient to support the day-to-day decision-making needed to rapidly evolve the solution in short, focussed Timeboxes

Empowerment is essential in order to avoid decisions being delayed or over-ridden. Encourage senior authorities to play a more active role, while gradually delegating more authority.

The DSDM roles and responsibilities are appropriately allocated and all role holders understand and accept the responsibilities associated with their role

Consider specific training or workshops to clarify roles and responsibilities. Ensure a good fit of each person to the role. It is possible to transfer some responsibilities between roles if necessary but if one or more roles is unfulfilled, escalate to the Sponsor to resolve.

The Solution Development team has the appropriate collective knowledge and skills (soft skills and technical skills) to collaboratively evolve an optimal business solution

Ideally, solution roles will be technically multi-skilled but if not, they must be able to support each other. Ensure all required skills are available within the team when needed.  Avoid putting a single one-man 10-day task into a 10-day timebox; break it down or share it.

Solution Development Team members are allocated to the project at an appropriate and consistent level sufficient to fully support the DSDM timeboxing practice

By default Solution Development team members should be allocated to the project full time, or at least the project should be their top priority. If not, secure formal agreements as to when their time will be spent on the project, synchronising with other team members to allow collaborative working. Beware of over-commitment and optimistic estimates. If resourcing is very unpredictable, avoid committing to a delivery date, and make the work as granular as possible.

Tools and collaborative working practices within the Solution Development Team are sufficient to allow effective Iterative Development of the solution

Encourage face-to-face communication whenever possible. The practices of Workshops and Modelling play a significant role here. Where the team is not co-located, utilise technology  to maximise the ease of communication and collaboration between team-members.

All necessary review and testing activity is fully integrated within the Iterative Development practice

Primary output of each timebox should be a demonstrable increment of the Evolving Solution. Be creative about what can be demonstrated if it’s not obvious. Get the Solution development team to demonstrate the solution to each user story completed in each timebox, with the Ambassador or Visionary formally ‘accepting’ what has been done.

There are no mandatory standards or other constraints in place that will prevent the application of the DSDM Philosophy and Practices on this project

Avoid commercial agreements that include a ‘fixed specification’, which exaggerates the risks associated with a Waterfall approach. Ensure the Procurement team understand DSDM Philosophy, Principles and Practices. Ensure that an incremental approach to installation of technical environments and to deployment is acceptable, and that all support functions are in agreement with the project approach.