Change managers know from the outset of a change journey that when embarking on large scale change it is close to impossible and likely unwise to define each change element in detail. Experienced change managers quickly learn change initiatives require a high level of flexibility. Often change starts with an idea, be it an opportunity or a response to a critical event. As the change vision starts to take shape, the discovery phase commences. As change always has ambiguity, a cycle of discovery and learning will continue throughout the change process.

This process of continuous discovery and learning will likely result in revisions to the change initiative scope, with possible revisions to the outcomes sought, the initiatives that make up the programme of change, as well as necessary adaptions to the selected delivery and stakeholder engagement approaches.

Flexibility and agility therefore become important attributes when managing broad-scale change. Leaders of change, financial sponsors, those managing as well as those impacted by the planned change, need to buy-in to this idea of flexibility and agility. The challenge being, we’ve been taught to manage scope tightly as a mechanism to achieve timelines and deliver within budget. Though what is of most importance when assessing the success of a change initiative? Is it time or budget or realization of outcomes sought? The answer is the latter. This, however does not mean budget and timelines are not important, they are of importance and do need control, but it is the outcomes sought that drives change. For change with high levels of ambiguity, it is inevitable fixed time and cost will need to flex. Judgements need to be made with spend and timelines as part of the considerations in reaching a balanced decision, with outcomes front of mind. We can refer this as an outcome-focused approach.

Ambiguity is a common characteristic of all change initiatives, as change is a future-focused activity where no one can be certain on what will happen next. Levels of ambiguity is hard to measure, influenced by the degree of change: size/scope of change, levels of emotional and financial investment required, capability shift needed to achieve outcomes sought, organizational change capability. Knowing what is ambiguous, however allows us to frame risks associated with change.

It is not possible to remove all risks associated with a change nor is it always necessary to reduce risks as far as possible. By understanding of areas of ambiguity and risks levels, choices need to be made with ‘eyes-open’.

Change teams will always need to deal with ambiguity, this is why a highly important attribute for change sponsors, change managers and change agents is that they are people comfortable with working with high levels of uncertainty.

Adopting a flexible approach, underpinned by iterative and incremental delivery, together with being open to changing requirements are often promoted as important practices underpinning agile approaches and methods. These practices have also been applied for a long time as important practices for successful management of broad-scale change.

Iterative and incremental delivery in an agile product delivery environment is often described as a practice where product requirements and product development evolves over time in conjunction with a cycle of regular product releases within fixed time-boxes (or ‘sprints’). The alternative to this development approach is an environment where all product requirements are considered prior to development, often referred to as a ‘waterfall’ approach. Some of the benefits of iterative and incremental development is that it allows the solution development team, under the guidance of a product owner:

• Adapt a product’s functions and/or features as they receive feedback from the users of early product releases
• Enables adaption to changing requirements
• Enables an approach for dealing with high levels of ambiguity
• Higher potential for early outcome realization, as users and customers have access to a product of value earlier, even if only in rudimentary form.

Where solution development teams tend to be focused on incremental delivery of products, change managers are adopting a similar approach, though the focus of change managers will be on incremental delivery of capabilities and realization of outcomes and benefits. Further, prioritizing and managing outcomes and benefits, so as to realize them as early as possible. 

Agile programme management principles in a bit more detail

• Programme goals are clearly and continuously aligned to business strategy
  • The vision and goals of large-scale change should be reviewed regularly, especially in light of any changes to business strategy, ensuring the change and its parts remain aligned to business priorities
• Benefits are realized incrementally and as early as possible
  • In an agile programme, capabilities are delivered incrementally. Prioritize capabilities to reflect benefits prioritization and only planning in detail capabilities that can be enabled in the short-term. As capabilities are transitioned and embedded the change effort continues to achievement of prioritized outcomes and benefits.
• Governance is focused on creating a coherent capability
  • Applying governance processes that: allows autonomy, ensures synchronization of projects, permits project synergies to be exploited, assures coherent capability across the organization, assures realization of benefits, tracks continuous alignment with the change vision.
• Decision-making powers are delegated to the lowest possible level
  • Empower leaders and managers of projects/sub initiatives to take decisions quickly and effectively, without undue interference.
• Agile programmes are iterative and have the ability to contain both Agile and non-Agile projects
  • Non-agile techniques, such as the previously mentioned, ‘waterfall’ approach, do also enable project teams to deal with ambiguity. Even if a preference exists within the programme to adopt an iterative and incremental approach for delivery of all projects/sub initiatives, this may not be possible due to the nature of the product being developed, contractual constraints or capability of the team. It is important that the project/sub initiative delivery approach selected is understood, agreed to and the team possesses the knowledge and skills to apply the preferred delivery approach. Hence, it is possible and may be most appropriate in certain environments to have a combination of agile and non-agile approaches being adopted to deliver projects/sub-initiatives within the programme of change.

Seeking to learn more about managing change and integrating agile principles and practices? Speak to a HiLogic trainer or coach to discuss your change and agile training and certification coaching requirements. Hilogic experts also provides PRINCE2 training in Melbourne and Perth and Agile learning in Malaysia.