The DDP includes the following main areas:

• Project overview: key parameters, milestones, roles and scope of project
• Use and market targets: who will be using this and how
• Project plan: how the project will be managed
• Roles and responsibilities: personnel and skills needed
• Supplier agreements and subcontracts. what external skills and resources might be needed
• Deliverables: what needs to be produced (this might be software, a product, study data etc) and timings for this
• Study management: how the research phases will be managed
• Risk management: how will risks be analysed, recorded and evaluated
• Software development: full details of any software that might need to be produced, including verification and validation for this
• Verification planning: how you will ensure that what you are building does all the things you said it should
• Validation planning: how you will check that you are building the right thing
• Design reviews: how often should these be and who needs to be involved
• Data management: what data will be collected and how this needs to be stored including details on data integrity.
• Issue resolution and change control: what happens if changes are needed or problems arise
• Data retention: how long will data be stored, and how
• Document control: how documentation for the project will be managed
• Analysis: defining the approach to any data analysis that is required
• Client communication: how will the client be kept up to date and who is the point of contact

Adapting a DDP to your project:

• Every project is different, the DDP is adaptable to the needs of a specific project so if some areas are genuinely unnecessary you can leave them out.
• This document can form part of the planning for both Agile and Waterfall project management styles. Even if a project will be iterative and run in sprints it still needs this level of planning at the beginning.
• Finally, the DDP isn’t something that gets ignored after the project starts, it’s a working document that should be revisited and updated on an ongoing basis, at the very least at the end of each design and development milestone.

First we want to take a look at user and market targets, outline an approach to risk and also think about data management. In the next section we’ll go into more detail on project planning and roles and responsibilities.

Focus area: user and market targets

Defining your audience should be a priority at the beginning of a project. This will allow you to appropriately tailor the end product, test it with the right people and deliver an effective marketing plan (we will look at this in more detail in Module 2).

Note: “everybody” is not a valid target user group! Even projects with broad potential appeal should identify the priority user group.

This doesn’t need to be a long definition. For example: when we worked on a project around insomnia, our definition in the DDP was:

Focus area: risk management

Identifying risks and how to mitigate them is a fundamental part of project planning. This process highlights possible issues and gives you a chance to plan for them or head them off before they become a problem. It also functions as a way to expose assumptions and make sure that everyone is in agreement and communicating clearly.

For health care related projects this is especially important as you’re dealing with sensitive areas that may even be a matter of life and death, so the risk tends to be high. If your study relies on ethics approval from an institution, evaluation of risk will be a requirement.

It can seem a bit like trying to predict the future, but gets easier once you have been through the process a few times and can base the risks on previous experience.

Management of risk is key to the ISO-13485 process which states ‘The organization shall establish documented requirements for risk management throughout product realization. Records arising from risk management shall be maintained’. There is also separate guidance for risk management in the form of ISO-14971.

At Ctrl Group we use the following format to complete a risk register – a spreadsheet that logs and tracks potential risks associated with the project and the product use:

Focus area: Data Management (and Data Integrity)

In our Design Development planning document you’ll see that Data Integrity is a subsection of Data Management. But what does this mean?

As a design research company, data is at the heart of everyday working practice at Ctrl Group. Through the design and development of clinical research Ctrl Group record, collect, transpose, manipulate and transform data through various methods.

The data lifecycle at Ctrl Group refers to the journey data takes from being generated and collected through to completion of a project or work relationship. Data integrity in this context is the need for Ctrl Group to ensure that the lifecycle of data is supported in its accuracy and consistency. Data integrity arrangements must ensure that the accuracy, completeness, content and meaning of data is retained throughout the data lifecycle.

Data should be ALCOA:

• Attributable
• Legible
• Contemporaneous
• Original
• Accurate

Regular reviews of the data are also a crucial part of our process and are completed by the Project or Research Lead as part of their project management responsibilities. Periodic reviews are completed by the quality manager auditing all company data and the operational and technical measures.