- Programme Management
- In a nutshell
- Common questions
- What is a programme?
- How does a programme differ from a project?
- For which projects do I need a programme?
- Pros and cons of programmes
- Are there different types of programme?
- How do I justify a programme?
- The vision and the blueprint
- Do I need a programme office?
- How do I start running a programme?
- Who needs to be involved?
- The key role of benefits
- How do I manage benefits realisation?
- How do I manage scarce resources?
- Running programmes
- Ending programmes
- Want to know more?
Having got this far and having done the majority of the hard work of planning and preparation, it is now time to get on with the work (assuming the approval for the programme has been given). The overriding aim for those involved with the programme governance structure is to assist and be supportive of the work of their projects and other activities. It is very clearly not about sitting on top of the projects, preventing them from working efficiently. After all, it is the senior responsible owner or sponsor who wants the programme to succeed; they need the work to be completed effectively and efficiently if they are be successful in delivering their vision of the future.
What else do I need to know?
Programme planning is rather different from the normal project planning with which many might be familiar. It is not necessarily appropriate, for example, to produce some sort of giant Gantt chart combining all the project plans into one big sheet. This is probably not a picture that decision makers can use to determine the strategic progress of the programme. It is likely that a time line, with the dates of key deliverables noted, together with their key dependencies and enablers, might be more useful.
One thing that is clear is that too much detail of project deliverables and activities is not useful to those trying to make strategic decisions. There will always be a danger that the more senior people in a programme organisation will want to get involved at the lower detail levels of the projects and this is not helpful. It is far better that the senior people deal with the strategic issues, leaving the day-to-day running of the projects to those directly involved.
Reducing the detail of the lowest levels of work visible to the senior management is one method of reducing their direct involvement.
Progress measurement can be achieved at a high level by checking against key milestones. These milestones could, for example, be the delivery of specific products, the achievement of particular benefits or the expenditure of significant sums of money.
One clear indicator of poor management is the frequent movement of key milestones. Good management should maintain set milestones and allow other less critical things to be moved around them to enable each milestone to happen in a timely and efficient manner. If milestones are regularly being moved, this suggests the overall management is not as effective as it should be.
As with much in project and programme management, reporting by exception is the most effective and efficient management process. Regular reports against an agreed plan can be provided at intervals to suit the governance structure – monthly would probably be about right for a programme. Meetings of the management board would only need to be called when a decision was needed or when something had gone awry and needed fixing. Meetings should also be held at the delivery of key benefits – a review of the progress so far at an appropriate interval or event.
Tracking resource usage and financial spend at a high level is clearly a necessary part of programme management and ensuring that higher priority projects receive the necessary attention and support should form part of this. The management of risk at this level is about checking the situation with regard to strategic risks and also the inter-dependencies of risk which might affect two or more projects. Issues that are raised for the programme team to solve need to be dealt with quickly and decisively if the work of the projects is not to be hindered unduly. These issues could be unforeseen problems, change requests or risks that have occurred, but in any event, time does not stand still and the work should continue if deadlines are to be met.
What does quality look like in a programme?
Quality in a programme is a little different from quality in a project. In a project, it is all about the products it is producing – the deliverables. Do they meet the users’ requirements and are they fit for purpose? Checking quality is done by those creating the products with approval sought from the end users. This should not be affected by being part of a programme.
In a programme, it is very much less about the products and much more about the processes in use in the management of the programme and projects. To that end, it may be entirely appropriate for the programme management team to have a group of independent assessors, who check on the work of the programme and the projects in an assurance-type role. They should check that the right degree of control is being exerted without the team being overbearing in terms of the way project managers and their teams are operating.
Naturally, the quality of the things being produced within the programme is still important, but this should be left in the main to those in the projects, with little interference from the programme team, except where there is a key issue of inter-project dependency. When the product of one project is required to be supplied to another project for further development, for example, it may well be there is a role for the programme manager to undertake as overseer of the quality of the specific deliverable.
Where quality in a programme really comes into its own, though, is when the benefits start to accrue. The quality of the benefits, their definitions, measurements and monitoring are crucial to the overall success of the programme. The benefits are why the programme is being undertaken in the first place. It is, then, the work of the business change managers and change agents that should really be the main target of the quality assurance team. The preparation for implementation and the transfer into the new ways of working are key areas where the quality card must be played forcefully.
What about the stakeholders and communications?
Stakeholders can be defined as those people:
- Who will want to see and use the end results
- On whom the programme will have an impact
- Who will have some control or influence over the programme.
Stakeholder analysis should have been completed at the start of the programme in order to understand to whom communications need to be sent during the programme, what sort of communications will be sent and, most importantly, what the feedback loop will look like and how it will be operated. The programme should be the sole source of information about all the work going on within it to avoid one project giving out information which is contrary to that given out by another project. A single message source should mean a single agreed message for all stakeholders and also a single source for requesting further information or clarification. This is not to say that all stakeholders should receive the same message, some variation is vital and inevitable, but the messages must all be based on the same essential facts and present a unified picture overall.
Stakeholder communications is perhaps one of the most important areas of a programme’s work. Without it, a programme can fail spectacularly, due in part to misinformation or the poor management of expectations due to poor communications. The analysis of the stakeholders must include an assessment of the importance of specific individuals or groups of stakeholders and how they perceive the programme being undertaken. These people must be given the right information at the right time by the right messenger if it is to achieve the right effect. If they are people with influence over the programme, the importance of the information they receive rises significantly.
The end users, those perhaps most affected by the implementations from the programme, are also key recipients of information from the programme. There is a tendency to set up a website and to send out copious numbers of emails as a way of dealing with this requirement. While these are both good measures and can be very effective, they are not the complete solution. Care must be taken to match the importance of the communication to the medium or channel used. For critical information, a mass email is likely to be very much less effective than perhaps a briefing or a DVD. The message sent out by the programme manager is likely to carry much less weight and authority than the one fronted by the CEO.
Caution must be exercised when recording details of stakeholders and their position in order to enable effective communications to be targeted at them. The document can become very sensitive and it is wise to be very careful about its accessibility and distribution. Nevertheless it is vital that such information is available to a few key people to ensure effective communications are maintained.