Dependencies

#portfoliomanagement #programmanagement #projectmanagement

In the progress of improving our IT portfolio management definition, we recently added dependencies in our system. So some program managers, project managers, and product managers came on the line with the question: what kind of dependencies do you want to see?

When they asked that question, I remembered two roadmaps hanging on the wall. Both were complex, but one of them had so many lines which connected items with others, it looked like a colored spiderweb. Nobody was going to get information from that one.

But they could at least say it was complete (…)

A better approach is, that we decide upfront which dependencies you want to view and which not. I suggest that you take an approach as done in risk management: The risk matrix. This matrix is based on two intersecting factors: the likelihood that the risk event will occur, and the potential impact that the risk event will have on the business. We change ‘on the business’ with ‘on the benefits to be achieved by this initiative’ and we have something we can work with.

If the dependency has the ability to block or fail the initiative, it must be mentioned, even if the probability is low. I would consider a probability low if the chance of happening is estimated between 1% and 25%. We don’t consider things as satellite impacts or ocean floodings when you are living 200 miles away from it at 100 ft height.

We don’t mention low impact dependencies.

If you choose to have also a middle category (e.g., a part of the initiative cannot be realized so the benefits would become less), I would mention this only when the chance of that this would happen would be high.