A well thought through project plan is a great tool for both planning your project work, and also for tracking your project work. It can help you to identify all the steps that need to happen to get you to the end of your project. As you work through the tasks the plan also lets you know if you are on track, or falling behind.
The plan can act as a roadmap for everyone who is working on your project, including yourself. But it can only act as a roadmap if it is available. If don’t publish your plan for others to see then you are not using the power of the plan to communicate to your team what the project is about. Think about what the plan holds: tasks, who is completing each task, how long the task should take, what is dependent on the task…A wealth of information that can make your role as a project manager much easier.
What do I mean by publish? Just making it visible. Print it out and stick it on a wall, somewhere where your team can see it and refer to it. You could email a soft copy to team members who work remotely.
Try publishing in different ways. For example you could post the schedule gantt chart view – this has the advantage of all team members seeing not only their own tasks but the tasks of others and the dependencies between them. Team members might also find it useful to get a list of all their tasks – a to do list.
If you’re running a project for yourself, with just you as a team member, you should still make sure that plan is somewhere where you can see it. Stick it on the fridge, or by the cookie jar – use it as a motivational tool for those moments when you might prefer to be doing something other than your project tasks. Put a reminder in your phone or calendar to review the plan regularly.
Reviewing the plan is the first step towards monitoring the success of your project.
Monday, December 13, 2010
Mitigate project risk
Mitigating a risk means to reduce the likelihood or impact of the risk, or to prevent the risk happening.
Working out the mitigation strategies gives you a backup plan that you can use should the risk occur. It means you are ready and don’t have to think through the problem when what you thought was a risk turns out to be a very real issue facing your project.
Let’s say your risk is that someone will call in sick, leave you short of people to run your project, and so delay your delivery. You could mitigate this risk by hiring temps to cover the absence, or maybe by making sure ahead of time that you have others who could step in, and making sure they are trained appropriately. In this example the risk could still occur, but you are more prepared and have options to reduce the impact.
If your risk was that you suspected a key supplier might not deliver vital supplies on time, you might mitigate the risk by working with another supplier. Or using two suppliers, or carrying more supplies in stock, or including penalty clauses in your contact with the vendor. In this case you are reducing the likelihood of the risk occurring.
You can see that there might be many ways of mitigating any one risk. Thinking through mitigation is an opportunity for you to think creatively.
Working out the mitigation can also mean you revise your original assessment of the risk. You might decide that the mitigation steps are sufficient to reduce the likelihood or severity of the risk so much that you are comfortable in reducing the score of the risk, and giving it less attention. Or, you might find few or no mitigation strategies, and so want to raise the score of the risk and keep it on your radar.
When you have identified your project risks you should review your project plan and determine if you want to make any changes. Do you need to add more contingency to any of your tasks? Do you need to add tasks you need to complete as part of your risk mitigation strategy? It might seem that you are making your plan more difficult to complete, but making your plan more realistic is a preferable option to ignoring risk and having it derail your project – that would be more expensive in the long run.
With your plan in place and risks identified you are close to being able to publish your plan.
Working out the mitigation strategies gives you a backup plan that you can use should the risk occur. It means you are ready and don’t have to think through the problem when what you thought was a risk turns out to be a very real issue facing your project.
Let’s say your risk is that someone will call in sick, leave you short of people to run your project, and so delay your delivery. You could mitigate this risk by hiring temps to cover the absence, or maybe by making sure ahead of time that you have others who could step in, and making sure they are trained appropriately. In this example the risk could still occur, but you are more prepared and have options to reduce the impact.
If your risk was that you suspected a key supplier might not deliver vital supplies on time, you might mitigate the risk by working with another supplier. Or using two suppliers, or carrying more supplies in stock, or including penalty clauses in your contact with the vendor. In this case you are reducing the likelihood of the risk occurring.
You can see that there might be many ways of mitigating any one risk. Thinking through mitigation is an opportunity for you to think creatively.
Working out the mitigation can also mean you revise your original assessment of the risk. You might decide that the mitigation steps are sufficient to reduce the likelihood or severity of the risk so much that you are comfortable in reducing the score of the risk, and giving it less attention. Or, you might find few or no mitigation strategies, and so want to raise the score of the risk and keep it on your radar.
When you have identified your project risks you should review your project plan and determine if you want to make any changes. Do you need to add more contingency to any of your tasks? Do you need to add tasks you need to complete as part of your risk mitigation strategy? It might seem that you are making your plan more difficult to complete, but making your plan more realistic is a preferable option to ignoring risk and having it derail your project – that would be more expensive in the long run.
With your plan in place and risks identified you are close to being able to publish your plan.
Saturday, December 4, 2010
Project Risk
With a draft plan in place you’re ready to start work – or are you? That draft plan is assuming that things will go to plan, and does not, for example, allow for
- tasks taking longer than anticipated
- new, necessary tasks being discovered,
- problems being encountered which need to be resolved
- supplies not being available on time
- or anything else that might go wrong.
Identifying risks allows you to think about ways to prevent those risks from happening, or reducing the impact of those risks. In other words, mitigating the risk, which means to reduce the likelihood or severity of the risk.
What does that mean? Let’s think about the first dimension of risk: likelihood. It might be feasible that your new manufacturing machinery might fail, but if you know it is new, it has warranty, and comes from a reliable vendor, then the risk might be identified as low in likelihood. But if you have experience of an unreliable vendor who provides supplies for your new project, you could rightly identify a likely risk of them again failing to deliver on time. Late delivery might mean you fail to meet your schedule.
The second dimension of risk is impact. Using the above example, if your machinery failed that could be a high impact risk – it would bring the whole production line to a halt, while you have workers standing idle, and deadlines not being met. Another example of one of those workers calling in sick one morning will not stop the whole production line, so might be a low impact risk.
Some risks you identify might not be relevant – you need to be realistic. A low-flying aircraft could crash into your factory, destroying it, and preventing you from manufacturing your new product. Although impact would be extremely high, the likelihood of this happening is very low indeed. So low you should not even consider it – it is not relevant to your project.
So, for each risk you identify you need to assign an impact and a likelihood, and you can create a risk matrix where you identify likelihood and impact as being either High, Medium or Low.
Next steps will be to work out how to mitigate the project risk.
Friday, July 30, 2010
Basic Project Management Definition # 3 - Gantt Chart
In some of the previous posts I’ve included pictures of Gantt charts like this one.
The Gantt chart is way of describing your chart visually, which will help you to schedule your project. Each task of your project is represented by a numbered horizontal row in the chart. And Time is represented along the top. The example above is showing weeks: you can see the start date of that week, each day represented by its initial letter, and each weekend represented by those vertical blue stripes.
On this framework you can then plot when your tasks will be completed and how long they will take. In the example you can see that the task “Prepare timber” will start on Tuesday August 3, and will take 3.5 days to complete, finishing on Friday August 6.
I’ve just used the column “Duration” to specify how long the task will take (more on this in later posts). In the example you can also see columns which show the start and end dates. I spoke about dependencies in the last post, and you can see these represented by the arrows between tasks: task 11 is dependent on the groups of tasks represented in rows 2 and 7.
This example was put together using a tool called MS Project which has way more functions and smarts than I’ve shown in this example, but you don’t need MSProject to plan with a Gantt chart. Some of the best and most useful charts I’ve seen have been thrown together on a whiteboard. I also use this format with pen and paper.
The Gantt chart helps you to visualise your project, and to question some of the assumptions round scheduling. Using this format is a also great way of communicating and sharing ideas about scheduling with others.
Wikipedia definition: Gantt chart
On this framework you can then plot when your tasks will be completed and how long they will take. In the example you can see that the task “Prepare timber” will start on Tuesday August 3, and will take 3.5 days to complete, finishing on Friday August 6.
I’ve just used the column “Duration” to specify how long the task will take (more on this in later posts). In the example you can also see columns which show the start and end dates. I spoke about dependencies in the last post, and you can see these represented by the arrows between tasks: task 11 is dependent on the groups of tasks represented in rows 2 and 7.
This example was put together using a tool called MS Project which has way more functions and smarts than I’ve shown in this example, but you don’t need MSProject to plan with a Gantt chart. Some of the best and most useful charts I’ve seen have been thrown together on a whiteboard. I also use this format with pen and paper.
The Gantt chart helps you to visualise your project, and to question some of the assumptions round scheduling. Using this format is a also great way of communicating and sharing ideas about scheduling with others.
Wikipedia definition: Gantt chart
Wednesday, July 28, 2010
Basic Project Management Definition # 2 – Project Dependencies
A second term which is important during your project planning is “Dependency”. If task B cannot start until task A is complete, then you can say that task B is dependent on task A. There is a dependency on completion of task A.
You need to consider dependencies as you work through the order of tasks in your plan. Let’s say we are still building that fence that we used as an example when defining project scope. You need to dig post holes before you can put your posts in place. So the task of erecting posts is dependent on the task of digging post holes. You need to have the fence in place before you can paint the fence. So the task of painting is dependent on the task of fencing.
It could be that a task can be dependent on more than one other task or chain of tasks. For example, in the fencing example you might have a group of tasks which are about procuring and preparing material: buying timber, cutting timber, buying hardware and tools. You might have another set of tasks which are about preparing the land, staking out the fence, digging post holes. The set of tasks required to erect the fence is dependent on the tasks required to prepare materials, and the tasks required to prepare the land.
You might also have other dependencies: on other projects (the project you are running to build a gate), or other suppliers (who will provide the fancy hinges you want for your gate), or on particular date (the date you get back from your overseas trip).
As project manager you can also question your dependencies in an attempt to find quicker or better ways of doing things. Did you see that earlier I said you had to put your fence up before you could paint it? Is that true, could it be possible, or even easier, to paint some of the components of the fence before you build it? Questioning your dependencies like this might help you find a better way of doing things.
As a project manager you need to be aware of all dependencies so that you can include them in your plan and have your plan be a more reasonable forecast of reality. If you’re not aware of dependencies you might find your project stuck, waiting for something to complete before you can move on.
So make sure you understand your dependencies, otherwise you will have problems –you can depend on it! (ouch).
You need to consider dependencies as you work through the order of tasks in your plan. Let’s say we are still building that fence that we used as an example when defining project scope. You need to dig post holes before you can put your posts in place. So the task of erecting posts is dependent on the task of digging post holes. You need to have the fence in place before you can paint the fence. So the task of painting is dependent on the task of fencing.
It could be that a task can be dependent on more than one other task or chain of tasks. For example, in the fencing example you might have a group of tasks which are about procuring and preparing material: buying timber, cutting timber, buying hardware and tools. You might have another set of tasks which are about preparing the land, staking out the fence, digging post holes. The set of tasks required to erect the fence is dependent on the tasks required to prepare materials, and the tasks required to prepare the land.
 |
| In this example the "Build" tasks are dependent on both the "Design & Prepare" tasks & the "Prepare Boundary" tasks. |
You might also have other dependencies: on other projects (the project you are running to build a gate), or other suppliers (who will provide the fancy hinges you want for your gate), or on particular date (the date you get back from your overseas trip).
As project manager you can also question your dependencies in an attempt to find quicker or better ways of doing things. Did you see that earlier I said you had to put your fence up before you could paint it? Is that true, could it be possible, or even easier, to paint some of the components of the fence before you build it? Questioning your dependencies like this might help you find a better way of doing things.
As a project manager you need to be aware of all dependencies so that you can include them in your plan and have your plan be a more reasonable forecast of reality. If you’re not aware of dependencies you might find your project stuck, waiting for something to complete before you can move on.
So make sure you understand your dependencies, otherwise you will have problems –you can depend on it! (ouch).
Sunday, July 25, 2010
Basic Project Management Definition # 1 – Project Scope
Project management is no stranger to jargon. Project managers use terms which may not be familiar or regularly used by others. Definitions may be useful for you.
Basic Project Management Definition # 1 is “Project Scope”. Your project scope is, put simply, all the things your project will deliver. “Scope” means “extent” or “range”. Your project scope is the extent or range of your project.
One way to think about it is in relation to your work breakdown structure. If you are going to include a task in your project, it is in scope. If you will not complete a task as part of your project, it is out of scope.
For example, if you have a project to build a fence round a garden there will be plenty of tasks in scope including buying materials, digging post holes, and putting up the fence. Tasks unrelated to your project such as tilling the field, or painting the farmhouse are out of scope – they are not part of your project.
Seems easy, but many problems can arise if you are not specific about scope or do not define it clearly. If scope is not clear your customer, whoever has asked for the project, may expect one thing while you expect to deliver another. Let’s think about that fence again – is it in scope for you to paint that fence? Imagine what it will mean to your project, your costs, and the good will with your customer if they assumed you would paint, and you have no intention of painting? Pretty bad, right?
So be clear on what you will deliver. Go back to your work breakdown structure (link) to help you think through exactly what you will deliver – what is in scope. Make sure everyone on the project and your customers know what you have decided – it is better to find out you disagree before work has started than much later. If you find out early you can work through the options, change the scope and cost maybe, and get to a point where all agree what will be delivered.
Project scope: a simple term, but an important one.
Basic Project Management Definition # 1 is “Project Scope”. Your project scope is, put simply, all the things your project will deliver. “Scope” means “extent” or “range”. Your project scope is the extent or range of your project.
One way to think about it is in relation to your work breakdown structure. If you are going to include a task in your project, it is in scope. If you will not complete a task as part of your project, it is out of scope.
For example, if you have a project to build a fence round a garden there will be plenty of tasks in scope including buying materials, digging post holes, and putting up the fence. Tasks unrelated to your project such as tilling the field, or painting the farmhouse are out of scope – they are not part of your project.
Seems easy, but many problems can arise if you are not specific about scope or do not define it clearly. If scope is not clear your customer, whoever has asked for the project, may expect one thing while you expect to deliver another. Let’s think about that fence again – is it in scope for you to paint that fence? Imagine what it will mean to your project, your costs, and the good will with your customer if they assumed you would paint, and you have no intention of painting? Pretty bad, right?
So be clear on what you will deliver. Go back to your work breakdown structure (link) to help you think through exactly what you will deliver – what is in scope. Make sure everyone on the project and your customers know what you have decided – it is better to find out you disagree before work has started than much later. If you find out early you can work through the options, change the scope and cost maybe, and get to a point where all agree what will be delivered.
Project scope: a simple term, but an important one.
Saturday, July 3, 2010
Iterative project planning
So far we have described a number of steps for building a project plan, and they were described in an order that seems logical. First we work out what we are going to deliver, then we work out what tasks we need to do, then we group and order our tasks, then we work out how long each task will take.
It all makes perfect sense. But it probably won’t happen that way. Sure, you’ll work out what you are going to deliver and then think about what steps you need to take…but maybe that will make you re-think what you are going to deliver. When you get to grouping and ordering tasks, you might be reminded of a task that you forgot earlier. While you are estimating the duration of the tasks you may be prompted to re-think the way you ordered your tasks.
Planning is not always the kind of logical, step-by-step process it might initially appear:
Planning is not always the kind of logical, step-by-step process it might initially appear:
- It is an iterative process, which means you will have to keep going back to the beginning and working through the process again, refining as you go.
- There is an element of creativity in planning, using your experience and imagination to predict what is needed and how best to achieve it.
- Each step is likely to help your thinking about other steps.
- You can keep refining each piece of the puzzle until you are happy with it.
For this reason, you might want to consider doing your early stages of planning in a very rough and ready way. Using paper and pencil, or a whiteboard can help to free your thinking in a way that staring at a computer based planning tool (such as MS Project) can’t. You can move faster, think quicker, make notes and scribble things out as you go. Brainstorming with others can also help to speed up your planning. It may be that you will finish your planning in a software tool, but try starting with a method that allows you to plan using broad brush strokes – it can save you a lot of time.
Saturday, June 5, 2010
Identify Key Milestones
There are two definitions for ‘milestone’ (www.dictionary.com) ‘a stone functioning as a milepost’ and ‘a significant event or stage…’. Milestones were used to give travellers information about where they were, indicating how far back to a major town, how far to the next. The traveller could see how far they had travelled, and how far they had to go.
It is no surprise that the word has taken on that second meaning, where an event becomes an opportunity to look back, and look forward. And just as the traveller might use the milestone to make decisions about his journey (do I need to move faster, or spend the night right here) the milestone helps us to make decisions about our project’s progress.
Try to incorporate milestones in to your plan, so that you are able to use them to assess progress as you go. This means you don’t have to wait until the end of the project to see if you are on target. You can pause at your milestone and consider if you had expected to be there earlier, or later, and what you have learned on the way.
Milestones are often formed by your logical groups of tasks. For example, if you have finished all the tasks that are needed to build the foundations of your new house, that could be a significant event, a milestone for your project.
A milestone could be formed by the end of a project stage. For example, completing the design for your new house, could be a significant stage, before the build stage.
A milestone could also be somewhat arbitrary. If you need to build 100 widgets that you will use later in your project you might want to put a milestone half-way through, at 50 widgets, so you can test if you are on track. Or 20% through, 20 widgets.
You can determine what milestones make sense for you. Don’t have so few that you rarely get the opportunity to test your progress, nor so many that they are no longer significant. Use them to reflect, and if necessary re-plan. Use them also to celebrate success, reward yourself and your team, and refresh yourself before moving on the next milestone.
Now, with milestones added to your plan there is just one planning task left – working out what can go wrong.
It is no surprise that the word has taken on that second meaning, where an event becomes an opportunity to look back, and look forward. And just as the traveller might use the milestone to make decisions about his journey (do I need to move faster, or spend the night right here) the milestone helps us to make decisions about our project’s progress.
Try to incorporate milestones in to your plan, so that you are able to use them to assess progress as you go. This means you don’t have to wait until the end of the project to see if you are on target. You can pause at your milestone and consider if you had expected to be there earlier, or later, and what you have learned on the way.
Milestones are often formed by your logical groups of tasks. For example, if you have finished all the tasks that are needed to build the foundations of your new house, that could be a significant event, a milestone for your project.
A milestone could be formed by the end of a project stage. For example, completing the design for your new house, could be a significant stage, before the build stage.
A milestone could also be somewhat arbitrary. If you need to build 100 widgets that you will use later in your project you might want to put a milestone half-way through, at 50 widgets, so you can test if you are on track. Or 20% through, 20 widgets.
You can determine what milestones make sense for you. Don’t have so few that you rarely get the opportunity to test your progress, nor so many that they are no longer significant. Use them to reflect, and if necessary re-plan. Use them also to celebrate success, reward yourself and your team, and refresh yourself before moving on the next milestone.
Now, with milestones added to your plan there is just one planning task left – working out what can go wrong.
Subscribe to:
Posts (Atom)