Today a new project manager, somebody running one of my work streams, asked to put her risks on my programme risk and issues log. She didn’t really want to but apparently she’d been told to do this by her organisational masters outside the programme. I told her not to. Why? Because I use the log for the programme not the sub-projects. Since I had to explain my thinking to people in the company I thought it warranted a blog entry.
It is all about threat and a threat to a project is not necessarily a threat to the encompassing programme. Even a threat to the programme might not be worth reporting on.
As an agile programme manager I’m interested in the things that threaten the programme. Of all the possible threats in the world the programme risk and issue log contains those things that I want to track. Specific items might be about finance, stakeholders, benefits, development and/or technology but they have to be big and chunky before I’d put them on my log. They have to be big and chunky or they won’t threaten the programme. Even some of those I only track; I only actively manage the high impact items. For example, I’m currently dealing with a 14% cut from the programme budget including a 41% cut from the budget of the current financial year. That is at the top of my issues log.
I expect my project managers to manage the threats to their work streams, including maintaining a project level risk and issue log. In most cases they have sufficient initiative and resources to deal with their own threats, however, if they escalate to me then I can help by drawing on resources across the programme to deal with the threat. Even if they escalate in that manner I might not add the item to the programme register. Only if the risk or issue threatens the programme as a whole would I add it to my list. For example the project manager responsible for infrastructure was concerned about delays in replacing the load balancer. This was significant to her because it was delaying the infrastructure project however I saw no potential impact on the programme as a whole and didn’t add it to my risk log.
The scale of the threat also affects how far I escalate programme risks and issues. That means, in addition to the two types of risk and issue log above, I’ve got two shorter lists for reporting purposes. These target different levels of management above me.
My programme board is, like me, concerned with threats to the programme. But they are not interested in all threats. I only tell them about the high impact items I’m actively managing. Typically I report on 3 or 4 risks and issues to the programme board. And of those I only formally escalate (i.e. ask for help on) maybe only one or two. If I had the risk about replacing the load balancers on this report the programme board would feel obliged to ask about it and try to help with it – which would be a waste of time for all concerned.
The sponsoring group are the people who stumped up with the cash and got the programme going. As with the programme board I filter what risks and issue go to them but the filtering is even more stringent. It has to be huge to warrant alarming these folk. Typically I report no more than one or two risks and issues up to the sponsoring group. Eight months into my current programme and I’ve still only escalated one issue to this group.
So like I said at the start … it is all about threat. Different levels of the organisation have a different concept of what is a significant threat and should only deal with those threats. Keeping insignificant risks off risk and issues logs avoids unnecessary noise.
Alternatively, just add a filter which determines whether it is a project or a programme risk. I have actively encouraged a single list which utilised filters (and not just talking about using a spread sheet). The principles of assessing risk are the same, be it project or programme, so why not use the same logging mechanism?
Further, as a programme manager, who also needs to understand the component workstreams, it is useful to see how ‘risky’ a project workstream is running and mitigate a workstream from impacting the programme overall.
It is a minor step to filter project noise from programme entries. Additionally, you gain the benefit of being able to transparently view how risks/issues in your projects are running overall as and when you need to.
Further if any of those project risks do enter into the programme level risk as a separate entry, it makes it easier to link and log the progress at both project and programme level.
At the end of the day this is about a preference of the way an individual works in the absence of a policy dictating how governance within an organisation will work.
Visibility is good. Of course I’m interested in the risks and issues facing my work streams.
I made no suggestions on how to log risks and issues. Your suggestion of a master list and filters is fine. From my perspective such filters are a way to have lists within lists. So for me this isn’t an “alternative”, only a way of implementing what I’m suggesting. The result is that I have a programme list and my work stream PMs have different lists.
I think it unlikely the same entry would be both a project and a programme risk/issue. If nothing else the impact and countermeasures will be different. So even if the cause is the same, and there is one master risk/issue log, I’m pretty sure I’d raised two items – one for the project and one for the programme.