This week on our Project Management Guide, we’re going to take a look at risks.

Every project will face risks. Risks are those things which could go wrong, or change, and adversely effect the project. The idea of handling risk in a project is not to avoid all risk. Any project will face some risk – projects are about bringing about change, and any change will bring some risk. The aim of risk management in a project is to make sure we reduce the risk to an acceptable level in a cost-effective way.

This means that we need to accept we will face risks, and to examine them with an open mind. It also means we need to track those risks, and think about how we would handle them if they occur.

The first step in managing risk is identifying them. We’ve already seen in Project Plans – The Art of Prophecy that risk analysis needs to be part of the project plan. But how do we go about it?

A system that I use is as follows:

1. Identify the risks: Preferably as part of a group, start to write down as many possible risks as you can think of. At this point, don’t try and think about how likely a particular risk is, just try and capture as many as you can. Include risks from a wide variety of areas, from technical nitty gritty details, all the way up to the environmental risks, such as natural disasters! Also include business risks, financial risks, etc.
2. Evaluate the risks: You should now have a nice list of risks. Now we need to evaluate the risks in terms of their probability and impact. Probability is the likelihood of a risk occurring – so, for example, a natural disaster is astonishingly unlikely to happen, while a computer failure is much more likely. (Knowing my luck, the Redoubt volcano in Alaska will blow just as I post this…) Impact is how much of an effect the risk would have – natural disasters next door, quite a lot. Computer failure, not so much.
3. Plan a response: You will now have a set of risks, with probabilities and impacts. You can now start to decide what to do about them. Your options are likely to include avoidance (doing things differently so the risk doesn’t occur), mitigation (take some action so the probability, impact, or both, of the risk are reduced), acceptance (just live with it) and contingency (a prepared plan of what to do if the risk occurs to deal with it quickly).

We don’t just stop there – this is just the first run through. You should record these risks in a risk log (or risk register, etc.) and make sure you monitor them throughout the project – and add new ones as necessary. We’ll look at this in more detail later.

Two tips:

• When it comes to evaluation of the risks, usually simpler is best. Grade the impact as High, Medium, or Low, and do the same for the probability. If you assign High a value of 3, Medium a value of 2, and Low a value of 1, you can simply multiply the probability and impact together to get a quick and dirty numerical grading for your risks.
• The grading of risks should have some bearing on how much you are willing to spend to deal with them. Obviously risks that have a high probability and a high impact should be looked at first!

Hope you’ve enjoyed this quick guide to getting started with risks. Do you have any tips? How do you start identifying risks? Let me know!

Project management does not exist in a vacuum. We have embraced the various new methods of communication to encourage better collaboration and team-work. It is now practically inconceivable for a project not to be using email, tele-conferences, even video-conferencing to maintain contact with the participants.

But are we embracing the new technologies available now? Are we making best use of the tools we now have? With project teams becoming even more spread out over the globe, are we making best use of our new communication methods?

This series will look at the various new social media tools available to us, and how we can start to use them in our projects. Some of you will already be using some of these tools. I’d love to hear your stories about how they have worked for you – many of the uses are only now developing, so I’d love to hear your best practices!

This week I’m going to take a look at Twitter. Twitter is a relatively new social networking and ‘micro-blogging’ service, based on the exchange of 140 character messages.

That perfectly explains what Twitter is, while also completely missing the point. Twitter is about keeping in touch with people, in a simple way. You can update people with a light touch, on a frequent basis. These are the kind of small interactions that help to build a community, or a team.

In Twitter, you choose who you want to hear from by selecting who you would like to ‘follow’. In turn, others can choose to follow you. If you want to, you can also make your account protected – this means only the people you allow to can see what you say.

Obviously this has possible applications for a project manager. Twitter enables you to keep your team members updated on a regular basis. For example, you could ‘tweet’ whenever there is an update of the blog you set up for the project. If the account you are using is protected, you can also tweet about the project status, questions you may have, and answers too.

Because Twitter isn’t one way, you can also follow your team members. This enables you to build a network within your team, with short and frequent contacts – especially useful if the team is scattered around the country or even the world.

The best way to learn about Twitter is to actually start using it. To get you started after you have created your account, you can start following a few useful project management people. Try Project Shrink, PM Tips and PM Opinions to get you started. You might also like to try following Josh Nankivel and, of course, Cornelius Fichtner, who is responsible for the great PM Prepcast.

Oh, and you can follow me too! Just click on the follow button after you have logged in.

Once you see how you can use Twitter, you’ll begin to see all sorts of ways it can be useful in your business. I’ll see you there! Next week, we’ll be looking at another social media tool, one which helps bring together all the other tools out there.

What about you? Are you already using Twitter? Who do you find most useful to follow? Or do you think it’s just a waste of time? Let me know!

Part of The Social Media Project Manager Series.

And maybe they’re right.

Project managers have a bad name. Let’s face it, we’ve all come across people and whole companies that think project managers just cause problems. In their eyes, we insist on the production of arcane documents, we get in their way while they are trying to just get on and do the work, and we hold far too many meetings. And don’t get them started on the metrics. Or the milestones. Or the project plans. Or the requests for progress reports.

Now, you and I know that project managers actually add value. We help to keep the project moving forward. We help to keep the team focused. We help to spot problems early, and deal with them. We help to bring it all together.

But… sometimes, those people who complain about us? Sometimes, they have a point.

When team members are complaining about project managers, one of the main reasons behind it could be our fault.

If project team members are complaining about project management getting in the way, it means they aren’t seeing value from it. And that usually means one of two things: either a methodology is being applied blindly, or the project manager isn’t explaining what the value is.

Luckily, the way to solve either of these problems is simple: take the time to talk to your team. And I mean really talk, and really listen, not hold yet more meetings. If there is someone who is complaining a lot, sit down with them, and have them explain why they aren’t happy. Sometimes, you’ll find that they hadn’t realised the benefits to the rest of the project of what you are doing – or asking them to do.

Sometimes, though, you’ll find they have a valid point. Perhaps you have been insisting on a particular piece of information being gathered, or a particular measurement being made, because it worked on the last project similar to this. But maybe it isn’t appropriate here. Don’t be afraid to learn from your team members that you are being too heavy handed in applying a particular methodology.

Remember, no methodology is ever going to be a perfect fit for your project. You need to flex it, lighten it up here and there, toughen it up in other places. You need to borrow some pieces from one system, and other pieces from another, to fit them together to make the right way for managing your project, right now.

So the next time you hear someone complaining about project management, take the time to talk, and to listen. You never know, they might be right.

What about you? Have you come across people who just didn’t get project management? How did you handle it? Let me know!

In previous posts in the Project Management Guide, I have alluded to the project management structure, the organisation that you as project manager will sit in. In keeping with the aim of teaching project management to absolute beginners, I’m now going to flesh out this idea a bit.

First of all, why do we need a project organisation? As we’ve already learned, a project is a temporary endeavour. A project also tends to be cross-functional, meaning people from across your business will be needed. That means people will be brought together for a relatively short period of time to work on the project, and their line management structure is unlikely to fit with what is needed for project management structure.

Because of this, we set up a project organisation. This organisation can be logically broken down into different levels:

1. Overall corporate (or programme) management
2. Project Executive with information from Project Board / Guidance Group
3. Project Manager
4. Team Manager
5. Team

Now, this seems like an awful lot, but don’t worry – they won’t all be involved day-to-day!

Let’s have a look at each of these levels.

1. Overall Corporate (or programme) management

This level represents the people at the very top. These are the people who have the final say over whether a project starts, stops, or varies. However, they are likely to be involved very rarely – they have responsibility for appointing a Project Executive to kick the project off, and to be available to guide the Executive should he need it.

2. Project Executive with information from Project Board / Guidance Group

The Project Executive is the person with overall responsibility for the project. You, as the project manager, will report to the Executive – he is your boss. It is the Executive’s responsibility to represent the business interests in the project. This means, for example, he or she will need to ensure the Business Case is kept up to date, that the project is still meeting a business need, and so on.

The Executive also monitors the progress of the project through two routes, the information you provide as project manager, and through the project assurance route. More on that later.

In addition, it is also useful to have the interests of the user (of the final product of the project) and the supplier (who is making that product) represented at this level. This can be done through the formation of a project board, with a User Representative and a Supplier Representative on it. However, this doesn’t make the board a democracy – it is still ultimately the Executive’s responsibility to guide the project to success.

3. Project Manager

That’s you! You have responsibility for the day-to-day management of the project. The Project Executive and other members of the board are likely to be doing their project roles in addition to their normal jobs. Because of this, you need to enable them to manage by exception.

What this means is that you should seek their approval at the beginning of each chunk of work (which should last a reasonable length of time). You will also set tolerances, as discussed in Project Plans – The Art of Prophecy. When that is done, you keep the Executive updated regularly, but only go back to him or her for a decision when either you have finished the chunk of work that was approved, and need to have the next section approved, or because something has gone wrong, and you have gone over one of your tolerances.

Obviously there is far more to the role of Project Manager, but this explains how it fits into the project organisation.

4. Team Manager

This role is the management of the team carrying out the project work. It is an optional role – the project may be of a size that the Project Manager also does this work. However, for various reasons, such as the complexity of the work, the technical knowledge needed, or even because the team is in a different company to the project manager (think of a client – supplier relationship), you may want to have this as a separate role.

The team manager agrees with the project manager the scope of the work the team is to carry out. This is generally done through the agreement of a package of work. The team manager then reports on progress to the project manager.

5. Team

These are the people that actually do the work! They are responsible for building the end product to the required quality, on time, and on budget.

One last role

That’s the broad overview of the management structure, but there is another function that I also want to talk about. This role can be called Quality Control, Project Assurance, Project Monitoring, etc. While it has many names, the main purpose is to ensure that the project is on track, and that the information that the Executive is getting is the truth, the whole truth, and nothing but the truth.

This role needs to provide an independent check on the information the project manager is providing. In addition, it can also provide information and guidance to the project manager, if there is something that he or she has missed.

Because the role needs to be independent, the project manager shouldn’t have anything to do with appointing or managing them. Ideally, the Executive, and User and Supplier Representatives if present, should each choose someone to perform this role for them. The Executive’s choice should focus on ensuring the project’s work and outputs are meeting the needs of the business, the User’s the needs of the users, and the Supplier’s the needs of the suppliers. This provides more information for the Executive / board and the project manager.

That’s a quick whistle-stop tour of a sample project management structure / organisation that I have used in the past. The structure can be formal and rigid, or informal and relaxed. Of course, every project and every business is different, and has different needs and drivers, so don’t be surprised to find very different management structures out there!

What about you? What type of project management structures have you worked in in the past? Do you prefer a formal structure where everyone knows what is expected of them, or a more relaxed structure where everyone can jump in where they think they can help? Let me know!

29th Jan: Edited to make role of Project Board / Guidance Group clearer

Project management does not exist in a vacuum. We have embraced the various new methods of communication to encourage better collaboration and team-work. It is now practically inconceivable for a project not to be using email, tele-conferences, even video-conferencing to maintain contact with the participants.

But are we embracing the new technologies available now? Are we making best use of the tools we now have? With project teams becoming even more spread out over the globe, are we making best use of our new communication methods?

This series will look at the various new social media tools available to us, and how we can start to use them in our projects. Some of you will already be using some of these tools. I’d love to hear your stories about how they have worked for you – many of the uses are only now developing, so I’d love to hear your best practices!

I’m going to start with something you should all be familiar with, but may not have used in a project context – blogs.

Now, I’m assuming if you are reading this you know what a blog is, because, well, you’re reading one. They are a great tool for getting a message out, but also, thanks to allowing comments, a great way of gathering information too.

A project blog is useful because whoever in the team you allow to post (and I would encourage you allow everyone in the team to do so) can put up some information, and ask for feedback. No matter where in the world the members of your team are, they can read the article, and post their comments.

And don’t worry, this doesn’t mean you have to put your dirty washing out for the whole world to see! A blog could be internal to an organisation, or it could even be restricted to just project team members. If your team is across multiple organisations, you could have it password protected on an external server so only those you allow can see it. (This is even possible using major blogging platforms, like Blogger and WordPress, which allow you to set your own privacy settings.)

You can also use the blog to get your message out. Project status reports, risk logs, all the documents you use to manage the project, can be updated and placed onto the blog. This ensures everyone has access to the information they need and want, when they want.

Don’t take this as a replacement of other communication methods, though – if there is vital information that team members must have and read, then use the most appropriate tool, be that email, tele-conference, or even face to face meetings. But to make your job, and the jobs of your team members, easier and better, use the blog as an additional tool, not a replacement.

You can go a lot further than just a simple blog, of course, with other collaboration technologies. But I’ll come to these in a later post.

This is just one example of how a blog can be used. What about you and your teams? How have you been using blogs? What value do you get out of them? What do you recommend as best practice? Let me know!

Part of The Social Media Project Manager Series.

As a project manager, you are likely to have to attend and run a lot of meetings. Indeed, some people see project management as basically making Gantt charts and holding meetings. But are we running meetings well?

I have a confession to make. I hate meetings. Always have. I started my working life in an organisation that seemed to love holding as many meetings as possible. The building we were based in kept converting rooms into more and more meeting spaces, and they were still always booked up. We always had weekly update meetings. This was the kind of meeting that infuriated me the most. A group of people whose only connection was their manager would sit and say what they had done for the last week. The work was often compartmentalised and unconnected to others, yet we all had to sit through this meeting every week. The mind-numbing boredom of these meetings has given me an extreme antipathy to all meetings ever since.

Unfortunately for me and my irrational prejudice, there is no denying that sometimes, just sometimes, meetings are needed and useful. So, as a project manager, how do I get through a project with as few and as useful meetings as possible?

1. Identify which meetings are needed. The quickest meeting is one that doesn’t happen. Look at the meetings you are holding, and decide which of them are really needed. For example, take a look at one of those perennial favourites, the project update meeting. Your project team dutifully troops into a meeting room, and you go around each of them individually, asking them to give an update on where they are up to. The only people getting value from this meeting are the manager and, while he or she is speaking, the person doing the update. The rest of the participants just sit around being bored until it is their turn to speak. Get rid of it, and find another way.
2. Find better ways of getting information. In the project update example above, attendees were sitting around bored for the majority of the time. You still need the information they gave, so schedule one-to-one meetings (what I like to call ‘a conversation’) with them to get this information. But make sure you are giving value back – give feedback, take on board any obstacles they are facing, and help them with any issues they have.
3. Identify who needs to attend. Meetings need to add value for you and for participants. Otherwise you are just a burden on their time, a drain on their resources. If an attendee isn’t adding and getting benefit from a meeting, they don’t need to be there. Free up their time and yours by letting them escape meeting hell.
4. Use better ways of giving information. If your team needs to have certain information, then get it out to them. But use an email, not a meeting. Take the information from the one-to-one’s above, and put it into a weekly update brief to send to people. Then they can see the parts that are relevant to them, and skip those that aren’t.
5. Have an agenda. If a meeting needs to take place, and you have whittled it down only to the people who need to attend, it is time to make sure the meeting is focussed on what it needs to achieve. Make sure you have an agenda in place, and circulated to all participants, at least 24 hours before the meeting start time. And it’s no good having an agenda if you don’t stick to it. Sure, major issues could arise before the meeting, but anyone who vitally needs to discuss that now can speak to you before the meeting starts. Don’t let rambling diversions occur in the meeting itself.
6. Achieve something. Decide what you need answers to, and get them. Decide what actions need to be taken, and assign them.
7. Be a facilitator, not an attendee. You’ve called this meeting, so you have a responsibility to make sure it goes well, smoothly, and quickly. Stick to the agenda, move the discussion along, agree the action points. Don’t allow the meeting to become a talking shop. This means being firm. Your meeting has a start time – stick to it, regardless of who hasn’t turned up yet. Your meeting also has an end time – stick to it, moving the meeting along smartly to make sure you achieve it.
8. Prepare. We’ve already seen you need to have an agenda. What else do you need to have the meeting go smoothly? A meeting room? Book it. A projector? Make sure it is there. A note taker? Bring someone along to do this. There is no excuse for slowing a meeting down because of your poor preparation.
9. Be brief. In my experience, a meeting should not go on for more than an hour. People stop concentrating, they stop engaging, you cease to get any value out of them, and they cease to get any value out of the meeting. If you think you have a meeting that will go on longer than this, see if you can split it up – and see if you can do it with fewer people in each meeting. If you really can’t split it up, then at least have a break in the middle.
10. Think of the money. Look around the people in your meeting. Have a rough guess at how much they are paid, and what that works out to per hour. Include your own hourly rate. Now calculate how much all of those people spending in a one hour meeting actually costs the business. Have you added that much value to the business in the meeting?

And as an extra bonus tip:

• Avoid meetings that don’t add value to you. I once worked on a project that wanted me to travel for 3 hours every week to attend a 3 hour meeting with the programme manager and the rest of the project managers, and then spend 3 hours travelling back. This was 9 hours of my life that gave me no value. The value I added to the meeting could have been done much more easily via the report I sent in every week. Eventually, I was able to move to attending by teleconference, and ultimately to attending only every fortnight – not ideal, but at least I had reduced the amount of my time spent on this time-sink from 36 hours a month to 6.

These are the tips I try to follow in a project, to reduce the amount of time, both mine and everyone else’s, spent in meetings.  What about you?  Do you have any other tips to share?  Or do you think I need to get over my aversion to meetings?

There are a number of qualities a good project manager needs.  A lot of these are so-called ‘soft skills’.  Let’s have a look at some of them.

• Be organised.  A large part of project management is keeping track of the project, and making sure the right things happen at the right time.  Naturally, being organised is a great help in making sure that this happens.
• Be a two way communicator.  You will be overseeing a disparate team, who all need to clearly understand their goals and responsibilities, to be given information about their performance, and the performance of the project, and to understand the expectations of the project and its customers.  But part of being a good communicator is also taking information in – it is important you can bring in feedback, and handle it correctly.
• Be a team builder.  Project teams are often temporary creations, and melding people who may or may not know each other into an effective unit can be vital to the success of the project.  You must be able to bring people together.
• Show integrity.  Your actions must demonstrate a commitment to the project, to the team, and to behaving ethically.  Showing and using these values will help bring everyone together.
• Show empathy.  You will often be working with a team you have no line management responsibilities over.  You will need to bring them together into a team, and one of the most important ways to do this is through showing you understand the needs of the team members.  This doesn’t mean you should be a pushover if someone tells you they aren’t going to finish a task assigned to them, but you do need to understand their position, and perhaps see if you are indeed asking too much.  Put yourself in their shoes.
• Be calm.  A project manager should strive to be calm at all times, even when the pressure is really starting to build.  Having confidence in your team and yourself to cope with problems, a self-assurance that can be seen, gives a boost to the whole team, and helps build their confidence also.  There will always be problems that face a project, there will always be stressful situations.  Having the right attitude to tackle them will help immensely.
• Delegate.  You simply cannot do everything yourself!  Often you will be brought in to work on a project which, for the actual nuts and bolts work, requires considerable technical knowledge you may not possess.  Equally, there are a number of tasks in project management which should be delegated to project support personnel, or to a project office.  You must be able to demonstrate your trust in other people by allowing them to get on with the work they are best suited for, allowing you to work on the tasks that really need you.
• Be a creative problem solver.  Project management is about solving problems.  Part of it is about making sure the right things happen at the right time.  There will often be barriers stopping this!  You must be able to look at issues and see the way around them, often needing to find novel approaches to do this.  Believe it or not, creativity is an important quality in project management!

What about you?  What other qualities do you think are needed?  Post below!

Today on Project Management Guide we are looking at project scheduling, a vital part of the project planning process.  I am going to try and focus especially on how to get this kicked off with a meeting, bringing in other people from your project team.

As we saw in the previous section of the guide, Project Planning – The Art of Prophecy, scheduling is just one of the many parts of a project plan.  To pull our schedule together, we need to draw on some of the other sections.  Remember, though, that scheduling is just one part of the plan, so it will feed back information into the plan, as well as drawing from it, until you have a completed plan.

At the start of a project, I find it most useful to use something called top-down scheduling.  In essence, what you are doing is organising the project into discrete chunks, each of which ends with a milestone.  Then, drawing on the knowledge and expertise of your project team, work to identify what tasks have to go into each of these sections to achieve the milestone.  You can then estimate how long the sections will take.

Another option is to use bottom up scheduling.  This basically takes the reverse approach!  You and your team identify what tasks need to be done, and identify milestones from the tasks.  This can be particularly useful in some software projects.

These two broad techniques are very useful.  What I find to be most useful in them is the way it brings other team members into the process, enabling them to buy-in to the final schedule.  One of the best ways to do this is run the scheduling meeting in the right way.

For example, I have often used pads of sticky notes to get everyone involved.  I hold a meeting with appropriate members of the team, and make sure all of them have a pad.  Once we have agreed the major milestones, I encourage them to start writing tasks down on their pads, and sticking each task on the wall, under the appropriate section of the project.  This helps to start discussion between the team members, and can also help them to see the dependencies across different project streams.

By the end of the meeting, you should have a good idea of the schedule, and can then start to put it together – with an eye on the resources for each task.

I hope you have found this section of the Project Management Guide useful.  What other techniques do you use in planning and scheduling?  What has been most useful to you?  Comment below!

In our last Project Management Guide (Planning the Planning – 2) we looked at all the areas of the project we will need to cover in our project planning. Now it is time to get on with it.

Firstly, I need to make sure we are all on the same page when it comes to what a plan is. Many people (and a distressing number of project managers, too) think only of a Gantt chart when they think of a project plan. You may recognise it as what you get from Microsoft Project. This is better called a project schedule, in that it shows when we expect the various sections of the project to happen. We’ll come back to this later.

What we want to have in our project plan is:

• Aim of project
• Outputs
• Quality criteria
• Resources
• Management structure
• Milestones
• Tolerances
• Dependencies
• Risks
• Schedule

Let’s have a look at these in turn, and see why they are needed, and what we want to achieve with each of them.

Aim of project

What do we want to produce? You’ll recall that we have looked at the reasons for doing the project, and the benefits expected, in Building the Case. (Take a look at the Business Case template (PDF) to refresh your memory.) The aim of the project is a mixture of these. This section of the plan can be either fulfilled by linking to the main Business Case, or by restating it in language for the expected audience. For example, your business case may have been written for high level approval in your organisation. You may want to now put it in terms the project executive expects.

Outputs

Given the aim of the project, what do we actually need to produce to get there? What will your completed project be made up of? These need to be clearly defined. For example, your project’s aim may be to upgrade the IT infrastructure in an organisation. Your final output would be a completed computer network, a new computer on every desk, and all appropriate software installed and ready to go.

Quality criteria

Now we have the outputs, we need to understand what quality they need to be of. In the example above, we have an output of a completed computer network. However, we need to know that the network can actually cope with the amount of traffic going over it!

This means we need the completed output to be of a certain quality, and we need to define what that quality is. These targets tell you what success is, what completion of the project is. They need to be SMART:

• Specific – Clearly defined and precise
• Measurable – e.g. not “new computers”, but “computers with 2Gb of memory”, etc.
• Attainable – Don’t ask for the impossible
• Relevant – Is the criterion actually related to the aim of the project?
• Time-based – Enough time to achieve this. There is no point expecting a year’s worth of work in one week!

It is important you take some time with the stakeholders in your project to produce this list. The final customer of the project will naturally be very involved, but don’t forget your business head – don’t promise everything without considering the costs. Your project executive, and a representative of those who will be doing the work, will have major inputs into this also.

Finally, you will also need to decide who has the final say over the quality of the outputs. Hopefully your work on defining the quality criteria will mean there are no arguments over the quality (i.e. no qualitative judgements, only quantitative) but you need to make sure you schedule in time and people to do the evaluation work.

Resources

We have now set down what outputs we need to produce, and what quality they need to be at. This means we are now in a position to look at the resources we will need to achieve this. Resources include staff time, particular knowledge or skill sets, money (e.g. buying equipment), and time (some tasks can’t be increased by throwing more people at the problem, e.g. delivery times, setting time for concrete, etc.).

Management structure

How are we going to manage the work? You need to describe the general approach to the project here. Who will be the decision makers for the various different streams of work? For example, you may be doing a significant procurement – who makes the decision about what company to buy from?

How will we share progress on the project? Who will we share it to? For example, you may decide to have regular project team meetings – who needs to attend? What level of information will you be sharing? Who else needs to be kept informed, at what level of detail, and how often? For example, you may want to keep the project executive updated at an overview level of detail on a weekly basis, while you keep other managers appraised at a higher level of detail.

You will also need to spell out the relationship of yourself to the project executive, in terms of the monitoring of progress. Equally, you need to put down how you will be monitoring progress of the allocated tasks.

There is no one right answer for how this should be done, and indeed it will vary with every project. Make sure you think about the size and complexity of the project, and also the organisation’s ethos and current management style.

Milestones

Here you need to think about how you will break up the project. Unless it is very small, you don’t want to have the entire project as one lump of work, with the only check on progress at the very end. Instead, it makes sense to break the project up into discrete chunks, where related tasks can be lumped together, with a sensible milestone at the end of them. For example, in the technology refresh in the example above, you may want to break the project down into something like:

1. Requirements gathering
2. Tender writing
3. Tendering process
4. Contract negotiation
5. Deployment
6. Testing

It makes sense to have a defined milestone, so you know when each section is completed. There is also another benefit of breaking the project into chunks, which I’ll come back to.

Tolerances

You will have already looked at the resources you need. Now we need to set how far you, or the project executive, can let the project stray from these targets before needing to sound the alarm. For example, you could set a tolerance in terms of finance of +/- 5%, and a tolerance in terms of time of +/- 10%. Equally, you may want to look at tolerances of quality – i.e. how far from the quality criteria are you willing to accept?

It is remarkably unlikely that a project will not deviate from its resource or quality targets. Setting tolerances allows you to be able to manage the project without continually seeking guidance from the project executive as to whether you should carry on. This is not to say that you should be happy with these deviations, and you should try to avoid them, and monitor them closely. That way you can build your understanding of the project for the future.

Dependencies

This is where you look at what needs to happen before something else. For example, in our example above, you need to complete the requirements gathering before you can finish the tender documentation. You need to start thinking about the dependencies so you, and the project team, can understand the impact of changes in any part of the project.

These dependencies should include both those internal to the project (i.e. those under your control), and those external to it (i.e. those outside of your control). For example, you may need an accurate figure for the number of staff in the organisation. This needs to come from your HR department, and would be an external dependency.

Risks

Simply, what could go wrong? What could happen that would damage your ability to deliver the project? Are there things you can do to avoid them, or minimise them?

Scheduling

This is the Gantt chart-style information that many people envisage when a project plan is mentioned. In this, you need to put down what you expect to happen when. It will include your dependencies, milestones, and probably resources. At this point, it will be a relatively high overview of the whole project.

There is something you need to understand about this schedule, and that is this: it will be wrong.

I know that seems a strong statement, but it is vital that you understand that you cannot make a perfect schedule. You really would be getting into the realm of prophecy if you think you can sit down now, and accurately and precisely pinpoint the date the project will end. No, what you need to do here is achieve the possible.

The schedule needs to include the overview, with the project broken down into sensible chunks. This is the other advantage of breaking the project into chunks we mentioned above. By having the project broken up in this way, you will be able to start planning the first section in quite some detail, extending out for a few weeks. But from then on, it will start to be based more and more on blind guesswork and faith. Don’t try to be artificially precise – keep it vague, use rough figures.

As you come to the end of each chunk of the project, you will be able to plan the next one. You can use the information and experience you have just gained from the previous section, and thus you will be able to be more confident.

Make sure you explain this to your project stakeholders! Often your project executive may look at a schedule, and imagine everything is laid out and known. You must get this idea out of their head straight away! Explain that the early part is firmer than the rest, and make sure they expect changes as the project moves on.

Your boss will crave certainty, and absolute dates for the project, from the very beginning. You must resist the pressure to name a specific date, and explain why. While there may be a temptation to give an answer (no doubt of a date plucked, essentially, from the air) you need to instead be realistic about what is and isn’t possible in terms of scheduling. Anything else can only lead to trouble for you, the project, and ultimately your boss further down the line.

Now we need to do all this!

Phew! That’s a lot to fit into a plan! But don’t worry, you won’t be doing this alone.

You see, you cannot know everything you need to complete the plan, and you shouldn’t expect to. I’ve mentioned bringing other people in to decide what success looks like, and it is vital that you bring people in to help with the scheduling. You will have a project team who will be doing the work, and it is probable, if not certain, that they will have a better idea than you of how to break down a chunk of work into specific tasks, and how long those tasks will take. Make use of their knowledge! This has the added benefit of bringing them into the project, and helping to start the process of turning a group of individuals into a team. In the next section of the Project Management Guide, I’ll be looking at some of the techniques and tips to carry out successful scheduling meetings.

That’s my idea of what is needed in a project plan. What have I missed? Do you include something else? Or do you manage with much less? Comment below and let me know!

Just a quick one today, with some more information on the importance of your project’s business case.  As you will recall from Building the Case, the business case should explain why you are doing the project.  This is vital moving forward, and needs to be revisited often throughout the life of the project.

PMHut has an article called Writing an Unbeatable Business Case which gives the PRINCE2 thinking behind it, which I personally find very useful.

Don’t forget you can also download my Business Case template (PDF) to get you started.