A timely talk from Nigel Marsh for Valentine’s Day?

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.

This is a great talk from Jason Fried about the problems with working in an office, with all the distractions that implies. It is interesting and provocative, and well worth a watch.

An important lesson from this, for me, is to remember what a project manager is for. The people who are actually doing the work in your project are the most important resource you have, and you as a project manager should be guarding their time jealously.

Now, most of us are pretty good at this when it comes to resisting attempts from outside the project to take away our team members’ time, but how do we perform in making sure we aren’t destroying their ability to work?

If nothing else, I can certainly get behind the idea of reducing meetings – maybe we can’t get rid of them altogether, but we can certainly improve on them – check out my post on 10 tips for better meetings.

We all know that good communication is important in project management. It helps to keep the project on track, reduce misunderstandings, and contributes heavily to project success.

But, sadly, there is also another benefit to good communication, depending on the type of organisation you work in. Because sometimes communication isn’t about getting your message across, it’s about being seen to be giving the message out.

Every organisation is in some way political. Even the smallest of organisations has people with varying aims, but the real problems happen when you get to large organisations. These have many different people, all of whom have their own goals, as well as trying to progress the organisation’s aims.

And, unfortunately, sometimes your project can run afoul of these different aims. Recently, a project I was working on was moving happily along with two different parts of an organisation. We were rolling out a new technology into one part of the business, and had left open the possibility of the other part getting involved later on.

But all the communication had been of a rather low-level, informal style. People on both sides knew what was happening, because middle management had been speaking to each other, and passing messages up or down their chain as needed.

However, when push came to shove, and the second half of the organisation had to decide whether to get involved or not, suddenly the communication seemed to have been for nothing.

You see, as no formal communications had been passed across – the other side of the business wasn’t a stakeholder – one side could claim the other hadn’t given them enough time to consider the options. This was despite the relaxed communications of middle-management.

Sometimes, you have formal communications just so you can prove you have had the communication. It may not be project management, but it’s something project managers need to do.

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.

After my post on Friday about building a team, the folks at Steelray Software sent me a link to a great blog post covering the subject of teams, and the different personalities in them. You really should go and read Why That Urge to Scream is Totally Valid.

So thanks to Steelray for sending me that link on Twitter. (Hey, don’t forget you can follow me on Twitter too!)

Don’t forget to send me your tips on building a team!

Last time, I talked about the importance of teams, and the importance of making sure they didn’t turn into cliques. That got me thinking about the good side of teams.

A team is really just a small community, a group of people who work together to achieve something. Now, a team at work is unlikely to be as close as other communities (which, as we have seen, is probably a good thing), but it is still a community.

Human beings like being in communities. We are social creatures. But it can be very hard to create a community deliberately, rather than having one gradually grow up. In a project, though, you want to ensure your team gels quickly.

This often means you, as the project manager, have to take steps to foster the growth of a team. Yes, this may mean talking about the dreaded team building activities.

One example I have is of the head of a department deciding the whole department should go and help out at a local nature reserve. Their job, when they arrived, was to use shears and secateurs to clear out some of the undergrowth within some woodland.

I can’t help but feel sending an entire department out into the wilds after arming them with sharp metal implements was a brave thing to do, especially as the senior management were out there with them…

However, it seems to have worked – though at least in part because the department bonded over the absurdity of the whole process!

This is where I throw it open to you – how do you go about creating a real team? What do you do to help them form a community? Any particular tips, techniques, even activities that you use?

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.