When it comes to projects there are three things you need to consider. First and foremost, you must decide on which project the business should focus on next. This should be the project which would add the most value to the company and would increase performance the most. Whether it be departmental or internal improvements, production or research, growth or cost control – you need to ensure you are choosing the right one. If you would like to discuss our criteria for how you can better prioritise and judge the best projects, you can of course, get in touch. Once you have chosen the best project there are two subsequent steps: the scoping and planning, then the execution and delivery. In this blog post, we will be touching on the link between the two, planning and execution. Most specifically, the focus will be on the words we use when we are planning our projects – how we describe tasks. Whilst this most likely isn’t the first improvement you would think to make, this is a change which will provide major value going forward. 

When planning a project, you must begin with the end in mind. The first assumption we must make is that any improvements made to the plan or the planning process are only useful if it helps us execute better. Therefore, any efforts made to upgrade the planning processes and procedures should be made only if they will help you to execute the project better or faster when it comes to do the work. Any improvements that do not help to execute better are simply polishing the cannonball – there’s no point. So, when it comes to planning the tasks, you should always begin with considering what effect it will have on execution and how you deliver the project. 

In execution, the most prominent question is that of how much work has been done, and how much work is yet to be done, relative to the time left to complete the project on-time. If you are aware of how much work if left to do, and how long you have left to complete it, you can know whether the project is running on-time, ahead or behind schedule. In order to understand how much work has been done/is yet to be done – you must be clear on what ‘done’ looks like.  

The challenge often faced in execution is that tasks are quite often described as actions. The problem with this is that you can easily say that actions A, B and C have been taken or completed, but that doesn’t necessarily mean that the project task has been successfully achieved. It simply means that you have completed the actions you thought were needed when you initially described the tasks in planning, often many weeks before. This is no longer helpful in execution. 

You must try and avoid the mismatch between actions completed and dependent project tasks which are not sufficiently finished. Building a project plan solely on the actions you are able to describe during planning, means that you will inevitably miss some items which will appear between the point of planning and the time when you execute it. It’s impossible to predict every possible eventuality and change needed while in the planning stage. It would be far more helpful to spend some time describing what ‘done’ looks like for each of the tasks. Move away from describing tasks as ‘Do action A’, ‘Do action B’… and move towards statements like: ‘X has been completed, delivered and approved’. Move towards describing task deliverables. 

Let’s look at a tangible example. Imagine you are going on a business trip from London to Paris. Your initial plan is to get a bus to London Heathrow, from there, fly to Charles de Gaulle airport in Paris and get a taxi to your destination. From a planning perspective, the tasks are clear: get the bus, board the plane, land in Paris and take a taxi. However, upon a price comparison you discover that you can make the journey for less money. Instead, you decide to drive to the Eurotunnel, take the train to Paris and drive to your destination. You reached your end goal, however, the tasks in the plan are no longer valid. What if the tasks in your initial plan had been described as deliverables? Rather than ‘Board the plane’, ‘Land in Paris’ and ‘Take a taxi to your destination’, you would have described the tasks as: ‘Departed the UK’, ‘Arrived in France’ and ‘Arrived at destination’. Then there would not have been any re-planning changes required, the only thing that may have changed are the durations and these we update regularly in execution anyway. 

This might take some practice! Often people are very good at describing the actions we think we need to take, they are far less good at describing what ‘done’ looks like when all those actions have been taken – plus those actions which are impossible for planners to predict at the time. If you can build your project networks using deliverables and ‘done’ statements, with good logic linking ‘When task A is done, then task B can begin’, you will have a much more robust project plan which would require far fewer changes and far less re-planning. Even better, execution will be made much easier to measure. When execution is measured against ‘done’ statements, you will have a much clearer understanding of where you are against the project timeline and a clearer understanding of where to focus in order to make sure the project is completed on-time. This definitely meets the criteria of helping us execute better.

_{By Phil Snelgrove, Lauren Wiles}