The incident pit is a concept I first read about in one of my mums diving magazines. At that time I realised how useful it is in describing incidents involving divers and how a lot of small things going wrong can result in a major incident.
In essence, the incident pit is something that you gradually fall into. One small thing might not initially go to plan or a relatively minor piece of equipment might break down or get left at home; when this happens you have put your first foot into the incident pit. Initially it is not a problem, but then something else goes wrong - that is another step into the pit. The challenge with the incident pit is that with each step, not only do you get closer and closer to the bottom of the pit and a serious incident, but with each step the sides of the pit get steeper and steeper. It gets more and more difficult to get out the further into the pit you go.
I think there is something to learn from this concept for engineers. I often see engineers taking steps into the incident pit with relatively minor problems, potentially causing much larger problems in the future. To define the incident pit I think that there needs to be two key elements. The first is that the incident pit is caused by a series of problems, any of which would not be a problem on their own, but each one exacerbates the next. The second is that you have to be in a situation where you are incrementally committing yourself. For divers this is relatively easy to understand, the deeper you are diving the more committed you are and the more difficult it will be to solve any problems. I think this is often the case for engineers; as we design and build something, we make more and more commitments and we have more and more invested in something, so just stepping away becomes difficult, if not impossible.
The trick is to know when to stop taking steps into the pit. Another key feature of the pit for divers is that you can always choose to stop taking steps into the pit, but this has a cost, because their dive may have to be cut short. It is the same in engineering, if you choose to stop taking steps into the pit there will probably be a cost.
I want to look at how the incident pits forms in engineering, so I'm going to consider a simple building being designed by a structural engineer. The design starts off well with no major problems and he makes his first submission to the client. They love the design, especially the huge front window that you have given them. At this point you haven't taken a step into the incident pit as nothing has gone wrong, but you have started to get committed.
The next day you get a call from the manufactures of the glass for the centrepiece window. They are no longer able to provide glass quite up to the specification you wanted. This is the first step into the pit. It might not be the designers fault but he does have the choice of whether to continue or not. At this point in time it is not a major problem, even if the glass is not quite up to the expected specification, it should still be strong enough so the engineer chooses to continue.
So the engineer goes and makes a few more submissions to district planners, the contractors who are pricing the project, and utility companies to check the sewers running under the house will be okay. As each one of the submissions goes in, the engineer gets more and more committed to the proposal; backing out gets more and more difficult.
And whilst the project is getting more and more committed, problems keep affecting the large glass window. The original calculations needed to be modified slightly imposing greater forces on the window, new codes of practise are issued which require a better performance of the window, the structural frame has to be modified slightly increasing the span of the window. The engineer is getting caught in the incident pit as he gets more and more committed. The small problems gradually mount up and if the engineer does not pull out soon enough he will be trapped - the design will not be adequate, but too many commitments have been made. All of a sudden the small problems escalate into one big problem.
There is no easy way to deal with the incident pit. You just have to recognise when things are not going as planned and know when it is time to pull out so you don't get trapped. By remembering how these small problems escalate and how easily you can get trapped, it is easier to deal with the problems.
Showing posts with label Problem solving. Show all posts
Showing posts with label Problem solving. Show all posts
Friday, September 21, 2007
Sunday, September 02, 2007
Creativity in engineering
Creativity is probably one of the less well recognised abilities that all engineers have. Solving practical problems is what engineering is all about and if you are trying to solve a problem that has never been solved before, you have to think creatively to come up with the solution.
The conventional view of creativity is that the fewer boundaries there are, the more creative the solution. This is however quite profoundly wrong in the case of engineering a solution to a problem, for engineers it is boundaries that allow us to use our creativity.
To demonstrate this I want to consider the case of somebody who asks an engineer to design a bridge from an island to the mainland. The engineer is only too happy to oblige and starts to scratch his head to come up with a design. So what design should he come up with? The engineer doesn't know much about his client or his problem, but does want to please him. So what is the best solution?
I'm going to simplify this problem somewhat to consider it in detail. I want to consider the bridge solution in terms of only two variables, the capital cost of the bridge and the capacity of the bridge, this is just to simplify the model we are going to consider, and more complex models will be developed later.
To model the solution I want to consider a two dimensional solution space. Each dimension represents one of the solution variables, so in this case we have a two dimensional space with one dimension representing the capital cost and the other dimension representing the capacity of the bridge.

Having generated this solution space, we need to consider the original request, a bridge to connect an island to the mainland. We don't know anything else so the best way to get as close as possible to the clients request is to go for something in the middle of the solution space, something average. In this case it probably represents a bridge with two lanes in each direction, something fairly standard and not very creative. If we go for a creative solution, something further from the middle of our solution space, we run the risk of being a long way from the clients requirements.
So how do we come up with something creative? What if we asked the client a few questions, one relating to each dimension of the solution space. What would you like the capital cost to be? What would you like the capacity of the bridge to be?
By asking these questions we can find the point on the solution space that represents our clients aspirations. But how does this relate to creativity, instead of having the whole solution space to use to come up with our bridge design, we only have a small part of the space to work with.

Consider what would have happened if our client had asked for a very low capital cost and a very low capacity because our client only needs to cross to the mainland on his own once a week. In this case, it seems like he doesn't actually want a bridge, because a rowing boat is a better solution. Just because we are tied to a small region within the solution space, it doesn't mean that our solution can not be creative; such as proposing a rowing boat instead of a bridge.
Exploring the different points within the solution space shows us the range of solutions that could be develop for this simple request for a bridge. Most of these solutions could not realistically be proposed without some initial input from the client to allow us to come up with the creative solutions for a point in the solution space.
Using this example it is clear that creativity in engineering and problem solving is not necessarily a result of starting with a blank sheet of paper and an open brief. It is the boundaries that are imposed on our solutions that both allow us and force us to generate a creative solution. I believe that many engineers do not like getting a full brief either because of the perceived difficulty in coming up with a solution with a very tightly defined solution space, or because they wish to have a broad solution space so they can look at many solutions.
This approach goes totally against what it means to be an engineer. We should be aiming to exceed our clients aspiration, and the only way to achieve this is through knowing where a clients desired solution is on the solution space. We should be embracing the challenges that we are set. Of course we must also have the tools to come up with the creative solutions that sit within a well defined solution space, and this is where engineers need to be taught design skills. It is these design skills that form our toolbox for coming up with creative and novel solutions.
The conventional view of creativity is that the fewer boundaries there are, the more creative the solution. This is however quite profoundly wrong in the case of engineering a solution to a problem, for engineers it is boundaries that allow us to use our creativity.
To demonstrate this I want to consider the case of somebody who asks an engineer to design a bridge from an island to the mainland. The engineer is only too happy to oblige and starts to scratch his head to come up with a design. So what design should he come up with? The engineer doesn't know much about his client or his problem, but does want to please him. So what is the best solution?
I'm going to simplify this problem somewhat to consider it in detail. I want to consider the bridge solution in terms of only two variables, the capital cost of the bridge and the capacity of the bridge, this is just to simplify the model we are going to consider, and more complex models will be developed later.
To model the solution I want to consider a two dimensional solution space. Each dimension represents one of the solution variables, so in this case we have a two dimensional space with one dimension representing the capital cost and the other dimension representing the capacity of the bridge.

Having generated this solution space, we need to consider the original request, a bridge to connect an island to the mainland. We don't know anything else so the best way to get as close as possible to the clients request is to go for something in the middle of the solution space, something average. In this case it probably represents a bridge with two lanes in each direction, something fairly standard and not very creative. If we go for a creative solution, something further from the middle of our solution space, we run the risk of being a long way from the clients requirements.
So how do we come up with something creative? What if we asked the client a few questions, one relating to each dimension of the solution space. What would you like the capital cost to be? What would you like the capacity of the bridge to be?
By asking these questions we can find the point on the solution space that represents our clients aspirations. But how does this relate to creativity, instead of having the whole solution space to use to come up with our bridge design, we only have a small part of the space to work with.

Consider what would have happened if our client had asked for a very low capital cost and a very low capacity because our client only needs to cross to the mainland on his own once a week. In this case, it seems like he doesn't actually want a bridge, because a rowing boat is a better solution. Just because we are tied to a small region within the solution space, it doesn't mean that our solution can not be creative; such as proposing a rowing boat instead of a bridge.
Exploring the different points within the solution space shows us the range of solutions that could be develop for this simple request for a bridge. Most of these solutions could not realistically be proposed without some initial input from the client to allow us to come up with the creative solutions for a point in the solution space.
Using this example it is clear that creativity in engineering and problem solving is not necessarily a result of starting with a blank sheet of paper and an open brief. It is the boundaries that are imposed on our solutions that both allow us and force us to generate a creative solution. I believe that many engineers do not like getting a full brief either because of the perceived difficulty in coming up with a solution with a very tightly defined solution space, or because they wish to have a broad solution space so they can look at many solutions.
This approach goes totally against what it means to be an engineer. We should be aiming to exceed our clients aspiration, and the only way to achieve this is through knowing where a clients desired solution is on the solution space. We should be embracing the challenges that we are set. Of course we must also have the tools to come up with the creative solutions that sit within a well defined solution space, and this is where engineers need to be taught design skills. It is these design skills that form our toolbox for coming up with creative and novel solutions.
Labels:
Boundary,
Complexity,
Creativity,
Design,
Engineering,
Inspiration,
Problem solving,
skills,
Solution,
Solution space
Tuesday, August 28, 2007
Ancient mysteries and the Litho Lift
I have a deep fascination with the problems faced by ancient people in constructing their monuments. I know I'm not alone in this and it is a lucrative business these days with countless websites, television programmes and books all claiming to have cracked one of the ancient mysteries.
I stumbled upon another solution to the stonehange problem today (Stonehenge building riddle tackled). I love this solution, it is such a compelling machine; one of those solutions that seems obvious only when you've seen it. In some ways I wish I was the first person to have come up with this solution; and yet I know that it can not have been the way Stonehenge was actually built.
I would like to look at the Litho Lift initially from a pure engineering viewpoint. Looking at the scale model of the machine by simply taking moments it is clear that the force in the ropes are greater than the weight of the lintol stone itself. The inventor of the machine does propose a solution to this, by using counterweights to balance the load. To me, this is the start of the process of laying solutions on top of each other. You create a solution to a problem, it seems a nice solution so you decide to run with it. The only problem is that another problem is created. So you add some additional complication to your original solution to solve that second problem. That second solution then creates a third solution and so your original elegant solution ends up being surprisingly complicated.
Often, it is possible to have avoided the complex solution simply by picking different a different solution to begin with. The solution might not be as ingenious as the Litho Lift, but it would have been far easier to implement.
I have tried to put myself in the position of the people trying to build Stonehenge; I have no doubt these people were master craftsmen, with skills and knowedge often far exceeeding our own. I am not so sure that their ability to conceptually generate complex solutions to problems has reached our level of skill. Complexity and the tools used to manage it are features of the modern world , as are the tools and skills we have created to manage it.
I can not see the people building Stonehenge having used the Litho method to lift the lintols. To avoid creating a complex solution from scratch, large parts of the solution must have already been developed before Stonehenge was built. It is difficult to see how any of the individual parts of the machine would have benefited Neolithic man without the other parts. Of course I could be wrong, I am using essentilly the same argument against mans ingiuity that is used against natural selection evoving the eye.
My argument for not using the Litho Lift somehow does not appear to be as strong as my instinctive feeling that the Litho Lift is not the solution that was used. In the end, it is not my rational argument that sways the case. It is simply that I have moved one ton stones by hand as part of a team, and I have built large timber structures. I know how difficult it is creating a large timber structure and how simple it can be to move large loads with levers and brute force. I have no doubt that the people who built Stonehenge would have also gone for the simple solution - all they would have needed was patience and time, something which past generations have always demonstrated.
I am going to take it as my lesson for today. If I am going to try and develop an elegant solution, I must have experience of working with a problem. I must have an understanding of how much effort it actually takes to solve a problem with brute force and patience compared to inginuity and elegance. Sometimes the solution that involves the least work is not the right one.
I stumbled upon another solution to the stonehange problem today (Stonehenge building riddle tackled). I love this solution, it is such a compelling machine; one of those solutions that seems obvious only when you've seen it. In some ways I wish I was the first person to have come up with this solution; and yet I know that it can not have been the way Stonehenge was actually built.
I would like to look at the Litho Lift initially from a pure engineering viewpoint. Looking at the scale model of the machine by simply taking moments it is clear that the force in the ropes are greater than the weight of the lintol stone itself. The inventor of the machine does propose a solution to this, by using counterweights to balance the load. To me, this is the start of the process of laying solutions on top of each other. You create a solution to a problem, it seems a nice solution so you decide to run with it. The only problem is that another problem is created. So you add some additional complication to your original solution to solve that second problem. That second solution then creates a third solution and so your original elegant solution ends up being surprisingly complicated.
Often, it is possible to have avoided the complex solution simply by picking different a different solution to begin with. The solution might not be as ingenious as the Litho Lift, but it would have been far easier to implement.
I have tried to put myself in the position of the people trying to build Stonehenge; I have no doubt these people were master craftsmen, with skills and knowedge often far exceeeding our own. I am not so sure that their ability to conceptually generate complex solutions to problems has reached our level of skill. Complexity and the tools used to manage it are features of the modern world , as are the tools and skills we have created to manage it.
I can not see the people building Stonehenge having used the Litho method to lift the lintols. To avoid creating a complex solution from scratch, large parts of the solution must have already been developed before Stonehenge was built. It is difficult to see how any of the individual parts of the machine would have benefited Neolithic man without the other parts. Of course I could be wrong, I am using essentilly the same argument against mans ingiuity that is used against natural selection evoving the eye.
My argument for not using the Litho Lift somehow does not appear to be as strong as my instinctive feeling that the Litho Lift is not the solution that was used. In the end, it is not my rational argument that sways the case. It is simply that I have moved one ton stones by hand as part of a team, and I have built large timber structures. I know how difficult it is creating a large timber structure and how simple it can be to move large loads with levers and brute force. I have no doubt that the people who built Stonehenge would have also gone for the simple solution - all they would have needed was patience and time, something which past generations have always demonstrated.
I am going to take it as my lesson for today. If I am going to try and develop an elegant solution, I must have experience of working with a problem. I must have an understanding of how much effort it actually takes to solve a problem with brute force and patience compared to inginuity and elegance. Sometimes the solution that involves the least work is not the right one.
Labels:
Ancient,
Complexity,
Elegant,
Engineering,
Lintel,
Problem solving,
Solution,
Stone,
Stonehenge,
Timber
Wednesday, August 22, 2007
I think it's time for something positive, it's not good to dwell on the negatives too long. One of the greatest gatherings of minds in the world are the TED conferences. An astonishing array of people attend all with there own ideas and stories to tell. Bill Clinton, Al Gore and Bono have all given talks in recent years.
Standing ovations are not common at this event, so what would it take for a teenager from Africa to get one? Could it be a story of person suffering, fighting against the odds, or making a stand. Not in this case, William Kamkwamba simply had an idea and he had a go. It is something we should all try and do more of. In the words of Nike; 'Just do it'.
Labels:
Bicycle,
Engineering,
Inspiration,
Problem solving,
Ted,
William Kamkwamba
Subscribe to:
Posts (Atom)