Research Projects vs. Continuous Improvement for Production Services

There should be a clear distinction between a research project and a production service.  I’d like to do a brief contrast and comparison of where these overlap, and where the concepts diverge.  Let’s say a developer want’s to introduce a new process change into the development life cycle, or into the hosting life cycle.  How do you define if what’s being change is part of continuous improvement, or is a research project?  There are several litmus tests…

1. Has the technology been proven in a pilot process, and is there a direct proven benefit to product quality, stability, and customer service?
2. Is the outcome learning or proving the value of a technology?
3. Has the technology been proven, and is the application of the process or technology easily repeatable for other applications?
4. Is there a measurable benefit, and is the risk from the change mitigated with an expected benefit?

To contrast and compare…

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.
Production Ready	No	Yes

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!