Capturing requirements and delivering change to a cinical

12

Click here to load reader

Transcript of Capturing requirements and delivering change to a cinical

Page 1: Capturing requirements and delivering change to a cinical

Adam Heatherington

Page 2: Capturing requirements and delivering change to a cinical

Include testing period

Business change and processes (SOP’s)

Trainers preparing courses and materials

Dry runs and dress rehearsals

Work with the software house product specialist and update the Trust specialist.

Migration plan

IT services and Hard ware updates for the new rollout

IT Helpdesk support

Contingency plan for system down time.

Page 3: Capturing requirements and delivering change to a cinical

Get business change analysts out on the shop floor engaging with managers and importantly staff at ground level (often overlooked)

Make sure every department has a Business change lead.

Weekly meetings, leave no stone unturned, ask all the questions compare and contrast the legacy system with the new system. Is it doable?

CAPTURE THE DEPARTMENTS WAY OF WORKING

Map all processes, revisit and rethink

Keep the staff in the loop, don't go cold.

Page 4: Capturing requirements and delivering change to a cinical

Hold these with a representative from each department and specialist

The trust involved in the process from day one, allow them to shadow contract staff & software specialists.

Share the knowledge within the team

Disseminate any new updates

Work with Communications, keep end users aware of the new system and when its goes live.

Page 5: Capturing requirements and delivering change to a cinical

Rigour testing

Cycle 1 to 3

Ensure the functional designs are received from the software company.

Work from the FD’s to get the basics of the system.

Further requirements any show stoppers?

Page 6: Capturing requirements and delivering change to a cinical

Ensure the strategic operational processes are there from the start.

Vital for testing scripts and further down the line, the trainers lesson plans

The SOP’s need to be continually reviewed, the edition date clearly marked on new SOP’s

The SOP’s is a working document, continually changing due to input from the client (trust)

Page 7: Capturing requirements and delivering change to a cinical

Ensure there is enough trainer to compliment each session

Role base or process driven?

Super User Training

Page 8: Capturing requirements and delivering change to a cinical

1) Workshops, know your end-users plan training with their input

2) offer taster sessions

3) Introduce “An introduction to the system” Foundation level prior to training go-live.

4) offer assessment in each session to assess the learners.

5) extensive go – live support

6) Provide a go-live help desk for system calls only.

Page 9: Capturing requirements and delivering change to a cinical

Perhaps pilot a ward and a clinic, one with low activity as not to hinder BAU

Ask the staff, engage with them and use their knowledge and feedback for improvements.

Always keep the end-users informed of any system changes.

Page 10: Capturing requirements and delivering change to a cinical

These are the vanguard of any system going live, you must have the Trust staff on your side.

Involve them in everything, every up[date, process change.

The SU will be the go to on Go-live and also provide cascade training pre and post go-live.

Page 11: Capturing requirements and delivering change to a cinical

Engage with other trusts who have already gone live with the system

Exchange ideas and ways of working

Away days and departmental visits

Have a bridge between the two trusts, link in.

Page 12: Capturing requirements and delivering change to a cinical