I’ve previously written in some detail about the processes you need to use or adapt in project management, and the steps you need to take to improve the chances of a successful project. But we mustn’t forget that projects end up affecting people, and we need to make sure they are considered as well.

Two weeks ago, I talked about the three broad types of communication we need to consider in our projects – internal, outgoing, and incoming. Last week, we had a look at the outgoing communications in the project.

Today, let’s have a look at the communications that happen within a project.

The most obvious example of this type of communication are the dreaded update meetings. I’ve written before about my general dislike for meetings, but they do have value as well. They are a very effective means of communication, so long as we make the best use of them that we can.

But while this is the most obvious example of internal communications, it is far from the only one. Other formal methods of communication also exist, be it in highlight reports from the project manager to the Executive or board, or even in the update reports the project manager receives from team managers or external suppliers.

Often, however, the best forms of communication are those that don’t take place in a formal structure – the quick chat in the corridor, the phonecall to query a couple of details, the email fired off late at night doublechecking something. These communications are a way of making sure that you as project manager know what is happening in the project, and that the people involved in the project all have a good idea of what they are doing.

Yes, if a major issue comes up from these informal chats, it needs to be recorded and captured in a formal way, whether in a risk or issue log, or by adding it into a highlight report. But often these chats, and a little bit of guidance, can prevent minor misunderstandings becoming major problems.

The internal communication of the project is one of the best tools you have as a project manager to keep the project on track, to keep the project team motivated and involved, and to bring the project to a successful conclusion. Importantly, this isn’t done by being blinkered into only using formal methods – it’s the friendly word at the right time that is much more useful.

Next time, we’ll look at incoming communications.

I’ve previously written in some detail about the processes you need to use or adapt in project management, and the steps you need to take to improve the chances of a successful project. But we mustn’t forget that projects end up affecting people, and we need to make sure they are considered as well.

Last week, I talked about the three broad types of communication we need to consider in our projects – internal, outgoing, and incoming. Let’s have a look at which parts of this we can do by following a process, and which parts we need to be more flexible around.

Outgoing communications need to be handled carefully, and should be subject to some form of control. This isn’t because we want a project to be a secretive and strange organisation within the business, but to ensure that the right messages are going out – the one thing worse than no information going out is incorrect and conflicting information going out.

For this reason, it is good practice to have a formal communications plan. It helps to ensure that some thought has been given as to who to communicate with, how to communicate with them, what to communicate to them, and how often to communicate with them. In addition, it means that members of the project team are aware of their role in communication, and, just as importantly, what their role isn’t.

The first thing a communications plan needs to do is decide who the audience for communications will be. Remember, the audiences can be many and varied, but the types of communication used can be just as varied. When thinking about the audiences, try to be as inclusive as possible.

Once you have been able to identify the various stakeholders and audiences that need to be considered, it is time to think about the information they need to see, and how they need to get it.

For example, there are some fairly obvious people who need to be kept informed – the people who gave the go ahead for the project to happen, be they a programme board or senior management within the organisation. Many of the communications to them will go through the Project Executive, or be done through formal documents produced by the project team, such as highlight reports.

However, these aren’t the only people that need to be kept informed. The people who will use or be affected by the project also should be told what is happening on a regular basis – if nothing else, frequent communications may reduce uncertainty, nervousness, and possibly even opposition to the project. The communications to this audience are likely to be very different than those to senior management.

Now we know who, how, and how often we are communicating, we need to know who within the project team has responsibility for doing it. As we’ve already discussed, the Project Executive is best suited for communications to senior management, but he will need information you provide as project manager. Possible users, though, may be better off getting information from the Senior User on the Project Board.

These are only examples, and of course will vary from project to project. The important point to take away is that you will need to consider how this is done, and have a plan, rather than muddling through as the project goes. Make sure that for every stakeholder or audience identified, someone has the responsibility to make sure the communication gets to them.

Next time, we’ll look at internal communications. I hope you’ll join me then.

Project communications are important in a number of ways – don’t neglect any of them.

There are a few ways that we need to be comfortable communicating when we are managing a project. Clearly, we need to enable effective communication within the project, so that team members and others have the information they need about what everyone else is doing to ensure their work remains on track, and fits in with everyone else’s.

But we also need to deal with communication going out of the project – every project I have worked on has had an element of communicating what the project is about to those outside. It’s about making sure that the mysterious organisation called the project doesn’t stay mysterious for long, and the rest of the business (who, ultimately, the project is designed to benefit) are aware of what the project is doing, and why.

One final aspect that is sometimes forgotten is being aware of communication coming into the project. The most obvious example of this is the communications being passed down from the Project Executive (or Sponsor) about the environment the project is working in. After all, this is part of their role – to be able to interpret the environment, and to be a point of contact for senior people within the business.

But this isn’t the only route communications will come into the project, though it is the most easily described formally. There will also be murmurings and rumours, gossip and chatter, most of which will be of no value, but some of which may actually highlight important issues.

For example, if the murmurs outside of the project, picked up in casual conversations by team members, point at a level of mistrust towards the project (and believe me, this can happen) it is important to make sure your communications out of the project are boosted – the message about the benefits may not be getting out clearly.

Of course, it may be that the project is always going to be seen slightly negatively – sometimes the project is doing work that is of benefit to the organisation as a whole, but not to certain individuals within it. In that case, it’s important to note the problems being aired, and realise they are issues to be dealt with, or indicate risks to consider, as the project continues its work.

Project communications are an important, and often overlooked, part of every project. I’ll be going into this in more detail next week – I hope you’ll join me then.

Project management with scarce resources, and in troubled organisations, brings new challenges. Be mindful of the needs of the people around you, but remember your job is to make the project a success.

One of the most difficult times for a project manager is when resources are scarce. You have to scrabble around, trying to find people who can complete different work packages, or to find enough money in the budget to pay for vital supplies.

Even worse is when the whole organisation is finding recources scarce. Then it’s even more important to be able to explain the benefits of your project, and fight to get it the resources it needs to be successful.

But worst of all is when resources are scarce for the organisation, and your project is about cutting costs – because most of the time that is a euphemism for cutting staff.

I’ve been brought in to run projects like that from time to time. It is a very difficult position for anyone to be in. It is also a problem for the project – an external consultant brought in to run a project which may lead to job losses is almost automatically distrusted.

An extra difficulty is that the people best placed to know how to make the project a success are also likely to be amongst those whose jobs will be put at risk. Initially, some will be eager to help, to get a connection with the project, but those who aren’t part of the project could very easily come to feel defensive and resentful.

There’s no easy way to deal with this. You have to remember that the project you are working on is for the benefit of the organisation as a whole, and unfortunately that means some people within it may suffer. Understand their feelings, but keep working to make the project a success.

The Executive is the one who makes the decisions about whether the project is right for the organisation. You have to trust his judgement, and be as professional as you can in completing the project.

Project management is often more about knowing what to leave out than anything else. Every project will need a different blend of methods, procedures and processes, and you need to use your judgement to know what to apply.

It’s easy to buy a book on project management which will hand you a set of processes to follow, or rules to obey. These books have their place, and are a valuable resource for those just getting started in project management.

But what these books are providing you with are the raw tools you’ll need. These are, naturally, incredibly useful. But there is no point in having a toolbox brimming with shiny new tools if, when confronted with a problem, we don’t know which one to reach for first.

Working as a project management contractor, I have to go into projects without any prior knowledge of the people I am working with, or the organisation. Sometimes I don’t even know much about the project until I’m sat at a new desk in a new office, trying to get to grips with it!

It would be madness to try to use every single tool I have to hand on every project as soon as I arrive. Some projects need lots of big, formal, prescriptive project management procedures and methods. Thankfully, the vast majority do not – they need bits and pieces, they need the right tools in the right places.

This is what the books of procedures and methods can’t teach you – judgement. I need to look around at the situation I find myself in, at the people around me, at the project itself, and make a judgement about what needs to be in place to give the project the best chance of success.

Sometimes, that will be quite strict project management methods. Sometimes I can be more relaxed. Some people I can happily leave a task and now it will be done, while with others I will need to chase regularly for reports. All of these decisions require me to draw on my judgement – and that judgement comes from experience.

Now, all this could be quite disheartening to someone coming new to project management – but it really shouldn’t be. Experience comes to all of us, eventually, and will come to you. And you won’t go far wrong if you apply strict methods to begin with, and relax from there once you have more understanding of the project and project team.

Building a team is tough. That seems to be the consensus.

Which is pretty odd, when you think about it. After all, human beings are social animals; we like to form groups. So why is it that we seem to find it so hard to form a team in our projects?

The problem isn’t really with forming a team, or a group, it’s with forming the team we want. Normally, we would form social groups with people we like, and the traits and attributes that we like in those people may not necessarily be the ones we would value in a team member.

And therein lies the problem. We select project team members based on attributes other than how well they get on with the rest of the team members. This is based on the not unreasonable expectation that they will be professional enough to work with pretty much anyone.

Much of the time, when there isn’t too much pressure on the team, this works out fine. People are professional enough to just get on with their job. But where this falls apart is when you start putting pressure on the group.

At that point, tensions rise to the surface. Little irritations explode into major problems. And people who were just getting on with their job start to feel less willing to do that.

The problem is the level of commitment, of connection to the project, that a group of individuals has is much lower than that of a team. A team is working towards a common goal, and feels a duty and responsibility to each other, and to the project.

That means that when a team is put under pressure, they work together to defeat the problem, to build the solution, to find the right path to their goal. Pressure can actually help a team be more productive, not less.

Building a team, then, requires emphasising and promoting the values and goals the members share, it involves listening to them, helping them all work together. But most importantly, it involves recognising that most of the work of building a team has to come from the team members themselves.

Yes, you can help the process, facilitate it, provide an environment which makes it more likely to happen. Ultimately, though, it is as much the responsibility of your team members as it is of the project manager. Let them know the importance of this, of them, and of the team.

Building a team is important, we all know that. Having a team that are happy working together, that are committed to the project and the goal, can be the difference between a successful project and one that fails. But what about when building a team goes too far?

There is a danger that a team will stop being a team, and move over into being a clique. In a business context, a team is a group of people who come together to achieve a specific goal for the benefit of the business. A clique, however, is a group of people who work together for the benefit of the group, regardless of the effect on other groups in the business, or the business as a whole.

In other words, in case 1 the team uses the group as a tool to achieve success. In case 2, the group’s existence is seen as important.

This leads to problems because the clique begins to set themselves apart from the rest of the environment they are in. They start to see the group as special, as more important than outside, as something to be defended and fought for – regardless of the wider consequences.

Now, all of this is often subconscious, but I’m sure you can recognise some of the signs – teams start to get more cliquey, they begin to disparage other areas of the business, even other people in the same area not on the same team. An adversarial and antagonistic relationship with the rest of the business develops, leading to an inevitable loss of trust on both sides of that relationship.

This is, suffice to say, not a good thing.

Yes, encourage a team to form. But be careful it doesn’t become a clique.

Information needs to flow freely in project management, whether that be to the project manager or from them. One flow of information must be from the project manager to the Executive, and other senior interested parties. These updates are highlight reports.

A highlight report is exactly what it sounds like – a report that only mentions the highlights. It should be a brief document which (hopefully) mainly confirms that progress has been as expected. Where there have been variations from what is expected, you should mention that corrective action has been taken.

What you don’t want to do is to turn these reports into a running commentary on the project management. There is a temptation both to demonstrate that you are actually doing something, and also to cover your back a little by setting out everything that you have done over the week.

The truth is that your Executive really shouldn’t want this level of detail. You have been hired to do a job, to manage the project. If you start sending a full commentary of the project up to the Executive, of every little thing that has happened, of every small decision you have made, you are essentially making him also manage the project by proxy.

The Executive doesn’t need to know all the details. He needs to know you have the project under control. He needs to know if problems come up that you can’t solve. He needs to know if you have to go over tolerances. He doesn’t need to know that you are just doing your job, that you are just getting on with it.

So free up his time, and yours – just the highlights.

Growing up, I was surrounded by my dad’s books of classic science fiction. He had always had a fascination and interest in science, and the ‘hard’ science fiction of the Golden Age naturally attracted him. The cheap paperbacks and, much rarer, the hardbacks of that time still occupied many bookshelves in our house by the time I came along.

And so, with my own interest in science, and my voracious appetite for reading, I devoured novel after novel, anthology after anthology. I’ll be the first to admit that some of the stories were, well, awful. But many of them were amazing, in the truest sense of the word. The visions of the future, and the sometimes idealistic vision of human nature, could seem terribly profound and exciting to my adolescent self. At the time, some of these ideas of how the future could be inspired me, and some inspire me still.

But one type of story had a particular place in my heart. These were the generally short, but humorous tales – essentially long jokes. It seems many of the authors of the time enjoyed these, but the master, as far as I am concerned, is Isaac Asimov.

One of these stories is titled My Son, The Physicist. And I think this story actually describes something that can be useful to us in project management. (See? I did have a point with this rambling preamble.)

The story tells of the proud mother visiting her son, who works for a space agency, maintaining communications. But on the day she is visiting his workplace, the son, and the whole agency, are in uproar. They have received a communication from an expedition sent to Pluto years beforehand – an expedition which had been thought lost.

The problem is, Pluto is so far away that radio waves take hours to get there, and a reply takes the same time to get back. This means that an interrogation of the expedition will take a ridiculous amount of time.

But, of course, the mother saves the day, by advising her son to Just Keep Talking, and informing the expedition to do the same thing. In other words, pass on as much information as you can, and ask any questions as you go. The other side will push as much information back at you as they can, and slip answers in as and when they receive your questions.

In a way, this is what we need to do with project management. You must keep communicating all the time. Now, naturally you are unlikely to have a long timelag between either ends of your conversations! But even so, think about how we deal with information as a project manager. We pull in as much as we can, through checking the status of deliverables, getting updates on progress, receiving information on problems. We make sure everyone in the project keeps talking to us, to keep us up to date.

But we need to do the same as well. We need to make sure everyone else on the project has the information they need. We have to accept a stream of data coming in, but we also need to be sending one out as well. Sometimes we will be sending out a communication in response to a specific question, but other times we are pushing out information without being asked, to make sure everyone is informed.

For example, you may be sending a highlight report or status update to your Executive every week or month. You keep doing this without being asked – you send out that communication stream. But if the Executive specifically requests information on one particular area, you prepare that specially and send it out.

In other words, you keep up a constant stream of general communication, and slip in specific answers as and when needed. It’s important to share information on the project with those involved in it, even the day to day stuff – that way everyone has the background they need to understand where the project is going, and the knowledge to ask the right questions if they need more guidance.

So that’s my message to you about project communication – Just Keep Talking.

Quality is an odd thing. What we mean by it varies by situation, by product, by person. It can be very difficult to know what someone means by quality when they talk about it.

For example, two people could ask for high quality clothes. For one person, this may mean durable work wear, strong enough to cope with use on building sites, to stand up to the punishment of hard manual labour. Another may be asking for highly styled and attractive fashion items, clothes which give them more confidence in social situations, which simply make them happier.

Either of these definitions of high quality clothes is valid, in the eyes of the person buying the clothes. The validity of the choice depends on the person, and most definitely by the situation the clothes will be used in!

In other words, the concept of quality is highly fluid. Yet one thing we can agree on is that project managers are constantly being told to ensure they deliver high quality projects.

The problem is knowing what is actually meant by this. The possibilities are wide. Is a high quality project one that delivers a high quality end result – whatever that means? Or one that delivers high quality management products? Or one that does the job, but at a low cost?

The problem is one of definitions, and of communication. Because our Executive, or project board, or whoever, have one particular way of looking at quality is, it is far too easy for them to assume their view is shared by everyone else. Naturally, this can cause a lot of problems when, somewhere down the line, this assumption is found to be untrue.

The way to avoid this, as with many problems in project management, is communication. Make sure that you have really talked with your Executive, and effectively drilled down to what he or she actually wants.

There’s no high quality substitute for communication.