Originally, I wrote this post from the side of testing, releasing and follow up. But, as the paragraphs got long, I realized what the real message was. Know that something will go wrong, no matter how well you thought your team planned. Then, take the time to think the issues through, clearly report what happened and the path forward. For me, this has meant some very long nights working through an issue then on a plane to present to Sr Management a few days later. While I agree that issues are problems with systems or processes, neither of these happen without a human being involved so a human has to stand up and plan to not have the issue occur again.
The message and timing of the presentation is important. People come to the meetings really pumped up, with some wanting to pound on the table and have a head on the block. Stay calm, breath, smile but appreciate that this is serious business and be prepared!
The deck covers*:
- What the was the Problem
- What was the Impact to the business, customers and income. This must be real numbers since many times a ‘huge’ issue is actually a low impact that was explosive only due to internal panic.
- What is the Solution – this could be how the issue was fixed during the outage, it is more effective if it is the long term solution.
- What is the Timeline for the long term solution implementation.
I say long term ‘solution’ since presenting short term patches to legacy will generally mean I would be back presenting the same issue in the future. It was better to explore a full solution. It may not be chosen as the path forward, but it should be shown as an option. A sure career limiting move is to present a quick fix that results in momentary happiness then a panic and another presentation when a similar issue appears. There are few companies that will continuously reward for solving problems over creating an environment where there is little or no problems. The better companies see low noise as success and promote individuals to problem areas for help in stabilization. Commonly know as, ‘work yourself out of a job’ and they will find you more work.
There are a couple lessons learned around presenting the above deck you may find useful:
Some attendees require the deck be given to them in advance. The likelihood they will pre-read it is low, but possible. Generally it is so they can print a copy to jump ahead during the meeting. Prepare to have folks ask questions several slides ahead of where you are. Slides need to have information but too much is clutter and drives to a person wanting to talk a single small item instead of understanding the full message.
Know that there may be unusual outcomes from the first day of a two day meeting which could mean the first night will be a complete re-write of the path foreword slides. Always think beyond the issue – a data issue can be the ability to enter data incorrectly, fixing the one entry point is just getting you to the next open entry point being found. Would it be better to rethink how people use the data rather than toying with the tool?
Beware of Red text in the first couple slides. The presentation falls apart quickly when red text leads off the meeting. No one can get past that and the rhythm will stall.
Be sure that the small group presenting understands that they are part of a very big team, even if it is a team of two. No one gets ahead singling out an individual for fault. Own the systems, be proud of the systems, but understand that systems are only bits and bytes and there is always an opportunity to be made better.
And, finally, system changes require process changes. Do not forget to cover how a person’s work will change with a change to a system. This is because process change can take time to think through, people can be resistant to changing the way they do things. Also, if changes to processes are not pointed out, someone will think of it in the meeting and the assumption is there will be pushback due to the unknown for the users.
Sooner or later there will be an issue, plan now how you can assemble the facts when that happens so you can be presenting a positive path forward. I don’t like problems but they are just opportunities to improve.
*We love acronyms, completely stumbling on the presentation to Sr Management when something went wrong as being: Problem, Impact, Solution, Timeline.