Following the Hack day Retro action we discussed and agreed the following points.
Purpose of Hack day - Agreement to hack on educational/social purpose, a problem or an idea. This can be tech or non tech.
Review the frequency - Agreement to have hack day set quarterly. As hack day frequency is reduced suggestion was to increase the event to day and half. Half day could be spent in discovery (problem space).
Review past ideas for Hack day - See below table with follow up actions.
Hack day Topic | Category
| Idea Description | Current Pain points/challenges | Does this idea require a full discovery Y/N | Outcome desired from the Hack day | Follow up action |
User & Stakeholder Management | Problem | Look at a way to manage lists and types of users in a structured way, perhaps linked to users e.g. a CRM to remove use of personal emails for contracts and user groups | Currently lists of users, stakeholders and groups dotted all over and not linked to TIS | Yes | A POC or similar perhaps linking TIS users to a OS CRM | Discovery is required to identify all users that interact with this process and begin engagement. |
Monitoring & Alerts | Problem | Partially done. Preference was cloud watch. Outstanding action to discuss migration to older monitoring | ||||
TSS Notification | Idea | Look at how built in notification in TSS can improve engagement with Trainees and reduce administrative burden for local offices | Currently Local offices contact/alert trainees of actions/deadlines via emails which can be replaced with notification | Yes | On the TSS roadmap - Use the outputs from hack day discovery | |
Chatbots | Idea | Can chatbot improve supporting trainees? | A POC which is used within TSS | This is part of user management - No evidence/research data to show that there is a need to develop chatbots | ||
User management | Idea | Improve how this whole area works e.g. admin console for Trust RO | We are at high risk of a problem as the current UM is inadequate |
| Some possible options to enable furtherance of work | Discovery is required - On the admin roadmap |
Jira dashboard | Problem | What problems are we trying to solve that Jira dashboards might be able to help with? | We have not been trying to drive insights from our internal data very much - Stan's presentation help shed light on some possibilities |
| One or more specific problems / insights we'd like to address An action item to address it / them (which may include extracting Jira data into Excel / Tableau to do further data analysis) Ideally one or more dashboards that addresses the problems | Identify users & stakeholders, looks at use case and WIP limited. Ticket number TIS21-3955 - Getting issue details... STATUS Action for individuals to review ticket and agree user story. Outstanding action - Understanding what we want to display on a dashboard in real time. |
Find the best way to rebuild Generic upload to support multiple instances | Idea |
|
|
|
|
|
Make more use of NDW data: | Idea | Set up a job to regularly update TIS/TSS | Maintaining GMC numbers takes time and is error prone |
|
|
|
Improving the TIS user access request process | Idea |
|
|
|
|
|
Reskinning TIS to fit with the new revalidation look | Idea |
|
|
|
|
|
Interoperability initiative to unify/integrate search and access of our documentation repositories (confluence, SharePoint, etc). could be based on open APIs that provide search, metadata access, content access | Idea |
|
|
|
|
|
Build user persona library via creation of user persona templates | Idea |
|
|
|
|
|
Kubernetes for load heavy applications | Idea |
|
|
|
|
|
Platform simplification | Idea |
|
|
|
|
|
0 Comments