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

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?

-

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

-

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!

-

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.

-

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.

-