Knowns, Unknowns and Project Management...

This article is a draft of a paper i started to write in september 2007 and left it where you see it today.  The purpose is to to come out with a conceptual framework through which “the knowledge needed to successfully execute a project” can be viewed and gauged and presents a brief outline of the same. As always comments are most welcome...

Financial Resources, Domain, Technology, Communication, Cultural Differences, Organizational Structure, Organizational Culture and Power Play within an organization are some of the factors that have an ultimate bearing on the success of a project.

All projects come in shades of grey is a fact that has to be acknowledged. For example, when we start a project, very rarely do we know everything about Project Requirement, Scope and other factors that impact the project. There will be lot of ambiguity and this ambiguity has to be accepted and put to proper use.

But the problem is that people usually look at these factors in black and white. This may be acceptable for senior management reviews, but not for project managers and other decision makers. These binary, uni-dimensional perspectives by Project Managers mean/ensure that they miss out on the nuances that enable them to make successful decisions.

Our knowledge of all these factors can fall under one of the three categories.

• It is good enough to execute the project successfully (what I call as 1).
• It is not good enough to execute the project successfully (what I call as 0).
• It is neither 0 nor 1. Our knowledge lies somewhere in between.

The take away is that our awareness of these factors varies. It lies somewhere between 0 and 1 (both inclusive).

For example, when we are in the analysis phase of a project, though we know requirements at a very high level ( for e.g., build a report that forecasts the earnings based on custody account), we still have quite a bit of drilling down to do, before we get a set of requirements that is ‘implement-able’ or ‘code-able’. I can say that, there is a certain degree of ‘unknown’ in this requirement. I can call (this) requirement an ‘Unknown known’. The same thing can also be said about all the factors that affect the outcome of a project.

A project or our knowledge of something can be looked at in terms of the following four

Unknown unknown - you don’t know you don’t know

Known unknown – you know you don’t know something

Unknown Known – you don’t know to what extent you know

Known known – you know to what extent you know

If the above sounds confusing, as it is bound to be, the example given below should help in clarifying

• Unknown unknown: Before the requirements are shared, our knowledge of the project or a report the system (to be built by the project) has to generate is not known. For us, the project or the report it has to generate is an `unknown unknown'.

• Known unknown: At the initial stages of the project, we will come to know that there is a report module, but don’t yet know what is there in the module. For us this is an example of `known unknown'.

• Unknown known: In the analysis phase, an analyst goes through the requirement for a ‘forecast report based on custody account’. He or she does not yet understand ‘forecast report completely’. For him or her, it is an `unknown known'. (Please note that the focus of the first `unknown' shifts here from lack of knowledge of the general to lack of knowledge of the specific.)

• Known known: After analyzing the requirements for the report well, it becomes a `known known': It is both known to exist and understood.

What this implies is that a project can be looked upon only in terms of our knowledge of the factors that impact the project (X) and the extent to which we are aware of these factors (Y). Since there are two factors and the value of these factors can vary between 0 and 1, this lends to representation as a 2 dimensional matrix, which looks like as shown below

Now, why is this so called known and unknown so important?

The Known and Unknown presents us with a way to approach the factors that affect a project. The extent to which we are aware has an obvious impact on how we manage the project and hence on the success or failure of the project.

The goal of the team should be to drive as much information down into the Known portion as much as possible. Only the information in the known quadrants is actionable. The majority of issues/problems come from the Known-Known quadrant (lower left). Since these are issues/problems, these are taken care as a part of Project Issue Management.

Most risks are found in the Known-Unknown quadrant (lower right). Known unknowns can be anticipated and planned. The Known unknowns are managed using Contingency Reserves. This is a separately planned quantity used to allow for future situations which may be planned for only in part ("known unknowns"). Contingency reserves are intended to reduce the impact of missing cost or schedule objectives. Contingency reserves are normally included in the project's cost and schedule baselines

To quote Tom DeMarco, “It's not what you don't know that kills you; it's what you know that isn't so”. We know a little bit about what we have to do and many a times may think that it is good enough for the project. But then we will be in for a surprise as reality turns out different. Unknown Knowns fall under this category.

Unknown knowns are also called ‘uncertainties’. Unknown knowns are usually factual and measurable; things are known, or not known, or known to a quantifiable degree or within quantifiable bounds. Please note that our knowledge can only be measured in relative scales and not in absolute terms.

The Unknown knowns should be managed by increasing our awareness [of the factors] to a certain level where the awareness is good enough to see us through the project. If we take our example of the forecast report based on custody account, the moment we know it is a part of the project scope, the project team has to know enough about the report to code it as per requirement. The same holds for anything that impacts the outcome of the project.

Unknown Unknown is the worst of all. We are not aware of its existence and hence can’t action on it in the usual. This is also known as ‘force majeure’ or ‘act of god’. The so called ‘unknown unknown’ is handled by using a Management reserve. It is a separately planned quantity of money used to allow for future situations which are impossible to predict. ("Unknown unknowns") Management reserves are intended to reduce the risk of missing cost or schedule objectives.

Unknown-Unknown is said to have happened, when a totally unexpected event that has an extreme positive or negative impact on the project occurs. Unknown-Unknown is still an upcoming area as far as project management and project risk management are concerned. And generally for projects of the financial magnitude and timelines that we execute, there is no need to be too worried about unknown-unknown. Managing Unk Unks can also be very expensive. I have given below what I read in a book review* on the web

Unknown unknowns (Unk Unks) cannot, by definition, be identified, but the areas where they lie – where knowledge about the project is lacking – can be circumscribed. Homing on them is a gradual iterative process of discovering the parts of the project in which the knowledge is the weakest. Once they are hemmed in, two methods can be employed to overcome them. These are Learning and Selectionism, respectively. Learning in projects is the flexible adjustment of the project approach to the changing environment, as it occurs. It is a repetitive process of asking, “What do we know, what do we need to know, and what might we not know that we do not know?”

Selectionism is defined as running multiple trials in parallel. It is most appropriately used when the terrain is so uncertain that a single trial is unlikely to home in on an appropriate solution. Selectionism is also called parallel development my product developers and it has fallen out of favor as development budgets have been squeezed.

The mindset needed to address Unk Unks is quite different than the one normally encountered in the corporate world. 

The authors illustrate this by describing a version of the mindfulness, which encompasses five components

• Preoccupation with Failure: Reporting and investigating any deviation from plan since it may be a precursor of serious problems ahead.
  
• Reluctance to simplify: Because unk unks fail outside of our experience, simplifying and focusing may blind us to them; the mindful manager lives with ambiguity and uncertainty.
  
• Sensitive to Operations: Not accepting standard procedures and outcomes at face value but looking behind them for patterns or hunches that might indicate unk unks.
  
• Commitment to resilience: recognizing that the unexpected will happen and being prepared to change plans quickly and bounce back from disaster.
  
• Deference to expertise: Pushing decisions down to levels where the experience to deal with them is greatest, response can be quick, and a diversity of options exist.
  

All the different combinations of known and unknown other than Unknown-Unknown, is about our knowledge of the factors that have a bearing on the success of a project. Hence it goes without saying that the project manager and the team are expected to continuously expand their knowledge levels. This can be through studying, attending courses, reading on the web and reading blogs. The team should also learn from other’s experience and should try hard not to re-invent the wheel.

The Manager should call up people on previous projects and talk to them about what happened. He can get seniors to address the team. Also, project managers are encouraged to study objectively, in depth, post mortems from previous projects. The onus is on the project manager to ensure that all the channels to acquire enough knowledge to successfully execute a project are available to himself and his team. This will ensure that the knowledge levels of the team grows and the team continuously brings what was in the realms of unknown into the known

At the end of a project, the knowledge levels of the project team should look like this.

Please note that increase in size of the known-known doesn’t generally mean that the size of the other quadrants decrease in the process. For e.g. even at the end of a project, there will still be some factors ( a requirement moved to the next release, a known bug that happens in a rare situation and so on) about which we are not clear about. But as long as it doesn’t have an impact on the outcome of the project, we are fine. That is why the boundaries are left open to remind that our ignorance is always going to be boundless. ;-)

A question may arise in the mind of the readers as to what level/depth their knowledge should be. A simple answer is that the knowledge should be good enough to help meet the project objectives. Nothing more is needed. But since this level of knowledge to successfully execute a project is difficult to quantify, the team should not mind overdoing their quest for knowledge. This is one area ‘over doing’ wouldn’t hurt.

* A review of the book “Managing the Unknown: A New Approach to Managing High Uncertainty and Risk in Projects Christoph H. Loch, Arnoud DeMeyer,and Michael .T Pich. Hoboken, NJ: John Wiley & Sons, 2006