Last week I read a nice post by David Anderson about the Information Generation Process. I realised that apart from badly naming what I was talking about, I had also failed to explain what I was talking about.
Most literature I’ve read about Process Improvement including Lean focus on the delivery of the product or service. None that I’ve read really focus on the flow of information in the process. Unless you consider the information flows, it is possible that your decisions will be severely sub-optimal.
As an example, consider the software product and information flows in software development. Traditional software development belief has an analysis phase followed by a parallel software development and test preparation, which comes together in a test execution phase. Focusingf on software only, parallelising the software development and test preparation phase makes perfect sense as it reduces the time to delivery of the software… Unless you consider the information flowing into the system. The test preparation phase involves creating detailed examples that would be used to test the software. Creation of these examples results in the discovery of details about how the system needs to behave that will be tested. The information about the examples needs to be built into the software. In other words, the information needs to be incorporated into the software development phase before the software can leave the test execution phase. The only way that the information is guaranteed to get into the software development process is as a “bug”.
In other words focusing on the software product only results in parallelising software development and test preparation which is the optimal way to deliver software INTO test execution. When you consider information flows in your system, you realise that the optimal way to deliver software OUT of test execution is to place test preparation before software development. In other words use “Specification by Example” or “Automated Acceptance Testing”.
This is one example. The general rule for optimising an information arrival process is that “All information needed to make a commitment should be available before a commitment is made.” The Feature Injection process is one way of implementing this principle. “Sense and Respond” describes a similar process for service organisations. Feature Injection starts with the value, whilst “Sense and Respond” starts with the customer.
Both Feature Injection and “Sense and Respond” are “knowledge discovery processes” that David refers to in his post.
Neither process is passive, simply waiting for information to arrive. Both actively discover the information needed in a structured manner, guided by the goal of delivering (customer) value.
I like to pride myself on the fact that I give things really really terrible names. “Information Arrival Process” is one of my worst. A ponsy name for considering how information arrives into a system as well as how the “product” flows through it. The aim is to avoid information loops where information flows backwards in the process, and ensuring the process is not halted whilst it has to wait for information to arrive. In effect, endeavor to create flow of information in the opposite direction to the “product” as well as flow of the “product” itself.
Note: “Product” is the thing delivered to the customer that generates value for them.