Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: programme management

Visualising risks and issues

Risk Management - Image from bigthink

One of the key tasks of a Project Manager or Programme Manager is to identify and control and mitigate issues and risks in projects or programmes. Traditionally these are done using an issue number as an identifier and using plenty of text to explain the context of the risk, how you identify it, estimating and evaluation methods, plans to mitigate, how you implement the actions and communicate with stakeholders. If you are lucky, there may be some risk maps that outline the risk assessment process and some graphs, if the risk is of financial nature. Again if you are lucky, you are utilising some web based mechanism that has an instant ability to raise and assign risks and allow dynamic reporting. More often than not, it is actually a spread sheet in someone’s laptop!

I have been thinking … what is the purpose for having a Risk and Issue Management process? The main aim is communication. You want all the stakeholders to be aware of the risks, allow the Senior Responsible Owners (SRO) to make sound judgements on the level of risk the programme or project should carry and the teams to know what to do when one of these risk events come to fruition. Human brain isn’t really programmed for reading huge amounts of text to understand context in an efficient manner. A picture tells a thousand words is true. When you think about traditional risk registers … are they really helpful in some situations?

I have identified some of the issues with the risk registers. Do we now draw pictures instead of writing the details? No, I am not advocating that. You need the details for implementation purposes, which cannot be ignored. How do you achieve the “communicate” bit?

One obvious area that comes to me is recording of risks spatially. In a lot of programmes, different projects are commissioned that deal with areas that overlap, or have interests in achieving different outcomes in the same area. An appropriate use of spatial context can give the stakeholders and SRO a good understanding of risk patterns over specific areas. There may be multiple projects coming up against similar problems in the same geographic area. This is a likely situation in a lot of disaster management and recovery scenarios.

Another area is likely to be temporal reporting. There may be specific risks associated with specific times during the day, week or month. Some candidates are service oriented programmes that deliver IT services. There may be specific times of day that have spikes associated with it. Some social programmes may also be candidate for similar communication strategies. Examples are risks of anti-social behaviours, accidents etc.
While I have been thinking about some of these risk communication challenges, I don’t think I have it totally sorted in my mind. I am keen to understand what techniques you use to achieve this. Any comments most welcome.
Related articles

How do I make sense of chaos?

Snowfall around Beehive (NZ Parliament) - courtesy

Snowfall around Beehive (NZ Parliament) - courtesy

I’m sitting in a transit lounge while I write this post. I’m heading to Los Angeles to undertake programme planning for three major pieces of work we’re delivering to our clients over the next twelve months. I was supposed to leave Wellington last night. If anyone has seen the news recently, Wellington has been hit by once in a 50 year snowfall, which has unravelled my travel plans. As I sit here in the lounge and kill plenty of idle time, it occurs to me, actually this is not too dissimilar to projects and programmes. How you may ask … read on.

If you think about it, going to LA is not really a task, it is an activity undertaken to achieve some outputs (planning for the programme of delivery). Any time you travel, one of the risks you must take into account is disruptions. In effect, it is just a project risk that I need to take into account. The fact that weather was going to be marginal, wasn’t obvious at the time of planning. However, as the travel was nearing, it was looking likely that I needed to actively monitor the risk and set out some responses. In order to transfer some of the risk, we had purchased travel insurance (corporate). At the same time, I was thinking of mitigation plans, in case disruption happened.

It appeared everything was on track, until about an hour before my flight out of Wellington. A sustained period of heavy snowfall whitened the runway and Air Traffic Control had closed all landings and take-offs. I knew I had no chance of catching my connecting flight out of Auckland even if the runways were opened again. I was straight on to the reservations to ensure I was first to get re-booked on to connecting flights for the following day. I also wanted to mitigate a further risk of not making the connecting flight again, thus rendering the travel less beneficial. This time, I ensured I took an earlier flight to Auckland, allowing me plenty of opportunity to re-book if necessary.

All done, it is now time to head back home for the night. As I come out, gale force southerly were lashing outside. There were thousands of people queued and not a shuttle or taxi in sight. I had to make a quick decision, to ensure I got home in time to get a decent sleep, so I could start my travel again in the morning. I decided to hire a rental car for the night and head off. This is no different to projects, where you have to take decisive action to ensure success.

All the planning that I do for projects and programmes, is to ensure that I don’t have to wade through this amount of chaos 🙂 Wish me luck.

Technorati Token: 8BB6S6NTA3XB

What is the difference between Project and Programme management?

I recently did my MSP certification, to gain better understanding of programme environments, compared to projects. One thing that came as a slight surprise to me was the difference in focus between projects and programmes. Projects are focused about providing fit for purpose products within a certain tolerances – time, cost, scope, quality, risk and benefits. Programmes are instead focused an realisation of benefits.

PRINCE2 does have a focus on benefits. However, it also acknowledges that in all likelihood the benefits from the project outputs are likely to be realised some time after the project is delivered and closed. In that scenario, how do you make sure that those benefits are indeed realised? This is where the programme comes into its elements. OGC explains programme as designed to bring in a transformational change in an organisation and providing a framework for achieving that. When you think about that, it does make sense. An organisation doesn’t go into a project becase it wants to do a project. The reason they do it is to achieve a change that meets their strategic objectives.

The  journey from inception of an idea to the actual realisation of benefits arising from that may not be a simple one. Ideas are inherently a vision from someone within the organisation that visualizes a future state of the organisation that is desirable. Ideas have to be tested for their merit, analysed against costs, implementation options considered. The end state can be a journey through fuzziness. This however, is not always the case. Sometimes the changes wanted are through known specifications, well understood and repeatable methods. In those circumstances, it is probably not worth running programmes. Projects are probably sufficient. However, fuzzier the journey is from vision to the future state, programmes are the way to go.

I thoroughly recommend the MSP approach to programme management.

%d bloggers like this: