≡ Menu

5 steps dependencies constraints copy

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.

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.

3 comments

Dependencies and constraints: An introduction

No project happens in a vacuum. Projects are influenced by and are dependent on the environment in which they are taking place – both the corporate environment and the wider environment outside the company.

Definitions

Dependency: The relationship that defines the order in which tasks are carried out. Task B is dependent on Task A if the start or finish date of Task A must be reached before Task B can be started.

Constraint: Something that limits your options.

Categorising dependencies

Dependencies can occur inside and outside the project, and inside and outside the company. The following table shows the four different types of dependency and some examples.

 

Different types of project dependencies

Different types of project dependencies

 

Another way of defining dependencies

Dependencies can also be ‘upstream’ or ‘downstream’. An upstream dependency is one where something else must happen before your project can start something i.e. you are waiting for a task to complete before starting work. A downstream dependency is something your project must deliver before something else can start i.e. someone else is waiting for you to complete tasks before they can begin work.

Constraints

Constraints are similar to dependencies: they also impact how you can deliver the project. However, constraints are restrictions.

Project constraints could be factors that limit the time, resources or budget available to the project. Despite these, you still have to get the job done. Your challenge as a project manager is to find ways to deliver the project successfully within the constraints of your environment.

Identifying and assessing dependencies and constraints is a useful activity because many of your project decisions will be based on this information. If a dependency cannot be met, or if a constraint turns out to be too restrictive, this impacts your ability to deliver the project to the original plan.

Discussions around dependencies and constraints form a key part of your stakeholder engagement plans. You can use these discussions to set expectations about what your project can realistically achieve.

As project managers it’s often tempting to spend a lot more time on managing risks and issues than dependencies and constraints, but they are just as important and can have a massive impact on your project if you don’t manage them effectively. So how do you identify the dependencies and constraints for your project? We’ll be looking at a 5-step approach for doing that later this week.

Read next: 5 steps for identifying dependencies and constraints.

3 comments

poster 5 more things

Last month I wrote about 5 things you should know as a new project manager. There’s actually more than 5 that newbie project managers should be paying attention to, so here are another 5!

1. Know what’s a showstopper

What is going to kill your project? Some problems aren’t that big a deal. But some are huge and will cause significant issues. Knowing which is which is partly down to your professional judgement, and if you are new to projects you might doubt your own ability to make that call. Showstoppers are things that will prevent your project from achieving its objectives. If you hit a problem and you don’t know how serious it really is, talk to your project sponsor or a trusted colleague. Chances are, if you are worried, then they will be too.

2. Manage risk

Risks are things that could potentially cause problems (there are also risks that could potentially improve things, but that’s for another day). They haven’t yet, but they might. Don’t ignore them. The project manager’s role is to work out how to make these risks disappear or at least have less of an impact if they do happen.

Each project risk will need a management strategy and an action plan. Work with your team to establish what to do about them. You might not take any action for some smaller risks but for those that have the potential to give you a big headache you’ll want to look at creative solutions to make them go away.

What documents should your project have?

Project Initiation Document
Project Plan
Risk log
Issue log
Change log
Project Closure Document

There are plenty of others but these are the minimum.

3. Learn to cope when things go wrong

When problems do hit (and they will!), the best project managers deal with them calmly and professionally. If that isn’t your nature, you’ll have to work hard to give the impression of having everything under control. You set the tone for the team and they will take their lead from you. However disastrous the problem, don’t run around like a headless chicken screaming, “The sky is falling!” Sit down with some subject matter experts and come up with some solutions to the problem so you can present your project sponsor with a recommendation of how to deal with it.

4. Understand the benefits

What benefits will this project deliver? Every project task you do should contribute to achieving those. These days, companies don’t have the budget or resources to invest in projects that don’t deliver anything useful. And as business priorities change at a scary rate, today’s high profile, top priority project is tomorrow’s pointless exercise. Make sure you understand your project’s benefits and keep checking that they will be achieved and that the project does still align with current business strategy. If it doesn’t, it’s probably time for your project to be stopped and for you to work on something more worthwhile.

5. No one will understand your job

Finally, accept the fact that people outside of project management won’t understand what you do. If the project goes well, they’ll ask why they needed a project manager at all. If the project goes badly, be prepared for it to be all your fault. I have always found it hard to explain the role of a project manager. My job is to make it easy for other people to do their jobs, and if that doesn’t sound like a non-job then I don’t know what does.

If you can get a mentor, then get one. If you can’t, read everything you can, research good practices online, attend training and take some certificates. In fact, do all that even if you do have a mentor. You should never stop learning and developing professionally, even when you’ve got lots of experience and people are asking you to mentor them. Project management is basically about building good relationships with other people to get things done, and as every project and every person is different, there is always going to be something you can learn and take forward to your next piece of work.

11 comments

New to project management? 5 Things you should knowIt would be nice to think that every company has a formal mentoring scheme, and that you can tap into the experience of other project managers through this. However, that isn’t always the case. As a result, new project managers and people managing projects for the first time often find themselves making mistakes. That’s normal – we all make mistakes from time to time, especially in a new job. But there are some simple things that you can do to get up to speed quickly and avoid rookie errors. Here are 5 things that I wish someone had told me when I first started managing projects.

1. Manage scope

The scope of your project is normally set at the beginning, but it’s foolish to think that it won’t change. The average project goes through 4 formal versions of scope, so you need to come up with a way of managing those changes when they happen.

2. Learn the vocab

Project management has a lot of jargon. From baselines to Gantt charts, work breakdown structures to risk sensitivity analysis, there are so many new terms to get to grips with. And don’t get me started on the terminology that goes with earned value management. The thing is, even if you understand it, your business colleagues probably won’t. Part of your job as a project manager is to translate the project and the work you are doing into terms that they can understand. Make it easy for them to work with you.

5 common rookie mistakes:

Failing to communicate
Overlooking stakeholders who should be involved
Not managing expectations
Not updating the project schedule regularly
Failing to manage change

3. Review success continually

Traditionally, project managers reviewed the project at the end. The lessons learned meeting would look at everything that went well and everything that didn’t, and pick out key lessons to apply to future projects. This is still a good approach, but a better approach is to do that as you go along, and not to leave it to the last minute. Then you can tweak what you are doing to improve things now.

4. Create a common goal

Projects are most successful when everyone knows what they are doing and why. I’ve worked on two particular projects where everyone had a very clear view of what would make the project a success and what the business outcome should be. They were easily the hardest, most challenging projects I’ve done to date, but it really helps to bring people back to the common reason why we were doing the work in the first place. Shared objectives matter, so make sure you understand what your project is for.

5. Use short tasks

Putting together a project schedule is time consuming and a bit boring. So it’s tempting to use massively long tasks on your plan like ‘testing’. This isn’t helpful in the long run as it is far harder to track progress when your tasks are long. There’s a risk that someone on the team will keep telling you that everything is on track and it’s only when it is too late to do anything about it that you’ll realise they were wrong. Short tasks help you pick up slippage early and do something about it.

Read part 2 of this article: 5 More Things You Need To Know

12 comments

PMI Global Congress EMEA Video Diary [Day 2]

This is the video diary from Day 2 at the PMI Global Congress EMEA, 12 May 2015… Continue Reading->

PMI Global Congress EMEA [Video Diary, Day 1]

This is my video diary for 10 May 2015 from the PMI Global Congress EMEA in London.  … Continue Reading->

UK PM: Challenges and Celebrations

Find out how project management in the UK has changed and why the 2012 Olympics was a turning point for the profession. What do British project managers have to be proud of and how do we address the challenges of fragmented professional representation?

7 Tips for Attending Conferences

These 7 tips will help you prepare for attending your next conference to get the best out of your investment. The more preparation you put into any event before you go, the more you will benefit from attending, whether that’s a small social gathering at work or a huge industry congress.

10 Ways to Present your Projects to Stakeholders

Find out how to communicate your project to stakeholders with these 10 tips and ideas. Better communication results in better engagement and ultimately more successful outucomes.

Are Your Project Communications Lost in Translation?

Pete Bennett of the UK’s leading business and professional translation company London Translations examines the challenges businesses must overcome to avoid ‘lost in translation’ moments as a new generation joins Britain’s workforce.