I have used this fictional case in workshops on Learning from ONE Event to demonstrate the process. I like you to read, stop from time to time for questioning yourself how to proceed, think also about its relevancy to less spectacular failures and what could be gained by learning the RIGHT lessons. This is part 1 of the case, part 2 would follow in a week.
The trigger for learning and the start of the process
The big test of the Wise-Cameras, intended to be the new diamond in the crown of TopSecurity, was organized for two hundred people from the army, air force, police and the secret service. It ended in total disaster. Samuel Fuller, the CEO of TopSecurity, the one who brought it all the way to become a $5 billion giant, nominated a team of three people to inquire the shameful event where the Wise-Cameras failed to identify the break-in of a test-group of five well trained people into Top Security’s building, in spite of all the sophistication that went into the Wise-Cameras system.
The inquiry team was led by Gilbert, the manager of SecurityCheck, an independent organization that checked the functionality and effectiveness of various security products. SecurityCheck was asked to try breaking into TopSecurity HQ. Their success was the biggest failure TopSecirity ever had. Linda, the brilliant CEO of ThoughtWare, a software company without any business linkage to TopSecurity, was another member. Jacob an organizational consultant was the third member of the team.
The project to develop Wise-Cameras started three years ago and was supposed to take two years. The idea was to use security cameras to automatically identify any attempt to approach a protected building. The identification of the potential intruders was supposed to be automatic and in high certainty. Additional expectations were to identify the exact number of people trying to break in, and recording special features of the intruders, notably the distance between the eyes in order to support identification even when the intruders wear masks.
What went wrong in the test was that the five intruders came to the building by rolling on the ground and by that fooled the system.
The failure certainly took Sam by surprise. It’s economically and operationally impact on TopSecurity was immediately recognized. The actual cost of the project was around $5M, but the hopes for future revenues were closer to $100M a year!
Is it a good idea not to include anyone from the project team in the learning-from-one-event-experience team?
Naturally the tendency of anyone involved in such a project is to cover the wrong actions and decisions that led to the failure. Nobody likes to be blamed even for much smaller failures.
But, what is the objective of the learning? Is it really to identify the guilt of some people, or reveal some common flawed paradigms, shared probably by many people, and fix them?
Jacob, the organizational consultant, proposed to add someone from the project team in order to radiate the message the intent is not to blame anybody. Linda added that they need at least two people with the knowledge and intuition of what happened. Thus, Alex, the chief project engineer, and Martha, a software specialist responsible for the movement recognition in the project, joined the team.
The new team, now consisting of five people, sat down to resolve the first issue:
Verbalizing the gap between prior expectations and actual outcomes
They soon realized this issue is more challenging than it first seemed to be. Actually two different gaps have been recognized:
Gap no. 1:
Prior expectations: The important guests, who are potential clients, would be grossly impressed by the performance of the Wise-Cameras.
Actual outcome: Huge disappointment, leading to inferior reputation and low perception of the system and of TopSecurity as a reliable and innovative supplier.
Gap no. 2:
Prior expectations: The system is capable of tracing even the most sophisticated breaking into a protected building.
Actual outcome: The system was tricked by a clever team.
Gap 1 focused on the event planning. A possible lesson might be running a rehearsal before such a show, or conducting closer communication between the developers and the testing team.
Gap 2 focused on the question how come a three-year project failed to achieve an effective product?
Gilbert, the team leader, asked Alex a clear question:
Was the failure due to a minor technical problem that could be fixed pretty soon?
Alex: “The specifications were very demanding that no incidental move of an animal, like a dog, would activate the alarm. In other words, no false alarm allowed! Thus, we assumed that any human being coming to the building would be walking on two feet. The image recognition algorithm was based on that assumption.”
Based on this statement it was clear that gap no. 2 was real and substantial. Considering the value of better understanding what led to failing to achieve the technological objective of the project and ensuring that such a failure would never happen again pointed towards the second gap.
What is important to understand is that inquiring both gaps by the same team reduces the ability to focus and by that the chance of learning a beneficial lesson of value.
Questions: What should the next step be? Is there a need for more information and analysis? If so, what missing information is required?
Eli Schragenheim 
Is it a good idea not to include anyone from the project team in the learning-from-one-event-experience team?
Yes, even ifs a facilitator that is ensures the group is trying to fix the problem, not assign blame. That person can also ask “the dumb questions” to challenge the basic assumptions used for the system.
We need to check a few assumptions about the Expectations of TopSecurity and their potential customers.
Top Security expected customers to buy their system because the cost of the system would outweigh the cost associated with a break in. They probably made the assumption that only their system would be in place. It would be difficult to believe that any automated system protecting something of high value would not some other redundant methods, like having a guard watching what was happening. A guard would have probably concluded that people rolling toward the building are bit suspicious. So we could argue that the system should have been tested with a guard of some type in place, and full reliance on the system would not be required.
Was the failure due to a minor technical problem that could be fixed pretty soon?
We could have the system determine a third state, where the computer is faced with an exception that would have to be checked out. A clean ID is one state, a rejection because it’s something we recognize that is not a threat (i.e., the dog) is another, and then a third is I don’t know, but its roughly human size and its moving toward the building, but is not something I recognize. With all of the algorithms involved, that state should be fairly easy to determine. But we’ll still need to pay for a security guard to check it out.
We also know that technology is changing quickly, and security and robbers are always in a race to design a “perfect” system, and then to crack a perfect system. That race will continue beyond this product. So a feature of the process has to be like virus software – we’ll constantly be updating this system as the bad guys get better. That can be pitched as strength, not a weakness.
Clearly in Gap 1 they didn’t do enough testing. Computer software people hire hackers, casinos hire cheaters, etc. It looks like they should have hired a few beta testers (our clever people, for example) and run a few beta tests before rolling it out. If they had seen the rollers first, they could have turned it from a negative to a positive. “We constantly test the system and update it as required. Here we have a video of a clever team that figured out they could fool a beta system (did I forget to tell you the system we showed you was a beta?) by rolling towards the building. Your guard would have caught that, but it needs to be addressed. We looked at the video, make a software change overnight, and when the rollers tried again, they failed.”
What should the next step be?
From a short term perspective, add the third state to the system, and hire the company who the system or another one that has similar skills to do some an internal tests, and make a guard part of the system. Resolve the issues they present, Test to see not if the computer system works, but the entire system (including the guard) works.
Is there a need for more information and analysis?
It would be worthwhile to understand what the customer wants, and what else will be part of the security system beside the camera system. But on-going information and analysis will always be required to keep up with all the changes.
LikeLike
Kevin, you make some admirable conclusions. I think, though, that given there is an inquire team the assumptions you make can be validated or invalidated when more checks are made. Actually this is what I think should be done: on one hand to raise many assumptions and potential explanations of what happened and why, and on the other hand check the facts that support or invalidate the assumptions.
I think, by the way, that any inquiry team has to include people who were part of the event being inquired, together with external people that are not limited by the shared assumptions and culture.
Let’s see whether the continuation of the case makes any difference to the initial assumptions.
LikeLike
In order to prevent likewise errors in the future, it is necessary to examine the way in which assumptions are challenged by teams participating in the development of new products.
E.g. Alex: “The specifications were very demanding that no incidental move of an animal, like a dog, would activate the alarm. In other words, no false alarm allowed! Thus, we assumed that any human being coming to the building would be walking on two feet. The image recognition algorithm was based on that assumption.”
How has the assumption that any human being coming to the building would be walking on two feet been challenged?
Also the way in which was determined that there were no contradicting requirements for the system is essential. E.g. if dog movements aren’t allowed to result in a false alarm, (how) is it possible to rule out if people moving like a dog won’t be able to make use of this requirement? It can seem very obvious, maybe even so obvious that people weren’t aware they had certain assumptions. To which extent this kind of assumptions have been considered consciously and explicitly is an important thing to find out. In order to be able to prevent this kind of mistakes in the future, it should be very clear which assumptions are important and should be considered explicitly when designing and developing new products.
LikeLike
Thank you Pepijn, I like your way of pointing out the assumptions to be checked. It certainly outlines directions to check and analyze.
LikeLike