ITBusiness.ca

Dos and don’ts of project management: part 2

In my previous blog on project management, I talked about project planning. In this blog I will be talking about managing risks and dependencies.

In order to deliver a project on time, it is important to identify dependencies and risks early. How do you do that? First you and the project team consider the question: What could go wrong with the project? This has to be a thorough and detailed analysis as it is often what you don’t know (as opposed to what you do know) that can kill the project.

Is the biggest risk the dependence on the vendor delivering the new product on time or having the right staff available? Both internal and external risks and dependencies need to be reviewed. Then you need to consider: What would be the consequences and impact with each individual risk or dependency and rate it as high, medium, or low risk. And finally determine what can be done about it.

For example, if you are renovating your bathroom (rather tedious job, but the results can be great), you need to asses the dependency on the contractor, whether the tiles will arrive in time, risk of cost over- runs, just like you would with an IT project. You have to assess each risk and dependency. If the vendor has never missed a delivery date, the risk is low. If the vendor only verbally confirmed the delivery date, the risk is higher.

After assessing the risk and dependencies for the project, the next step is examining your risk tolerance. With the above example, you may be willing to accept a different towel rack, but not a different vanity top (you have standards, after all).

To assess the sponsor’s or stakeholder’s risk tolerance, a conversation between the project manager and the stakeholder needs to take place early on in the project to fully discuss the risks of a project and how those risks will be handled if they occur. The ideal time to assess risks and risk tolerance is at the start of the project so that the scope can be adjusted based on this discussion. It can’t be just a high level examination of possible risks, it needs to be meaningful, culminating in an agreement on how much risk the sponsor/organization can tolerate.

We have now talked about initiating a project, developing a project plane an risk and dependency management. Next time the two topics will be reliance on key resources and playing the “blame game”. I’m sure many people experienced these issues, please share your best practice!e

Exit mobile version