Problem solving seems to have been a fairly regular theme lately. Let's face it life in general is about problem solving of one kind or another, whether it be personal or professional. The concept of problem solving and quality are synonymous. Why else would be trying to solve a problem if it weren't to make something better? Whilst experience is invaluable, it doesn't hurt to learn a few SIMPLE tools to help with problem solving along the way. Please note the emphasis on simple. In some of my previous blogs I have emphasized the value of a simple approach. The truth is that many well recognized process/quality improvement techniques, whether older such as Method Study or newer such as 6 Sigma, owe their basis to simple fundamentals underneath. Understanding the fundamentals, as in most things, is far more important and valuable than thinking that learning some new “flavour of the month” technique will somehow make things better.
As a young, wet behind the ears, Chemical Engineer I was introduced to an excellent team based technique for studying and improving process plant safety and operations. It intrigued and fascinated me. It was called HAZOP (Hazard & Operability Studies). Back then it was quite new. If you look up HAZOP today on the net you will get lots of hits and see many variations on the original technique. The basis of the technique is now even being applied in the IT world. For example, I recently came across this reference, “UML-HAZOP”.
You are probably saying, “but what has this to do with general problem solving?” Please bear with me and I hope that will all become clear. Some 25 years ago, when I came to Canada, I was introduced to a new colleague, who was to become a great source of problem solving knowledge for me and ultimately a very good friend, as he still is to this day. Believe it or not he is now in his late eighties and still in demand for his work; only age and his wife now forces him to work part-time. His general and technical knowledge is very broad and his sharp mind is still there, even if he has become a little forgetful :). I only hope that I am half as sharp as he is at his age, assuming that I get that far!
Now comes the connection! It turns out that my new colleague was the “father” of HAZOP and that he had developed and refined the approach based upon sound but simple principals that he had used over more than 30 years, much of it from Method Study. He had worked in a very wide variety of roles, including process plant operations, drug research studies, business improvement modeling, company operational studies, planning and many other different activities requiring “process improvement”. In fact he somewhat reminds me of the “versatilist” that has been discussed many times here. BTW I begged my colleague to franchise HAZOP in partnership with myself when it was clear that it was really taking off in a big way. Today it is huge business! Oh, well that was my one and only chance to make both our fortunes…..but unfortunately he didn't 'see the light'. His wife still beats him up about it on a regular basis when I am around :).
He had been recruited to install the HAZOP technique in the company and to offer his knowledge on a consultancy basis. As it turned out, I was destined to work with him in his consultancy work (it took me all over Canada and the USA, and to Saudi Arabia). We also worked together on some interesting federal government projects (more on that sometime). Neither of these activities were my main job role. I just showed interest and it all developed from there. If you remember, I mentioned in a previous post, “the road less traveled”. All experience and knowledge is never wasted! However, let's get back to the main purpose of my article. Much of what I am about to say will hopefully seem rather obvious but that is the beauty of simplicity. It makes it easy to remember and easy to apply!
Before we can solve a problem, we must be able to very clearly define the problem; sounds almost too simple but not as easy to do as one might think. That is where structured problem solving begins to come in. Projects sometimes fail because they are solving the wrong problem and that only becomes apparent when it is often too late. So how do we go about defining the problem? A clear understanding of how things work or are done before we attempt to change things is step one. How often have you asked someone how things are done and then asked 'why' to be told, “that's how we have always done it as long as I can remember”? Please note the keyword 'why'. Since I have introduced the concept of keywords, here are a few more that we will discuss; 'what', 'where', 'when', 'who' and 'how'. 'What' is, of course, the activity under study. Here scale becomes very important. For example, if 'what' is, “write a piece of software to do event registrations”, then it will be impossible to study it in any meaningful way, because it is at too course a scale. So we must break down the problem to a scale at which we can sensibly apply the keywords. For example, if step one was, “gather requirements”, then we can ask and answer, 'where' (at the client's premises), 'when' (next week), 'who' (client representatives and project team), and 'how' (brainstorming or some other recognized technique). Now comes 'why'! If you cannot ask and answer the question 'why' for each of these and be satisfied then you have missed something. It is an iterative process.
These keywords may help us to define how we handle each step in the overall process, but what about help with defining the steps? You may have noticed that this article is entitled, “Make Ready, Do, Put Away…”. The planners/PM's amongst you hopefully you should be able to identify with this. Absolutely, every single thing that we do, both personally and professionally, can be viewed in this way. How often do we hear people say that they wish that they had put more thought in before acting? That's the importance of, ”Make Ready”. “Do” is fairly obvious. “Put Away” is the clean-up after “Do”. If we are determining the requirements for our software example, “Make Ready” might be preparing ourselves for the meeting with the client, “Do” is the meeting and “Put Away” is properly documenting the requirements determined at the meeting. The ultimate value in this pattern of thinking is that the “Put Away” from one step should lead us neatly to the “Make Ready” for the next. Incidentally, as you go through the analysis, everything should be well recorded. It will prove valuable later during 'critical examination'. As a sidebar my colleague was also involved in the development of Critical Path scheduling. Hopefully that connection is reasonably obvious.
So have we equipped ourselves with all of the necessary tools? Well, there is another set of helpful keywords, which actually form much of the basis of HAZOP. Let's suppose that we have done a good job of breaking down the overall process into meaningful steps at the correct scale. BTW you will soon know if you have the correct scale based upon the difficulty, or otherwise, of asking and answering the keyword questions. Our old friend experience doesn't hurt either :). We now need to apply some 'critical examination' to our plan to see if it can be improved and to determine its weaknesses. The original HAZOP keywords can prove helpful here, 'No or Not', 'More', 'Less', 'Other Than', 'Part Of', 'As Well As' and 'Reverse'. 'No or Not' might raise the question of whether a particular step is needed or it might point to the consequences if that step is eliminated, or missed. 'More' and 'Less' go together and could mean, 'More or Less time, effort, equipment, money, etc.' for example. 'Other Than' could mean to do something in a totally different way. 'Part Of' might question the need to do the whole step or the consequences of only doing part of a step. 'As Well As' might get you thinking about what steps can be done in parallel. 'Reverse' might get you thinking about reversing the order of two or more steps. In all cases, 'consequences', good and bad, should always be uppermost in your mind and clearly recorded for follow-up and resolution..
By now you have probably realized that carrying out a full comprehensive study is both time consuming and expensive. This was one of the early impediments to the adoption of HAZOP but eventually it became evident that the benefits far, far outweighed the costs. Today not only would nobody think of not using something like HAZOP in the process industries but it is now a legal requirement in many parts of the world. Legal requirements are now finding their way into the IT world! Once a full study has been carried out for a particular type of activity then you have a 'template' for future use, permitting quicker and cheaper studies. Note the study should always be done. Every case is slightly different and that must be evaluated. At the outset I mentioned that studies should be carried out in a team. It is also important to consider the makeup of that team (representation of skills and stake holders). Don't make the mistake of making the team too big (no more than 5 to 6 people). It will be ineffective and waste even more money. The team should have an appointed leader, who should be familiar with the technique, preferably having had some training. Recording the collateral from a study and how that is post-processed is obviously important (there is lots of info on the net). Although, this is intended to be a team technique the structured thinking and analysis can be very useful at a personal level. I have used it many times over the years, probably somewhat unconsciously these days.
Even if you don't go as far as formal studies, I hope that the fundamentals of what is presented here is helpful. I encourage you to give it try. It has served me very well and I consider myself very fortunate to have 'apprenticed' under my good friend, who impressively still continues to throw out new ideas and perspectives on all of this on a regular basis! We have many interesting chats on the subject!