How can a Project Manager manage a dependency on an external team?

Question

A given project team may have a dependency on an external team in order to complete work on their own project. The Boeing 787 Dreamliner project is probably an excellent example of a large project that depended on company A to develop widgets, company B to develop sprockets, both of which were key dependencies for the "assemble the airplane" project.

How can a project manager manage external dependencies outside of their control that directly impact the feasability and progress of their own project?

Answer 1

You don't manage the dependency, you manage the risk.

What is the impact of the risk? If we don't get the toilet paper dispenser installed, will the plane be unable to fly?

What is the probability of the risk? If the supplier has never missed a delivery date, the probability is low. If the supplier doesn't even know how to forge admantium, then the risk is high.

What is your risk tolerance? Building an airplane, you are pretty risk adverse. Building a $.99 iPhone game your probably willing to ship with some crash bugs.

Calculate your impact to probability score and see how it rates on your risk tolerance scale. Anything over the threshold must have a mitigation plan and should be included in sponsor status reports.

I use a spreadsheet I made for risk tracking. It has a weighted scale that gives more weight to impact than probability. Then at the start of any project I work with my team on the risk tolerance. I've had products where a score of 50 was considered a red risk and projects that a score of 90 was a red risk.

Best,

Joel

Answer 2

You ask how can a project manager can manage external dependencies outside of their control that directly impact the feasability and progress of their own project? This management cycle works well for me in that scenerio.

1. IDENTIFY-The PM should facilitate the identification of these external dependendcies. Host a workshop with your team and work out what you need from the external party and when you need it by.
2. AGREE- Contact the external party and ensure they understand what you want and when you want it by. If they are able to deliver, great! If not negotiate. Either way formulise what has been agreed and write it down.
3. PLAN- This where your scheduling tool can be of help. I use MS Project and record my external dependencies as milestones. I give each depenendency a reference number so I can quickly find it across all documentation. I make sure the dependency is linked into the rest of my schedule so if does slip I know what the impact to the rest of the plan will be. The baseline date is the date that we have both agreed the dependency will be delivered by.
4. VALIDATE- Any project could have a series of dependencies, which means a change in one can have a knock on effect to others, rippling up and down numerous projects. Therefore some dependencies are going to have a bigger impact than others if they slip. I find it useful to RAG rate (red,amber,green) dependencies according to the impact they could have. I check these ratings each month, that way validating the prioritisation and management attention I give to those dependencies I'm monitoring most closely.
5. MONITOR & CONTROL- as part of a regular management cycle, I check with the external party that they are still on track to deliver the dependency to the date we agreed. Any changes to the date I need it by, I feed across as well. If the agreement needs to change then we can work that through as part of a change control process.

The key thing here though throughout is to maintain communication with the party you are dependent upon. As soon as that communication breaks down then any chance of 'managing' the dependency is lost.

Answer 3

I've never experienced this scenario before, but I believe all the PM can account with is the other team's estimates. Every part of the whole process has it's own managers, and they should have the responsibility of delivering before deadlines.

I believe it's not acceptable to have a project manager from A who depends on B to start micro-managing B. It would

• Create a very uncomfortable relationship between A and B PMs (B has a PM, right?)
• A's PM will be creating more work to himself than he's supposed to do

Bottomline: A PM is restricted to his team. If he depends on other teams, he will discuss with other PMs to take the estimates he needs, and that's all. If something gets out of the track, PM B will be asked to give answers, not A.

Again, never lived this scenario. It would be my approach in this case.

Rgds!

Answer 4

When there is dependency between a project and its suppliers, it is a good idea to shorten the release cycles of the supplier projects and integrate the solutions and see how they are coming.

It is not important to have finalized pieces from the suppliers, the idea is to have something new and see how it servers the projects purpose. We are using this approach - we have a huge platform dependency - and now we see what will come and how our solution works with the new features/changes. They are tested with our latest version - non of the is official yet - in a sandbox area, and at the end of the projects the official integration goes more smoothly.

With this approach we don't have to spend a lot of time on integration and the received feedback from both size is very valuable. We know the exact state of our supplier and we also know what kind of traps we are going to receive.

Answer 5

You're asking about management of procurement. I would strongly recommend to read about "Project Procurement Management" knowledge area from PMBOK and ask a more specific question.

Answer 6

External dependencies are a complex issue in Project Management. Direct external dependencies may cause those issues in our program schedule:

• Non-critical schedule delays (negative floats)
• Critical schedule delays (negative floats in the critical path, or in one of them
• Higher costs and risks derived from these delays
• Issues with resources interacting with these external sources (vendors, suppliers, engineers, construction managers, etc.)
• Issues among contractors working at the same site

Project schedule issues cause all kind of risks, which need to be properly analyzed by the adequate method and software, strategically planned, managed timely, and controlled closely. Risk management is a complex topic by itself, and can be related to the nature of the activity, to the project scope and location, to the project environment, to the industry, to the contractor, supplier or vendor past performance, etc., etc. Problem is that a contractor may try to hide issues (and their related risks) to avoid penalties and other repercussions to his job and company.

A good project manager and project controls manager will however be able to detect when something is not looking right. An odd cost pattern, a productivity index spike, a resource work surge or replacement, may be a hint that an issue has been hidden. The next step for the PM is to try to manage the issue(s) by interacting with the external source(s) of the risk(s), analyzing the situation together, and try to build a solution that will solve, or at least mitigate the problem for the project. I have seen this done several times, and this is what is called Dependency Management. This effort is especially important when the external dependency impacts the critical path, or causes a relevant cost increase, a serious environmental risk, or another relevant issue.

However, we also often have "indirect external dependencies" that need to be detected and managed - whenever possible. They occur when a contractor's schedule have direct dependencies with another contractor's schedule. THESE dependencies can also cause several issues, costs, risks, and delays, with one blaming the other, and the PMO should try to solve or direct their best resolution, to minimize program issues.

To deal with these external dependencies in a large program, I have often created separate top sections, one for the Key Milestones, and other for these external dependencies, and directed the contractor schedulers to have similar structures, so that even though they can make frequent changes to the schedule, their top sections would continue to be static, and their related special links in my IMS would continue to be valid, without the need for serious maintenance.

A relatively small number of external dependencies in a single project can be properly identified (special column with a flag, for instance) and controlled without the need for these top sections, even though I always use the Key Milestones one.