The goals and objectives add context to a strategy for why a project is being delivered. The strategy then informs a delivery protocol or methodology that is to be applied to all facets on the project through delivery.
All programmes of work or individual projects, no matter how big or small, have a simple reason for existing. Why then do we struggle to describe that reason and have it reflect the way the projects are delivered? Maybe it’s because we can’t easily relate the goals or objectives of the project to the reason they’re being implemented. We confuse the things we CAN do, with the items we SHOULD do. Here’s a simple litmus test - How do you determine if something is ‘nice to have’ or a ‘must have’ on a project?
When I was at school and conducting science experiments, I was taught to write the aim of the experiment first. The rest of the experiment then outlined all the inputs, equipment, methodologies needed to achieve the aim. We measured the results and either proved the aim or not. Now I write complex project plans which account for technology, procurement, contracts, health and safety and a multitude of other workplace and engineering complexities and realise that we’re actually doing the same thing.
So the goals and objectives add context to a strategy for why a project is being delivered. The strategy then informs a delivery protocol or methodology that is to be applied to all facets on the project through delivery. We then inform all parties on a project WHY we’re doing what we’re doing, and all project participants understand and they deliver. Stakeholders know what they’re getting.
This idea is such ‘common sense’, yet being able to describe the reason on many projects we undertake seems very complex. Why? Is it really such a struggle for many stakeholders to grasp what the finer points of a project will deliver them? That doesn’t seem likely.
I believe the answer lies in the way we communicate the delivery strategy. It’s just not simple enough. We blame scope management, or engagement of the parties, or a lack of skill of project participants or the way we actually communicate. There are protracted procurement models, CAPEX, OPEX, programmes, probity and all other manner of considerations to communicate. All of these could be resolved more clearly if we just communicated why it’s being done to everyone.
Once the WHY has been determined, agreed and communicated, the correct application of the project process will determine WHAT needs to be achieved; HOW it will be done; WHO is best placed to influence this work; and WHEN in the project cycle this should be achieved. If a task developed doesn’t satisfy why it should be done when applying the strategic objectives to it, then should it be performed?
The process should be continually reviewed and checked through the project against milestone deliverables. If the strategic reason changes, re-apply across the whole project. It’s necessary to do this to ensure all project participants’ outcomes are met. A change to a methodology may prove beneficial to a specific aspect of the project but fail to consider the wider context. This can lead to disparate outputs and expectation misalignment.
The above diagram is a very simple structure that places the reason at the top of the heap. The functional delivery of all other decisions should be guided by the objectives that this reason sets out. There are many complex combinations of criteria that can lead to an outcome but even these are usually governed by the same principal reason.
It’s little wonder why this whole process becomes complicated. Keeping it really simple is where the true strategic value lies. We should try and make it simpler to start with.