- Has the technology been proven in a pilot process, and is there a direct proven benefit to product quality, stability, and customer service?
- Is the outcome learning or proving the value of a technology?
- Has the technology been proven, and is the application of the process or technology easily repeatable for other applications?
- Is there a measurable benefit, and is the risk from the change mitigated with an expected benefit?
|Attribute||Research Projects||Continuous Improvement Project|
|Expected Value||Knowledge, any other value is a bonus||Either explicit, or intrinsic improvement|
|Cost Recovery Model||Sunk / No Option for Recovery||There is a payback or cost recovery period|
|Proven Technology||Proves Hypothesis||Yes, this is either an application of a technique to a new system, or an evolution of an existing process.|
|Known Outcome||No, the potential for improvement may be radical, however the risk is unknown.||Yes, with a very high likelihood of success|
|Level of Risk||High, first tested on low impact situations||Low, the technology has been proven.|
A continuous improvement project is one that improves on existing processes in a risk-mitigated fashion. It is evolutionary in nature. Research projects are attempts at revolutionary changes to processes, and are equivalent to a larger scale lab project to learn more about a process, and to evaluate the potential for improvement. Once research projects have been proven, then the new process is mapped to existing processes, and a gap analysis is completed. As part of the gap analysis, production processes are compared as evolution using moderate steps through continuous improvements to reduce risk. Research projects are similar to a petri dish experiment… and can be anything from a proof of concept, to a radical change in processes or technology.
Because production services are expected to be stable, changes are introduced using a method that reduces risk. The change is normally evolutionary, with prior proven steps, and a proven change management process. Once the research project has proven successful, then it needs to be mapped, and evaluated based on its potential as a production service. This means looking through the lenses of stability, customer service, process improvement, efficiency, and value.
I’m not adverse to radical changes. However these should be first proven on services which have a higher tolerance to disruption, and then migrated up the service chain. The exception of course, is when you are not meeting service commitments for a critical service, and can take a measured risk that the radical change will improve the service. Unstable systems have a different criteria for change than proven stable systems. There are a number of reasons why a system can quickly become unstable, including changes in infrastructure, rapid adoption, and inadequate sizing – all of which should be mitigated, where possible, with adequate testing. Like the commercial from a few years back… if you click the go-live button, and you are an overwhelming success beyond your wildest dreams, you could have a scalability and stability issue you need to address with radical changes.
That’s it for now… Happy Computing!