No news is good news: Management by Exception

Are you fed up with boring Project Management meetings? Are you in an interminable cycle of weekly meetings? Are you overdosed by tedious Powerpoints?

It could be that you are suffering from “management by meeting”. If the only way that your company can manage a project is to hold weekly meetings with everyone round the table, then they are doing management by meeting.  Another day, another meeting.

There is an alternative. There is a way to reduce the number of boring meetings. It’s called Management by Exception.

Management by Exception is based on constrained delegation. Delegation with limits. When the delegation is in place, then you apply the old saying “no news is good news”. If there’s nothing exceptional going on, then you probably won’t have a meeting.

Here’s how it works:
    •    you propose a plan with some defined constraints
    •    when the plan is agreed, your manager delegates
    •    during the period of the plan, the delegation is in place…
    •    … unless something “exceptional” happens, notably if you exceed any defined constraint

So you only need a meeting if something exceptional happens. You don’t need management by meeting!

Let’s look at an example. Let’s imagine a project to install some packaged software.
    1.    You divide the project into stages. Let’s say that one of them is the software selection stage
    2.    You write a short document with your criteria for software selection; you create a work-plan for the software selection stage, with two constraints
    ⁃    The software is supposed to cost 30k€, plus or minus a tolerance of 10k€
    ⁃    The stage is supposed to take 2 months, plus or minus 2 weeks tolerance
    3.    This plan, including the constraints, is approved by your project board, so you start work. They know what you are doing, and when you plan to do it, so delegation is in place. Limited delegation - you can’t exceed your tolerances!
    4.    You send a regular weekly report to the board, showing your progress.

Let’s now see why it’s called Management by Exception, by looking at two scenarios, the best case scenarios and the worst case scenario.

Best case: For this stage of the project, you are broadly on time and on budget. Nothing exceptional takes place. You find the software and finish this stage of the project. No weekly meetings are required during the stage.

Worst case:  For this stage of the project, things are difficult. Let’s imagine some possible exceptional events
    1.    You can’t find suitable software
    2.    You can’t find anything under 50k€
    3.    You will need 3 months to evaluate and select the software
If any one of these exceptions occurs, then you need to get back ASAP to your board. You are outside of the delegation limits, so you do need a meeting.

So we only have meetings when they are useful. That’s why Management by Exception has big benefits
    •    It saves management time - it limits the time wasted in meetings
    •    It lets the PM manage, and helps avoids micro-management by top managers

Let’s be clear, Management by Exception doesn’t means laxity and absence of control. It is a practical approach, it is is not an idealistic “zero meetings” dream.

Some meetings are needed - for example:  
    •    at the start of the stage to agree the plan
    •    at the end of the stage to review the stage, and to plan the next stage
    •    if anything exceptional happens

It’s a best practice approach. It’s a cornerstone of the Prince2 family of methods. Prince2, the Project Management method uses management by exception. It is also used in MSP (Programme Management), MoP (Management of Portfolios) and P3O (Project, Programme and Portfolio Offices).

So if you are fed up with boring Project Management meetings, then bring in a best practice alternative. Stop wasting time, week after week after week. Move to Management by Exception.

Need inspiration on project quality? Look at your car!

If you are a project manager and you need to deliver quality, then go look at your car for inspiration. Your car is a high quality product which should inspire you in your project management...

A modern car is long-lasting and useful. It's high quality. The car manufacturers (Toyota, Renault, Ford, etc.) have worked hard to improve quality over many decades. Consider the last 50 years. If you compare the quality of two cars from 1964 and 2014, the difference is huge. The 1960's car had an limited lifespan, typically less than 10 years - its body would rust away year by year, its engine would wear out; whereas today's car should run for several hundred thousand kilometres and remain largely rust free for all its long life. Additionally, that 1960's car was basic - no radio, no heater, no seatbelts. That's very low quality in today's terms. Today, all that comes as standard.

So when you look at your car, you should admire a high quality product, and ask what the project manager can learn from car manufacturers.

In manufacturing, quality is defined in two ways: "Meets specification" and "Fit for use"

The manufacturer has delivered both in your 21st century car

- manufacturing specifications have vastly improved (better paint, more robust engines, etc.).

- customer satisfaction has vastly increased (the car is more "fit for use" - temperature control, audio, safety...)

Both of these definitions come from the world of manufacturing, but both can be applied to projects.

•  In automobile manufacturing, the car is the product. Toyota, Renault and Ford focus on delivering a high quality car
• In project management, your project has a "product" - this is your deliverable or your solution. This is where your quality focus should be.

We have two definitions of quality, so there are two ways to focus on quality in products.

1.  Using the approach of "meet specification", the starting point is to define (i.e. write down and describe) your final product, then to break it down into sub-products. To document that breakdown, you can draw a simple diagram called a "Product breakdown structure", which shows the 15 or 20 deliverables that make up your final product. You can then focus on each of these deliverables - particularly, on how to deliver quality for each deliverable, one by one. If each deliverable is high quality, then your final product will be high quality
2. Using the approach of "fit for purpose", you start with a less defined final product, typically a list of user needs or functionalities. (Sometimes these are expressed as "user stories"). You then work iteratively, trying to converge towards a solution that meets user needs. Each iteration is a better approximation to the final product, and where possible, is a partial working solution. Throughout the process, you work closely with your user or customer, showing them each iteration to get their feedback, so they can check that it's fit for purpose. Iteratively, you converge towards a high quality solution.  

These two approaches correspond to two Project Management methods

•         Prince2: The specification-driven approach is the way that the Prince2 project management method addresses quality. Prince2 has a "path to quality".
•         AgilePM: The iterative approach is an Agile way of working, supported by methods like DSDM (which is the basis for the AgilePM certification). DSDM says "never compromise quality"

Whatever your method, it's time to take action on Project Management quality.

One of the famous books on manufacturing quality is called “Quality is Free”. The book says that addressing quality correctly doesn’t cost you time and money, it saves time and money.

If you don’t use a robust approach to quality, you’ll probably waste time. You’ll discover the defects downstream. You’ll find out the customer’s quality expectations when you deliver. And you’ll probably fix any problems. But fixing quality defaults once the product is delivered can be very time consuming. You may end up doing the work twice… once to make the product, and a second time to fix it.

So addressing quality saves you time, keeps your customer happy, and delivers added value. Free of charge.

So maybe it's time to go admire your car... and to get inspiration for your next project.

6 honest servants to build your Communications Plan

Do you know who said this?

"I had six honest serving men. They taught me all I knew.

Their names were: Where, What, When, Why, How and Who"?

You probably don't know - but you'll recognise his name. It's Rudyard Kipling, author of "The Jungle Book", now famous as a Disney film.

Rudyard Kipling's saying can help you in Project Management. His basic questions "What, When, Why, How and Who" can guide you though the tangled jungle of project management communications.

Communications are important in Project Management - they can be critical to project success. Various analysts have highlighted poor communications as a major source of project failure, from the Standish Report of 1996 to the 2007 survey by COMPTIA.

Why is it so important to communicate? Firstly because many projects are cross-functional. Most organisations are functionally based - they are a series of functional silos. Things may work well inside each silo, but projects need to work transversally, across the organisation (more than one silo) and they often need to work with partners outside of the organisation (more than one company). For a cross-functional project to succeed, you need rich, transversal communications.

Secondly, the project is a vehicle for change. People are naturally resistant to change; they are familiar with the current ways of working. Change is disruptive; there is resistance to change. For your project to deliver real change, you need to communicate to maximise buy-in and to minimise resistance.

As it is important to communicate, the project manager needs a communication plan. This is where Rudyard Kipling's saying comes in.

We need our own Six Honest Serving Men to create a communications plan.

·  To whom? The stakeholder group who receive the communication

·  What? The message to communicate

·  Why? The objective of the communication

·  By whom? Who will create and/or deliver the communication

·  When? What frequency, or what date, or during which stage of the project

·  How? What channel of communication (email, face to face, meeting, intranet...)

Example

To Whom?	What?	Why?	By whom?	When?	How?
Entire project team	Initial objectives	Get involvement	Project Manager	Start of project	Kick-off workshop
Order management team	Training schedule	Ensure availability for training	Order Admin Manager	Start of stage 2	During monthly team meetings
Sales Force	New bonus scheme	Motivation	Regional Sales Manager	At next Quarterly Meeting	Powerpoint with Q&A
Internal Audit	Process flowchart	Compliance	Process team lead	For each new version	Process workshop
etc...

Creating the communications plan is the first step. Once that's done, the next step is to put the plan into action - to use it to organise your communications, week-by-week, month-by-month.

For the project manager , creating a communication plan is useful investment of energy. It normally takes you only an hour or two to create an initial plan, and it will save you hours of sweat throughout the project. It helps identify your transversal stakeholders. And it helps you focus on areas of possible resistance, and how best to mimimise resistance.

A communications plan is a best practice approach. In the Prince2 project management method, it's the basis of the project's Communications Strategy.  In MSP, for programme management, there is a diverse toolkit, starting with a Stakeholder Engagement Strategy; passing by various Stakeholder Analyses; and finishing with a Communications Plan.

Whatever your method, get out of the jungle! Remember Kipling's six honest servants and create a communication plan for your project or programme.

Risk: Does your project need seat belts and airbags?

Would you buy a new car if it didn't have airbags? Probably not. Would you drive without attaching your seat belt?  Again, probably not. You don't take risks with your cars. So why you take risks with your project?

Most project managers don't really bother about risk management. If you are one of those project managers, read on. Your project needs an airbag. You need to buckle up your project seat belt.

Projects are like cars, they are inherently uncertain and risky, because:

* Each project is unique, you've never done it before.

* Your project has a one-off team, who have never worked together

* Your project is delivering change (and that's hard and innovative)

Project managers try to manage uncertainty with a plan. A plan is your road-map into that uncertain future.

But most project managers are optimists. Your optimism can generate an over-optimistic plan. So each time you plan, you should perform a risk analysis, and bring that over-optimistic plan back to reality.

Here's how to do a risk analysis.

You need a flip-chart or white-board. Draw a table with 5 columns, marked

·  Risk

·  Probability

·  Impact

·  Danger

·  Response Action

Step 1 is to brainstorm the risks. You should do this as a small team exercise - ask one or two project team members to join you.

During brainstorming, you collectively generate negative ideas, for perhaps 10 or 20 minutes. You invite pessimism, and even criticism. Don't filter the risks, don't discuss them. Every risk goes straight onto the flip chart or the white-board.

Step 2 is to estimate those risks, one by one, using two criteria

1. Probability, from 1 to 4 (where 1 is least probable and 4 is fairly certain)

2. Impact, from 1 to 4 (where 1 is low impact on your project and 4 is high)

You multiply the two numbers to give the danger. You will focus on the high danger risks in step 3.

Step 3 is to think of possible risk response actions for all of your most dangerous risks (for example, with danger = 9, 12 or 16). For each dangerous risk, generate as many response actions as possible. (Don't worry now if some of these risk responses are overlapping or mutually exclusive, you'll handle that in step 4).

Here is an example for a conference:

Risk	Probability	Impact	Danger	Response Action
Low attendance	3	4	12	More advertising Change the date Lower the price
A presenter arrives late	2	2	4
We overrun the schedule	3	2	6
Presentations arrive too late for printing	3	3	9	Set an earlier date Postpone the conference Print after the conference Find a faster printer

Step 4 is to select a number of risk response actions. As you select them, remember that you only have a limited amount of resources and time. You can't select them all, you can't do everything,

That's the risk analysis DONE, in 4 easy steps.

Now you need to update your plan. All the risk response actions that you selected need to be added to your plan, and then followed through to execution in the following days and weeks.

Let's look back on what you have just done

1. You initially created an optimistic plan

2. The risk analysis allowed your team to be pessimistic for 10 or 20 minutes

3. You updated your plan, which should now be more realistic.

You've gone from optimism via pessimism to realism.

You've also created a simple risk register. Your 5-column table is just that, a risk register, which you can keep alive using regular reviews and risk analyses.

You've just started on the road to better project management, as suggested by methods like Prince2

In just a few simple steps, you have a lower risk project.

You have buckled your project seat belt. It's easy to do. So do it now, to increase your project safety.