How to Properly Map Out Project Dependencies For Better Management
Share this on:
Project management requires the planning, execution, and monitoring of all tasks and processes. Being able to successfully navigate both predictable and unforeseeable circumstances is key.
This is the case whether you’re managing construction or software development. Successful delivery depends on balancing many aspects, such as risk management, resource management, and time management.
None of this can be accomplished without taking into account project dependencies.
What are Project Dependencies?
Project dependencies are the interrelationships between project tasks, components, and processes. They dictate the order of activity completion during a project.
From a big-picture view, every task or assignment is a dependency for project completion. However, project dependencies vary both in type and how they affect project planning and execution. Different types of dependencies require different management strategies.
For example, writing mobile application features is dependent on UI designers. Developers must wait for things like wire-framing of components. Another example may involve transitioning to a unified data warehouse. As soon as data is processed, data scientists can start the analysis. However, they would need to wait for data migration to complete before analysis can finish.
While these situations present unique challenges, they both represent potential areas for bottlenecks. Each project dependency is an opportunity for your project to slow down or halt. If enough time or resources are lost, then a project fails.
Four Main Types of Dependencies
Four dependency relationships form between project tasks.
Finish to Start (FS) – the predecessor must finish before the successor can start. This is the most common type of project dependency. An easy example would be that feature requirements must be defined before development can begin.
Start to Start (SS) – the predecessor must start before the successor can start. This is common in app testing. Feature development may not yet be complete. However, as soon as one feature is complete, feature testing can begin.
Finish to Finish (FF) – the predecessor must finish before the successor can end. Most of the time, an FF-dependent task is also SS-dependent. Let’s take the above example. App testing can’t be completed until development has finished.
Start to Finish (SF) – the predecessor must start before the successor can end. This is the least common type of dependency. An example would be a developer contract. The contract might go beyond the scope of the project. However, the developer can’t begin work until the contract has commenced.
Understanding Project Dependencies in Depth
There’s more to understanding project dependencies than simply understanding the order of events, however. In order to accurately map them out you need to consider whether they’re internal or external, as well as mandatory or discretionary.
Internal vs External
Internal dependencies are the ones you (or the business) can control. These are project dependencies that you can manage from within.
Preferred or best practices– meeting safety, hygiene, or quality requirements
Resources– costs, computing power, and other dependencies
Software– updates, version incompatibilities, legacy systems, and other bottlenecks.
Some project dependencies are out of your control. These are known as external dependencies.
Examples of external dependencies include:
Supply chain– logistics problems with delivery of physical or virtual supplies
Bureaucracy or jurisdiction– certifications, permits, and other legal requirements from external bodies
Weather or natural disasters– unpredictable events that cause power outages or network failures
Finances– accounting hold-ups prevent tasks from starting or finishing
Development environments and developer tools– failures or glitches in these services will delay completion
Mandatory vs Discretionary
Another classification of project dependencies is whether they are required or “nice to have.”
Mandatory dependencies are exactly as they sound. These are project dependencies even the best managers can’t wiggle their way around. Until addressed, they will block further progress or development.
Discretionary dependencies can be altered without impacting project completion. Changing these dependencies may be forgoing a preferred method of doing things. For example, the marketing department may launch a campaign for AI call center software – but before development is complete!
The preference of course would be to have the finished product before going to market. However, development can still be finished before the launch deadline – it just makes it harder to factor in delays.
Discretionary dependencies can also relate to the order of two tasks. They may both need to be completed but the order doesn’t matter. An example of this would be usability testing and performance testing of your app. These can be done in any order or concurrently. However, your team may have a preferred way of doing things.
Benefits of Outlining Project Dependencies
Whether you define project dependencies or not, they’re still there waiting for you. It’s best to discover and map out every relevant dependency. By doing so, all project stakeholders are better prepared with a well-thought-out plan. This also ensures you deploy the right people at the right time, from your coding team to the AI experts.
Other benefits of mapping out project dependencies include:
Optimizes lead times– everyone involved will know the earliest a task can begin. This reduces waiting times and speeds up overall project completion.
Prevents bottlenecks– you identify the highest potential for project delays. Better foresight helps planning to eliminate blockages.
Better schedule planning– everyone knows the stakes involved and is more accommodating. Shifts, sprints, and task assignments are streamlined.
Deliver on time– resources can be used more efficiently. It’s easier to keep every project on track and on schedule.
Risk management– identifying dependencies ahead of time keeps you better prepared. Map out backup plans and redundancies to manage potential roadblocks.
Change management– you get a clear picture of project lead and lag times. If any delays occur, you can more easily adjust the schedule to manage change.
How to Map Out Project Dependencies
Here are some strategies to help you manage project dependencies.
Define Project Objectives
The first step to project management is to define the scope and objectives involved. What is it that the business wants to achieve? What deliverables are expected? This will give you greater context and lay out the foundation for planning.
For example, let’s say you are building an enterprise phone system solution. This project has very different objectives from developing an internal-only application for small businesses.
Visualize Activities, Tasks, and Components Involved
Mapping out project dependencies is easiest when you use visualization techniques. There’s no hard and fast way to do this. Go with your weapon of choice.
Some options to consider include:
Gantt chart– horizontal scheduling tool, typically created as a spreadsheet. Each bar represents an activity’s duration. Tasks are arranged vertically by the order they are initiated.
Kanban board– works similar to a whiteboard. Project tasks are written onto cards and can be moved around like sticky notes. Items are color-coded or categorized by columns so every project member can see what else is going on.
Shared calendars– a simple way to keep stakeholders involved and teams on track. A tool like Google Calendar allows everyone to see deadlines and milestones.
Project management tools– software that streamlines project management. These apps allow for flexible visualizations. They also provide a central hub for updating and managing projects in real time.
Research visualization methods and go with what works best for you. If in doubt, sign up with project management software. These tools give you the most options for mapping out project dependencies.
Collaborate with Project Stakeholders
Armed with project objectives, it’s time to get everyone on the same page. Consult with members of every team involved in the project. This will give you a better understanding of potential project dependencies.
Make sure all communication flows both ways. Take any feedback from subject matter experts and apply it to the planning phase. It’s also best practice to conduct an internal audit of your current systems, processes, and procedures.
At the same time, communicate what’s at stake to every team member. Once you map out project dependencies, educate and inform every team member. When the development team knows that a delay will affect the QA team, they will be more likely to stay on track.
Identify Lead and Lag Times
During project planning, some dependencies necessitate gaps between tasks. Others may be pre-installed to give flexibility. These are known as lead and lag times.
Lead time is the amount of time a task takes from start to finish. Lead time is vital to project management. Long lead times denote greater bottleneck potential. Shorter lead times allow for great flexibility.
Lag time is the amount of time between one activity finishing and the next one beginning. A basic example would be having to wait for paint to dry before adding a waterproofing protectant. Knowing lag times beforehand allows project dependencies to be accurately identified.
Lead times and lag times are a key component in managing project dependencies. They allow you to create buffers and manage risks. For example, during a long lead time, another activity can overlap where possible. In an SS or FF dependency, you can aim to have the two tasks finish around the same time for better efficiency.
Don’t Depend on Luck
Sure, the stars align once in a while and a project goes smoothly. However, the odds are that delays and unexpected events occur. As a project manager, you need to control risk and provide alternate solutions. Mapping out project dependencies reduces the need to cross your fingers and hope for the best.
Disclaimer: The author is completely responsible for the content of this article. The opinions expressed are their own and do not represent IEEE’s position nor that of the Computer Society nor its Leadership.