| 1 | 2 | 3 | 4 | 5 |
| Develop the business case | Programmes funded without formal business cases. Little mention of benefits | Business cases are documented but read as requests for funding. Benefits are either not mentioned or are generalised and intangible | Business case is documented. Tangible and intangible benefits are listed but benefit quantification is anecdotal | Business case fully documented. Benefits address business pain points. Financial case demonstrated as improvement to recognisable and measurable KPIs | Benefits address strategic issues and pain points. Financial case demonstrates shareholder value through improvement to economic KPIs over defined time period. |
| Define the architecture and end-state | The target end-state is not known at the outset. Little thought put in to how project deliverables combine to deliver the overall programme outcome. | Programmes expect to deliver a number of solutions, but not all are clearly understood at outset. Some technical solutions are anticipated but they are isolated. Business solutions are not considered | Programmes expect to deliver a number of technical solutions, which are individually understood. There is some understanding as to how they will fit together. Business solutions are partially understood. | Programmes start with a high level blueprint that illustrates how various technical outputs will interact to deliver the desired outcome. There is come consideration of business solutions. Blueprints evolve with programme delivery. | Programmes start with a high level blueprint that shows how technical and business elements will interact together. The blueprint is optimised for scalability, re-use and efficiency whilst maximising modularity to minimise dependencies. |
| Plan and estimate | Plans are either developed at a very high level or not documented at all. Estimates are based on gut feel rather than evidence. | Estimates are based on an assessment of tasks to do, but tasks are not granular. Little consideration of contingency. Plans are documented in spread sheets and updated infrequently | Plans and estimates are developed bottom-up from knowledge of granular tasks. Contingency is applied. Planning tools are used to document detailed plans. Summary plans show overall milestones. Plans are regularly updated. | Estimates are made both bottom up from tasks and top down by comparison with previous programmes. Detailed plans roll-up into summary plans. Critical paths are identified and tracked. | Estimates are based on a variety of sources including formal methods such as Function Point analysis. Advanced planning and tracking tools are used to capture and report progress, predict slippage and generate project metrics to improve the estimation process. |
| Delivery Focus | Programmes tend to be absorbed into Business as Usual with little focus on specific milestones and timescales. Deliveries frequently slip with little consequence. Progress is rarely reported. | Programmes work to a plan, but milestones frequently slip and have to be re-baselined. There is little formality over deliverables. Progress reports are ad-hoc and informal | Programme team push to deliver the plan. Some milestones are met after slight slippage. There is some formality around production and signoff of deliverables. There are regular progress reports to senior stakeholders. | Most milestones are met. Slippage is tracked and used to further inform plans. Earned value is demonstrated. A mix of methods is used to optimise communications within the programme team and with external stakeholders. | Programme team deliver as if they were an independent commercial organisation. All milestones hit on time. All deliverables formally accepted. Programme team focus on benefit delivery in addition to project deliverables. |
| Effectively manage resources | Staff are engaged on an ad-hoc basis. Finances and budgets are not clearly defined or managed and may not be separate from Business as Usual finances. | Programmes have allocated budgets but they may not be actively managed. Staff are allocated on an informal and part-time basis. External suppliers may be engaged but are not actively managed. | Programmes have small, dedicated core teams with a mix of experience. Budgets are actively managed and tracked. External suppliers are incentivised to deliver through their contracts. | Programmes have experienced leaders and teams who are dedicated to the programme. All resource usage is tracked with timecards. External suppliers are actively managed against their contractual obligations. | Programmes have resource managers to ensure optimal efficiency and skill usage. Programmes are seen as a means of skills development and training: New staff are rotated through roles to build organisational capability. |
| Mitigate risks and dependencies | There is little if any consideration or management of risks, issues or dependencies during the programme lifecycle | Risks are considered at the start of the programme only. Dependencies are only considered within individual projects. | Risks and dependencies are regularly captured but managed on an ad-hoc basis and generally at an individual project level. | Risks are regularly captured, managed and tracked, primarily by managers. Dependencies are identified at a project and cross-project level and teams actively seek to break them. | Tools are used to ensure risks and dependencies can be captured, managed and tracked by all programme staff. Management use scenario planning and decision trees to minimise impact of risks and dependencies. |
| Release benefits | Programmes may mention benefits at the outset but generally do not consider how they would be released | Programmes start with the intention of delivering benefits, but reduce to focusing project solutions and deliverables. Projects conclude once deliverables have been accepted. | Programmes may start with a number of benefits but end up focussing on one or two key areas where the benefits are most obvious or easy to achieve. Some work streams may extend into benefits delivery. | Programmes produce benefit delivery plans which link project deliverables through to benefits with owners and related KPIs. Programmes have explicit benefits delivery phase. | Tracking and reporting of benefits built into Business as Usual processes. Responsibility for benefit delivery built into targets for benefits owners. |
| 1 | 2 | 3 | 4 | 5 |
| Create the case for change | Programmes do not generally articulate the need for change and the anticipated benefits. There is no clear understanding of how the change will impact different groups across the organisations or the need to sell the change to staff. | Programmes present a rationale for change but reasons are high-level and generic, and benefit statements are intangible. There may be some understanding of the cost of change, but messages are not tailored for individual audiences or stakeholder groups. | Programmes present a coherent case for change. Tangible and intangible benefits are clear and specific. The cost of change is identified at a high level and there is a basic understanding of the impact of change on key groups. | Cases for change are well presented and logically structured, laying out tiers of benefit as well as the consequences of inaction. The impact of change and its cost to individual groups is understood. Wins and benefits are tailored to individual groups to overcome the costs and provide an incentive for engagement. | Cases for change lay out a compelling future vision that addresses the needs and concerns of all affected groups. The case is credible, engaging and describes the journey for each group. Stakeholder wins are scheduled for regular delivery to ensure on-going support for the programme. |
| Design the future business | Programmes do not formally map out the target state for the business. There is an acceptance that programmes may introduce process or organisational changes but there is no concept of business, process or organisational design. | Programmes recognise that process and organisational changes will be made but the organisation lacks process or organisational design skills. Programmes therefore have little structure to their approach. End states are not described coherently and are rarely complete. | Some programmes consider target state but do not produce a formal Target Operating Model (TOM). Programmes do undertake some process and organisational design, but these are managed as discrete activities or separate work streams. Consequently, solutions may be fragmented and opportunities for radical change may be missed. | Programmes start with a TOM that drives process and organisational design. Design is top-down and comprehensive, considering and discounting options. Wider staff groups are used to validate options and designs. Programmes have tools and techniques for structured process and organisational design, ensuring timely integration with technology delivery streams. | TOMs are modelled and optimised to deliver programme outcomes and benefits. Process and organisation changes are designed with the business to optimise TOM delivery. Design states show a path through the intermediate stages of transformation enabling impact of change to be understood and recognised by each stakeholder group. |
| Secure leadership commitment | Programmes do not define which leaders within the business will be critical in making the change successful. Leadership roles do not generally change as a result of programmes. Programmes tend to be led by existing management teams. | Programmes understand which leaders are important but do not engage those leaders beyond the programme, focusing primarily on the programme sponsor or immediate programme board. Leadership engagement generally restricted to upwards reporting of status. | Programmes create stakeholder maps and plans to engage different stakeholder groups and their leaders. Communications with leaders are on-going but ad-hoc. Feedback may be solicited but there is no formal mechanism for incorporating it into the programme. Programmes tend to work in isolation from each other. | Experienced and committed sponsors guide programmes to deliver goals and help overcome blockers. Leaders beyond the programme understand goals and receive regular updates to enable them to align their own programmes and activities. | Sponsors and other leaders lead by example e.g. by accepting new performance targets based on successful change outcomes. They act as advocates, passionately extolling the virtues of the programme. |
| Engage the staff | Programme communications are generally internal to the programme. External communications are restricted to programme board representatives. Generally there is little appreciation that a wider audience should be engaged to make the change happen. | Programmes make periodic announcements to directly affected staff and occasionally to wider organisation. Broadcasts may be focussed on programme internal processes and rarely tailored to audience. Feedback is generally not sought. | Programmes communicate to staff directly and indirectly affected using a variety of media and against a pre-defined plan. Communications plans are based on stakeholder segments. Staff feedback is solicited on an ad-hoc basis but there is no formal mechanism for incorporating it into the programme. | Programmes communicate regularly to staff and actively seek feedback and suggestions through a variety of formal and informal channels. Staff champions are able to directly engage and contribute to the shape of programmes. Programme actively monitors and responds to staff sentiment. | All people impacted are clear on what change means for them, and excited about the future. Key messages are relevant to them and reinforced through multiple channels, including from their own leaders. Staff are able to contribute and engage directly with programme activities and feel their input is making a difference. |
| Roll out new ways of working | There is little recognition that things need to be done differently if a programme outcome is to be achieved. New ways of working are generally considered to be the use of new tools or technology. Programmes do not consider the ability of staff to work in new ways. | Programmes recognise that things must be done differently if outcomes are to be achieved. New ways of working are generally rolled out by training staff in new tools and technologies or by updating corporate policies. Business process changes may be developed ad-hoc and retrospectively to fit around systems. | Programmes design and develop new ways of working top-down and train staff in new processes and systems. Programmes do not go as far as to consider staff capabilities and ability to adapt to new ways of working. Training is delivered by individual workstream so staff may be hit with a number of disconnected training activities. | Programmes develop a variety of training methods and engage advocates in the business to promote, demonstrate and support the new ways of working. Programmes anticipate impact on staff groups and roll out changes to give them the best possible experience. | Feedback and suggestions are regularly captured and implemented. Measurement is established to monitor take-up of new ways of working and the translation into benefits. Capabilities are embedded into staff targets, role descriptions and career paths. Recruitment processes are updated to reflect required staff competencies. |
| Reinforce behaviours | There is little recognition that people need to behave differently if a programme outcome is to be achieved. Current and desired staff behaviours are not considered and programmes do not attempt to change them. | Programmes recognise that staff need to exhibit new behaviours if programme outcomes are to be achieved, but have little understanding of how to promote the new behaviours or maintain them. Programmes therefore rarely manage to change staff behaviour. | Programmes understand which new behaviours staff must exhibit to achieve the desired outcome. However, new behaviours are generally asserted by the programme (e.g. top-down by regular management announcement). Staff targets are modified to try and reinforce the behaviour but focus on KPIs that could be achieved by other means. | Programmes identify current unwanted behaviours and new desired behaviours, and design incentive mechanisms and schemes at role level to promote and reinforce change. Staff are individually evaluated on their behaviours and are given coaching plans. Staff who consistently demonstrate desired behaviours are promoted as role models | Programmes embed behavioural scoring into staff targets, role descriptions and career paths. Leaders are selected and rewarded based on their ability to demonstrate the required behaviours and values. Staff who consistently demonstrate desired behaviours are fast-tracked into coaching and leadership positions. Recruitment processes reflect desired behaviours. |
