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.

Thanks for coming back to Project Management Guide. If you haven't already, you may want to subscribe via the RSS feed, or if you prefer, via email. Thanks for visiting again!

Technorati Tags: project management, project management guide, project management tips

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.

Technorati Tags: project management, project management guide, project management tips

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.

Technorati Tags: project management, project management guide

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.

Technorati Tags: project management, project management guide

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 communicationg 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.

Technorati Tags: project management, project management guide

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.

Technorati Tags: project management, project management guide

Project management isn’t just about project managers. We are just part of a team that works on the project. Our job is to help the rest of the team to be successful at their job. So what are some of the signs of a project team that successfully works together?

I’ve come up with ten different characteristics of a team which I think will be successful:

1. Pride in their work - no project is perfect, but that’s no reason not to try. The team is committed to producing the best output they can, and are willing to put the case for the right decisions to get there.
2. Members support each other - they really are a team, not a group of individuals. Team members trust in the skills of the other members, and support them in tough situations.
3. Understanding - the team knows what they are doing, and why.
4. Competent and confident - the team members are all able to do their work, and confident in their abilities.
5. Communicate openly - the team understands that project management thrives on good communication.
6. Accepts final decisions - the team understands that the people making decisions for the project are doing so in good faith, and while they may make a decision the team disagrees with, they have a good reason for doing so.
7. Solve the problems they can, and deal with the ones they can’t - the team understands that problems will occur, no matter what. There is no point in complaining about them, all the team can do is handle them.
8. Clear direction - the team knows where the project has come from, where it is now, and where it is going.
9. Embrace project management - the team understands that project management is about helping them achieve success, not blocking it!
10. Loyalty - members are loyal to the project, to the business, to the team, and to themselves.

What do you think? What have I missed? Which of these aren’t important? Let me know!

Technorati Tags: project management, project management blog, project management guide

I’ve been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

So far, I’ve suggested that:

• The primary aim of every project is to benefit the business.
• Project management is about making the project environment as stable as possible. What is possible varies.
• Project management needs both awareness and control of the project. Control is impossible without awareness.
• The project manager can control time taken, money spent, and scope fulfilled - but only within set limits.
• The project team is a project’s most important resource. Guard them well, to allow them to get one with their tasks.
• The project manager doesn’t do the project work. The project manager does the project managing.
• Only work a project team member is doing on something assigned by the project manager is project work.

Today I want to look at the knowledge that all project managers need about the work on their project. The project management concept I will be looking at today is: Project managers need to know what has been done, what is being done, and what needs to be done.

We need to have knowledge of what has already been done. It is important for us to know the path we took to get to where we are now, to understand the decisions we took, to remember the obstacles we had to overcome. In this way, we can learn from our project experience, and make our future path smoother.

We’ve already seen that we need a good awareness of what is happening in the project at present. This awareness, this knowledge of what is happening right now is means we become aware of problems as soon as possible, to make sure we can solve them as quickly as possible.

We also need to have knowledge of where we plan to go next. It is important for us to have a clear idea of where we are going, to understand the challenges that we will face, to accept that unforeseen problems will arise, and to plan to deal with surprises. To make sure these unexpected events don’t derail the project, we have to have an understanding of our final objective.

By having knowledge of these three areas - the past, present, and future - we can improve our project management. We can do this by drawing on our experiences from the past to help us overcome obstacles we face in the present, and plot a course around foreseeable problems in the future.

And that leads us to today’s project management concept: Project managers need to know what has been done, what is being done, and what needs to be done.

(Image courtesy of Jacob Bøtter. Some rights reserved.)

Technorati Tags: project management, project management guide

Communication is vital in project management. In fact, I’d say good communication skills are one of the most important qualities a project manager can possess. But is a project manager getting involved in the internal communication of the project team actually providing value?

As a quick thought experiment, let’s imagine a team of five members. In a self-organising team, it may be that each member has a discussion with every other member to let them know where they are up to, what they are working on, etc. This communication, in one direction (i.e. person A telling person B their situation) takes an amount of time I’ll call t.

Now, the communication cannot be one way - person B also needs to tell person A what they are up to. So they also take time t to pass that information on. So the total time for the update conversation is 2t. But the total work time is 4t - i.e. 2t for each participant.

I have shown this situation in the 5 person team in the diagram. In this situation, each person talks to every other person. There are 10 conversations, each taking a time of 2t. This means, with two people in each conversation, the total work time used is 40t.

Now let’s look at the situation when we add a project manager. In this case, I have assumed each team member tells the project manager where they are up to. The project manager then evaluates the information, and feeds back to every team member. The two way conversation thus still exists, though the two ways may happen at different times. In this model, there are 5 conversations, each of which take time 2t, giving a total time of 10t, or a total work time of 20t.

In other words, adding a project manager reduces the time the team spends in sharing information by half - in this particular case.

Of course, there are other possibilities. It may be the self-organising team shares information through a meeting, rather than separate conversations. This would dramatically reduce the total time. In this model, person A tells all the other members of the team what they are doing at the same time. Then person B does so, and so on.

This reduces the total time taken to just 5t, but the total work time is only reduced to 25t - it only takes person A time t to update the other 4, but each of the 5 has to be there, a total of 5t work time. This is repeated for the other 4 people.

In a team with a manager the total work time would be higher - purely because the project manager has to sit in the meeting too. If, however, the project manager receives updates from the team members individually (for a total work time of 10t) and then feeds back to the entire team (for a total work time of 6t) then we have a total work time of 16t - again less than in the self-organising team.

We can easily expand this up to teams with 10 members. In this case, team members holding individual conversations gives us a total work time used in communication of 180t, a team holding a meeting gives a total work time of 100t, while a team using a manager and meetings takes a total work time of 31t!

At this point it all looks cut and dried - self-organising teams, even if they use meetings, spend far more time in communication than a managed team.

Of course, that’s only true when you have been as grossly unfair with the figures as I have. (Using pseudo-scientific methods and information to draw unfounded conclusions is fun!)

The most obvious way I have been unfair is assuming the project manager can condense down everything all the team members need to know massively. In the model where the manager has a conversation with each team member, I have decided the information which the other team members took 4t to pass to him can somehow be condensed down to only take t for him to pass on! This seems rather unlikely…

So no, I’m not saying these figures are going to be accurate. But they do illustrate some important ideas.

1. Time taken to communicate amongst a team rises dramatically with team size.
2. The most effective way to reduce this is to hold meetings, so team members don’t have to repeat themselves with each other member.
3. Project managers can aid communication if they act as a central collation point.
4. But the best improvement in communication comes if the project manager condenses or filters the information.

In other words, you need to be more than good at talking. A project manager needs to understand the project well enough to know who needs to know which pieces of information, and just as importantly, which pieces of information are of no use to other members. You need to act as a filter, to make sure you’re not wasting the time of your team members.

Communication isn’t about how much you say to everyone, it’s about saying the right things to the right people.

Technorati Tags: project management, project management guide

I’ve been giving some thought recently as to what lies behind the work we do as project managers. Too often we get caught up in the tools and techniques, the how of what we do, without looking at the concepts and ideas behind it, the why of what we do.

So far, I’ve suggested that:

• The primary aim of every project is to benefit the business.
• Project management is about making the project environment as stable as possible. What is possible varies.
• Project management needs both awareness and control of the project. Control is impossible without awareness.
• The project manager can control time taken, money spent, and scope fulfilled - but only within set limits.
• The project team is a project’s most important resource. Guard them well, to allow them to get one with their tasks.
• The project manager doesn’t do the project work. The project manager does the project managing.

Today, I want to look at one of the fundamental ways we maintain control on a project. As we’ve already seen, control is impossible without awareness. So we’ll also look at one of the ways we gain awareness in the project. The concept I am looking at today is: Only work a project team member is doing on something assigned by the project manager is project work.

We know we need both awareness and control. One of the clearest and simplest way of gaining awareness is for the project manager to assign all work that takes place on the project. Indeed, this is one of the purposes of the project manager role - to allocate the work sensibly, without doing it himself.

But by assigning work, the project manager is also taking control. By doing this, he or she is demonstrating to the project team that only work assigned like this is work on the project. Thus, assigning work gives a project manager both awareness and control.

And that gives us our project management concept: Only work a project team member is doing on something assigned by the project manager is project work.

Technorati Tags: project management, project management guide