How to schedule a project

techniques to make a good project schedule

Everyone wants to know how soon your project can be completed. Getting the answer wrong can cause many sorts of problems. This article suggests how to answer the question well. It uses ideas from the popular PRINCE2 Project management system, but is intended for readers with little or no background in project management.


Main steps

The main steps to scheduling a project are:

  1. Obtain a clear picture of what it is the project needs to deliver. You can’t build it unless you know what “it” is!
  2. Break the project into its basic chunks (sometimes called “work blocks”)
  3. Break those chunks into their tasks, being sure to go into enough detail that you reduce the risk of forgetting important steps
  4. Put the tasks into order. Some clearly can’t be achieved until an earlier task has been done (for example you can’t paint a wall until you have built it). In other cases you have the option of doing several tasks in parallel. Sometimes outside circumstances determine when something can be started.
  5. Decide who will do each task, and estimate how long each will take.
  6. Optimize the order of tasks and their starting dates.
 

Typically, you will be doing a lot of this early in the project – it is usual for your organization to want to know how long a project will take (and how much it will cost!) before agreeing to proceed. But as the project proceeds there is a need to keep looking at your schedule and updating it, so that it is ready as a tool to help you deal with any problems or delays that arise. 

There are various ways of recording and keeping your schedule, and comment on these at the end of the article.

Obtain a clear picture of what it is the project needs to deliver

For some projects this may simply require some time to sit down and think. Or it may be that you can sort this out in a meeting, or even that someone else has already done much of the thinking. But sometimes the work of “requirements analysis” is more complicated – especially if you have to ask a lot of other people or it is not quite clear what is needed. My article on requirements analysis may be useful in that situation.

Break the project into basic chunks

Start by making a short list of the things you will need to produce in the project. Don’t go into much detail yet. For example, if you are to make a book with a CD-ROM bound in the back, the basic chunks (sometimes known as “work blocks”) might be:

  • Printed book
  • CD-ROM -which comprises:
    • Interface
    • Multiple choice questions
    • PDFs of the printed book
    • Help file
 

Note that the chunks don’t have to be tangible things – for example, perhaps your book needs to be approved or endorsed by an outside organization (e.g. it is a textbook needing approval from the examination board for the course). “Endorsement” might then be a work block – because it might indeed be quite a lot of work. 

It can be helpful to make a diagram, like a company organization chart, to show this (the PRINCE2 project management method calls the diagram a “Product Breakdown Structure” or “PBS”):

Fig 1: A "Product Breakdown Structure" - the main parts of a project shown like an organization chart.  

This example (Fig 1) was drawn using the organization chart tool built into Microsoft Office (e.g. Microsoft Word). If you dislike that tool (or dislike Office, or Microsoft software) it should not be too hard to find an alternative tool.  

 
Diagrams like this are surprisingly useful as a summary of the project – it can help to find whole missing chunks (“but wait a moment, what about the Welsh Language version??!”) or to raise useful questions. For example, this “interface”. By interface I mean that we want the CD-ROM to autorun when loaded onto someone’s computer and show a menu of the available content (which are so far the multiple choice questions, PDFs and Help file). If the Multiple Choice Questions are delivered electronically (as opposed to being, say a PDF to print out and do on paper) the “interface” might also be bound up with the technology used to deliver the questions. There are various ways to do this – using HTML, using Flash, or other technologies. Perhaps your vision of the CD needs some work in order to sort out how this should be done and where to get the skills to do it.  

The diagram can also help with those dangerous things that hang around just at the border of the project and risk not getting done because they are no-one’s work. For example, perhaps the “interface” includes a link to your organization’s website. If so, you need to establish whether special web pages or websites need to be built (or are we just linking to, say, the home page for branding purposes). Or then again, should we consider the option of putting the multiple choice questions on the website as opposed to being on the CD? If special web pages or websites are needed, it might be a good idea to show them on the diagram as a work block – they may be a lot of work and putting them on the chart stops them being forgotten!

Break the chunks into their tasks

Now work out what has to happen to complete each work block. For example, what needs to happen to create the printed book, or the multiple choice questions. There is typically a lot of information to assemble here. Some people like to use self-adhesive notes (such as PostIt™ notes) – they write down one task on each note, and then order them on chart paper or a table top. Some people like to draw everything out as a “Mind Map”. 

Try to break things down into a lot of short tasks rather than a few long ones, especially if the work is unfamiliar. If tasks bundle a lot of steps together, it is easy to mis-estimate how long the work will take (often because a part of the task was not included in the plan). A further advantage of breaking things down further is that you will have more points at which to check progress, and to see whether the project is on schedule.

Having many, short tasks also helps when it comes to running the project. It means that there is always a deadline coming up soon - this helps keep people focused. And it means that if people are not getting enough done for any reason, deadlines will soon start to be missed and you will know there is a problem.

Lastly, ask yourself how you will know that the task has been completed to the right quality. Sometimes this will make you realise that there is a checking step to do that you had not so far thought about. There should be some tangible output. 

There are two schools of thought on whether you should plan the entire project in this level of detail. If you do, you will have a very clear idea of how you currently plan to do the work. But that means a lot of planning, some of which may have to be changed as the project proceeds (things may go wrong, or there may be new needs and opportunities to meet). The alternative is to plan the entire project enough to be confident about overall finish dates and other key dates, and then to break the project into a series of mini-projects. Each of these is then planned in detail only when you reach it. The book Agile Estimating and Planning (Mike Cohn) is an excellent reference for the mini-project approach

Put the tasks into order

As you break things down to tasks, you will begin to realise any “dependencies” (tasks that cannot be competed without some other part of the project being completed). For example, in the book/CD example, the CD is to include a PDF of the printed book, so obviously the CD cannot be completed until there is a PDF of the finished book text.  

One way to show these orders is to expand your Product Breakdown Structure, constructing a flow chart for each work block. This makes a new kind of diagram (the PRINCE2 project management method calls this a “Product Flow Diagram”). An example is shown in Fig. 2. 

Important conventions to avoid a confusing and messy diagram are:

  • Time goes one way only (e.g. from top to bottom, or left to right)
  • Each box represents a task (something that could have a start date and a finish date)
  • Arrows connect a task to its successors (things that can’t be achieved without completing this task). Do not use arrows to represent work or events.

The diagram shows a “Product Flow Diagram” for the book/CD project. In a real project I might break the tasks down further, but have not done so here to keep the diagram easier to understand.

image
Fig 2: A "Product Flow Diagram". Each work block has been turned into a flow chart, showing the sequence of tasks needed to get the work done. Each task is shown as a block, with arrows connecting a task to any successors
 

Decide who will do each task, and estimate how long each will take. Optimize.

The next step is to decide who will do each task. One person should be responsible for each task - either because they are doing it or because they are managing a team of people doing it. This means there is someone you can go to for progress reports and to discuss any problems. It also avoids the risk that nothing happens on the task, because everyone thought someone else was doing it! Make people responsible for reporting that they have finished their task (strangely this does not occur to everyone even when they should realise that someone else needs their work to do the next thing).

You also need to add an estimate of how long the task will take. You can of course record this graphically on your Product Flow diagram (scaling the boxes according to the length of the task) or it may be time to move to another way of showing your schedule (more on that below).  

As you include likely durations and consider the likely workload on your people and equipment you may see ways to optimize the schedule. For example, perhaps it is clear that the priority is to get started on the work block that will take the longest. Or perhaps you want to get some tasks done earlier than is strictly necessary, to free a person or equipment for other work later.

Tools to display your schedule

Tables

For simpler projects it may be perfectly adequate to keep the schedule as a table, like this:

Task No Prog-ress Task name No. days work Start date Finish date Person responsible Predecessor tasks Successor tasks
                 
                 

Microsoft Word or Microsoft Excel (or non-Microsoft equivalents of your choice) will probably be suitable.

Microsoft Outlook

Microsoft Outlook has a “Tasks” feature in which you could store tasks. Outlook will allow you to assign tasks to others (with some exceptions if they are not on the same network), and will remind you when tasks are due. If you already use Outlook to manage your appointments, using it for tasks too may have the advantage that you can integrate your schedule straight into your normal time management tool, as opposed to needing to copy deadlines and other info regularly from the schedule into your diary. It is possible to view tasks as various kinds of lists, which could be made to resemble a tabular schedule. This may be an option to consider if you don’t need to display the schedule as more than a task list, and if you use/like Outlook already. Similarly, if you already use a non-Microsoft equivalent to Outlook, it may be worth investigating whether it would be suitable for keeping your schedule.

Wall planner

Or, of course, you may be perfectly happy to keep everything on paper. You might try using “wall planner” charts, which show a calendar year as a big table on which you could write your tasks. Often these charts are plasticised and come with a write-on-wipe-off pen. This allows a crude way of updating the schedule.

Microsoft Project

For more complicated schedules, specialized software is available. Many Project Managers use Microsoft Project, which can display the schedule in various ways, including this Gantt chart (Fig.3). 
 
Fig 3: A Gantt chart prepared using Microsoft Project. The tasks in the schedule are shown both as a table and as bars on a calendar. Tasks can be gruped into various work blocks and the dependencies indicated with arrows.

image

Such software has its pros and cons. These are the ones I have noted from using Microsoft Project (non-Microsoft alternatives may have different strengths and weaknesses):

  • Pros
    • Automatically updates dates in schedule if there is a change. If a task is delayed by a week, say, all its successors are pushed along. It can be tedious to do this manually in Excel/word, and easy to make mistakes.
    • Good for modelling effects of various changes to the project (e.g. “what if we do this in a different order?” “What happens if the artworks are late?”)
    • Good a showing critical path (the sequence of tasks which is currently dictating when the project will end, and which therefore earns the project manager’s special attention)
    • Various displays from the same data – e.g. Gantt chart or calendar – without re-entering all the information
    • Can include workload information (you can tell it that “Fred” is doing several tasks. If Fred ends up with more hours per week than you have said is OK, Project will alert you, and can adjust the schedule to allow for Fred being unable to work that much).
    • Can use progress-tracking features
    • Can “roll up” detail so as to present summary schedules
  • Cons
    • Can be expensive: at the time of writing a single, full-price licence for Microsoft Project  is over £ 400 (four hundred GBP).
    • Takes some time to learn to use it effectively
    • Harder to share data with colleagues who do not have this software (c.f. most colleagues will be able to look at an excel spreadsheet without problems)
 

When choosing your software (or paper) system for keeping your schedule, important factors to consider are:

  • Use something you are comfortable with (or can become comfortable with soon enough and cheaply enough). You may need to work on the schedule regularly to track progress and to update the plan if things get behind (or more rarely, ahead). If maintaining the schedule is hard to do, you will probably not do it as much as you should.
  • Make sure you have a way of sharing the schedule information with the others involved in the project. They need to note and act on their own tasks and deadlines, and need to know about the overall progress being made.
  • The fanciest software cannot do the thinking for you – it only displays the schedule as you have supposed it is, and so is only as good as you rthinking and planning.

Comments

Chris Baker
Chris Baker
Freelance Project Manager, Publishing and IT Projects at Chris Baker Project Management Ltd.
Oxfordshire, UK
Article rating:
Your rating:

Reviews

    Chris Baker also wrote

    Knol translations

    Activity for this knol

    This week:

    62pageviews

    Totals:

    2123pageviews