I don’t need to convince you that project scheduling is important. After all, if you’re involved in projects in any way shape or form you’re going to know that anyway.
On saying that, do you know how many projects fail because of poor scheduling? No? The results might surprise you. 43% of projects failed due to inadequate task and resource estimation. (Source: PMI Pulse of the Profession 2018)
In this post, I hope to give you tools and techniques to ensure your projects don’t fall into the 43% of projects that failed due to inadequate scheduling of resources and time. One of the first things to remember is that scheduling is more than just a GANTT chart. I’m amazed at the number of people who, when I mention scheduling, automatically start talking about the GANTT chart. In my opinion, the GANTT chart is the visual component and the output of the activity known as scheduling.
Here are my tips on how to do project scheduling:
Start at the end
Before you even think about creating the schedule, go right to the end of the project and think about what it is you’re going to deliver. At this point, I can hear you screaming “what, are you daft, woman? Why would I think about the end?” My response is Yup – the end point! What is it you want, or in all honesty, are being expected to deliver? The answer to this is going to colour everything else you do. Do this exercise – write down a synopsis of the end point. Then, go and read the business case and ask the project team to do the same exercise. Check that what you all understand the product/service etc. to be is the same as what is documented. If they don’t broadly match you have some work to do!
Something I can’t emphasise enough is you can’t build a schedule on your own. Well that’s not strictly true – you can. It will likely be total rubbish, but you can do it. In all seriousness though, when you begin to build your schedule do it as a team. I like to get everyone into a room, begin with the exercise above and then start to work on the work breakdown structure. Getting the whole team together is both a chance for a get-to-know-you session, and sets the tone for the entire project. You’re also getting the experts involved early.
I like to have at least three scheduling meetings, as it usually takes that long to get the schedule into a usable state.
Work breakdown structure
A work breakdown structure is normally one of the first deliverables of a project. It is a hierarchical breakdown of the deliverables of the project. It sounds like it should be really easy to create, but it can be an interesting exercise, as things that haven’t been considered often come out of the woodwork at this point.
It’s likely that when you go into the initial meeting you’ll have some ideas about how the project will be scheduled. Please, leave those ideas at the door and go in with an open mind. You’ll be amazed at the solutions your team can come up with which will solve what looked like insurmountable problems.
When I run a work breakdown structure meeting, I make sure I include a representative from the test and support teams, as well as a user representative if possible. These critical functions are often ignored until the very end, which can lead to overruns, delays and ill-feeling.
For the initial meeting I get the team to use different coloured sticky notes . The first step is to get the team to write down every single thing they can think of which the project needs to do. I get them to put the ideas into loose themes. I emphasise that no idea is stupid or too small.
Once that activity is finished, I go round the room and ask everyone to share their ideas. I begin to group the ideas into themes (task groups, or level 1 of the work breakdown structure) on a large surface – normally a wall. Once we’re all happy with the top level structure, we get down into the activities which make up the task groups. At this point there is usually a lot of to-ing and fro-ing with sticky notes being moved around, duplicated and removed.
I tend to stop the meeting once the initial work breakdown structure is complete. The next meetings get into resources and estimates, which leads nicely to the next topic. For more information on this topic, check out my blog post on five tips to help you build the best work breakdown structure possible.
During the initial scheduling of the project, you’re unlikely to know exactly who you are going to need to do what. This doesn’t mean you don’t need to think about your resource requirements – far from it. At this point, I tend to plan using roles. For example, I know I’ll need business analysts, developers, testers, etc. and then, during estimation, I can work out how many of each role I need and use that information to inform the resource managers.
Once you’re happy with the amount of resources you need for each task group, you’ll find you’re in a much better position to approach the resource managers to request specific people to work on your project.
Estimating the time it takes to complete a task can be a painstaking process. You can make it easier by following a few simple steps.
Always give people time to come up with the estimates. I’ve found the estimates I receive when I’ve rushed people, tend to be overoptimistic and often need to be changed at regular intervals.
Try to give the estimator as much information as possible up front. It’s impossible to give an accurate estimate without having all of the information available.
Make sure you ask the right people to give you the estimates. There’s no point asking someone who has never done a particular job before to tell you how long it will take. That might be stating the obvious, but I’ve seen it happen on more than one occasion, with the predictable results.
Get the estimators to provide three figures for each task – the best estimate, the most likely estimate and the worst-case estimate.
Try and use bottom up estimating where possible. It is the most time consuming, but tends to give the most accurate results.
Creating the schedule
Now it’s time to take all the information you worked so hard to collect and turn it into a beautiful GANTT chart. The amount of detail you include very much depends on what you think is important.
I like to make sure the critical path, or golden thread, is clearly visible. I also put the name of the individual responsible for the delivery of the task group on the chart.
What to do with it
You have this gorgeous GANTT chart with all of the tasks linked and key information associated with it. Now what? You’d be amazed at how many times this hard won piece of work ends up on a network drive, never to be looked at again!
This is NOT what you should be doing with it! A schedule is a living document and should be updated and maintained regularly. I like to have mine updated at least once per week. Any more and I’m getting too obsessed and need to back off. Any less and I’m likely to be losing control and oversight – which is never a good look.
If you’re looking for a tool to help you schedule projects, aggregate the data into programs and portfolios, look no further than Psoda. You can get a free, no obligation, 30-day trial right now. Just click on the big red free trial button at the top right hand corner of the page.