Unmanaged Risk: The Source of All Software Engineering Problems
Unmanaged risk is the source of all software engineering problems. Risk is a measure of uncertainty in the project’s outcome. The greater this uncertainty, the greater is the risk.
Consequently, an IT organization’s quality efforts must be focused on best practices that reduce this uncertainty.
If we look at history we can make a few obvious observations. First, we can say that this project uncertainty can vary significantly over the life cycle of the effort. In general, it is at its highest when the project begins, since this is where we least understand the project and its dynamics.
As the project advances our degree of uncertainty about the project’s outcomes (e.g., delivery date, cost, quality, adoption rate within the enterprise, ROI, etc.) generally decreases—although in fits and starts and with setbacks and leaps forward—until we reach the end of the project, when our true understanding is at its highest, and our uncertainty is close to zero.
This leads us to instantly draw several conclusions about how to reduce uncertainty and risk. For example, if risk is at its minimum at the end of any project, and if we happen to come across another customer with exactly the same needs as that first customer, then it should follow that the project to deliver the first solution, again, to the new customer can be carried out with very little risk.
Thus, our first axiom: Reuse reduces uncertainty.
Wherever possible, solutions should be delivered by assembling pre-built and pre-validated components, rather than by constructing them. The fastest, cheapest way to build anything is to not build it all. This is the primary learning that arose out of the many quality efforts during the last fifty years in engineering and manufacturing. Reuse is so powerful that it absolutely demands emphasis. Very few actions that an organization can take will have this level of ROI.
Reuse derives its power because after we build that first solution we have two critical pieces of knowledge that we didn’t have before: (1) A customer together with the requirements, needs, constraints, and expectations of a successful solution, and (2) an actual instance of such a successful solution.
So, whereas at the project’s beginning, we were uncertain about these two points, we now, at the end, have much greater clarity, understanding, and certainty.
This leads us to our second axiom: Customer usage reduces uncertainty.
This is the primary learning from reuse. Everything else (better requirements, inspections, reviews, testing, more effective tools, etc.) are all merely weak approximations to simply getting the solution in front of a customer. And, then let them experience it in some organized way.
Remember, the quality principles require that any effective process (in this case, the SE process) must listen to the voice of its customer and then match that voice with the voice of the process (the solution). Further, we know from experience that in SE projects, the voice of the customer cannot be completely captured in the documented requirements, but only fully surfaces and reveals itself when customers actually experience something. These missing requirements are often called expectations, and must be identified, captured, and met for the solution to be considered successful. Moreover, the best way to flush out these missing or misunderstood requirements and expectations is to give customers something to touch and use and interact with.
Consequently, if after exploiting reuse as best we can, we find that we must still build all or portions of the solution, then we must exploit the second axiom, customer usage.
We do this by finding ways to structure and package the total solution into a sequence of component sub-solutions, and then incrementally deliver these sub-solutions to the customer throughout the project’s lifecycle, not just once at the end. Each one of these incremental sub-solutions is simply an opportunity to directly engage the customer with a chunk of the evolving total solution and to get feedback on how well that chunk meets the customer’s needs and expectations. But, because these chunks (customer interaction opportunities) are spread out over the duration of the project, we quickly learn and can reduce uncertainty rapidly.
So, whereas, the first axiom, reuse, is based on delivering the same solution to a different customer, this axiom, is based on delivering different solutions to the same customer. The first reduces uncertainty by leveraging the certainty in the solution, the second by leveraging the certainty in the customer.
An important conclusion to all this is that the higher the delivery frequency (the more chunks the business solution is composed of), the greater is the reduction in uncertainty. However, since each delivery incurs a necessary cost in energy utilization (labor and resources are consumed to deliver each chunk to the customer), the question that matters, is “How many delivery cycles are necessary to reduce risk commensurate with the proposed energy expenditure?” In other words, how do we balance the dramatic reduction in risk associated with each subsequent customer delivered chunk, with the incremental additional expenditure of resources?
This is, in many ways, the key trade-off for IT leaders and their project managers to more fully understand.