What comes first when you’re starting a project?
Is it setting the timeline? Or maybe the budget? Or is it the scope?
The answer, is that it’s none of the above. The first thing you need to do when you’re starting a project?
It’s strategy.
But there’s a high likelihood that this is not what you’ve been told. The most common thinking is you should start with a project scope that’s defined based on your budget and timelines. Or that the scope will determine your budget and timeline. And then you’ll use scope, timeline and budget to define your project strategy.
Using scope to drive the success of your project is a mistake.
The problem with putting scope at the centre of your decision making, is that in reality, it’s simply a list of tasks you commit to delivering as part of the project.
Now let me ask you this. How can you commit to the tasks, without understanding the success criteria?
The best way to explain my thinking on this, is firstly to outline what should be decided and included in a project strategy on a very basic level.
What is involved in setting a Project Strategy?
When it comes to good project strategy, the most important thing is to be clear on what the strategy should help you to achieve.
In its simplest form, a strategy should help to guide the need or problem we must solve and what we are choosing to do to meet this need.
The stuff in the middle can cause unnecessary complications… if we let it. For the purposes of answering the question posed in this article, I’m going to show you how to get started with creating a simple, easy to execute strategy that doesn’t get caught up on things like feasibility assessments.
Your Project Strategy Needs These 3 Things
A good project strategy should involve 3 things.
These are:
1. The Why
The Why is one of the greatest keys to the success or failure of a project.
The Why relates to why we are doing the project – what need or pain point must we satisfy?
When we get this right we solve our stakeholder’s need and deliver a fit-for-purpose solution. But often project teams get caught up wanting to deliver a new ‘shiny object’ without aligning the specifications back to solving the project’s why. This results in re-work, scope creep, and dissatisfied project stakeholders.
It can be very tempting to include the latest gizmo and gadget functionality as part of a project because in isolation these have several benefits. Yet, when we tie the functionality back to the need, we often find that only a small handful of the shiny stuff is necessary.
2. The Who
As equally important as finding out the project why, we need to take the time to know who this information should come from.
In short, the why should come from anyone signing off the project or anyone who will be using the project’s deliverable. Typically this will involve the person funding the project (the sponsor) and any key subject matter experts testing the project’s deliverables.
If key, impacted stakeholders are not providing sign off or testing deliverables, it is still valuable to capture their why perspective. Each stakeholder will have a different idea about the why, because the project will impact them in different ways. By understanding varying stakeholder needs, the project team is better able to ensure the final product delivered is effectively functional, reducing missed requirements and the need for re-work.
The people who should not answer the project why is the project team.
This is because their interpretation of the problem will often be incomplete or different to those who are facing it directly. The project team’s role is simply to make sure they know and understand the why so they are able to deliver to its requirements.
When drawing out the strategy it is useful to start considering which stakeholders will need to be engagement, involved, and communicated to. While only at a high-level, being aware of this broader list of “Whos” will help to determine the size, length and reach of the project.
3. The What
Once key stakeholders have told you what need or problem must be solved, the what becomes a brainstormed list of ways to solve the why.
This brainstormed list is very different to a scope as it is not a committed list of deliverables. It’s simply a list of possibilities. You’ll prioritise these later in the process, and not all of them will be scoped as part of the project deliverables.
How to gather the Why, the Who, and the What: An example
The Why: A water truck can no longer deliver water to the village. The villagers can source water from a nearby well however they have no container to collect the water from the well and no vehicle to transport it to the town.
The Who: The villagers, the water truck drivers, the village leader, the village funding committee.
The What:
* Round or square bucket
* Plastic or wooden bucket
* 1 colour option or several colour options for bucket
* 1 size option or 3 size options for bucket
* Rope to pulley the bucket
* Trolley to carry the bucket (brainstorm list of possible materials)
* Spout to pour the water out of the bucket
* Lid for the bucket
* Tap for the bucket
Prioritising the Whats to the Project Budget and Timeline
Once you’ve got your why, who and list of whats, you’ll need to prioritise your whats list.
To do this, you need to, at least at a high level, expand each possibility. This will help you to understand what is needed to achieve it, what costs may be involved and how long it will take.
Using the water example above, we need to determine what is required to produce a plastic bucket versus a wooden one. Do the skills and material to develop either option already exist and what will be the cost comparison if we do or don’t have them on hand? What is the time variation between producing a plastic bucket over a wooden one? Will the weight of the bucket impact the choice of material? Do stakeholders have a particular preference to plastic or wood?
These questions help to ensure the final list of possible deliverables meet the stakeholder’s budget, time needs, and functional requirements.
From Strategy to Project Scope
Now that you have a prioritised list of what can be done to solve the project why, the project team should work with key stakeholders to agree and commit to the items they can and will deliver.
This final list forms the project scope. For more information on how to successfully scope a project, refer to my article Project Scope Creep: How to take control and get back on track.
Don’t forget – The Why, The Who and The What
Sometimes These are the three key elements to getting started with a project strategy that will lead your project down the path to success.
When you choose to put strategy before scope, you’re choosing to deliver powerful projects that avoid scope creep and deliver ongoing value to your organisation.
Creating a powerful project strategy and scope with the Project Manifesto
My philosophy is to help people deliver more powerful projects more easily!
One of the ways I have done this is by creating a fail-proof process and documentation to develop a good project strategy and scope.
Time and time again I see projects unnecessarily fail due to not drawing out and overcoming potential risks at the beginning. And that’s why I’ve developed this approach.
I call my success strategy the Project Manifesto.
The Project Manifesto is a step-by-step, guided document that will allow you to create a powerful project strategy by defining:
Usually only available to my training and coaching clients, I’ll soon be making my Project Manifesto available to all those looking to power-up their projects with good strategy.
The project manifesto product is a step-by-step project planning document template and is accompanied by a 50 minute tutorial video showing you how to use it through every step of the process.
I am committed to supporting you to delivering successful projects, no matter what stage of your project journey.
You can access the Project Manifesto, along with a preview of the tutorial video you here.
Subscribe for insights, tips and strategies to help you deliver powerful projects.
We support and inspire project teams with insights, tips and strategies that build their confidence in delivering powerful projects.