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

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.

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

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.

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:

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