Categories: Risk Management
Sometimes, external dependencies want to make me shake my fist in rage.
But that's not how it should be.
A critical factor when planning a project should be a risk analysis, not only for the project as a whole but also for individual autonomous groups within the project when there is collaboration going on between the following:
- multiple self-funded groups within an organization (not just one 'project' pot of money)
- multiple companies/agencies
- multiple contracts/vendors
Emotional Responses
However, here's what will happen when you propose a risk related to a depedency external to your immediate group:
- "Hey, we're all one big team here. Aren't you a team player?"
- "Ummm... Politically, I don't know if we want to carry our collaborators as risks."
- "XYZ does a great job. They'll never be late! How dare you insinuate something could go wrong?"
Let's get past the emotional responses now. We want to openly acknowledge areas outside our control, that is the important thing.
Transparent Structure
Perhaps you don't carry these external dependencies as risks (although I would) but use them to build a structure into your plan which makes these dependencies obvious. Making these external dependencies transparent would be a part of my mitigation plan in the risk management process.
Why make them transparent? A primary reason is so that if an external group's deliverables slip on the schedule and you are dependent on those deliverables, a red flag is triggerred and an appropriate response can be acted on. One reason why I advocate carrying these touch points as risks is precisely so that a risk response plan can be formulated ahead of time, and if the risk becomes an issue you can act on a solid plan that wasn't just thrown together in the heat of the moment.
Example
If a vendor is developing something new that is an input to your development process, try to structure the work so that the pieces dependent on the vendor are separated from other work. You might plan a separate release just to incorporate the vendor's new technology.
If you don't do this, late or incomplete deliveries from the vendor will get pieced into your development life cycle and reworked, reworked, reworked as new updates arrive.
If you call the external dependent deliverable separately in your schedule, there is something you can point to if and when things go bad. This is not to place blame; in my book blame has very little use.
No, it's to make it crystal clear which group needs to have their feet held to the fire so we can deliver this project on time.
