Earlier this week I looked briefly at an introduction to dependencies and constraints on project and why they matter. Today I’m going to share a 5-step approach to identifying and reviewing all the dependencies and constraints on your project. If that sounds daunting, don’t worry. It’s a much faster task than you think.
Step 1: Create a log of all the project dependencies
Now you understand what a dependency is, you can brainstorm and document all the dependencies that have an impact on your project. Set up a dependency/constraint log using an existing template from your PMO or by designing your own.
Remember to include who is responsible for managing the dependency and all the other pertinent information including whether it is an internal or external dependency. If it is an external dependency, you can add a link to where you can find out more information. This is particularly relevant if the external dependency is another project and you need to remember to regularly catch up with the other project manager to assess the impact on your project.
Step 2: Create a log of all the project constraints
Brainstorm and document all the constraints that have an impact on your project. You can use the same document as you used to record the dependencies, although if you feel it is more appropriate to create a separate log – for example, if you have a lot of constraints – then feel free to create another document.
Step 3: Ensure the major dependencies and constraints are in your Project Initiation Document
Transfer the major dependencies and constraints to your Project Initiation Document (PID). The purpose of doing this is to have all the key information about the project in one place – the PID (or Project Charter).
If you don’t have very many dependencies or constraints you could include them all in the PID. If your log has lots of entries, consider which ones are the highest priority and only include them. The audience for your PID is your Project Sponsor, and it is unlikely that he or she would want to read every single low-level dependency. However, this does not excuse you, as the project manager, from monitoring them all.
Have a discussion with your Sponsor and ensure that they understand the dependencies and constraints and what could happen if a dependency cannot be met or a constraint turns out to be too restrictive. You need to ensure they have a full understanding of the project environment, and dependencies and constraints are two key elements of that.
Step 4: Ensure the major dependencies and constraints are in your risk log
Read through your lists. Do any of these dependencies sound like project risks to you? Outside-the-project dependencies are often contenders for being transferred to the risk log, especially if you are reliant on third parties to deliver certain items.
Constraints such as limited access to people for user testing are also potential risks, so make sure they are recorded as well. In fact, if you know already that the constraint is going to be a problem, record it on your issue log.
Get a free risk log template here.
Step 5: Agree how you are going to monitor the dependencies and constraints
Having a log and an up-to-date PID or Project Charter is great, but your project will not be better just through doing that. You have to work out a way to regularly assess the dependencies and constraints so that you can manage their impact on the successful delivery of your project.
If you have external dependencies on other projects, talk to the project managers concerned and agree how to let each other know when things change. Reporting by exception is a solid principle that you can use here: only report to the other person when something is not going to plan. So, if your project is reliant on another project to complete a certain task by a certain date and it looks as if that will be achieved, the other project manager will only report to you if it now looks like it will not be achieved.
For extra comfort, you may want to schedule regular meetings with the project managers concerned to ensure that you understand how their projects are progressing and any changes this has for the way in which your project will be delivered.
A simple way to manage internal dependencies is to remember to discuss them in your project team meetings. The more aware the project team members are about the impact of their tasks on other people’s work, the more likely they are to flag when there is going to be a problem. But if in doubt, ask them, and make this is standing agenda item in your regular meetings. During these meetings you can also update the log to include any new dependencies or constraints that emerge as the project progresses.
Of course, for those dependencies and constraints that have made it on to the risk log, your risk management processes from the basis of how you will review and manage them.
Easy enough, isn’t it? If you have any tips of your own about managing dependencies or constraints, let us know in the comments.