Posted on

Risk Management

The Management Pocketbooks Pocket Correspondence Course

Pocketblog has gone back to basics. This is part of an extended management course.


We are now at the end of our series of blogs, looking at some of the essential models that a project manager will need. We have covered:


Project Management blogger Glen Alleman (at Herding Cats – a trenchant blog by a serious heavy-weight project manager) describes risk management as the way grown ups do project management. I thoroughly agree (and have written a book on it, ‘Risk Happens!’ to boot).

Why does he say this? I can’t speak for Glen (I wouldn’t dare) but my own feeling is that professional project managers have nailed the planning process as a fully developed skill set. So all the uncertainty in your project – and therefore the difference between success and failure – lies in the risk. This must take up a large part of your attention.

So let’s see how to do it…

The Risk Management Process

Risk Management is a simple process:

  1. Identify anything and everything that you think can go wrong
  2. Analyse each potential risk and prioritise them by assessing the impact of their consequences, and the likelihood of them happening. High likelihood, high impact risks are your top priority, and low impact, highly unlikely risks can be deliberately set to one side – you cannot ignore them, but you can choose to do nothing.
  3. For everything else, plan what you will do. Will you:
    • mitigate the risk by reducing its impact?
    • reduce the risk by making it less likely?
    • create a contingency plan in case it materialises?
    • find someone else to take the risk for you?
  4. Once you have your plans, put them into effect
  5. Review the outcomes of your interventions and, if necessary, plan and take further steps.

Risk Analysis

We analyse risks against their potential impact, their likelihood, and sometimes other factors like how soon they might affect us. The commonest tool is a chart of impact versus likelihood, onto which we plot our risks. The best approach is to keep it simple. Here is an example…

Risk Analysis

 

Further Reading

From the Management Pocketbooks series:

  1. Project Management Pocketbook
Share this:
Posted on

The Gantt Chart

The Management Pocketbooks Pocket Correspondence Course

Pocketblog has gone back to basics. This is part of an extended management course.


We are working through a series of blogs, looking at some of the essential models that a project manager will need. We are covering:

 


The Gantt Chart is like a non-identical twin of the Network Chart which we saw last week. It contains all of the same information, but displays it in a different way.

The Gantt Chart is named after Henry Gantt, who did not invent it. As far as I can find (Wikipedia seems clear on this), it was invented some twenty years before Gantt re-invented it by Polish engineer and economist, Karol Adamiecki. Writing in Polish, of course, and calling it a harmonogram , would never endear it to Anglophone engineers and managers, who, if they had heard of it, would probably have thought Harmonogram too effete and musical-sounding a term. Gantt Chart has an air of brutality to its sound and Gantt was a thoroughgoing American.

Building a Gantt Chart

Anyway, let’s convert last week’s network chart into a Gantt Chart.

First, we draw two axes:

  • on one, put a time scale
  • on the other, list all of the tasks

Now, starting with the first task, represent each one by a bar. Make the length of the bar represent the duration of the task, and place it to represent its scheduling, as driven by the sequencing and dependencies of your network chart: voila!

First, here is our Network Chart

Critical Path on a Network Diagram

Now, let’s translate this into Gantt Chart format…

Gantt Chart

And it really is as simple as that… until your project gets large and complex.

Further Reading

From the Management Pocketbooks series:

  1. Project Management Pocketbook

 

Share this:
Posted on

The Critical Path

The Management Pocketbooks Pocket Correspondence Course

Pocketblog has gone back to basics. This is part of an extended management course.


We are working through a series of blogs, looking at some of the essential models that a project manager will need. We are covering:

 


One of the pieces of project jargon that causes most confusion is ‘Critical Path’ and ‘Critical Path Analysis’, the process of calculating the critical path. The concept is actually quite simple, providing you start at the beginning.

Tasks, Duration and Sequence

The first step in preparing a project plan is to identify all of the tasks you will need to complete. When you have done this, for each task, you must estimate how long it will take. The third key step is to figure out how the tasks connect up, logically, into a sequence. For most of them, one task will be followed by another, which will be followed by another. In project management jargon, this is a series of ’finish-to-start dependencies’. This sequence creates what is known as a ‘work stream’. The complications arise when some tasks can run in parallel to one-another, when some tasks can trigger the start of more than one task, and when some tasks can only start when more than one task has finished. There are more complications than this, but that’s enough and covers most small to medium sized projects! The best way to make sense of all of this is to draw yourself a flow chart; what is known as a ‘network diagram’. Network Diagram

Calculate the Critical Path

Once you have the logic of your network drawn out, you can add your estimates of the duration of each task. These will allow you to calculate how long each path through the network will take. The longest path is called the ‘Critical Path’. It is critical because any delay (or ‘slippage’) to a task on that path will cause a delay in the completion of your project. Critical Path on a Network Diagram There you have it – simple in concept. Of course, like much that is simple, in the real world it is seldom easy. Calculating (and optimising) the critical path for a large, complex project with very many interdependent tasks is a big computation. When the methodology was invented in the 1950s, it was a big job to undertake. Nowadays, all but the very the biggest projects can be planned, optimised and monitored with the help of software running on a standard personal computer. I will never forget having the chance to look through the network diagram of the project to build and launch the first NASA Space Shuttle. Hundreds of pages of large paper and small print. ‘But’ said the project manager who showed me it, ‘when they planned the Mercury and Gemini missions in the 1950s, every time an engineer or project manager wanted to change the logical sequence, the network (or a chunk of it) had to be re-drawn by hand.’ How would that affect our attitude to getting it right the first time?
Further Reading  From the Management Pocketbooks series:

  1. Project Management Pocketbook
Share this:
Posted on

The Triple Constraint

The Management Pocketbooks Pocket Correspondence Course

Pocketblog has gone back to basics. This is part of an extended management course.


We are working through a series of blogs, looking at some of the essential models that a project manager will need. We have covered:

Defining a Project

We define a project in terms of its purpose, goal, objectives and scope.

  • Purpose: why we need it
  • Goal: what it needs to achieve
  • Objectives: the constraints we must meet
  • Scope: The breadth and depth of the work to be done

Objectives come in Three Flavours

Objectives set constraints we must meet: time, cost and quality parameters that define our priorities. Once all of these are fixed, we can think of them as occupying three corners of a rigid triangle: the time-cost-quality triangle.

The Triple Constraint - The Time-Cost-Quality Triangle - The Iron Triangle - The Triangle of Balance

This is also known by other names, the most useful of which is the Triple Constraint. Because once you have a plan, any attempt to change one corner…

  • to reduce the cost
  • to speed up delivery
  • to improve performance

… will only be possible if you are prepared to compromise one or both of the other two corners.

The important thing about the Triple Constraint is that it never tells you what to do – your primary and secondary time, cost or quality objectives must be your guides. But it will always show you clearly what your choices are.

An example…

You want your IT system to produce management data more quickly than it is specified to? Well that is okay. It can, as long as you are prepared to either:

  • Compromise on budget, spending more on the system and on the people and systems that feed it with data  –  or
  • Compromise on performance and accept either a reduced data set focused on the most important figures, or reduced data quality, giving first estimates only, based on the most material information, but awaiting the precision of the full information.

This is just an illustration, but it shows clearly how the Triple Constraint offers us options.

Further Reading

From the Management Pocketbooks series:

  1. Project Management Pocketbook
Share this:
Posted on

Project Lifecycle

The Management Pocketbooks Pocket Correspondence Course

Pocketblog has gone back to basics. This is part of an extended management course. This is our last blog before Christmas so may we wish everyone a happy and safe holiday and we’ll be back in 2022.


Implementing business strategy usually means starting one or more projects. Whilst nothing would please me more (as a former professional project manager) than to devote a series of blogs to a thorough description of project management, that is not the role of these blogs and also, The Project Management Pocketbook already covers that ground.

So I shall limit myself, in the next few blogs, to some of the essential models that a project manager will need. We will cover:

 

Four Stage Project

There are as many ways of representing the lifecycle of a project as project managers, but they all contain many of the same features, just different language for the stages, different choices of how detailed to be, and different graphical metaphors for how to draw it.

Here, we will use the version in the Project Management Pocketbook.

Project Lifecycle

Scoping

Define the purpose, aim, objectives and scope of the project to evaluate whether it makes good business sense and is therefore worth proceeding to the planning stage. Good business sense here means consistency with your organisation’s mission, vision and values, and a reasonable expectation that the benefits will exceed the costs.

Planning

Put together a detailed specification for what your project will produce and then use this as the basis to plan what you need to do, in what order, at what time, with what resources and allocating work to which people. Calculate the cost of your plan to create a budget and compare that with the benefits you will get if your project delivers to its specification and you can create a business case. You business case will guide your decision whether to invest in implementing your project.

Implementing

Now deliver your project, constantly monitoring for risks, changes, delays, overspends and the quality of your delivered products. Intervene where necessary to maintain control. At the end of the implementing stage, you can hand over the last of the things you have created to your customer, boss or client. Will they accept them? Only if they are fit for purpose.

Evaluating

How did it go? What did you learn? How did team members perform? Was it all worthwhile? Take this new knowledge into your next project and do that one even better.

Further Reading

From the Management Pocketbooks series:

  1. Project Management Pocketbook
Share this: