Taking the time to map and scope projects properly is the first crucial step towards project success.
Consider the Giza Pyramids, one of the Seven Wonders of the Ancient World: made from some 2.3 million blocks of stone, constructed by more than 100,000 workers and completed within just 20 years.
One look at their construction and it’s clear that the Egyptians knew a thing or two about the importance of scoping a project. Indeed, there is strong evidence that the master builders of the Great Pyramid of Giza (the tallest building in the world for some 4,000 years, until 1874 when the Eiffel Tower was constructed), were also accomplished project managers.
They could see the totality of the construction and had an acute understanding of the project’s scope; the complexities, activities and deliverables that had to be achieved to build the pyramid within its timeframe.
For example, before construction could start, 500 men had to be dispatched 500 miles to Aswan to quarry the massive granite blocks that would take 10 years to be shipped down the Nile, finished and hauled into place.
There’s also evidence that blocks were stockpiled in quiet periods of construction to help manage peak demand. Regular Nile floods were also factored into the plan, allowing the stone to be transported by riverboat to within a few 100 yards of the construction site.
As a project, the Pyramids of Giza can be counted as a remarkable success. Sadly, that’s not always the case. History is littered with projects that have overrun. Take Barcelona’s magnificent Sagrada Familia Cathedral. To be fair, it was always going to take a long time; its architect, Antoni Gaudí, famously said, “My client is in no hurry” – referring to God. Some 150 years later, it’s still unfinished, although there is now a target completion date of 2026.
Overdue and over budget, the Sagrada Familia project is far from unique. Only around 50% of projects are completed on time and around 55% within budget. Infamous examples abound from the UK’s Millennium Dome to Berlin’s Brandenburg Airport. Delivering a project on time and within budget is no mean feat. And most of us contend with more mortal and less understanding stakeholders than Gaudí.
Project management processes are designed to address this. And the first stage is to properly map out what you want to do by identifying the project’s scope. We’re not suggesting we project manage a wonder of the world, but we can all learn from the Egyptians in terms of the value of scoping a project before we get started.
In all the excitement of starting out on a new project, it can be tempting just to jump headfirst into working on some key project tasks. But if we fail to spend the time defining the project properly, looking at the different options, thinking about the project’s risks and doing the all-important preparatory work, we’re setting ourselves up to fail.
Scoping a project pre-empts and flags potential pitfalls. It’s the best way to ensure a project runs on budget and meets its deadline, avoiding any 'why didn't we see that coming?' moments. Think of it like checking out a car journey on Google Maps before we set off. It helps us to avoid traffic jams and closed roads, and find the best route to our destination.
Scoping also empowers project teams to work as efficiently and effectively as possible so they’re not doing unnecessary work or wondering what they should be doing next.
If a project is a building, we might think of the process of scoping as building the foundations. It’s designed to capture key information and determine objectives alongside key deliverables while avoiding pitfalls. Taking the time to map and scope a project carefully is the first crucial step towards project success.
There are three core ingredients and variables of managing a project that we need to juggle: quality, time and cost. Because they are interlinked – any change made to one will impact on the others – they are often known as the project or iron triangle.
Imagine, for example, that we’re running a project to develop a piece of software. If we want to change one of the variables, say, improve its functionality (quality), this will have a knock-on effect on at least one of the others: it will either take more time or cost more (or both).
Or, if we need to deliver more quickly, then we can either compromise functionality or we’re going to need more resource. It’s not surprising that the variables are also sometimes known as the triple constraints.
We need to know which of these variables is most important to our stakeholders (the people involved or affected by the project) at the outset so that we can plan for how these factors are defined and agreed and will be measured up front as part of our scoping.
Keeping them in mind will also help if we need to adjust parameters or outcomes once the project is underway. They can help us to manage competing pressures and make any trade-offs we might need to make down the line.
Nailing our scope down helps prevent the curse of project management: scope creep.
Guaranteed to chill the blood of all project managers, scope creep is one of the main reasons many big projects fail. It occurs when, almost imperceptibly, little tasks are added to the scope of the project, or changes are made. Eventually, neither the original timeframe nor budget will be achievable.
Scope creep has many causes. Sometimes stakeholders want the project to do more than they initially predicted and start adding in last-minute requests. As leaders, we need to be acutely aware of this. During scoping it’s essential to be clear about objectives. Adding details and making changes later on in the project will add time and money to a task, causing problems in that project triangle.
Other times stakeholders aren’t consulted early enough in the process, leading to major and expensive redesigns on completed sections of the project. The failure of Denver International Airport’s automated baggage-handling system is a textbook example of this. The plan was ambitious and laudable: reduce aircraft turnaround time and bring together three terminals with a fully-automated system serving all airlines.
By the project end, the project had overrun by 16 months, had exceeded its budget by $560m and could only serve one airline, at one concourse, for outbound flights only. It transpired that the major airline stakeholders had not been consulted early enough in the planning. When they were asked for their opinions, they required major changes, resulting in hugely expensive redesigns and severe delays.
Gold-plating is another cause, which is what happens when someone on the team starts over-delivering, which can threaten to take the project over budget. We can spot early warning signs, as soon as colleagues start asking things such as "can we just...".
In a paper for the PMI American academics Richard and Elizabeth Larson, identified five top causes of scope creep and suggested what we can do to avoid them.
Ambiguous scope definition: use a work breakdown structure (WBS, of which more below) to define a detailed scope.
Lack of any formal scope: formally communicate and review to get all requirements approved.
Inconsistent process: develop a clear scope with key stakeholders and requirements.
Lack of sponsorship and stakeholder involvement: engage stakeholders and demonstrate how deliverables are happening.
Project length: keep projects short, focused and divided into smaller sub-projects.
We’d be well advised to take their advice as we tackle the process of project scoping.
Armed with these key principles – and forewarned about the pitfalls – we can embark on the scoping process.
The first stage is to test our assumptions about the project and its viability. This means determining clearly the problem the project will look to solve or fix. That might not be obvious and it can take time to get to the root cause of any problems. Two tools can help with this analysis:
You might use a SWOT analysis to weigh up the strengths and weaknesses of the proposed project and assess the opportunities it might bring and the threats it could face.
A PESTLE analysis will help us to explore or anticipate external influences that impact on a project’s potential and success.
We might also conduct a project pre-mortem, a pre-planning method that asks us to that asks us to imagine a worst-case scenario and work back from that to identify the reasons why things have gone so badly wrong. A pre-mortem can help us to identify blind spots and risks we might not otherwise have considered, and helps us to challenge our assumptions in a straightforward, structured way.
Stakeholders are so-called because they have a ‘stake’ in a project’s outcomes. They could be senior leaders who will want to make sure projects are delivered as planned; they may be customers for a new product or service; they may be members of our wider community who will be affected by a new building.
Projects might also have a sponsor, the person commissioning, championing and shaping the project. That could be us, as the project leader, accountable for its success, or it could be a third party. Sponsors might also be the key project manager, or the two roles may be separate.
Whoever they are, we need to identify stakeholders and sponsors up front, how crucial they are to project success, if and when we’ll need to involve them and how we’ll communicate with them as the project progresses. Early buy-in from the most important stakeholders is important.
A lack of stakeholder involvement was ranked the top reason for project failure, according to 2020 research into US software project failures from Standish Group.
Once we’re sure of the project and clear about our stakeholders, we need to consider a critical document called a Scope of Work (sometimes called a Statement of Work).
A Scope of Work plan outlines the details of a project, essentially an ‘agreement’ on the work that lies ahead. There is no fixed template for what needs to be included, and it will vary according to the size and complexity of the project involved. It needs to walk the tightrope between adding enough detail to make the plan clear and adding so much detail that writing the Scope of Work becomes an overwhelming project all by itself.
At a bare minimum, it should include information on the overall goal and objectives, key deliverables, a timeline and milestones, and key stakeholders. It might also help to define the project (by being clear about what the project will not cover), outline the business case for it or highlight any external factors that might be crucial (such as hiring in people with specialist skills).
For example, if we are planning to conduct some market research to test ideas for a new product launch, the Scope of Work might include the following:
Goal/objectives: to assess the viability of 'new product X', briefing a market research agency to research and report on viability and potential.
Deliverables: shortlist agencies; appoint an agency; write the brief; approve brief with internal stakeholders; confirm the brief; set deadlines for research and final presentation.
List timeline: 1 January – shortlist research agencies; 20 January – appoint agency; 1 February – write brief; 20 February – confirm brief; 20 March – conduct research; 1 April – agency presents findings.
Milestones: appoint research agency; agree on research questions; conduct consumer research; research presentation.
Stakeholders/reporting: check the status of research brief approval; stay in touch with research agency for progress; check agency to confirm agreed deadlines.
We might also take into account some more qualitative factors. For example:
Why does this project matter?
What difference will it make?
In what ways does it matter differently to different people?
What preconceptions or assumptions exist?
How will we know when we’ve done a brilliant job? (What are our key performance indicators?)
How do we want people to feel about the outcomes?
To help create a project scope document, use our editable template and work through the guidance and sections.
The Scope of Work should define the goal and objectives. The two are often used interchangeably, and are generally used in tandem, but they’re not the same. The goal is what’s wanted, the objective answers how it’s achieved. One answers the question: “What do we want?”, the other, the question “How will we do it?”.
The massively ambitious goal identified by American president, John F Kennedy when he prefigured NASA’s Apollo programme is a good example. In his famous address before Congress in 1961, JFK proposed that the US “should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to the earth”. The goal? Put a man on the moon. The objective? Achieve this by the end of the decade and return him safely to earth.
When setting goals, a popular approach is to use the SMART model, which helps to make goals clear and specific by meeting the criteria set by each letter of the acronym:
Specific: what exactly is the project going to achieve? Be clear and unambiguous.
Measurable: how will we know if we’ve succeeded? What metrics will we use?
Achievable: is the project realistic? The right level of challenge is motivating, but let’s not set ourselves up to fail.
Relevant: what is the project’s purpose, its benefits? How will it contribute to wider goals and objectives?
Time-bound: how long should the project take? Don’t leave things open-ended.
For more complex projects, identifying the phases and deliverables of a project can be more difficult. Using a work breakdown structure (WBS) can help us to encapsulate and communicate project scope by breaking the project down into its component parts.
A WBS looks at the entire work of the project and breaks it down into chunks. These chunks are then broken down further and further into their most manageable units until we arrive at a series of clear, understandable tasks that can more easily be allocated and managed.
These large chunks and smaller chunks allow for numbering and sub-numbering so providing a comprehensive list of every activity that needs to be done — the scope of the project. Armed with this, estimates can be made as to how many people are needed to complete a project, as well as how long the project will take.
Creating a WBS involves three steps:
Visually showing projects through a WBS can aid understanding among different stakeholders and also help a project manager quickly see what is required. There are many different ways of creating and showing a WBS, but they all end up looking something like this:
The devil really is in the detail. The most important tip for a well-written Scope of Work is to make sure it’s as specific as possible. Everyone involved needs to have a common understanding of what’s expected of them, who’s doing what and when, and what things mean. Being specific avoids ambiguity and reduces the likelihood of misinterpretations, confusion and potential dispute down the line – not to mention costly reworking.
We can all learn from the Death Star, the Empire’s ultimate weapon in the Star Wars franchise, a moon-sized space station with the ability to destroy a planet. But its project managers and stakeholders were so focused on building a world-breaking weapon that they forgot to mitigate against risks such as an attack by a small spaceship on a tiny exhaust vent no bigger than a womp rat. An effective scoping process would have prevented this by outlining potential risks and challenges, as well as considering how unforeseen circumstances might be dealt with.
Back to those Giza Pyramids. The project had an achievable objective (build another pyramid), in a clearly defined timeline (around 20 years before Pharaoh Khufu died), an engaged and motivated stakeholder (the Khufu himself) and a highly knowledgeable team (a nation with over 200 years of experience of building pyramids).
Moreover, the precision and efficiency of the construction project make it clear that there was no margin for error – implying a detailed Scope of Work. If the base was off by a few centimetres and not perfectly level, the pyramid would be off by metres at the top. Quality planning at the outset avoided costly mistakes later on. To put this in perspective, the entire 13.1-acre site isn’t a centimetre out of place, comparable to accuracy only achieved today with laser-levelling technologies.
So, plan like an Egyptian — there’s no better historical proof of the power of planning.
Identify the three core project management variables of the iron triangle.
Explain how a pre-mortem can help us to test our project ideas.
Outline the purpose of a work breakdown structure (WBS).
Use our project scoping template to plan for an upcoming project.