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.

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.