Reducing Risk in Software Development
Posted by rbpasker on August 21, 2007
Have you ever heard the expression, “Ready! Fire! Aim!” ? Scoping projects has a natural progression: (1) figure out what you’re going to do (2) figure out how you’re going to do it (3) then do it. Confuse the order, and your asking for trouble, like slipped releases, incomplete features, and poor performance.
All of these problems hurt the overall business as the company and customers lose confidence in engineering’s ability to deliver product. Confidence is inversely proportional to risk – less risk means higher confidence, and vice versa – so reducing risk in a release should increase its confidence.
One way I have found to reduce risk is to categorize projects or tasks into three risk categories – low, medium, and high – which follow the 3 stages above:
- high risk – tasks which you don’t know what to do or how to do. High-risk tasks might also be labeled research projects. There’s a grad school joke that research is the process of going up alleys to see if they are blind, and finding the right alley can take a long time. From a product defensibility standpoint, however, these kinds of features are great because they are notoriously difficult. But from a product delivery standpoint, these are schedule-destroying tasks. If you have research projects on your product schedule, there is significant risk of failing to deliver.
- medium risk – tasks which you know what to do, but not how to do it. The risk here is in how long it takes to figure out how to complete the task. This is one of the mains reasons why smart and experienced people are so valuable: they know how to do stuff.
- low risk – tasks which you know what to do and how to do them. These tasks are not necessarily simple or less complicated tasks, but they are ones which can just be implemented.
Reducing risk then becomes an exercise in turning high-risk items into medium-risk ones, and medium risk into low risk by answering the unanswered questions, and by dividing higher risk tasks into a number of smaller lower-risk ones. Preferably, this should be done outside the release cycle, but that’s not always possible. The release, then, includes only lower (although not necessarily lowest) risk items.
To convert a high-risk project into a medium risk, you have to know what you’re going to do to solve a problem. For example, imagine you have a system that process 100 transactions per second, but you need to increase throughput to 200 TPS. There could be many different ways to achieve this goal, such upgrading systems, adding disk spindles, partitioning the application, implementing a SAN, converting from a scripting language to a compiled one, or some combination thereof. Say, after a month’s worth of research and experiments, you decide that partitioning and converting to a compiled language are going to have the greatest impact. You have now converted a high-risk task into two medium-risk ones.
To convert a medium-risk task into a low-risk one, you need to answer the question “how?” In our example, we have “partitioning” and “compiling,” so then you have to figure out how you are going to partition the application and what techniques you might use to convert your scripting language to a compiled one. A number of additional experiments might be in order, and you might also evaluate helpful third party products. But at the end, you have to know pretty much what you’re going to do, and create a new set of low-risk tasks to complete the project. The better you define how you’re going to do something, the less risk there is.
Reducing risk is not an exact science, but what I’ve tried to do is create a paradigm which you might adopt to your own work habits, whether you’re running a huge engineering project or you’re working on your own. Doing what you say you’re going to do when you say you’re going to do it gives you great credibility among your colleagues, and its also a huge confidence builder. Identifying and reducing risk is a great way to achieve it.