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.