In Round 1 of the Apollo 13 simulation the team designed (and built) the Rocket. This was an important exercise, as the Nawah IT organization will be developing new products and services in readiness for the reactors going on-line.
The solution was delivered over time, over budget, with quality issues and hidden bugs that the team had not discovered, representing a significant risk to both safety and to realizing the mission goals! Although 20% of team, when asked afterwards, said they thought it would never be finished on time, they did not signal this or take ownership for the promised results.
What had gone wrong?
The round was characterized by an internally focused, SILO’d approach. The teams ‘dived into the technique’, there was little engagement with the customer, the users, the supplier or the IT operations team.
During reflection at the end of the round we explored the definition of a Service according to ITIL.
‘A Service is a means of delivering Value to Customers by facilitating Outcomes they want to achieve without the ownership of specific Costs and Risks’ – 4 keywords that EVERYBODY in IT should know and use to prioritize, negotiate and make decisions. These are: Value, Outcomes, Costs, Risks.
The team had failed to use this to explore with the business the Risks – short time, new technology, skills shortage. The business could have decided to extend the time or allocate more funding to hire in additional expertise, or the business could have agreed on less features and quality to ensure an on-time launch was achieved.
As part of the exercise in round 1 the team developed a Service Transition Checklist (STC). ‘What needs to be transitioned into live operations before we can launch’. However as a result of time constraints, poor allocation of responsibilities, and working in SILO’s the list was only superficial. We explored the 5 Ps (People, Process, Product, Partner, Performance) and looked at their checklist. Their list primarily focused around the product itself. Again this lack of completeness meant that the hand-over into operations introduced new risks and with time pressures building gave operations little chance to say ‘No’ when the solution was ‘Thrown over the wall’.
After reflection the team declared a STC should contain:
People:
• Trained in Product AND Process (IT and Business users)
• Engage with and gain commitment from customer – product requirements (test, validate and accept) and performance requirements (Value, Outcomes, costs, Risks)
• Clear RACI (including Authority, Accountability), also Customer and Partner
• Ops manuals & User documentation
Process:
• Defined, agreed and accepted processes (incident, changes, Service Levels)
• Integrated into existing processes
• End-to-end process flow and agreements
• Safety & Priority mechanisms
• Escalation mechanisms
• Overview of costs and financial model
Product:
• Tested, validate and accepted product
• Integrated into CMDB
• Integrated into KEDB and IM tool
• Integrated into systems and network management tools (event monitoring and alerting)
Partner:
• Agreed RACI
• Integrated into Process and Tools
• Underpinning contract
Performance
• Agreed KPI’s & SLA’s
• Agreed Reporting (content & frequency)
Transferring Learning into the roadmap for moving forward
When asked, if we were now to start a new project in your org, what would you do differently than you do today?
• Use VOCR to explore with the customer the business goals, explore thresholds for costs, risks, delivery expectations.
• Perform a Risk assessment and have all parties sign off on this.
• Get everyone on the same page? Same time. Understanding goals, roles & responsibilities, escalation procedures.
• Confirm everyone understands roles and responsibilities, accepts these and is trained or coached to be able to do these. This also includes ‘authority’ to take decisions.
• Help each other. Dare to say you need help, ask others if they need help.
• Apply continual improvement to capture lessons learned and suggestions for improving next time
• Agree KPI’s (VOCR) and priorities.
• Agree communication and reporting needs.
• Ensure Customer, User & Partners roles and responsibilities are clear, particularly for right knowledge and skills, escalations, validation and acceptance.
• Ensure we have a complete STC with input from all stakeholders. This STC needs to be given to all development projects and teams and should form the basis of ‘Service Acceptance
Criteria’.
Go Live….Launching into the unknown
In the next round the team used (or rather didn’t use) their transition checklist to ensure that everything was ready for Launch. The Flight Director (IT director) agreed everything was ready. The Mission Director (Business) then insisted on a ‘Go-No/Go’ test to conform that everybody was clear on ‘the goals, their role, and the agreed process’ – suddenly we heard from delivery teams ‘No GO’! Processes were unclear, escalation mechanisms were not agreed, there was no priority mechanism. The checklist had not been agreed and signed off by all stakeholders.
The Rocket blasted off into a clear blue sky, with risks that were introduced by a poor design and build and made worse by a poor transition. Incidents and requests started occurring, capacity issues arose…
A bumpy ride…..
‘Where is my critical O2 tank solution…we’re running out of Oxygen’!? asked the Astronaut
‘How should I know?…..I’ve no idea!’ Declared the frustrated help desk (‘…Have a nice day, we appreciate your call, please let us know if we can be of further help in the future!’)
The Mission Director asked the Flight Director ‘How is it going’?
‘Fine…no worries’ was the answer!
‘That was impossible!’ Said the Flight Director, ‘there was far too much work. You (business) gave us far too much to do, we need more people!’
‘Show me the evidence’? I asked as Mission Director. ‘How much work did you have? Which specialists had too much work? How long did each incident take, how many are open? Closed? What were the priority issues?…..there was silence. The team had no ‘Transparency’.
A smooth glide….
The team then applied continual improvement, reflecting and agreeing improvements using the 5 P’s. The next round was smoother, key goals were achieved, the team was less stressed, more motivated, celebrated their successes. The Astronauts and Mission Director were all happy.
‘This went much smoother’ said the Flight Director, ‘but we had less work’?
‘No’ I said, ‘You had more incidents AND you had to manage a change requiring multiple specialists as well!’……there was silence. ‘That is the impact of applying an integrated approach like the 5 P’s’.