Dependencies are generally activities or tasks within or outside the scope of a project that are required or must be completed to enable it to progress. They can be linked to factors associated with people, processes or technology and their interaction. Dependencies can become potential disrupters if not identified, tracked, monitored, and managed.
This blog explores the different types of dependencies and their potential impacts on traditional “waterfall” projects driven by the requirement of a key output within the constraints of the quality triangle of time, cost, and scope.
Approaches for identifying and anticipating them are considered, as well as the management tools that can be used to control their outcome. Dependencies have many attributes that determine the best management strategy to use. You may also need several different strategies within a single project to help reduce or mitigate variability and increase the predictability of success.
Definition of a dependency
There is a lot of debate on the difference between a dependency and an assumption, but we have settled on the following definitions. We have included the definitions of risks, issues and change to add further clarity:
- Assumptions are part of the natural flow of the project and are often referred to as prerequisites. These are defined as stable items that are known to be true. Key project prerequisites and assumptions should be recorded as they are the foundations of your project. They should also be continually validated throughout your project life cycle in case these facts change or become subject to change.
- Dependencies are project tasks that can ‘stop the clock’ on progress if not completed or delivered on or before the planned date. In simple terms, two high-level types can become potential disruptors for your project:
- Internal Critical Path tasks are always dependencies. Where there is a complex multi-stranded plan with multiple workstreams, secondary critical path items may also be identified.
- External dependency tasks need not be on the Critical Path. These are typically outside the scope of the project and its governance controls.
- Risks are often tied to dependencies, as these capture the underlying potential cause of a delay or failure for a project. Risk Management is often considered a major tenant for good project management. Still, usually, the mitigation steps only treat the symptoms that have been identified and, on their own, will not guarantee task completion. Hence, the importance of maintaining focus on the top-down tasks and dependencies themselves in case additional risks or constraints are identified.
- Issues are usually generated by incomplete tasks and failed dependencies, or the risks associated with that task not being effectively mitigated. This leads to an activity not being completed to schedule or to the correct quality. Additional actions will be required to remediate the issue to remove any blockages so the task can be completed. The impact of this delay on the schedule, scope, cost or quality will also require an assessment to determine if the overall project needs a re-baseline (a formal change) to enable the original objectives to be met.
- Changes to a waterfall project will always need adequate impact assessment before approval. Whatever the item is may lead to modifications to the tasks required to complete the project, which can impact people, processes, and technology. Any change can impact the project RAID (Risk, Assumption, Issue, Dependency) Log/Register. If the project's critical path is changed, new or revised dependencies in the plan will need to be identified and managed.
Each dependency identified for management will typically have four Attributes that will determine the management strategy that you will want to use:
Classification
- Intra-project – both tasks are within the same project (prerequisites for a critical path task or a critical path task required for non-critical path task)
- e.g., Task A cannot start before Task B completes
- Inter-project – the tasks are from different projects
- e.g., Task A in Project 1 cannot complete until one week after Task C in Project 2 completes
- Contractual – there is a contractual agreement that one partner must provide something for the other partner to complete their tasks (3rd Party or Business Owner)
- e.g., the Client will provide detailed documentation about the existing platform
- External –usually a hard dependency on something outside of the project that is needed to proceed
- e.g., Government guidance, resource availability etc.
- e.g., the project is implementing new legislation which is still in draft. Assumptions may have been made that the final version would have been published, but until the final version is issued the plan cannot be finalised (this is an example of an Assumption becoming a Dependency)
- Business Owner – funding and vision, which includes objectives/expected outcomes
- e.g., the Sponsor will provide an updated Vision document before mobilisation commences so that the scoping, planning, and budgeting considerations have not changed
Direction
- Inbound – The project is dependent on something else
- Outbound – Something else is dependent on the project
Relationship
- Finish to Start – Task B can’t start until Task A completes
- Start to Start – Task B can’t start until Task A starts
- Start to Finish – Task B can’t complete until Task A Starts
- Finish to Finish – Task B can’t complete until Task A completes
Lead or Lag
- Lead – The predecessor task is due to be completed in advance of the successor task by defined period of time. This is often referred to as “slack” or “schedule contingency” that keeps a predecessor task off the critical path
- Lag – This usually is the identification of a task start or end date being in overlap between two activities. Caution may be required here to determine if any lag is a hard or soft dependency, and what happens if the time is exceeded. This could also hit the critical path and lead to delay if not managed, but could also be “slack” or “schedule contingency” for that task.
When can you identify a dependency?
Figure 1. Project Lifecycle
Dependencies can be identified at any stage in the project, but it goes without saying that the sooner they are identified, the easier they will be to manage. At each stage, along with risks and issues, dependencies should be actively sought out, captured, and communicated so that they can be managed appropriately and the associated risks fully understood and accepted by the Sponsor. All dependencies should have a clear date associated with them and an allocated owner from within the project team or stakeholder group who is accountable for them. This is important for any commercial implications should they be missed on a fixed price / fixed duration project. Maintenance of these roles and responsibilities is also an important attribute in building good stakeholder relationships and buy-in and trust between a supplier/partner and their client.
Contract Agreement
Internal projects may not think contractual agreements are relevant to them without external commercial considerations. However, all projects (both internal and external) can suffer from the same dependency problems and result in the same consequences – e.g., delays, additional costs, and failed expectations. It is, therefore, useful to consider agreeing on a contract with the Sponsor, albeit an informal one, with all the internal departmental groups. This can help ensure collective corporate buy-in and commitment to the initiative.
It is essential that where one party needs to provide something for the other party to progress that this is acknowledged and accepted by both parties. For example, the Client may need to provide IT access for the Contractor’s staff before any work can commence, or the Contractor may need to provide resources with specific skills or experience. These should be noted, and the Project Manager should be made aware as soon as possible. The key dependency likely to be actively managed and resolved during this phase is funding allocation.
Make sure that all groups involved understand:
- What the client is to provide, and by when?
- Documented key information, documents, funding, vision, and steering - What is the contractor to provide, and by when?
- Documented key information, documents, funding, vision, and steering - Who is accountable/responsible for what?
- Ensure each dependency has an accountable owner.
- Provide key points of contact and escalation routes should they be required.
- Also, ensure this tie-in with a defined escalation and governance process for dispute handling.
Formally capturing dependencies in a contract agreement is a key step in defining a fixed price/date delivery project. It’s vital to validate the delivery plan, the critical path and any risks around completion and acceptance quality before committing your contract scope, cost, and timeline. Where possible, ensure that loose, unbounded, or optimistic assumptions are captured as dependencies. Similarly, if opportunities exist to clearly exclude items, ensure these are stated so the boundaries of the contract are made clear to both parties. If your organisation has a Commercial or Supply Chain (Procurement) function, ask for their support and assurance before finalising a new contract.
Mobilisation / Initiation
This is where the dependencies captured during the Contract Agreement phase are actively managed for the first time. Additional dependencies may need to be identified at this time, as things may have changed since inception. Therefore, all aspects of the contract agreement should be revalidated for change to determine whether a re-baseline is required before starting. It is best practice at this stage for the Project Manager to assemble a kick-off meeting with all parties involved in the supply chain (including 3rd parties) to ensure alignment and to validate if any changes occurred that now need to be impacted.
Typically, dependencies managed during this stage are most likely practical, such as IT access (although this can be ongoing as new resources are on-boarded) and resource allocation for the next stage. Third-Party dependencies should also be a key consideration at this stage.
Execution
Throughout project execution, additional dependencies will be identified. Where the project is driven through traditional waterfall stage gates, formal project reviews may be required before the beginning of the next phase. For example, dependencies for Development or Test may be identified during Design. Best Practice suggests that a Project manager should look for impacts as early as possible for all the stages ahead, with the next phase being the main priority.
Close
All dependencies should have been closed off by this point in the project. As part of a project closure review or a lesson learned session, some focus should be given to the identified dependencies and issues encountered throughout the project. To help organisational best practice, items likely to be repeated in similar environments or solution deliveries should be captured so that others can learn from the approach taken on the project and the mistakes encountered on the way so that they can be avoided in future.
How do I identify my dependencies?
You will identify dependencies in many ways. What follows are just examples.
- Establishing a Work Breakdown Structure for the Plan
i) Do we understand the triggers and the enabling events that enable a key milestone to be met?
ii) Have the relationships between key activities in the plan been documented?
iii) Has the overlay of any governance and controls needed for decisions approvals to move forward and any allowances for review periods been considered?
iv) Are there any allowances for rework, resubmission and retesting to gain acceptance? - Defining the organisational roles and responsibilities (and capturing this in the contract if possible)
i) Do we understand the roles and responsibilities of each internal or external team or supplier involved in the project eco-system and the (contractual) requirements on them at each phase? - Planning Forums and Project Meetings
i) Are any cross-functional planning activities undertaken to identify any unknown dependencies?
ii) Have you analysed the inter-relationship of tasks, timelines, and resource requirements for critical and non-critical path activities?
iii) Is the project measuring progress against the end goals and objectives for the project? - Sponsors and Product Owners
i) Has clear sponsorship and subject matter expertise/leadership from the business been identified?
ii) Is there a connected governance and communication regime established to manage things inside and outside the project's scope that could impact the delivery? - During each project phase (examples)
iii) The Designer or Developer may identify that there are platform or other technical dependencies.
iv) Specific skills may be required to develop, implement or support the solution.
v) Specific test data or scenarios could be required to prove the solution.
vi) Other projects could be working on the same platform (generating contention for dedicated resources), and it may be necessary for one project to launch before the other one can be deployed.
I have identified my dependencies. Now what do I do?
Document, assess the risk, allocate ownership, determine the priority, and communicate it, then track and manage the dependencies, reassessing risk and priority as required.
- Documenting dependencies
i) Recording the precise details of the dependency and attributes
ii) What is it dependent on: Which deliverable, task or event? - Risk Assessment and Risk Log
i) What is the impact if the dependency isn’t resolved in time?
ii) Establish the level of risk associated
iii) Record possible mitigation options
iv) Manage any interventions agreed upon, ideally managed through any contingency set aside. - Ownership
i) As with risks, every dependency must have an owner
ii) A RACI will help understand and manage ownership of dependencies and the risks associated with them - Prioritisation
i) Understand the strategic position of deliverables in comparison with others.
ii) Is it on the critical path?
iii) Is it imminent or further down the line?
iv) Does it have a high risk associated with it? - Timescale – depending on the type of dependency
i) When is it needed?
ii) When will it be ready?
iii) What will happen if it is not met? Is this tied to a documented risk? - Sphere of control
i) Within the project’s control
ii) Outside the project’s control but within the organisation’s control
iii) Outside the organisation’s control, but with a degree of predictability or certainty e.g. planned legislation, regulatory requirements or statement of current policy or approach
iv) External factors that cannot be predicted, e.g. COVID, Storms, Catastrophes etc. - Stakeholder engagement
i) Provision of additional information from the business
ii) Advise the business of the dependency
iii) Interproject dependencies need regular communication between the projects so that any joint risks can be managed, and the impacts of delays relating to dependencies need to be fully understood by both projects and all parties. - Communication between parties
i) Can be automated and/or manual, and the frequency should be declared until no further dependency. - Status (RAG)
ii) Using the likelihood, impact, proximity and level of control, you must give each dependency a score and RAG these.
iii) Review regularly
Are there any tools, strategies, and methodologies?
If your project or programme expects delivery to be made by a fixed date, fixed budget and potentially fixed scope, having a structured approach to tracking, managing and governing your dependencies will be essential.
The first recommendation for all Project Managers to consider is for them to remember their contract. Make sure to read it and any agreed Change Requests a few times. This document should define the boundaries for your project, confirmed ways of working, how acceptance will work and how exceptions should be handled. Your initial set of dependencies will have come from there, but it will also set the guardrails for how other ones may need to be addressed.
The tools and processes you could use will be influenced heavily by choices others may have already made within the project delivery environment. This could be using enterprise tools like Clarity, Service Now, Plan View, or integrated departmental integration of planning collaboration environments like Microsoft Enterprise Project Management or Atlassian Jira and Confluence. On smaller-scale initiatives or where a company has not been specified, a Project Manager may need to use a bespoke set of templates developed in Microsoft Office – i.e., Excel trackers.
While some tools and processes can simplify the collation of information, communications and reporting, the most important thing is having a defined control mechanism that all parties are bought into using. The most crucial tenant behind good dependency management is the availability of quality and consistent information that covers people, processes, and technology, not actually the tool that you are using.
Reporting, Communications, and Governance forums to provide the needed controls will usually be established within the working environment as part of mobilisation, with dependency management being just one facet.
Tracking and monitoring
A standard set of project tools is listed to aid your project management.
- RAG status will identify those dependencies that need your immediate attention (but don’t completely ignore the green ones!)
i) Status reporting will highlight any risks.
ii) Review regularly, as the status will change over time - RAID
i) All dependencies should have associated risk documented, which drives RAG and escalation as required. These should be reviewed regularly. - Project Plan with a Critical Path
i) Who – who is assigned?
ii) What – is the task?
iii) When – is time required, and at what point in the project?
iv) How - what is the approach being used?
v) Why - what makes this task critical?
vi) Contingency plan/mitigation – Do we have defined options/alternatives?
vii) Issue identification - What happens if delivery is not on time? - Communication
i) Establish a clear Communication Plan for the project
ii) Define the mechanisms for routine, standard and escalations
iii) Keep communication lines open with those responsible for delivering and those impacted by dependencies
Governance, Reporting and Escalation
- Governance forums
i) Ensure that the governance forums know all dependencies and understand the risks, status, and ownership.
ii) A process is defined to allow mutually agreed dependencies to be added to the plan and to have commercial standing should they be required.
iii) The consequences of failed dependencies are also fully understood by all parties, with roles and responsibilities for them so that a speedy resolution can be agreed upon. - Reporting
i) Use standard project tools to regularly report where possible
ii) Ensure all parties fully understand any external dependencies
iii) Get regular updates from projects you are dependent on
iv) Provide regular updates to projects that are dependent on you
v) Track the impact of failed dependencies against any agreed contingency allowances and the impacts on the critical path as soon as possible - Escalation
i) Gain backing from stakeholders for prioritisation, decision on mitigation
ii) Document any acceptance of risk
iii) If an external dependency fails to deliver on time and this affects the delivery plan, check any commercial impacts and, if required raise a change (to both the project and the contract if necessary)
Summary
Early identification of dependencies will help target your risk management efforts at the items most likely to impact your critical path or the success criteria defined for the project.
Knowing your dependencies and risks will help you prioritise your contingency budget on mitigation actions that matter the most.
Many of the techniques and tools used to deliver a project will regularly touch on dependencies, but this does not mean they will be managed. It requires the PM to have the right mindset and space to focus on them, which will be key.
Regular communication on progress and ownership will be critical to their management and project success.
Finally, remember to continuously reappraise the long list of dependencies and prerequisites, not just the high-priority items, as things can change over time. Hence, you need to be prepared to evolve the list with them.
In Conclusion
All dependencies are pre-requisites, but not all pre-requisites are dependencies. They can and should be identified and managed as early as possible in the project lifecycle – but it is never too late to start; unmanaged dependencies have a habit of turning risks into issues which can result in failure. Be prepared to re-assess your full set of project dependencies, particularly when applying change requests or re-baselining the plan as some of these relationships may have changed.
If you are interested in having further discussions with NTT DATA on how we can offer professional expertise and support your projects and programmes, please contact Martin Lyndon and we will arrange for one of our experienced Project Consultants to contact you.