Program Management Flashcards
What are the 2 facets of the Transformation thread?
Clear Vision & Real Benefits
What are the 2 facets of the Alignment thread?
Agile Governance & Active Change Leadership
What are the 2 facets of the Adaptation thread?
Incremental Delivery & Robust Risk Management
What is Agile Governance?
Governance is the alignment of an initiative (project, programme or product development) with organisational goals to create value. Governance defines how the initiative is set up, managed and controlled.
Agile governance is the application of Lean-Agile values, principles and practices to the task of governance.p
What are the 2 types of control fallacy?
Internal Control Fallacy: They don’t delegate and try to do everything themselves, or delegate but micromanage. They might also bully their staff.
External Control Fallacy: They become passive and give up doing anything, because they believe others have the control.
What is the Transformation thread?
Programmes, whether traditional or agile, are fundamentally about organisational change. This transformational change is the thing that defines a programme and distinguishes it, for example, from a project. It is the single major difference between a programme and project.
Management expect benefits to result from any such transformational change – otherwise why bother. These benefits might be creating new products or services, generating greater revenue, or driving out efficiencies. Whatever the specifics the aim of any programme is to change the organisation for the better.
The point of applying an Agile approach to programme management is to make this transformation faster and hence start delivering the benefits earlier.
What is the Alignment thread?
Business objectives change, as does the world around us, so throughout its lifetime a programme must stay aligned with the evolving organisational strategy. Good governance ensures that programmes remain aligned to the business objectives even as they change. Poor governance can mean the programme delivers against its originally defined goals but the organisation no longer cares.
The trouble with governance is that it can get horribly bureaucratic and slow down the desired transformation. This is another area where Agile can help. Agile governance is “the application of Lean-Agile values, principles and practices to the task of governance”. Agile brings good governance, i.e. alignment, without the bureaucracy.
What is the Adaptation thread?
A successful programme team must adapt to the events as they unfold. This is partly about retaining alignment with changing organisational strategy but equally about responding to unforeseen events. Here are some examples of unforeseen events that I’ve had to face. Some good, some not so:
The chosen technology is found to be wanting
Specialist staff are hard to find
A trial solution doesn’t offer the benefits hoped for
Half the development funding is withdrawn
one of the developers comes up with a stunningly innovative solution that will take half the time
The user adoption rate far exceeds projections
The programme starts delivering financial benefits a year ahead of schedule
So a programme manager and their team must adapt. However adaptation isn’t enough, they must also adapt quickly. This is where Agile comes in. Enabling the programme team, sponsors and other stakeholders to learn and act on that learning in a timely fashion. That increased responsiveness increases the benefits derived from the programme.
What is Programme Management?
A temporary flexible organization structure created to coordinate, direct and oversee the implementation of a set of related projects and activities in order to deliver outcomes and benefits related to an organization’s strategic objectives. A programme is likely to have a life that spans several years.
Where benefits are:
The measurable improvement resulting from an outcome perceived as an advantage by one or more stakeholders, and which contributes towards one or more organizational objective(s).
And programme management is:
The coordinated organization, direction and implementation of a dossier of projects and transformation activities (i.e. the programme) to achieve outcomes and realize benefits of strategic importance.
So a programme is intended to deliver capability (via projects) which, when utilised, results in business benefit. I like this because it helps clarify what a programme manager is meant to do as opposed to what a project manager does (for more on that see Difference between programme, project, portfolio and product management).
Conclusion
For me a project manager builds capability, a change manager rolls out the capability, and a programme manager uses both of these to deliver benefits – usually cash – back to the organisation.
What does the Programme Manager report on?
Risks, Issues, Budget, Milestones, Financial Benefits, Reach, etc, etc & Success Stories
What is the difference between Project and Programme risks?
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.
What are the 5 Ps?
product portfolio, programme, project portfolio, product, and project.
