What is the Procedure For Handling High Risk Involving Another Team's Conflicting Goals?

Question

I am working on an ongoing project which spans over the course of several years. The project has moved to the stage where the product we're building has customers.

Our management structure is the matrix style where project managers work with functional managers to find resources for the project. The team is also self-organizing in that people will sometimes volunteer their time to help out with a specific area in their expertise.

The challenge sometimes is that the other departments have their own goals and deadlines. The general rule of thumb is that they provide services to internal clients, but sometimes their customers take precedence.

This is defined as a risk to the growth of the project and is documented, but what is the procedure for handling high risk involving another team's conflicting goals?

Answer 1

This is quite common in projects. If you have team members attached who have operational duties, they can run into priority issues. I've found the best way to deal with this is both risk management and issue resolution. If you identify the risk in the early stages of your project, you can set up some theoretical approaches, but when it comes down to having to actually deal with it, you need a specific plan.

Keeping communication open, building strong relationships, and dealing with the issues professionally will go a long way toward resolving the problem.

Answer 2

When we had a similar situation, the PM presented two risk mitigation options to the business:

Option 1: Buy in dedicated resources (ie avoid the risk);
Option 2: Accept the risk of staff being deflected away from the project if operational issues arose.

In the end we had a combination of the two, where some dedicated contract resource was bought in for the activities that required specialist knowledge and were on the critical path, and agreed that ongoing discussion between team leaders / managers would be used to handle any conflict for more generalist resources.

It worked fine most of the time, as long as the "generalist" team members were properly informed as to how they should be allocating their time to the project. This was usually between 40% and 70%, depending on the individual.