≡ Menu

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.

2 comments

Leave a Comment

What makes a project successful? (Infographic)

Click for larger image

Click the image for a larger version or click here.

2 comments

Leave a Comment

Book Review: From Projects to Programs

From Projects to ProgramsFrom Projects to Programs by Samir Penkar is a business book in story form. I’m not a big fan of business novels, although I did enjoy Critical Chain.

One of the problems I find is that the stories just aren’t that gripping, and that is the case here. Reading about someone else’s day job on an IT programme is pretty dull. It isn’t a true novel format, either. Each chapter ends with ‘reflection questions’ for you to consider and see how the concepts apply to your own work. It also pulls you out of the story by referring to figures.

In pure ‘story’ terms I didn’t think it was as well-written as Critical Chain. The reported speech doesn’t tend to use contractions, so unless the characters are all very particular in their choice of words it doesn’t read naturally.

There is also an awkward mix of past and present tense, sometimes in the same paragraph and even in the same sentence! For example: “Sure,” said Bill and heads down to his desk.” Many of the paragraphs are long and I found there was a lot of exposition.

Penkar adds in a side-story about the main character’s running group. He uses the running metaphor to explain ideas outside of the work setting, which is a good addition to the story. However, they only seem to talk about work!

Outside the story

The story is only half the book. The rest of it is made up of a glossary, two transcripts of interviews with programme managers, an agile primer, a long chapter on benefits management reprinted from another book and another chapter reprint on PMOs.

I can’t criticise the content. Penkar knows his stuff and this is about programme management. You could argue that he has made the topic accessible and not scary for new programme managers. He includes useful, constructive advice and clearly defines the role of the programme manager. The book is strong on integration management, the use of meetings, team dynamics and communication. There is good advice in here and if learning through stories is your thing, then you’ll no doubt get something from it. It just wasn’t my cup of tea.

 

Buy on Amazon.co.uk
Buy on Amazon.com

1 comment

Leave a Comment

This is my video diary from the Association for Project Management’s Women in Project Management Special Interest Group 21st Anniversary Conference last week. Approx 5m22s.

 

1 comment

Leave a Comment

The Parent Project: Month 19

I been back at work full-time for a month. I am not superwoman. The only way I have been able to do this is to have an excellent team around me at home and at work and fab systems in place to make everything run smoothly.

However, it is very clear that things are far from perfect and some quality standards have been lowered!

picture of socks

Do these socks match?

For example, is this a matching pair of socks? They are both from the Thomas The Tank Engine set, but one is Thomas and one is James. There is another Thomas sock and another James sock, but I couldn’t find either of them. Socks from the same pack, I have been told, do not make a matching pair. My view was that this is Good Enough (and regular readers will know that Good Enough is OK for me).

These are Jack’s feet. You can see how much he’s grown by comparing them to this picture.

 

2 comments

Leave a Comment

What users want from project software: A case study

Photo of slide

Pawel Wieckowski’s opening slide for his talk on user needs

Pawel Wieckowski from GlaxoSmithKline presented a case study on their project software deployment at the Gartner PPM & IT Summit earlier this year.

He started off by saying that they defined who would be using the tool. Users, he said, fell into the following categories:

  • Project management community
  • Project Management Office
  • Senior management
  • The whole company

“A PPM tool is not just for the PMO,” he said, “it’s for use by the wider business community.” Therefore they had to find the right balance between user wants, what technology can deliver and business needs. “If you find the right balance you’ll be successful and everyone will be happy, but that’s not easy,” he said.

They were also clear on why they wanted to invest in technology by stating why it was needed. GSK needed a PPM tool because they wanted to simplify their data and have one repository. They wanted to also enable and empower the project management community.

Starting small

Pawel explained that they had the choice between a big bang roll out or an evolutionary approach and sensibly they chose to start small. They opted to roll out their solution, then refine it and optimise it later. They took an interesting approach to those refinements, too. The team gathered enhancement requests from users and then asked them to vote on them. Using this method meant that the user base set the priorities for enhancements.

Photo of Pawel

Pawel Wieckowski presenting at the Gartner PPM & IT Governance Summit, June 2014

Next steps

Three years on their solution is a tool that helps the company plan and realise its investments. One of the big refinements that Pawel explained was to plug the gap in corporate financial planning. The business has a complicated structure between bits of the company that deliver solutions and bits that fund projects. Any single project could be funded from a multitude of sub-companies or departments or countries and the PMO wanted to be able to see the impact of a project on one of these companies, countries or teams.

The business wanted projects linked to capital and operational plans so the team mapped the organisational structure and high level aggregated spend performance. They were then able to show the benefits and disbenefits of projects, where they hit, forecasted cost at completion, accurate actuals, along with high level and adjustable financial plans. In short, a really comprehensive way of looking at projects as investment spend.

Waterline spend

One of the key features was the ability to show a list of prioritised projects. The waterline is the amount the company can spend. It is marked on the project list and clearly shows which ones will be funded and which ones won’t which, Pawel said, is very useful for forecasting and for having difficult conversations with project sponsors.

You don’t need fancy software to do this – every PMO should have a list of projects that it can resource and a pipeline of projects that it would like to do next. Priorities change and so does the list, but you need some view in order to manage resources accurately.

Finally, Pawel said that his team had had to make many changes to the software, working alongside the vendor (and he didn’t tell us who it was, or if he did I didn’t write it down), in order to make their solution do exactly what they wanted. He recommended that we should all do the same and add the features we wanted even if they don’t exist at the moment. “Don’t hesitate to improve your tools,” he said. “PPM vendors will follow.”

5 comments

Leave a Comment