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.

If you want to get things done, prioritise

If you want to get things done, you need to prioritise. Not all things are equal. In this busy world, if you don't prioritise, you won't get the right things done.

This simple truth applies at all levels. At the lowest level, it applies to your personal productivity. At the wider level, it applies to your project, your team or your company. If you don't prioritise, you won't drive things through and get the essential things done. You'll get distracted on the way by myriad lesser details and secondary priorities

Personal productivity

Getting things done (GTD) is the current fashion. An American guru called David Allen has pioneered a method called GTD which has been commercial success for him, but a disaster for many people's personal productivity, The fashion has created a tsunami of GTD offerings - there are hundred of Smartphone apps, Mac and PC software apps, books, websites and videos based on Allen's work. All of these can lead you into the same trap: you end up with long, long lists of un-prioritised tasks, which you try to pick off one by one. Do you get more things done? For many people, the GTD method doesn't increase productivity; it produces a mess. It's like a compost heap – a large, untidy mixture of assorted tasks, some old, some new; some urgent, some trivial.

There are better ways to work, and better apps. An early app came 10 years ago with the Palm Pilot, before Allen wrote his book. The Palm was a predecessor of the smartphone, and part of its success was due to its excellent ToDo app, which prioritised tasks as ABC (and, of course, also by category). You knew what was important. Today, there are a few good alternatives to GTD, such as the 2Do app, which prioritises tasks in 5 ways (Star-High-Medium-Low-None). This works, this really does help to get the right things done. You know what's important, even if you have hundreds of pending tasks.

Project priorities for on-time delivery

In the work environment, some project methods prioritise to stay on target and on time. The AgilePM method, based on the DSDM Atern variant of Agile, uses MoSCoW prioritisation. The MoSCoW acronym stands for "Must Have", "Should Have", "Could Have", "Won't Have". Using MoSCoW prioritisation, you prioritise your scope (features or needs) both at the project level and also timebox by timebox. This is a powerful technique, which really does help you to get the right things done, and - very importantly - to guarantee on time delivery. (It's an Agile technique which you can transfer to non-Agile projects, using Waterfall methods or methods like Prince2).

Portfolio prioritisation model

At the big picture level, it's important to prioritise too. If you are running a set of projects and programmes, you have a portfolio which you ought to prioritise with care and intelligence, so you can deliver your strategic objectives. If you don’t prioritise, you can end up busy, but getting nowhere.

The best practice approach is to prioritise using a combination of the attractiveness and achievability of each project or programme.

·       Attractiveness should be based on multiple criteria, such as alignment to your high level strategy and expected ROI (return on investment)

·       Achievability is typically based on the delivery risk (probability of success)

Best practice guides like MoP (Management of Portfolios) and P3O (Project, Programme and Portfolio Offices) tell you how to do this. They suggest that you start by getting agreement on a Portfolio Prioritisation Model. Once this is agreed, you can use it to assess both your current portfolio and your "demand" (the pipeline of new ideas and requests which could become lines of your portfolio). This is proven best practice. This works.

So whether you need to get things done at the personal level, the project level or the portfolio level, you need to prioritise. If you don't, you'll probably lose your way. If you do, you may really get the RIGHT things done.

Do it right or do it fast?  There's sometimes a price to pay for "Do it fast". It's called Technical Debt.

Probably the most famous example of technical debt is MS-DOS. Back in 1981, IBM asked Bill Gates for an operating system for its new PC. To deliver on time, he took QDOS, (QDOS stood for Quick and Dirty Operating System) and renamed it MS-DOS. Born quick and dirty, MS-DOS was loaded down with debt from its very conception, with a poor command set and limited features.

In the world of project management, on time delivery is a key measure of project success for most projects. As you rush to meet the deadlines, you may be accumulating debt silently, invisibly... but incessantly.

Technical Debt may appear as

o   No documentation or user guides

o   Low quality programming (unstructured, few comments, hard-coding)

o   Badly structured databases (redundant data, data errors)

o   Poor designs (poor architecture, not modular)  

o   Poor processes (inefficient, waste time, error prone)

Debt is typically associated with software projects, but it's not only about software - all sorts of project can generate debt.

Technical debt is often generated by the pressure to finish on time, but it's not just a question of speed. There are several sources of debt.

• Speed: rushing is probably the number one cause of technical debt.
• Short term view: Patching and mending. Non-architected solutions
• Fire-fighting: Focusing on backlog (not on the future)
• "Bleeding-edge" innovation: Learning as you go along
• Lack of skills: Putting staff with wrong skills (or no skills) onto complex tasks 

Why do we worry about it?

Technical debt is like financial debt... you can ignore it for a while, but the accumulation of debt will come back and haunt you.  As you build up debt, you end up with a mess - a patchwork or spaghetti that's difficult to understand or difficult to change.

That's a potential surcharge on everything you try to do - technical debt can slow down and complicate future projects. You may also end up with premature aging - the accumulation of debt can shorten the lifetime of your solution.

Don't Sprint into debt.

The main cause of debt is speed. Some project management methods focus on speed, notably most lightweight variants of Agile. Lightweight Agile methods such as Scrum can force you into debt if you over-focus on sprints and speed. You may deliver on time, but if you sacrifice other factors of best practice, such as design, planning or quality, then you could be accumulating debt.

There are two ways around this problem for Agile projects. You can try to make your lightweight method more robust (as described in the book "Managing Software Debt" by Chris Sterling) or you can use an enterprise Agile solution

How Enterprise Agile helps

Enterprise Agile methods such as DSDM Atern (sometimes branded as AgilePM) allow you to combine agility with architecture and design. Atern also has a project management toolkit to ensure a long-term approach (plans, business case, etc.) - these help to clarify the trade-off between speed and debt (and therefore to remove or reduce debt).

Whichever way you choose, and whether you use Agile or not, you need to be aware of debt. You probably won't be able to be debt free, but you should apply three golden rules:  

• Start today to pay back old debts (each new project cleans up some previous mistakes and clutter)
• Avoid new debt (do it right in future, balance speed with quality)
•  If a project does have to sprint into debt, clean up the mess ASAP