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.

In this video, Alain de Botton talks about a different way of looking at success. It’s a good video, Alain is a witty and amusing speaker. He got me thinking about this blog, and whether it has been successful.

It’s been eight months since I started this blog, and seven since I really threw myself into it at the start of the year. Over that time, I’ve produced almost 100 posts. But has the whole process been a success?

As project managers, it’s too easy for us to get bogged down in one definition of success – the same we use when we are dealing with projects. Did it deliver to requirements, was it on time, and so on.

But, of course, this blog isn’t really a project – for a start, it doesn’t have an end-date! I also didn’t set myself goals when I started it, other than writing about project management.

So when it comes to deciding whether it has been a success, it has to be a personal and relative judgement, not an objective one. And looked at that way, I’m pretty happy. I have indeed been writing about project management, and I like to think my writing has been getting better. There are now a considerable number of people who read the blog, and I thank each of you.

More importantly than the numbers and the writing, though, is that working on the blog has forced me to take the time and give myself the space to think more deeply about project management, and about what it means to be a project manager. I’ve clarified my own feelings on what is important, how we should handle teams and managers, and how to be more successful in our projects.

I’ve also had my eyes opened to new ways of sharing my passion for and knowledge about project management. I’m currently working on another project (this one really is a project!) to help me do this, and will be able to talk about this more soon.

I’ve also been lucky enough to share in a whole world of online project management blogging, tips, advice, podcasts, information and community. Project management can sometimes get lonely, and it’s good to remember we are all part of a global community of professionals.

So has it been a success? Personally, yes, it has. I’ve got a lot out of it, and I hope you have got something out of it too!

So, last Friday I asked “What’s the point of project managers?” Not surprisingly, as a project manager myself, I think project managers are very useful! But I wanted to throw it open to you guys, and see what reasons you have for the importance of project managers. And you didn’t let me down, especially on LinkedIn!

John Burke says:
“Having someone trying to manage a project alongside the day job has never worked successfully wherever I’ve seen it tried. The individuals, when stretched with ever increasing workloads, have always reverted to completing day job tasks first at the expense of the project”

Dveirel Kovalsky says:
“Project managers contribute to the Knowledge Management and ‘wisdom’ of the company as an asset.”

Mahesh Subramaniam says:
“It is only the project manager whose sole aim is to keep an eye on the deliverables and align the individual objectives towards the common goal of delivering the business product that represents more or less the vision of all interested parties on the project.”

Karl Geppert says:
“The project manager is the valve between the business and the project team. They are needed to focus the whole project team on the business outcome ensure that this is planned, scheduled and delivered on targeted date and content.”

Tom Andries says:
“What’s the point of an architect? What’s the point of a clown? What’s the point of a designer?
With each profession are associated a set of skills that an individual tries to embody and practice.”

Mark Parrish says:
“Since most people got into PM as a SME, I think that they could do it. If people had the time and training.”

As for me, in common with many of these comments, I believe that a full-time project manager provides much more value above a part-time one than he costs. Yes, as Mark Parrish says, with training, the tools we use, the processes we follow, these can be learned, but that doesn’t make you a project manager.

Ultimately, a project manager needs to manage the project well, and for most of us this means, wherever possible, making sure the project is completed in a successful manner. And that takes more than pieces of paper.

Imagine the all too familiar situation that one of the project tasks is stalled, because the person working on it needs information from someone else in the organisation – information that just isn’t forthcoming. The monitoring of the project you have been doing means you have become aware of this problem, and that means you need to take steps to solve it. So what do you do? Well, you go to where the information is supposed to be coming from, and you talk to them, you smooth things over, you negotiate with them to get the information the project needs delivered as soon as possible.

These are the kind of soft skills you must have. You have to be a manager, laying down the law to team members who aren’t pulling their weight – and supporting them to solve whatever is stopping them. You have to be a negotiator, making sure suppliers, internal and external, deliver what the project needs when it needs it. You have to be a politician, talking to senior managers to make sure the staff the project needs are available at the right time. You need to be an advisor, giving the Executive the information he needs to make decisions about the project.

In short, you need to be a problem solver. You need to be able to handle any of the situations project management can throw at you. Some of this can be improved by training. A lot more of it can be improved through experience. But a lot of it is down to your own personal inclinations. Regardless of the type of projects you do, regardless of the industry area, you are going to have to be good at dealing with people. You could be working on the most high-tech space-age wonder gadgets, but it will still be people that will cause your biggest problems – and give you your greatest successes.

To be this kind of person usually takes: time, to gain the bitter experience; effort, to learn the tools, techniques and processes; and the right personality, one that enjoys solving these types of problems.

Now, that’s not to say that a member of the team couldn’t do these things, and be good at them. But the skills that make someone, say, a good programmer, aren’t necessarily the same skills that would make a good project manager. And besides, wouldn’t you rather have your good programmers spending their time actually programming, instead of project managing?

I’ll leave you with the most poetic of the comments received, from Eugenio Magnone:
“Scattered bright and colorful pebbles do not create a mosaic.”

Seriously, what’s the point? Note that I’m not asking what the point of project management is – any project needs project management of some sort. But what is the point of having a dedicated project manager?

Think about it. What if you just gave, for example, your lead programmer enough time to do some project management as well as coding? Wouldn’t that work just as well? After all, he’d be closer to the work, he’d have a good idea of how well it was progressing, and he’d know exactly what technical difficulties are cropping up – and how tough they are to solve.

Or what about an infrastructure upgrade. Why not trust the ICT manager to handle the negotiations with suppliers, and chase them up to ensure delivery? Couldn’t she better allocate work to her team than a project manager?

There’s actually a lot of sense in this view. Detailed knowledge of the subject of the project can be a great advantage, and naturally the people doing the work have a lot of this knowledge! If they can be given the time and training in project management, why not do this?

Now, naturally as a project manager I am not fully convinced by this argument! But this means I believe project managers provide benefits above and beyond what a subject matter expert could. I can think of a few, but I’m interested to hear what you think. So, how about it? What do full-time project managers provide to a project that a part-timer can’t?

40 years ago, man walked on the moon for the first time. This was an incredible achievement, the culmination of an immense project. This project had a lot of advantages:

• Clear objective – to send a man to the moon, and bring him back again
• Clear quality requirements – keep them alive
• Strong support from senior stakeholders – Presidential support
• Extensive funding – between $20 and $25.4 billion in 1969 dollars (or approximately $135 billion in 2005 dollars)

But, of course, the project had an awful lot of difficulties too. Not only were they trying to do something never done before, but they also had a clear and public deadline – the end of the decade. It took determination, hard work, acts of genius and even a bit of luck to get there. And, of course, good project management!

The other thing the project had going for it, though, was a healthy attitude to risk. The project was trying to do something incredible, and the people involved, most especially the astronauts, accepted that there was a genuine risk they could lose their lives. But they believed that the risk was low enough, and the prize was great enough, that it was a risk worth taking.

As we look back at the achievements of the Apollo programme, it’s also worth looking forward, to see where we want to get to now, and how we want to do it. There is talk of establishing a permanent base on the moon. This presents all sorts of engineering challenges, and is an interesting proposition.

But to me, the real excitement comes at the thought of sending a man to another planet, of getting completely out of our little Earth-Moon gravity well. Putting humans on Mars would be a herculean task, a task to truly challenge the science and technology of our era. The biggest challenge, though, seems to be cultivating a mindset that accepts the ultimate risk, that helps all of us again believe that some things are worth risking everything for.

I hope you’ll forgive my self-indulgence in writing this post, but sending humans to another planet is important to me. Yes, for the scientific knowledge we would gain. Yes, for the chance of spreading humanity that little bit wider in this universe. But most of all, for the adventure, because I believe seeking out this kind of adventure is part of what it means to be human. Here’s hoping it’s not another 40 years before we make another giant leap for mankind.

(Image courtesy of dcysurfer. Some rights reserved.)

In this video, the lead author of the 2009 refresh of PRINCE2, Andy Murray, talks us through the new Directing guide for PRINCE2. This guide is aimed at project board / Executive level project members.

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.

Tom Wujec talks about how we understand ideas. He discusses the different ways our brain interprets what we see around us, and how this builds up into a mental map of what is happening.

This is a good video, but what I found particularly interesting was the look at how Autodesk work to create strategic plans. They make sure they get everyone involved, on their feet, and putting information up on the wall. This is a great way of enabling everyone to see how they fit into the big picture, and to understand the way it all hangs together.

This is similar to the technique I use when building up a project plan and schedule. Get the team involved, use their expertise, and put the information up on the wall, so everyone can see. I wrote about it a little in What happens now? – Scheduling a project.

Enjoy the video!

(From TED.)

If you look at pretty much any contract job board online, you’ll see an awful lot of the project management roles call for someone with the ability to ‘handle senior stakeholders’.  I think this is a pretty revealing request in a job advert.

For a start, while I don’t deny this should be part of any project manager’s job, the main work of handling senior stakeholders should be done by the Executive.  This is, after all, part of why they are in position – not only to give authorisation for the project to go ahead, but to gain support from senior stakeholders.

When I see a job advert asking for someone who can ‘handle’ senior stakeholders, it makes me think that the organisation as a whole probably doesn’t really embrace project management.  The Executive probably doesn’t understand, or doesn’t carry out, the responsibilities their role brings.  Project managers are probably engaged in a perpetual struggle to get support for their projects.

Unfortunately, this type of organisation isn’t unusual.  The situation described above is one I have often gone into as a contract project manager.  Part of me even kind of enjoys it – even though it certainly makes life more difficult.  But it does give an opportunity to transfer some project management knowledge to the organisation as a whole, and hopefully leave them in a stronger position for the next project!

What about you?  Have you come across this problem?

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.