Project initiation

At project initiation, the RDS development team should walk the requester through:

• The six stages of RDS toolkit development and the associated checklist, both of which are available in the RDS Learning and Support area.  
• The roles and responsibilities of the requester and team working with them, and of toolkit development team.

The development team may already have introduced this process at the pre-planning stage, however the specifics should be covered fully as part of project planning at project initiation. 

An essential first step in order to progress with development of a toolkit is to complete the form for Part 1 of the HIS/RDS governance process.

This form is sent to the HIS/RDS team for approval.  The RDS team may seek clarification or additional information on some points before approving.

Once the request is approved, the RDS team will create the toolkit "shell" - i.e. set up the toolkit homepage node on the RDS content management system, and assign content management permissions to designated editors.

The part 1 toolkit form asks for the following details: 

• Name of toolkit​
• Purpose of toolkit​
• Primary users of toolkit​
• When/ where toolkit will be used​
• Key contact​
• Senior responsible owner (senior lead ultimately accountable for the toolkit)​
• Confirmation of local governance approval 
• Go-live date

If you have completed an SBAR  or similar documentation at the pre-initiation stage to make the case for development of your toolkit, you will be able to re-use much of the information in the part 1 form. 

Project planning

A key activity in the project initiation stage is development of the project plan. This is an important guide for the toolkit developers and requesters as it sets out projected timelines, activities and responsibilities to keep the project on-track for delivery by the target date. 

The project plan needs to be reviewed and monitored regularly, and updated to ensure it aligns with the reality of delivery.  Monitoring the project plan will give you an early indication of whether the delivery date needs to be adjusted, or whether additional resource is needed to ensure delivery by a fixed launch date.

The Association for Project Management provides a short blog with a helpful overview of project planning for those new to project management. You might also want to consider using the principles of agile project management to ensure that you put the users' needs at the centre of development, and flex the project management approach when required.

Creating a Gantt chart, defining milestones

A Gantt chart is a project management tool assisting in the planning and scheduling of projects of all sizes. It provides a graphical representation of activity against time and is useful for visualising projects so that you can monitor progress. The Association for Project Management provides a useful overview of creating and using Gantt charts, and signposts to useful Gantt chart templates which you can customise in Excel.

To support the monitoring of progress with your project, it can be a good idea to define project milestones and highlight these within your Gantt chart. These are events or deliverables that mark key points in progress - for example: 

Managing project documentation

You might want to create a channel or folder on MS Teams to share project documentation and to enable members of the development team to discuss the development process.

Risk management

Risk management is an important part of project initiation. It enables you to  identify and address potential problems before they occur.  The UK Government Orange Book provides a clear and comprehensive guide to identifying, scoring and managing risks. It includes an example of a risk register, and emphasises the importance of sharing learning from risk management, to inform future developments. 

The Right Decision Service standard operating procedure on risk management also provides guidance and a template to support management of safety risks that could arise from the design and delivery of the toolkit. 

At the project planning stage, concerns may emerge that:

1) The scope of requirements exceeds the time and /or resource available for delivery.

OR

2) The requesters have conflicting or unclear ideas about requirements.

In either of these situations, you might want to consider focusing initially on a minimum viable product (MVP). 

A minimum viable product is a new product with just enough features to provide essential functionality and attract early adopters. An MVP can enable you to acquire user feedback that can then  guide the product’s future development in later stages. This helps to ensure that user needs and priorities are at the centre of development.

Techopedia provides more information about the purpose and development of MVPs, and how to use them as a basis for learning and future development. 

An important part of project initiation is to introduce toolkit requesters and any new RDS editors to the suite of standard operating procedures which guide RDS toolkit development. These cover key aspects of RDS governance and processes, including standards for content management, accessibility, risk management, and user testing.  The development team will need to confirm compliance with these governance requirements in order for the RDS toolkit to authorise publication of a toolkit on the live RDS platform. So it is important to ensure that everyone is working to these standards from the first. 

Part 1 ‘request a toolkit’ form

Six stages of RDS toolkit development and the associated checklist

Overview of project planning  (Association for Project Management)

Principles of agile project management (Association for Project Management)

Overview of creating and using Gantt charts, and customisable Gantt chart templates (Association for Project Management)

UK Government Orange Book on risk management

Right Decision Service standard operating procedure on risk management

Right Decision Service suite of standard operating procedures

Try documenting your reflections after a project initiation meeting:

1. What went well?  
2. What could have gone better?
3. What would you do differently next time?
4. What advice would you give yourself if you were to go back to where you were before the meeting?
5. What would be your advice to future project teams based on you experiences here?
6. Is there any additional support the RDS team could offer to help teams with project initiation?

You may have a colleague locally who can review your reflections and discuss with you.  If you would like to be put in touch with an RDS toolkit manager or editor for this purpose, please contact his.decisonsupport@nhs.scot.