Ignorance and knowledge – how to reduce project risk

If you want your software project to be a success, then it is not only sufficient to deliver a functioning product, but also to deliver the product in time. Whether this happens or not depends largely how the project copes with risks that may occur. Does the project identify risks and take preventive or corrective measures? In past projects, I have come to see that risks are a form of ignorance – you don’t know what bad things will happen, and often things happen that you couldn’t imagine at all in advance. This observation means that risk and ignorance are related, and that reducing ignorance will reduce project risk. But there is more to say to ignorance than just this…

Five orders of ignorance

Years ago, someone explained to me the concept of the Five orders of Ignorance. As far as I can see, this concept was first introduced in an article in Communications of the ACM, available here. The article states that ignorance exists in multiple layers. I’ll describe my interpretation here and apply it to a software development context.

Level 0: knowledge

At this level, there is no ignorance involved. Level 0 means that you have the answer readily available. If you have years of experience in a given programming language, then starting a new project in this language won’t result in any questions. You know what to do to get things working. You have the answers, or rather, there is even no question involved.

From project perspective, using a familiar programming language involves no risk in itself. As a result, the project planning will be more reliable when using known technologies as opposed to introducing new technologies.

Level 1: lack of knowledge

At level 1, we don’t know something, but it is clear what we need to know and also how to find the answer. As an example, suppose you don’t need the exact details of some business logic that you need to develop, but there is someone available to give you all the answers. In that case, you can go to him and ask.

From project perspective, this is somewhat worse than level 0, but still not so bad. You know beforehand that you need to reserve some extra time to obtain the missing information, but then you’re all set. It just makes the project planning a little bit less reliable, but if you reserve sufficient time, you may also finish earlier if things turn out to be simpler than expected.

Level 2: lack of awareness

Lack of awareness is about the things that you don’t know that you don’t know them. For example, when developing your application, you suddenly realize that you need to implement a complex algorithm that you know nothing about. Or you may have planned to use a service to do something for you, but it turns out it does this completely different than you thought.

From project perspective, these are the serious issues that may cause projects to fail. They occur when a project ventures in uncharted areas (at least for the project team) with things like new technologies, new markets or building new products. This level of ignorance introduces large risks that may not just make the project planning more unreliable, but instead make the planning completely invalid.

Level 3: lack of process

At this level, you don’t have a means to find out that there are things that you don’t know that you don’t know them, that is, you don’t have a good way to find out the level 2 issues. An example is a research project for a new technology, where there is sometimes even no certainty that the goal can be attained. Only by performing the work, it may turn out that you didn’t know that you didn’t know things that you need to find out.

From project perspective, you’re on this level if you have no way of finding out what your level 2 risks are, other than building the product. But if you build the product, then those issues will catch you by surprise, because you couldn’t see them coming up front.

Level 4: meta ignorance

You’re on this level if you weren’t aware that ignorance occurs at multiple orders of magnitude. But that should be fixed by now 🙂

Risk reduction

In the explanation of the orders of ignorance, I already related the orders to project risks. This also makes clear that risks exists in multiple orders of magnitude. Risks at level 2 are much worse than risks of level 1, because they can kill the project. I think that project members should be aware of the fact that the difference between the levels is not gradual but exponential.

In my opinion, it is therefore very important to get risk (and, hence, knowledge) under control. What can we do to reduce the risks during a project? Here are things that you can do:

Be aware what the goal of the project is, and live up to it. This helps to avoid scope creep. Scope creep introduces risk, especially when introducing order 2 things, like new technologies.
Set up to use feedback as much as possible. This means that the project should deliver working functionality as soon as possible, in as small increments as reasonably possible.
Identify the areas where knowledge is lacking, and focus on these first. That way, when risks become reality, you’re still early in the project and have many more options to cope with the problems.
Be conscious about introducing new technologies. Most of the time, they are sold like they solve all your problems, but be aware that they also often introduce lots of new problems, if only it were for the fact that you need to get acquainted with them first. Sometimes, it may be very useful to introduce something new, but it is very difficult to assess the risk beforehand. That’s exactly why it is an order 2 (or 3?) risk.
Try hard to decouple things in your project. I once witnessed a project were two pieces of hardware were developed at once, and those pieces had to be integrated as well. That way, there’s not just the risk of piece 1 and piece 2 separately, but also the combination of risks. The project couldn’t deliver until both pieces were ready, so the combined risk was much higher than the risks of the development of the separate pieces.
Build in the possibility to scrap features when time runs out. This can be done by building the important features first, and the less important features later in the project. In case of setbacks, you can still deliver the most important parts.