In my experience running ICT Projects and Programmes, the biggest challenge was trying to get a committed Senior Champion / Sponsor across areas impacted by the project which was always difficult because different units reported to different sponsors.

The best we could do was force it through a governance framework that knits these disparities together in a project framework to get some kind of business integration in the programme. This helped a lot with quick resolution of risk, bureaucracy related to invoices and payment of material needed to procure especially where there is impact to deadlines.

In cases where signoffs and release of funds had to happen within units, we kept a risk log with a risk escalation procedure depending on the severity of the risk. Where the risk had a critical priority and high potential for loss ... possibly due to idle / lead times /... shorter resolution times were agreed upfront, an escalation procedure that reroutes the risk back to the Senior Sponsor when set resolution times are missed was put in place to avert unnecessary costs. The former assumes that contractors are commissioned on a plan and cost of delay / idle time are paid etc.

In some companies, costs of delay will be paid by the responsible unit to force improvements on the project value chain but this was agreed upfront as part of the programme or project governance.

Please note that these were in a South African context but I hope it gives you some ideas.

Ayanda saki, thank you for sharing your experience..project framework for business integration to minimise risk and to also direct these risks towards responsible senior sponsors would most likely be the best solution once the project is up n running.

The internal risk management with risk registers gives a clear idea of what the impacts of these risks would be.But, Will this register be prepared as you go or does this happen before the start of the project to know what the potential risks are and to mitigate these risks ?

Hi Sahithi ... my pleasure

Well, you have to start with the governance framework and agree on a risk management plan plus attached clauses on certain conditions that may lead to fruitless expenditure, impact timelines or quality on your project.

You definitely have to maintain this doc from the beginning to the end of the programme and keep a RAG status of each risk whether open, closed deferred and accepted etc. This is important for two reasons, firstly it will give everyone a view of risks that could not be resolved for whatever reason ... especially the ones that have to be handed over to operations after the project is completed for resolution. Good examples maybe some maintenance agreements not concluded in project due to financial or other reasons plus operational SLAs that need to be agreed out of the project environment.

Some may be relevant to quality of project deliverables and may help you justify how quality measures were met and why they were not met but make sure you attach each risk to a measure of success the risk impacts ... be it quality, cost or time. This will help you to easily report at the end of the programme.

Other aspects may be related to gaps in resources to look after deliverables after the project based on a resource plan. Here you map skills in project that may not exist in the AS-IS operating model of the organisation and highlight this gap as a risk as you handover to operations. In essence, you are managing both technical and non-technical risks in the project (which will be the TO-BE STATE) throughout the project life cycle keeping in mind that your project will also be the TO-BE business state once completed.

That transition is also very crucial ... especially from a risk management perspective if there are support, maintenance and other related activities that need to be highlighted for the deliverables to work properly after the project. A parallel change management process might help take the human aspects of the transition off you ... so you can focus on the deliverables but I am not sure if that is part of your project organisation or not. Might have to consider based on the size of your project.

I hope this helps.

A

Thanks a ton Amanda, the information you have shared is precious..like you have mentioned the risk tracking all through the project is highly important and the change management will depend on the nature of the project, the kind of resources Tht needs to be managed and organized to minimize the risk as there are certain aspects that are project specific.

I really appreciate you effort, if you could post any articles or journals regarding the same if you come across any will be much appreciated. 

Most welcome ... will certainly do.

All the best

A