Failing "Up", and Finding Value
- September 26, 2010
- 0 Comments
“Successful Failure” has been used to coin the events which unfolded for the Apollo 13 mission. The failure was that the mission did not meet its original objective to land on the moon and return but rather met a more urgent objective which was to successfully deliver home the astronauts who were caught up in a series of unexpected and violently changing situations.
During the course of BPM delivery, and if a company is open-minded enough they can actually benefit from a failure. Now to be clear, I am not suggesting that every endeavor should automatically be assumed to fail or for that matter even the planning for failure is not something anyone would really want to do. Risk mitigation, yes of course but what I am referring too is a willingness to change a plan if the business value interests aren’t completely aligned with that initial plan. Things happen on a project and sometimes even a perceived negative situation can be capitalized on and may actually yield a better overall outcome than that original improvement roadmap. For example, when you are finding yourself looking at a process and subsequent solution requirements and they have stagnated. Stagnation of solution requirements is extremely common. Perhaps those requirements were developed months and months ago (or even longer), or similarly developed in isolation of the true voice of customer/voice of business. If you approach this purely from a plan-driven approach your failure scenario is high pure and simple. And achieving that failure may be the best thing to happen on that project because it opens the door to re-adjust and go after the more immediate business-value aspects of the solution; the here and now, not the how it was. As a result, you likely just saved a ton of capital by avoiding the ongoing support for a solution that was at best dead on arrival, and at worst just added to the overall process problems.
In a Lean-Agile delivery approach the notion of “failing fast” and being business-value driven over plan-driven are extremely important in these scenarios. Business-value driven simply means that during delivery you are willing to put the true needs of the business first, those solution requirements that will actually move the performance needle and not generating assets just because they may have been written down in a plan once upon a time. In essence, separating the wheat from the chaff.
For Apollo 13, as much as solutions were needed to the various problems, solutions had to be identified quickly in the face of the many unknowns that the mission was faced with. To do so the team needed to “fail-fast”, meaning that the capability to perform quick failure assessments and prevent re-occurrence is equal to the value of identifying a solution. Simply stated, do everything you can to get the real problems you are going to face identified up front. For companies new to BPM and its Agile software delivery tenets no matter how rock solid you believe your plan to be the teams will be undoubtedly faced with unexpected challenges. Getting too far ahead of the risk aversion curve by trying to engineer for every possible corner case everyday is fruitless, expensive, and ultimately useless. Reason being is that in doing so you will create more mass in the project than what can literally be propelled off the ground; more mass requires more energy and will ultimately result in inertia. The last thing anyone would want to have on their delivery project is a vast, never ending source of mitigations and controls based on theory or even meta-theory. An organization needs to have courage to move into and stay in a delivery mode versus discussing what delivery may or may not mean for a project academically.
What is required in delivery is proportionality and pragmatism in order to achieve the mission objective. In Lean-Agile, which happens to be the method of choice for us at BP3 in delivering BPM solutions, there are just a few simple staple items all of which are based on delivering business value as soon as possible. When we talk about what is value we talk in terms of a working solution over the documentation of a solution, collaboration over negotiation, flexibility being valued over rigidity as examples. The reason we value this is because it brings everyone closer to seeing a successful outcome by bringing risk and unknowns forward to deal with immediately.
In Lean, something which is considered Value-Added must pass three discrete tests:
- The customer would be willing to pay for it
- Done right the first time
- Physically transforms the output; increasing its value
If you took the same philosophy to dealing with failures which occur on projects today then its pretty evident that there is a tremendous value in being able to identify and resolve issues quickly.
- The mission/project/program would be willing to pay to prevent or remediate issue
- Identified and resolved early
- The outcome increases efficiency, effectiveness, and business value of the ultimate solution
Again, in order to truly realize the value of putting your undiscovered troubles behind you quickly you have to begin by acting, doing something that provides the opportunity of discovery versus avoiding the journey all together. So if your going to have a failure, set yourselves up to do it quick and unequivocally.