Industrial disaster strikes – ever been there? I have: :
Disaster can take a number of forms: late delivery, key personnel absence; shortage of materials, total failure of product due to soldering: .any number of events can be termed “disaster” by the team.
I have worked on projects which ranged in scope of disaster recovery from pulling “all nighters” in order to recover a project, through all weekend working by a team of mechanical fabricators (to meet year end shipments where the product was not to drawing): in one event, I was called at 10pm on a Friday night by a project manager from Solectron to say that the “fix” one of the manufacturing engineers had “engineered” into a product was not working: and that production was stopped, and so the Monday shipping targets for year end would not be met: 30 minutes later I was on his line in Milpitas in a white coat re-engineering the “fix” and by mid-night the line was back up and running: I stayed until 6 am and the end of quarter shipments went out as scheduled.
I guess everybody is different. When issues come up, there are the people who get upset, those who record the event in impassive minute detail, and those that attempt to fix the issue in a gung ho “let’s go do it” fashion: ..
Whatever the issue, and whatever the plan, it is important that there is a plan of record on the recovery action.
A manager of mine many years ago told me when an issue came up that I jumped into and was in the middle of fixing “don’t become the problem”. It took me a few years to understand this comment: but I finally “got it”.
What he actually meant by this terse one liner comment was this:
When an issue comes up, the cause is often (before the event) outside the scope of influence or control of the people who end up having to fix it. Once you jump in to “fix” the issue you effectively accept ownership, and any further delays from that point are attributed to you and (if you have one) your team: you have effectively: without a plan of record become the problem: and anything from before the time you got involved is treated to a dose of “corporate amnesia”.
That is why, when a project has or is about to become derailed by events unplanned, that there is a definitive plan for the recovery action. The issues involved leading up to the event should be documented along with the recovery plan, the expected time frames and any milestones expected such as a plan adjustment as a result of an initial discovery process of the extent of the issue concerned.
This may seem like an industrial CYA but in fact it is just an extension of the multiple spreadsheets, reports and PowerPoint’s that we use and prepare every day.
By preparing a plan, which can be very simple in nature, you are able to circulate it, invite comment on it, and invite input to it: in other words get the team buy in from the management level down through the team that will actually have to carry out the “fix”
When ever issues come up remember: the aim is to fix, not become the problem: a simple well documented plan will help the whole team to understand the actions to be carried out, from the discovery process through the stages of the fix.
Oh and by the way: if issues do come up I wish you a speedy and effective “fix”
John Burke
