Well this one is about as simple as it gets.

Yet I’ve found it very useful as is often the case with simple models. Maybe it’s my style of consulting but I have always found simple models which explain a key concept very well to be far more useful than models which require lots of explanation to be used effectively.

A while ago I wrote this article: 100 Management Models & When to Use Them in which I promised to slowly get through all 100 Management Models, explaining each one in more detail.

That list is a collection of really useful management models (i.e. things like The Forming, Storming, Norming, Performing Model of Team Dynamics, Chunking and Maslow’s Hierarchy of Needs), most of which are well known models you should be able to find more details about via a simple Google search (in case I haven’t yet elaborated on the model myself), so that is a very useful list in itself even if some of the models don’t (yet) have an explanation. I also include a few of my own models I’ve used as a consultant.

So this is one more checked off that list (which I’m slowly getting through) and in this case one of my own models. (which is probably why it’s simple lol). I came up with this in picture form quite a while ago (we’re talking about nearly 20 years ago now) to explain a simple concept to a client. Since that time I’ve used this model plenty of times when consulting, it’s one of my favourites.

Introducing the No/Know Model

The model has 2 axes, Capacity (for Knowledge or Lack of Knowledge about the project or endeavour) on one and Time (or you could use Project Lifecycle) on the other.

The model simply shows that for any given project (or indeed any particular endeavour, but I’ve mostly used this related to projects) our knowledge of that project increases and at the same time the amount that we don’t know about the project diminishes.

No = What we don’t know about the project – this can encompass unknown costs, risks, dependencies, issues, requirements we didnt think about which we should have and any other difficulties which are likely to affect the time, cost or scope of the project.

Know = What we know about the project – fairly self-explanatory this is what we know about the project, the requirments we have documented, the risks we have gathered and accounted for, known issues, project plans, key stakeholders, known dependencies and also what we know about available resources and the project environment.

The irony is (and where I have used the model to illuminate the point many times) we generally agree the requirements of a project and sign off on it quite early (draw a vertical line somewhere near the front of the model, like so…).

This is obviously quite risky (increased chance of missing something).

Final Thought – Where to Use This

This model is most useful as a communication tool.

To show in a picture what can be explained in words, but something you can easily draw out in seconds on a flipchart, whiteboard or sheet of paper, because it has more impact than words alone.

Used the model as a communication tool from a consulting perspective to explain where things may have gone wrong on a project (e.g. in a lessons learned or audit scenario), to argue the case for a more agile method of project delivery vs a more traditional waterfall type approach (particularly if the project is quite big) or to simply communicate the situation so that everyone involved has a perspective on where the current level of knowledge vs no knowledge on the project stands and that this will change as time goes on and more is known about the project.