Smooth running: ensure your systems training projects run without a hitch
•Descargar como PPT, PDF•
2 recomendaciones•835 vistas
This practical example-packed session covers everything learning teams need to consider ahead of, and during, a systems project of any shape or size. Presented by Brightwave's Head of Production Rachel Sefton-Smith, the session covers: • Gaining buy-in from the right internal stakeholders and teams • Agreeing UAT environment early on • Planning roll-out and training implementation • Compiling a realistic schedule • Planning and getting ahead - even if the system isn’t quite there • Dealing with timescale challenges This presentation was delivered by Rachel Sefton-Smith on Wednesday 28th January at Learning Technologies 2015.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (20)
Similar a Smooth running: ensure your systems training projects run without a hitch
Similar a Smooth running: ensure your systems training projects run without a hitch (20)
Más de Brightwave Group
Más de Brightwave Group (20)
Último
Último (20)
Smooth running: ensure your systems training projects run without a hitch
- 1. Smooth running: ensure your systems training projects run without a hitch brightwave.co.uk Rachel Sefton-Smith – Head of Production rachel.sefton-smith@brightwave.co.uk
- 2. Rachel Sefton-Smith (Seffy) Head of Production Systems Training Consultant Welcome
- 3. o What is systems training? o Challenges o Laying the groundwork o The production process o Questions Agenda
- 4. o Simulations - Show me, Try it, Test me, Role play • Guided - what to do and why do it • Supported - feedback if you go wrong • Scenario led - context / story / personalisation • Chunked into bitesize logical steps • Reinforcing best practice / business knowledge o Other resources – cheat sheets, videos, job aids o Reusable – system launch, induction, ongoing performance support What is systems training?
- 5. Set each task in context Demonstrate best practice Learning-by-doing in a safe but realistic environment oShow me – demo mode oTry it – guided practice mode oTest me – assessed simulation oRole play – combine soft skills and system application Can be system focussed or integrated into a wider knowledge / process piece Let’s see a quick example Systems simulations
- 6. Our clients
- 7. The challenge System readiness Tight (squeezed) timeframes Little time with SMEs Stakeholder review Managing change Detailed planning/preparation Modular approach Early stakeholder agreement scope/scripts Capture as late as possible Plan for rework The solution
- 8. The groundwork o Learning and development o IT / test team o Stakeholders o e-learning partner Roles Training design to meet learning objectives ……………………………………… ……….... o Development process o Tools o Releases and signoffs o Deployment Process Knowledge ……………………………………… ……….... Knowledge o System knowledge o Business process knowledge o Source content o Scripts ……………………………………… ……….... o Development lifecycle o Realistic data and scenarios o Data capture o Dealing with change System
- 10. Roles o Project management – internal team and e-learning partner o Subject expertise – scope, content, reviews o Development resource – what can you do in- house? o Training delivery – facilitators o Capability and capacity Your team
- 11. It’s all about you! Understand owhat and who the project is for othe learning solution oyour role in the project othe process Be clear about your availability and how much time to set aside To do list… 1.Define learning objectives 2.Complete script briefs 3.Take screen grabs 4.Review scripts 5.Review developed modules and provide feedback 6.Sign off module
- 12. Roles o System users – ‘real’ users to sense check best practice o IT / test team – visibility of development timeline, access to environments, data population o Marketing and communications – wider business change message Your allies
- 13. Roles o Engage early through presentations of solution design, demo modules o Wider stakeholder group for early signoff of design and scope o Narrow stakeholder group for speedy signoff of module content later Your stakeholders
- 14. Knowledge
- 15. The knowledge o New process, new system o Established process, new system o Established process, established system
- 16. The knowledge o Defined best practice? Who decides? o SMEs – may be combination of different roles o Source content – user guides, facilitator guides, previous learning, system design specification, flowcharts, test cases
- 17. The system
- 18. The system o Timeline – understand / influence development & testing lifecycles – align training development o 90% stability – visually and functionally o Data – help provide use cases for testing – ready to screengrab – avoid ‘hacking’ o Practical – getting access – training logins – installing capturing software o Planning for change – contingency budget
- 20. Data capture and scripting Testing and deployment Localisation and maintenance o Structuring the learning sessions o Mapping scope to audience o Agreeing realistic customer scenarios and data – generic vs role specific o Planning step-by-step route through each system task o Preparing for data capture – location, PC, capture tool, file transfer o Art direction and technical set up Design and planning Content integration Design and planning
- 23. Data capture and scripting Testing and deployment Localisation and maintenance o Housekeeping – naming / numbering conventions o Working with SME to capture screen grab for each step of each system task o Noting any additional behavioural or business messages for reinforcement o Writing detailed content scripts – review - signoff o Route depends on system readiness – batching modules Design and planning Content integration Data capture and scripting
- 24. System ready oScope oPrep oCapture oScript * oBuild oAlpha oReview oFinal Minimal handoffs Accurate scripting Review script with screen Fewer review cycles
- 25. System not ready oScope oScript oReview * oPrep oCapture oAdjust script oBuild oAlpha oReview oFinal Makes best use of time Scripts 80% accurate Increased review time Early signoff should reduce alpha to final changes
- 26. Data capture and scripting Testing and deployment Localisation and maintenance o Finalising course structure o Using the authoring tool to assemble screengrabs, adding instructional layer o Creating non-systems based screen – intros, summaries, questions o Publishing the course o Early review with client Design and planning Content integration Content integration
- 27. Data capture and scripting Localisation and maintenance o Testing – script to screen, functionality, flow o Objectives – does it meet them? o Pilot sessions, Alpha (Beta) and Final reviews o Implementing review fixes o Deployment to LMS - tracking and reporting Design and planning Content integration Testing and deployment Testing and deployment
- 28. Data capture and scripting o Localisation – translate content, re-capture same processes in localised system o Maintenance – in house or outsource o Planning for change - major or minor system changes? To hack or grab? Can you re-populate same data? o Adding new simulations as functionality becomes available Design and planning Content integration Testing and deployment Localisation and maintenance Localisation and maintenance
- 29. What if there’s change? o Aesthetic vs functional changes? o Minor system changes - does it matter? o Major system changes? o To hack (Brightwave could make graphic edits on small scale) or take new screen grabs? o Can you re-populate same data? o Can the change be explained on the Summary screen instead? o Is a Release Note required at Go-Live?
- 30. Business impact
- 31. Bupa OnePlan o 15% increase in customer satisfaction with call centre enquiries o 53% decrease in complaints from previous year
- 32. Lloyds Banking Group – PhoneBank Induction o Accelerated speed to competence - reduction from 20 to 12 training days = £1,200,000 p.a. productivity gain o Reduced training costs equivalent to £250,000 p.a.
Notas del editor
- Will give handouts at end Whitepaper on the way – we will be sharing with invite list
- ASK AUDIENCE – show of hands – how many Never done it About to / in middle of a systems training project now - pause – ask examples of what they’re doing Have done in past keep your hands up if you’ve ever delivered a training project to schedule? Sounds familiar? Goal of this session is to help them put in place processes to reduce headache... ASK What do you want to get out of this session?
- Let’s give quick definition of what we mean by systems training Mostly talking about simulations – pictures of the system with supporting knowledge and instructions Simulation = not the real thing – but it looks like it for a specific defined task (important to understand it’s not the real thing – set expectations) – not emulation But good enough to build confidence for the user and prove competence for the business Many advantages over a duplicate training system – expensive to maintain, unguided,
- Immersive – full screen simulation of live system Reinforces best practice approach to each task Set each task in context Learning-by-doing in a safe but realistic environment Show me – demo mode Try it – guided practice mode Test me – assessed simulation Role play – combine soft skills and system application Can be system focussed or integrated into a wider knowledge / process piece SHOW EXAMPLE Barnsley Hospital NHS Foundation - Registering a patient
- Wide range of clients and subject matter from banking systems, to patient record systems, to retail, to systems which manage sovereign debt (expand and check can reference this) Scaleable and flexible – from half hour refreshers to 12 day induction programmes
- System training can be complex – working around incomplete or fast-changing systems means it’s best to leave screengrabbing and content integration until late in the process. This only works if all stakeholders have bought in to the scope and content early on in process, reducing need for change once the simulation is built. --- Smart writing – to get around things that aren’t ready yet, to show a generic example but refer out to role specific examples … BREAK HERE – does this resonate? Any other challenges?
- KEEP THIS REALLY QUICK – 1 sentence about each All feed into your overall training design which will meet your learning objectives Where does this training initiative fit into an overall timeline if a wider change/ engagement process Any of these elements wrong – can spiral and create huge remedial costs – e.g. using live data – 3hr training project may be xxxx screen grabs x 10mins per graphic = X days = X cost
- So let’s go through each of these in more detail
- Understanding how long things take – signoffs, support for data capture Ideal simulation script brief writer and builder combines attention to detail, conscientiousness, organisational skills, consistency and self-discipline. SMEs Engage early – set expectations, carry out training & agree processes Schedule time in content development & reviews
- For instance – this is from a pack we used to brief an internal design team about their role
- Real users – if established system or process questions – also for realistic scenarios Test team – your new best friends! You can help them too – use cases and data Marketing – may be visual elements from a wider campaign you can use to tie in the learning – provide assets Cartoon character – face of the change – incorporate that into the learning – menus, avatars
- Who does the change impact? Business owners Service managers Branding IT Compliance Engage early – manage expectations – not the real system, it’s pictures of the system Their role – signoffs Timelines – understand turnaround, e.g. 5 days script review This only works if all stakeholders have bought in to the scope and content early on in process, reducing need for change once the simulation is built.
- Who’s got the knowledge – may depend – new / established process/system
- Defined best practice – who decides? – be consistent (assessment) most efficient way of doing a task – If multiple ways, then stick to one – be consistent (assessment) (e.g. always use the menu structure even if there are shortcuts – then have one navigation module which teaches the shortcuts)
- AGILE - Working closely with test / dev team – INFLUENCE - can help prioritise issues being dealt with in each release – example, Sky Case Management and screen text Test data – work with the analysts – use cases – scenario data – data refresh cycles 90% stability – good enough for training Prioritise modules – stagger training delivery installing capturing software - ask me later about the tools... Planning for change – stop press screens - to rework or workaround
- QUESTIONS SO FAR – do any of these challenges resonate? Any other factors to share? Next – we’ll move on to look at the production process in more detail
- Knowledge of the overall business requirements and training delivery plan A clear understanding of the overall business objectives A understanding of the training blend - i.e. how the e-learning will be run in the classroom A defined scope - understanding of how many modules BA have identified and the learner time associated with this - if this exists, otherwise we will work with you to help define this Training delivery plan - how modules are mapped to audiences, and how this fits with the delivery plan. This will allow us to prioritise batches for development and produce a detailed schedule. So some of this already covered - audience mapping – designing the structure – example coming up E-learning set up DATA – examples Lannister family, child serial killers, Manchester United Live data – medical or banking systems COST implication of manually editing multiple – often thousands – of screengrabs
- Example of a facilitated learning session – Remember – you may not need to cover EVERY possible path – Can cover other variations along the way – “what ifs” – or on summary screens
- Example of a script brief which SME would help compile – collaborative approach with BW
- ‘Batched' approach to progress the modules which are ready, while also proceeding with detailed planning for those which are not. Housekeeping – huge timesaver if all using same conventions EXAMPLE – recent project – approx 175 individual components, based on 172 individual items of source content (TMI joke) – hadn’t had chance to get this agreed – took longer to get a handle on! Saving to a shared drive Agreed module numbering and filenaming Agreed version control methodology Using a shared workflow tracker with Brightwave to track status of each module Screen grabs – with tool e.g. Captivate Or print screen into PPT works well if right screen res and PPT size (some tools will import PPT e.g. Storyline)
- SCRIPT * - could script straight into tool – e.g. Unison Route A: where functionality is ready in the system Script outline: module specification from session guides/flowcharts - scope and treatment of each module, plus any scenario/data requirements and key learning objectives - to be agreed with SMEs Capture - with tool, using agreed scenario/data Full development and scripting directly into tool Alpha release With this route we release the working Alpha in front of you as early in the process as possible and therefore skip the detailed script review phase. We have found that SMEs respond well to this method as can review words in context. We then make allowances for script changes between Alpha and Final release. This also clears the decks for the modules which we expect to come into play later.
- Route B: where functionality is not yet ready in the system Script outline: module specification from session guides/flowcharts - scope and treatment of each module, plus any scenario/data requirements and key learning objectives - to be agreed with SMEs Full scripting - based on session guides, flowcharts etc, - delivered for signoff (The above can happen well in advance of system functionality becoming available) Capture - with tool agreed scenario/data Full development and input of signed off script Alpha release With this route we can delay data capture until much later in the process, and have the reassurance that the script content is already signed off, therefore change between Alpha and Final release should be minimal.
- In house or with e-learning partner
- pilots
- Localisation – once English signed off – thinking about how to refer to button names – leave in English, or translate in brackets If you’ve been kept in loop with development process then you should be aware of volatile areas – so perhaps cover only at high level in initial release and then add later Stop press screens It is likely we’ll be capturing screen grabs from pre-final versions of the system in order to meet the project schedule. So what if something changes? Think about if the change will impact the experience for the learner. Aesthetic vs functional changes? Minor system changes - does it matter? Major system changes? To hack (Brightwave could make graphic edits on small scale) or take new screen grabs? Can you re-populate same data? Can the change be explained on the Summary screen instead? Is a Release Note required at Go-Live? We may decide to log changes to pick up in a maintenance phase later on so induction / BAU training will be up to date.
- Example from SME briefing pack
- All of this in place?
- Training led to staff having right knowledge and skills which led to…
- Training led to staff having right knowledge and skills which led to…
- White paper – in couple of weeks Be good to get some audience feedback to go into white paper