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

Need to deliver on time? Then start using time-boxes!

On time delivery is the El Dorado of project management. No one wants to be late for a key deadline. As the deadline approaches, and you’re running late, the project manager and the project team work like crazy to stay on time.  Everyone works late and comes in at weekends. This generates stress, overload, even burnout.

There’s a better way to deliver on time. It’s called time-boxing.

What is a time-box? A time-box has an fixed end date, which is fixed, but the work to be done is variable. If you are running late, you have a clear, pre-approved way of doing less. If you have less to do, you can probably get back on schedule. Before the time-box starts, you need to list the work to be done, and then get agreement on how prioritise it.

Here’s an example, for a simple project to tidy up and repaint a garage.

Without a time-box, you might list the needs in any order, perhaps in order of work
    •    Sort content of boxes
    •    Recycle junk
    •    Install new lighting
    •    Buy new tools
    •    Paint floor
    •    Paint walls & ceiling
    •    Paint woodwork

Without a time-box, if you run short of time, you may have to rush the last painting tasks. If you want to do a good job, you’ll be painting until midnight, and completely stressed out…

By using a time-box, you can keep calm and avoid panic. You will focus on the essentials, and make sure that those essentials are delivered on time.

The trick is, before you start work, you should get the time-box agreed. You need to prioritise the list of needs.

Prioritised list
     -- Must have --
    •    Paint walls & ceiling
    •    Paint woodwork
    •    Recycle junk
    -- Should have --
    •    Paint floor
    •    Install new lighting
    -- Could have --
    •    Sort content of boxes
    •    Buy new tools

 If we are a bit late, we will drop one or more items from the “could have” list. If we are seriously behind schedule, all the “could have” items and one or more “should have” items won’t get done. We will plan our work accordingly, with the the “must have” items early in the schedule and the “could have” items later.

The first time you use time-boxing, you might hit the problem that people can’t or won”t prioritise their needs. Your boss might say that everything is top priority. Nothing is negotiable. That’s normally not true, especially if on-time delivery is important. You may need to “educate” your boss. You may need to help people think through the real priorities.

If you are using a method like Prince2, you can add time-boxing to your work. In Prince2 terms, a stage or a work-package could be a time-box. You commit to deliver on time (zero tolerance on time), but you have a lot of flexibility on what you delivery, using your prioritised list of needs (so you have high  tolerance on scope)

Another choice for methods is to move to an Agile method such as Agile ATERN (with AgilePM certification), which is built around time-boxes and prioritised lists. This method  uses the acronym MuSCoW for Must have, Should Have, Could Have, Won’t Have to help you remember to prioritise.

So if you are always rushing to hit your deadlines, you have a better way forward. You have a way to avoid last minute stress and panic. If need to deliver on time, then it’s time to to start using time-boxes.

Project management, change management are like apples and pears

Should a project manager be a change manager? The traditional answer was YES, a project manager should know how to manage change. Today the answer is more often NO, as there are new and better ways to manage change.

Change initiatives are increasingly using a new role of Business Change Manager to manage complex change. In such cases, the project manager is no longer a change manager. Apples are apples and pears are pears: project managers manage projects. And change managers manage change.

What is wrong with a project manager running change management? Why invent this new role of Business Change Manager?

If we understand the Customer - Supplier relationship in projects, we will understand why. A Customer - Supplier relationship underpins most change initiatives: the project teams are on the supplier side, delivering a solution. The business teams are on the customer side, using the solution.

This “customer - supplier” relationship is not a question of contracts or invoicing. This relationship exists even for internal project teams working inside one company - an internal supplier provides a solution to an internal customer

This is why the we have two distinct roles, the project manager role and change manager role. One role on the supplier side, a separate, distinct role on the customer side.  And this is a peer-to-peer relationship, where the two roles are equal, not hierarchical.

Programme management methods like MSP (Managing Successful Programmes) recognise this separation. MSP has two two key processes
    ❑    a supply side process, called “Delivering the Capability”, for building the solution in project mode 
    ❑    a change management process on the customer side, called “Realising the Benefits”, for transitioning to the new solution and measuring the success of the change.

This approach has many advantages. Notably, it recognises that the motivations of the Project Manager and the Business Change Manager are very different.

The Project Manager is often motivated by
    ❑    technology (performance, features, innovation)
    ❑    sign-off and approval
    ❑    project performance measures such as finishing OTOB (On-time and On-budget)
   
The Business Change Manager has different concerns
    ❑    reliability, stability
    ❑    ease of use, training, support
    ❑    good documentation
    ❑    long term benefits

The Business Change Manager role needs business skill, rather than project management skills. The Business Change Manager should be chosen from the business area that will use the new solution. Crucially, after the solution is implemented, the Business Change Manager will return to the day-to-day business, and will use the solution week-by-week, month-by-month.

This reveals another important difference in motivation between the two roles the Business Change Manager (and his or her colleagues) is going to use the new solution, whereas the Project Manager will probably never do so. That’s a big difference, and that’s another reason why we we need a dedicated Change Manager.

So for your next business change initiative, try not to mix apples and pears. Don’t confuse project teams (apples) and business teams (pears). Project managers should manage projects. And change managers should manage change. Keep those apples and pears apart.

Time for timesheets.. or wait until tomorrow?

If you want to get control of your projects, you should use timesheets. Or should you? Is the accepted wisdom really wise?

Timesheets allow you to measure effort; i.e. man-days of work. All project management methods suggest you should control time and cost. Human effort one dimension of cost. It is normally expressed in man-hours or man-days of work (which usually can be  converted into a financial cost). To control effort, you need to estimate it when you plan and then track the actual effort. That’s where timesheets come in, to track the actual effort.

The Prince2 project management method follows this approach. The Prince2 planning process has an estimating step. For Prince2, effort is the primary resource estimation for each task. (Secondary resource needs include equipment, travel or money). By saying that you should control effort, Prince2 ask you to plan and then to track effort. Prince2 therefore assumes that you will use timesheets.

That’s what they are doing at one major bank using Prince2. Effort is indeed the main measure of project resource estimation. A small banking project may have a budget of 50 man-days of effort, whereas a large project may have a budget of 3000 man-days. To monitor progress, the bank uses timesheets to record actual effort by the project teams. So, for example, a 10-week project estimated at 50 days may finish with 45 (or 55 or whatever) actual days of effort. This is calculated from the timesheets of all the project team members submitted during the 10 weeks.

So timesheet solutions aggregate a lot of data from a lot of people. You need timesheet software, which lots of people need to use correctly and regularly. That’s where the problem starts. The software vendors will tell you that the software is easy to use (maybe true, maybe not!), but they won’t always tell you how much work is needed to achieve a sustained, widely-used solution which truly delivers benefits to your wider organization.

In some organisations, there can be hundreds of people working on various projects. A large hospital tried to implement a timesheet solution to control project effort.  Inside the IT department of about 50 people, this worked OK.  But most projects go beyond IT. The hospital has about 3000 staff, very many of whom could work on a project. You can’t ask 3000 people to fill in timesheets, just because some of them may work on a project from time to time.

Even for the small IT department, the hospital hit another problem, of scope creep. Once they had estimates of project effort for their teams, they had a partial forecast everyone’s future work plans. So they decided to go for a 100% solution, and complete the picture with plans on non-working time (holidays, etc.) and non-project work (support, maintenance, staff meetings, etc.). Once you try to manage the full working week for your entire team, you add extra complexity for little benefit. The hospital could not sustain the effort, and the timesheet solution failed.

There are a lot of failures with timesheet implementations. It’s hard work and there can be a lot of resistance. People don’t like filling in timesheets. It takes a lot of work to get everyone to submit a time sheet each week (and to sustain this 52 weeks per year). Furthermore, if you succeed, the data quality may be low, and consequently the benefits for project control may be slim.

Timesheets can work well in certain environments, for example where hours are billed to the customer. Or in closed environments, such as software development teams, where all projects are done by a limited number of project team members. In these cases, there is a clear benefit to the organization, so you can more easily succeed with timesheets.

If you choose not to implement timesheets, what can you do? One major chemicals company has decided not to use timesheets today for their projects. They know it’s premature – timesheets wouldn’t work today. Their solution is to track cost and time, but not effort.  Costs are tracked (expenditures); time is tracked (activity start and finish dates); but effort is neither estimated nor tracked.

So should you use timesheets? If your goal is to improve your team’s or your company’s project management maturity, yes, it should be on your long term agenda. Should it be a priority? You need to analyse timesheet deployment as a long term project. It’s not a quick-win software implementation project – you need sustained long-term commitment to get any benefits. Work out the business case, study the risks of failure.

You’ll possibly find that deploying timesheets is not a priority project. Your return on investment is perhaps too uncertain, your risk too high. Focus instead today on easier project management improvements with more certain benefits. Wait a while until you tackle timesheets. Mañana, demain, morgen, tomorrow.