Leading successful change

A project creates outputs; change happens when people start working differently because of them. PRINCE2 7 treats leading successful change as a core part of the people element. It recognizes that the project manager is rarely responsible for the whole organizational change, which usually belongs to the business, but that the project must be designed so that change can happen. That means understanding who will be affected, planning the products that help them change, working with the people who lead change in the business and handing over in a way that supports adoption. This lesson explains how to do that with a PRINCE2 lens. General change theory is covered more fully in BUS-130.

Project management and change management

Project management delivers products within agreed constraints. Change management helps people move from the current state, how they work today, to the target state, how they will work in future. The two overlap but are not the same. A project can be well managed and still fail to produce change if nobody prepares people for it. A change can be well led and still fail if the project delivers late or poorly. Successful initiatives integrate both: change activities are planned as products, scheduled alongside specialist products and reported through the same controls.

Current state, transition and target state

Change is often pictured as a journey through three states. The current state is familiar, even if imperfect. The target state is where the organization wants to be. Between them is a transition in which old ways have stopped working and new ways are not yet comfortable. Performance commonly dips during transition as people learn new tools and processes, make mistakes and lose confidence. The depth and length of the dip depend on how well the change is prepared and supported.

The change curve is a simplification, and some people adopt change quickly with little dip at all. It is still useful for planning, because it reminds the project and the business that benefits rarely start on the day of go-live. Business cases that assume full benefits from day one, with no transition cost, are usually optimistic.

Who leads change

PRINCE2 is clear that the business, not the project, owns the outcomes and benefits. The senior user is accountable on the board for making sure the products will meet user needs and that the expected benefits can be realized. In many organizations, particularly those running programs, a business change manager or change lead works within the business to prepare people and embed new ways of working. Line managers are often the most influential people of all, because staff look to their direct manager for signals about whether a change matters.

The project manager's role is to make sure the project supports these leaders. That means involving them in planning, including their change products in the project plan, giving them early sight of products so they can prepare their people, and agreeing clear handover arrangements. A project manager who tries to lead the business change single-handedly, without business leaders visibly owning it, will usually struggle, because staff take their cues from their own management.

Change impact assessment

Before planning change activities, the project needs to understand who will be affected and how much. A change impact assessment lists the groups affected, what will change for each, how significant the change is and when it will happen. It draws on the user representatives and the business change manager, and it feeds the plans, the risk register and the communication management approach.

Readiness and resistance

Readiness is the degree to which people are prepared to adopt a change. It can be assessed through surveys, interviews and observation, and it changes over time. Common dimensions include understanding why the change is happening, believing it is worthwhile, having the skills and tools, having time to learn and feeling supported by managers.

Resistance is a normal response to change, not a sign that people are difficult. People resist for reasons: fear of losing status or competence, doubts that the change will work, poor past experiences, extra workload during transition or simple lack of information. Treating resistance as information is more useful than treating it as opposition. If experienced staff say the new process will not work at month end, they may be right, and their insight could prevent a failure. In PRINCE2 terms, legitimate concerns about products should become issues or risks and be handled through the usual controls.

Change products in the plan

The most practical way to integrate change into a PRINCE2 project is to treat change activities as products. Training materials, a training schedule, support arrangements, communications, revised process documents, updated role descriptions and a readiness assessment can all be planned as products with product descriptions, quality criteria, owners and dates. They then appear in the product breakdown structure, are estimated, are given to teams as work packages and are tracked through checkpoint and highlight reports.

Handover and benefits after closure

PRINCE2 projects close when their products are handed over, but change and benefits often continue long afterward. The closing process should confirm that users have accepted the products, that operations and support are ready to take ownership, that follow-on actions are recorded and that the benefits management approach describes how and when benefits will be measured after the project. The people side of handover includes making sure support staff are trained, that super-users and champions remain in place for a period, and that line managers know how to sustain the new ways of working.

A useful test before closure is to ask: if the project team disappeared tomorrow, would people keep working the new way? If the answer is no, more change support may be needed, or follow-on actions must be clearly owned by the business.

Measuring adoption after go-live

Adoption should be measured, not assumed. Useful measures include the share of transactions handled in the new way, the number of people using the new tool each week, help desk calls per user, error rates and user satisfaction. The benefits management approach should say which measures will be used, who will collect them and when. In the first weeks after go-live, the project and the business should review these measures frequently so that support can be targeted at teams or locations that are struggling. A single average can hide a team that has not adopted the change at all.