I’ve been delivering projects for 20 years and over that time I’ve used various different tools to make my deliveries as effective and efficient as possible. Different planning approaches require Gantt charts, Kanban boards, burn-down charts and/or many others, all using different technologies including PowerPoint, Excel, Project and similar products from vendors other than Microsoft. This post gives my view of what’s essential, which versions I prefer, and why.

The most important item in your toolbox as a project manager is a detailed plan. To a certain extent it doesn’t matter which tool you use for this job, but by far the most comprehensive and useful is Microsoft Project, which is the de-facto detailed planning tool on the market. It has been around since the early ‘80s and has grown over this time to include the ability to manage every aspect of your project. I don’t however advocate using it to manage all areas, instead using it to perform a few key functions, but that list of functions depends on what it is that you’re trying to achieve – I’ll be writing a more detailed blog on this in the coming weeks, but for now I’d advise that at the very least your detailed plan includes all of the tasks, dependencies and resources for your project.

What about an Agile project? I’ve fixed a few broken projects that were following an Agile methodology and without exception the use of a project plan has been an essential factor in the remediation process. You may not put detailed development functions of each sprint into your plan, but there are so many other things that need to be carefully managed. Creating a plan that includes placeholders for sprints allows you to control the overall timescales and resources in the full context of the project. This includes all testing phases, including non-functional and end-user, as well as all of those implementation tasks that are invariably left to the last minute and are typically poorly planned.

I wouldn’t use MS Project to control/manage finances, but it is useful in the construction a financial forecast. Using it to track costs can become extremely complex and unnecessary when a simple spreadsheet will suffice. Other functions, such as levelling are extremely useful but this is a means to an end in creating your detailed plan. Again, more on this in a later blog, but for now don’t shy away from levelling your resources – pressing the levelling button is not a self-destruct action for your plan as some may suggest!

Probably the single thing that a detailed plan gives to you is confidence in the key dates for your project, and it does this based on facts about the things that need to be done, how long they will take and who will be doing them. If this is accurate and sufficiently detailed then the rest will be straightforward.

The old adage that ‘a picture tells a thousand words’ couldn’t be more true when it comes to planning and reporting delivery progress. A high level plan is essential for understanding the overall shape of your project’s timescales. High level Gantt charts are the perfect way of doing this, but without a good tool for doing them quickly and accurately they can be extremely time consuming, especially when your project’s overall timescale changes.

The perfect tool for this job is Timeline Expert. It can be used to quickly work on a high level plan, either when you’re working through options by yourself, or in a workshop setting with others trying to define the key activities. Whiteboard diagrams can become messy and confusing and can lead to extra work when you have to make sense of them and draw them up after the meeting. Another feature is that it can be used to extract the salient high level elements of your plan directly from the master source of your planning data: MS Project or Excel. I couldn’t operate effectively without using a high level plan, and I couldn’t manage a high level plan without Timeline Expert. Creating a high level plan in this way also removes the need to keep two things aligned with one another. Your detailed plan in the master source for all of your planning data and the high level plan is a graphical report on that data.

Back to Agile and the argument that this methodology doesn’t require a plan, I argue that it does. Remember that a plan on a page is primarily a communication tool and there is no reason why you can’t show the time periods for sprints within the wider timeframe of your overall project delivery.

I’ve come across many project managers who don’t have a high level view of their project’s plan, and without exception those projects have missed key dates and have required significant replanning. Furthermore the stakeholders for those projects have always commented on how they don’t know what’s happening in the project or when they’re expected to perform their key activities.

All projects no matter what methodology is used will need to have their plans communicated to several important audiences and contributors. This is an essential part of a project manager’s toolbox.

There are several aspects to good project planning some of which haven’t been covered in this article, but the key things that are important are being in control of the details, and then being able to communicate that to key stakeholders. This theme is central to all aspects of project management and will appear as a theme throughout this blog series. Next time I’ll cover off another vital communication tool, the project diagram.