Are You Making Proper Use of Dependencies and Constraints?

Project constraints and dependencies are two important, but much-misunderstood concepts in project management. Not only do they get confused with one another, but the term dependency has two distinct uses. And then, there are also interdependencies.

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:

• Constraint
• Interdependency
• External Dependency
• Task Dependency

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.

RAID, CAD, and DCARI

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 DCARI. So, what do these mean?

Assumptions, Risks, and Issues

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.

Uncertainties, Assumptions, and Risks

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’

Issues

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.

Constraints

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:

1. Project Constraints – Those which are internal to the project
2. Organizational Constraints – Which come from within your organization (but outside of your immediate project
3. External Constraints – That arise outside of the sponsoring organization or organizations

The PMI’s Project Management Body of Knowledge, the PMBOK Guide, labels the second and third of these as: ‘Enterprise Environmental Factors’, or EEFs. In giving examples, it then splits them back out into ‘EEFs internal to the Organization’ and ‘EEFs external to the Organization’.

Project Constraints: The Triple Constraint

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

• Time constraints – fitting with an external schedule, like:
  • announcements
  • product launches or withdrawals
  • implementation of legislation or regulation
• Resource constraints – limitations on the availability of:
  • people
  • materials and supplies
  • equipment, plant, machinery
  • venues, warehousing, factory capacity
  • logistics and supply chain
• Budgetary constraints – tied to:
  • cash flow
  • cash availability
  • release of funds
  • debt repayment
• Quality constraints – that arise from:
  • Voice of the Customer
  • external standards and legislation
  • brand requirements and reputational considerations
• Scope constraints – which are driven by:
  • functional requirements
  • client specification

Organizational Constraints

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).

• Shared Goals: The mission, vision, values, and over-arching goals of the organization.
• Strategy: this will be reflected in the portfolio of projects and programs the organization commissions, to take it forward in the direction of its vision and goals.
• Style: If they’d not been after an alliterative mnemonic, they’d have called this ‘culture’. How people work and the informal and political structures that support it.
• Structure: these are the formal elements of how the organization organizes itself. They include divisional, departmental, and functional structures; geography and regional organization; and vitally, governance.
• Systems: this includes infrastructure and assets, processes and procedures. IT equipment and software also fit in here.
• Staff: the people available, how you can access them, and the terms of their contracts. This may include the way the organization sources external staffing support from contractors and consultants.
• Skills: this is about the expertise, capabilities and competence levels of the staff available to you.

External Constraints

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.

• Social forces – what is going on in your community and wider society?
• Political pressures – macro and local politics – the preferences and requirements of your external stakeholders and the way they influence yu, your colleagues, and one another.
• Economic forces – the economy can affect many things that will have an impact on your project. These include:
  • trading environment
  • inflation rates
  • currency and foreign exchange fluctuations
  • borrowing rates
  • market returns on investments
  • foreign and domestic tariffs
  • tax rates – corporation taxes and sales taxes
• Commercial pressures – or competitive forces, arising from existing and new competitors, and new market trends.
• Technological shifts – these impose both opportunities and constraints.
• Regulatory requirements – regulation, legislation, and industry standards can affect the quality and certification processes for the deliverables of your project.
• Environmental pressures – while views differ, you will need to conform to minimum environmental standards but will often choose to take a more assertive stance. And let’s not forget that the environment has a way of fighting back with weather and geological events.
• Security concerns – data protection and data security are now as big a concern as physical safety and security.

Working with Project Constraints

As you move through the project lifecycle, you need to make effective use of your project constraints.

Constraints at Project Definition

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’.

The Impact of Constraints on Project Strategy and Tailoring

Once you understand your constraints, they will inform your decision on your project strategy, or approach. For example, will you:

• Buy in services or work with in-house resources?
• Prefer to design and build your own components, or use commercial, off-the-shelf (COTS) products?
• Use a highly staged process, or aim for fewer, bigger, product releases?
• Adot a traditional, planned approach, or prefer some for of Agile methodology

And once you’ve determined the over-arching project strategy, you need to determine:

• what project stages you’ll need
• how to specify your project control process
• what methods to apply
• which tools to use
• what team structure you prefer
• …and a host of other things

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

Project Constraints and Your Plan

Clearly your project plan will take into account the constraints you face. They will impact things like:

• Resourcing
• Scheduling
• Spending choices

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:

• nature of your organization (private or public) and its culture
• scale and complexity of your project
• profile, importance, and sensitivity of your project

Project Constraints in Your Work Packages

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:

1. their implications for the Work Package
2. Appropriate work-arounds and resolutions

Interdependencies

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:

• Permanent parts – functions and departments
• Temporary parts – other projects, programs, or initiatives

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 program.

External Dependencies

External dependencies are external events or decisions, that can impact the timings or choices within your project.

Let’s compare dependencies, interdependencies, and constraints:

Comparison of 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:

• Product launch
• Announcements
• Annual budget cycle
• Health & Safety inspections
• Audit cycles or internal audits
• Busy periods – trading, regulatory, service users

But they can also link to things that happen outside your organization, such as:

• Competitor actions
• Regulatory and legislative timetables
• Community events
• Fixed events in the calendar
• Partner or supplier actions
• Delivery times
• Transaction processing times

The Impact of External Dependencies on Your Project

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.

Step 1: Identify and Characterize Your Dependencies

At the definition stage of your project, you need to inventory all of your external dependencies. Where possible, note the key dates.

Step 2: Plan Around Your Dependencies

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.

Step 3: Monitor Your External Dependencies

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.

Task Dependencies

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.

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.

Predecessors and Successors

In our examples, Task A is the ‘predecessor’ of Task B. At the same time, Task B is the successor’ of Task A.

Lags and Leads

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 and Discretionary Dependencies

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.

Do You Have Any Questions or Comments about Project Constraints and Dependencies?

If you do, please leave them in the comments section below, and I will respond to every contribution.