Project c
So we need to understand these terms. And, more important, we also need to see how you can make proper use of them in your project definition and planning.
In this article, we’ll examine the use of the terms:
And, for each one, we’ll discuss how to put it to work in the definition or planning stage of your project. So, get set for some valuable and actionable advice on project constraints and dependencies.
Let’s start with an introductory video. In defining your project, constraints and dependencies are two among a range of useful concepts. And Project Managers have come up with a number of acronyms to help remember them. Common acronyms include RAID, CAD, and
In this article, we shan’t be talking about assumptions, risks, and issues. But we will take a moment to be clear what they are, and where you can learn more about them.
Our project team is uncertain about something that may or may not be true, or might or might not happen. So, we make an assumption that allows us to proceed by making a plan or a decision on a reasonable basis. But there is a risk that our assumption is incorrect.
Uncertainty, assumptions, and risks are closely related to ne another. Indeed:
‘A risk is uncertainty that can affect the outcome’
There is no uncertainty about an issue. Unlike a risk, an issue is present: it is something that has happened or will definitely happen.
In our free guide to Project Management jargon, ‘Be on the Inside: Decode the Jargon of Project Management’, we define an issue as:
A problem the project faces: an issue is technically a risk with 100% likelihood – that is, one that is certain to occur.
Be on the Inside: Decode the Jargon of Project Management
We need to manage issues actively. Therefore, we answer the question What is Issue Management? in a short video. But, for the full details, we have written a comprehensive article: Issue Management: All You Need to Know about PMBoK’s Missing Process.
A constraint limits your choices – it constrains your options. In our ‘Decode the Jargon’ glossary, we describe them as: ‘Limitations on what you can do’. This is wholly consistent with the Project Management Institute (PMI) Definition:
Constraint: A limiting factor that affects the execution of a project, program, portfolio, or process.
PMI Project Management Body of Knowledge, 6th Edition: Glossary
The easiest framework is to think of constraints as falling into three groups:
The PMI’s Project Management Body of Knowledge, the PMBOK Guide,
The constraints that are built into your project will obviously have arisen outside. But they get pretty-much baked in and determine the choices you’ll need to make. These are the triple constraint of Time, Cost, and Quality; also known as the ‘Iron Triangle’ or the ‘Triangle of Balance’.
In the US, the Iron Triangle is most often articulated as Time, Cost, and Scope. But my experience is that scope is most often the constraint that project managers allow to shift. This is either a deferral or even, sometimes, a scope reduction.
When we apply these constraints pragmatically, we encounter
A good way to get a handle on the organizational constraints your project may need to deal with is the McKinsey 7S Model. You’ll find it in the book, ‘In Search of Excellence’ (US|UK).
Since we have used one model from the world of business strategy, how about another? To help me think of external constraints, I like my own enhancement of the widely-used PESTLE model: SPECTRES.
As you move through the project lifecycle, you need to make effective use of your project constraints.
Everything starts at the Project Definition stage. And constraints are one of the important definitional elements of your project. So, you need to identify and characterize your constraints as part of your project definition.
For free content on creating your Project Definition, take a look at our article: How to Build a Robust Project Definition [The Key Components]. But if you need to get it right, we recommend our innovative course/toolkit, ‘The Project Manager’s Project Definition Kit’.
Once you understand your constraints, they will inform your decision on your project strategy, or approach. For example, will you:
And once you’ve determined the over-arching project strategy, you need to determine:
This is what the PMBOK Guide refers to as ‘Tailoring’:
Tailoring: Determining the appropriate combination of processes, inputs, tools, techniques, outputs, and lifecycle phases to manage a project.
PMI Project Management Body of Knowledge, 6th Edition: Glossary
Clearly your project plan will take into account the constraints you face. They will impact things like:
But you also need to document and explain the project constraints within you planning documents. If you fail to do so, you lose the chain of reasoning for some of the key decisions that your plan will embed. And that means losing the audit trail – which would be poor governance. However, the significance of this is clearly related to the:
I’d also suggest that you need to document relevant constraints within any Work Package Definition (WPD). The Work Package Manager or team leader to whom you assign it needs to fully understand the constraints under which they must work. I’d recommend you devote part of your briefing to discussing the constraints and working through both:
This is something of an ambiguous term. It is sometimes applied to the connections between various parts of your project. To the extent that the PMBOK Guide discusses the term (minimal), this is how it uses the word. I think a better term for that would be ‘intra-dependencies’. But the truth is, it isn’t a concept that has anything in the way of tools and techniques, so we don’t pay it much mind.
It is also sometimes used in the way that I will use the term ‘External Dependencies’.
But, most usually, ‘interdependency’ refers to interactions between your project and other permanent or temporary parts of your organization:
Interdependencies add complexity, which is an issue you need to manage. And your primary means f managing them is simple: communication. But, as you’ll know, simple does not mean easy. Interdependencies add an extra layer of work and complexity onto your stakeholder engagement
External dependencies are external events or decisions, that can impact the timings or choices within your project.
Let’s compare dependencies, interdependencies, and constraints:
Dependency | When what happens can affect your project |
Interdependency | When other entities can affect your project |
Constraint | When the way things are can affect your project |
Usually, dependencies relate to other things going on inside your organization. Some examples:
But they can also link to things that happen outside your organization, such as:
Having a lot of external dependencies creates additional risk to the project. So your ideal response should be to try to decouple your project, as far as possible, from external events. Here are the three steps I always take with respect to external dependencies.
At the definition stage of your project, you need to inventory all of your external dependencies. Where possible, note the key dates.
In the planning stage, start by looking for ways to break dependencies. The usual way to do this is to make choices that are no longer dependent on the external event or decision. That is, whichever way it goes, your choice will not change.
Then, build your plan – and your schedule in particular – around the external dependency events. I will always get these onto my timeline before doing anything else. This way, it is as easy as possible to be aware of the key dates for them, and build my plan around them.
I would hope that this goes without saying. But that doesn’t mean I won’t say it. Keep an eye on each dependency. Make it easy, by building reviews into your weekly routine. Once each event happens, quickly assess whether there are any implications for your project, your plans, or for decisions you need to make.
In our free glossary, ‘Decode the Jargon of Project Management’, we define task dependencies in this way:
‘Some tasks can get done at any time and are independent of other activities. Others are linked to events like the start or completion of other tasks. These linkages are called dependencies.’
Be on the Inside: Decode the Jargon of Project Management
They are logical relationships between activities. Curiously, PMBOK Guide does not define dependencies, but defines:
‘Logical relationship: A dependency between two activities, or between an activity and a milestone.’
PMI Project Management Body of Knowledge, 6th Edition: Glossary
So, dependencies are relationships that define the order in which you need to carry out project tasks. We say that ‘Task B is dependent on Task A if the start or finish date of Task A must be reached before Task B can be either started or finished. This gives rise to the four types of logical task dependency.
Finish to Start | Task A must finish before Task B can start | This is by far the commonest form of dependency. Many methodologies prefer to use this form and only this form of dependency. |
Start to Start | Task A must start before Task B can start | If the time gap is precisely zero, this is like a race! |
Finish to Finish | Task A must finish before Task B can finish | If the time gap is precisely zero, this is how a dish is served in a meal – with all the food ready together |
Start to Finish | Task A must start before Task B can finish | This is rare. It deprecated by most project managers and methodologies (I can’t cite an exception). The PMBOK Guide gives the only example I find plausible: You can’t shut down a legacy system until its replacement is tested and live. |
In our examples, Task A is the ‘predecessor’ of Task B. At the same time, Task B is the successor’ of Task A.
If a standard Finish to Start dependency requires that Task A completes and then Task B can start, what if there is a gap in time? That gap is called a ‘lag’. So, if task B starts 2 days after Task A is complete, this is a ‘Finish to Start dependency, with a 2 day Lag’.
Likewise, if task B starts 2 days before Task A is complete, this is a ‘Finish to Start dependency, with a 2 day Lead’.
Note that the Association for Project Management‘s Body of Knowledge, the APMBoK 7th Edition (which we recently reviewed) states that lags and leads are bad practice.
Mandatory task dependencies are logically necessary. The timing of one task is linked to that of another because of legal, technical, or contractual reasons. Breaking the link will necessarily cause problems.
On the other hand, discretionary task dependencies are those that we create for convenience. Maybe because of the availability of resources or the use of funding. Often they arise because of either custom and practice within your organization, your own preferences through experience, of what you consider to be best or good practice.
One way to think of discretionary and mandatory dependencies is that:
Breaking a discretionary dependency may expose you to
a risk .
Breaking a mandatory dependency will expose you to an issue.
If you do, please leave them in the comments section below, and I will respond to every contribution.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Session expired
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.