Robust Project Definition: How to Build it and the Components you Need

Project Definition is not just the first substantial stage of your project. It is also the foundation upon which you will build your whole project.

The rewards for getting your Project Definition right are matched only by the penalties of getting it wrong.

So it’s time we took on defining your project with one of our giant guides.

Rewards for getting your #Project Definition right are matched by penalties of getting it wrong

Tweet

What You Will Learn in this Article

This article will give you comprehensive coverage of how to build a Project Definition and include all of the essential elements. We’ll look at the 10 most important elements and other things you may also choose to include.

The sections of this article are:

1. What is a Project Definition? …and How Does it Differ from a Project Brief?
2. The Purpose of the Project Definition Stage of Your Project
3. Creating Clarity in Your Project Definition
4. The Ten Essential Components You’ll Want in Your Project Definition
5. Is this a Comprehensive List?

So, let’s begin at the beginning…

What is a Project Definition?
…and How Does it Differ from a Project Brief?

Interestingly, neither the PMI (in either the 6th or 7th editions of its PMBOK Guide), nor the APM (in either the 6th or 7th editions of its APMBoK), nor PRINCE2 (in Managing Successful Projects with PRINCE2) define the term ‘Project Definition’.

So, I’d better start with my own answer to this question…

In our free glossary ‘Be on the Inside: Decode the Jargon of Project Management‘, I offer this definition:

Project Definition Document: Also known as project terms of reference, outline project initiation document (outline PID), or project brief, a project definition document contains the definition of your project, and therefore sets out the definition of what the anticipated project is (and is not).

Be on the Inside: Decode the Jargon of Project Management – 2nd Edition
Mike Clayton, OnlinePMCourses

This also answers the question: ‘What is the difference between a Project Definition Document and a Project Brief?’ Effectively, nothing. The two terms are used for the same thing by different organizations and different project managers.

That said, of course, each will have its own precise definition of what needs to go into their own Project Definition or Brief. But I am aware of no consistent definitions of either, that can help us draw a meaningful distinction between the two terms.

Project Brief and PRINCE2

In passing, however, I will note that Project Brief is a term used in PRINCE2. Managing Successful Projects with PRINCE2 gives us these two statements:

A project brief is used to provide a full and firm foundation for the initiation of a project and is created in the ‘staring up a project’ process.

A statement that describes the purpose, cost, time and performance requirements, and constraints for a project.It I created before the project begins, during the ‘starting up a project’ process, and is is used during the ‘initiating a project’ process to create the PID and its components. It is superseded by the PID and not maintained.

Managing Successful Projects with PRINCE2
Axelos, 2017
I have added the inverted commas for clarity

What is a Strategic Project Definition?

The term, STrategic Project Definition’ is my own. It extends the idea to a more strategic level and is consistent with the imperative to start a project from the point of view of strategic value to the organization. I explain the idea here:

The Purpose of the Project Definition Stage of Your Project

Before we look at the how, perhaps we should start with the what…

And the why…

Why do you need to define your project at the outset?

The answer to this question is easy. If you don’t know what your project is, you can’t make a well-reasoned decision about whether or not it’s the right project to do. This is as true for Agile projects as it is for more traditional methodologies.

Indeed, it doesn’t matter where you are on the Agile-Traditional scale, or whatever project methodology you choose, from PMBoK^® to PRINCE2^® or from Kanban to Scrum. Wherever you are, you need to know if doing your project will be a wiser decision than not doing it. Or doing a different one.

And, before you make that decision, you need to know what it is your project will be about. That’s your Project Definition.

A Project Definition is all about answering a simple question:

Does this project make good business sense?

To do this, you need to do two things:

1. First, you need to be absolutely clear what your project is, and what it is not
2. And second, you need to create a broad estimate of what it will cost you to deliver it – in terms of cash, resources, and time committed.

It is the balance between these two that will influence your Sponsor’s or Project Board’s decision to approve your project.

What constitutes ‘Good Business Sense’?

There are two principal parts of the answer to this question.

1. Strategic

For starters, your project must align closely to your organization’s mission, vision, and strategy.

Note that this does not mean that the project must be a part of your primary strategy. An important aspect of strategic planning is building-in flexibility. So it’s vital to set up a portfolio of projects moving towards different futures. This will give your organization some resilience against events that may not match the scenario you are basing your main plan on.

But your project does need to fit with organization-wide strategic thinking. If it does not, then it will conflict And that will divert valuable resources and attention from what matters.

2. Tactical

The second component is whether the project looks like it will deliver good value for the money, risk, and effort it needs.

You won’t be able to do this in detail during the Project Definition stage. This is because, for a full budget, you’ll need detailed plans and specifications. These will come in the Project Planning stage. But you should be able to:

• put a broad estimate on the primary benefits
• quantify the major costs, risks, and resource requirement.

So Project Definition will Help You Determine Good Business Sense…

Without it, you can’t understand the strategic contribution your project would make. Nor can you estimate the costs and benefits. In this article, we will focus on the first requirement for establishing ‘good business sense’:

The need to be absolutely clear what your project is, and what it is not

Creating Clarity in Your Project Definition

Being clear what your project is and is not is the purpose of your Project Definition. So, in this extended article, I’ll show you the ten essential components you’ll want in your Project Definition.

Let’s start by listing them. And then we can discuss each one in a little more detail.

If you’re in a hurry, you can click on any of them to go straight to that section.

1. Goal
2. Objectives
3. Scope
4. Exclusions
5. Deliverables, or Products
6. Dependencies and Constraints
7. Risks and Issues
8. Uncertainties and Assumptions
9. Stakeholders
10. Project Team

So, with no further ado…

The Ten Essential Components You’ll Want in Your Project Definition

This template is taken from our free Project Management Fundamentals course. You can take this short video course here, on the website (no sign-up required) or sign-up for an enhanced version.

Goal

This is the over-arching aim of your project. It answers the question:

What do we want?

So your goal describes what your project is in the widest possible terms. It is also your marketing and recruitment statement. Because when anyone asks you what you are doing, the answer you’ll give is your goal. So make your goal valuable to your primary stakeholders (see below) and motivating to the people who will work on the project with you (see below).

You can find out more about project goals in our Video: ‘What is a Project Goal?’

Objectives

After your goal, your objectives are the next most important part of your Project Definition.

They set out the criteria by which you’ll assess how well your project succeeded in the way you delivered your goal. They articulate the factors that matter to your stakeholders. Put another way, they answer the question:

How do we want to achieve our goal?

The three most commonly stated objectives are time, cost, and quality. Together these form the ‘Time-Cost-Quality Triangle’ – which is also known as ‘The Iron Triangle’.

So, you need to consult your stakeholders (see below) on:

• When do you need it?
• How much are you prepared to pay for it?
• What quality standards must it meet?

You have probably heard of the SMART, or SMARTER, or SMARTEST formulations for crafting well-structured objectives. These are the commonest memory aids. Although you’ll find plenty of variants, they most commonly stand for:

Scope

Determining the scope of your project is the hardest part of creating your Project Definition. In fact, I’d say it’s the most difficult part of Project Management*. The scope is all the things you will do within your project, or all the things it will create. We have a short video that will give you more of an answer to the question: ‘What is Project Scope?’

(* This is one of our Essential Project Management Rules)

Why is this so hard?

Because your different stakeholders (see below) will have different ideas about what is vital, important, desirable, or unnecessary.

And pleasing some will mean upsetting others. Unless, that is, you have a limitless budget…

Which you won’t.

So, in the real world, as PT Barnum would have said if he’d been a Project Manager rather than a showman:

You can please all your stakeholders some of the time…

And you can please some of your stakeholders all of the time…

But you can’t please all your stakeholders all of the time*

So scoping is an exercise in negotiation and compromise. Your job is to maximize the the value you can generate with the resources you can secure.

(* This is another of our Essential Project Management Rules)

Project #scoping is an exercise in negotiation and compromise

Tweet

To help you navigate the challenging waters of project scoping, check out our videos and feature articles:

• How to Define Project Scope
• Establish Project Scope: How to Master Your Toughest PM Challenge
• Getting a Clear Scope for Your Project: A Conversation with Joseph Garfield | Video
• Scope Management Plan: Everything You Need to Know
• How to Prevent Scope Creep | Video
  

Exclusions

For everything you decide you can and should do within your project budget (your scope – see above), there will be a load of things can’t or shouldn’t do.

The problem is that some stakeholders will assume from your project goal (see above) that these are a part of your project. So, if they find out they aren’t, they’ll be disappointed. More worrying, they’ll ask you to add them in, with the three words a project manager most fears:

Could you just…?

So, to avoid the dreaded specter of ‘scope creep’ you need to have a strong answer. The best is to have a signed-off project definition. And in it, you’ll need a list of Project Exclusions. These are potential items of scope, which you have explicitly excluded. These are the things you could do… but you won’t.

The three words a #Project Manager most fears: ‘Could you just…?’

Tweet

Deliverables, or Products

In the US, your Scope (see above) will be articulated in terms of the things your project will produce. These are your Products or Deliverables.

In many other places, like the UK, scope refers to the scope of work. There, Project Managers articulate scope in terms of the tasks, or activities, that produce the deliverables.

Both approaches are fine. If you do articulate your scope in terms of products, then you’ll still need to create a task list when you start planning. If your scope statement reflects tasks and activities, your project definition will need to include the things you’ll produce.

When you get to planning in detail, you’ll break these down into fine detail. But in the Project Definition Stage, your main deliverables will usually be enough.

Dependencies and Constraints

When you want to define your project fully, you will need to consider some of the context within which it sits.

So your next consideration will be dependencies and constraints.

Dependencies

Dependencies are external factors that will interact with your project, affecting its progress, timing, resource selection and utilization, and technical capabilities. And dependencies work in both ways. So they are therefore sometimes referred to as inter-dependencies. This means that:

• Not only can outside factors like:
  • the wider organization,
  • other projects,
  • competitors,
  • suppliers, and
  • regulation

affect your project, but

• Your Project can impact other parts of your organization, or other projects, for example.

Constraints

Constraints are factors that will constrain, or limit, the choices you will be able to make. Typical examples are:

• regulation and legislation
• standards
• policies and procedures
• resource availability
• externally imposed deadlines

For more detail about Dependencies and Constraints:

• What are External Dependencies in your Project? | Video
• and What are Task Dependencies in Project Management? | Video
• What are Project Constraints? | Video
• Are You Making Proper Use of Dependencies and Constraints?

Risks and Issues

There is no such thing as a project, without risk.

Risk arises from uncertainty, complexity, pressure, and novelty. And projects have all of these. If Tim Lister is right, and I believe he is, then:

Risk Management is how grown-ups manage projects

If you are going to manage your project in an adult way, you have to start as you mean to go on, with a thorough assessment of the risks. Remember, the reason for the Project definition stage is to inform robust decision-making. And any go/no-go decision must be informed by a realistic assessment of the risks.

Issues are like risks. Risks have an uncertainty to them. They or may not happen. Issues will happen – or have happened already. So you need to deal with them during the project definition stage, or see the case for your project undermined from Day 1.

Uncertainties and Assumptions

Uncertainties and assumptions are close cousins of risk.

• I am uncertain about how much budget we are likely to secure
• He assumes we will secure sufficient funding
• She thinks there is a risk that we won’t secure enough budget

They are three ways of explaining the same underlying insight. But, often, some things are most easily uncovered through one mode of thinking.

Why do you need to consider Assumptions and Uncertainties as part of your Project Definition?

This is simply because the unknowns define the fuzzy boundaries around your project. Without identifying them, our rational decision will be compromised, because they lead to risk.

Stakeholders

If risk management is how adults manage projects, then sophisticated adults manage them through careful stakeholder engagement. Your stakeholders will determine the success or not of your project*. So, defining your stakeholder group, and their respective concerns, is effectively defining your project.

At this stage of your project, I’d suggest you follow four steps:

1. Identify as many stakeholders as you can think of
   Remember: a stakeholder is anyone who has any connection to your project.
2. Prioritize your stakeholders into primary and ‘other’
   Your primary stakeholders are those who can properly help you set and confirm the goal, objectives and scope of your project.
3. Assess the priorities of your primary stakeholders.
   And then plan how you will start to engage with them.
4. Engage your primary stakeholders.
   Your aim is to reach an agreed Project Definition.

(* This is another of our Essential Project Management Rules)

Project Team

The last of our components of your Project Definition is the team you’ll deploy to deliver it. At this stage, you aren’t recruiting. But you do need to think about the range and depth of skills, expertise, and experience you will need. This will inform your set up of the project.

Governance

I’d include in this, some early thoughts about the kind of governance arrangements that will be appropriate. This will need to take account of the level of risk  (see above), the scale of the project, and the importance of the goal  (see above).

Is this a Comprehensive List?

Is this an absolutely comprehensive list of things to consider in your Project Definition?

No…

But it’s a very good start… And certainly more comprehensive than many I’ve seen applied. More to the point, there is a lot more information to learn about the process of creating each of these components. That’s why we have built our most innovative program to date.

The Project Manager’s Project Definition Toolkit is:

• half Project Management Training Course to learn it as you do it
• half Project Management toolkit to do it as you learn it

It combines:

• regular emails
• real-world exercises
• videos
• templates
• checklists
• articles

Together these allow you learn and do at the same time – or to simply learn how to Define your Project, and put the tools aside for when you need them.

Learn More about this innovative program here.

Other Things to Consider

Here are some other things to consider. They are less often a part of a Project Definition. However, they may be important to you.

What it’s for? Your Purpose

Why will you be doing your project? Unless you know the context and what it is wanted for, you will find it hard to make robust choices when you encounter problems. And, of course, we all find it hard to motivate ourselves when we don’t know what we are doing something for. We are just children at heart and desperately want to know ‘why?’ So be sure to set out the purpose as part of your project brief.

This is essential to a Strategic Project Definition. Typically it will need to address two things:

1. Business Drivers: What is compelling you to undertake this Project?
2. Business Benefit: What will you get, once you have completed this Project?

Together, these contribute to the wider concept of Project Value.

What are the Design Criteria? Your Specifications

Once you know what you will deliver: how do you want it? Define a specification for each deliverable, so that you know what ‘done’ will look like.

What will be the Acceptance Criteria? Your Quality Standards

When you produce a deliverable, how will your customer, boss, or client know whether to accept it? It must meet pre-agreed standards. Determine these and document them in your project brief. There is a simple rule: ‘no standards: no acceptance’. Then create a quality assurance and quality control regime to ensure you only deliver products that meet the standards you have set.

What will You use to get Your Project Done? Your Resources

Any project brief must set out what resources (people, materials, assets) you will need, and what limitations you are under when drawing them down. When you calculate the cost of these, you will be able to build your project budget.

Although a full budget is rarely an essential part of your Project Definition (it’s too early for that), you will need to give an estimate of the resources you require. And therefore, you will be able to give an indicative budget.

…and, the all important… Sign-off

Everything we have discussed is important, but it comes to nothing unless your client, customer, boss, or sponsor formally signs off your project definition. Only when this happens can you safely proceed, knowing that any changes can be handled in a controlled way.

Please Share Your Thoughts on Project Definition

Please do add your thoughts on crafting a great project definition, in the comments below. And, as always, I will respond to every comment.