By: Thomas Bertels (Partner, Valeocon)

The shared services project that was shelved halfway through the design phase because the parent company decided to sell one of its three business units. The process redesign effort that never got fully implemented. The ERP system deployment that limped to the finish line, with nobody involved willing to do a post-mortem analysis of the business impact. Three examples of those countless attempts to change the way work gets done that failed to deliver. Why?

When it comes to undertaking significant transformations – creating a shared services organization, reengineering a major business process, designing a new organizational structure, or implementing a new performance management system – the approach most organizations use is based on outdated assumptions. This article examines why the traditional approach is no longer suitable for delivering value, and proposes as a remedy a framework based on agile principles.

The Traditional Model: Slow and Steady Wins the Race

The typical starting point for any transformation is the recognition of a problem or opportunity and the chartering of an initiative, program, or project. Once initiated, the first step is usually an extensive exercise to develop the business case and make the case for change. Over the course of the analysis, the data gets condensed, consolidated, and socialized, up to the point where the final decision-makers are presented with an executive summary that contains only the most pertinent information.

If the project gets approved and funded, it moves to the design phase, where teams tackle the various aspects of the project: define the required technology, design business processes, develop change management and communications plans, define key performance indicators, and of course provide governance. These teams work in parallel towards developing a detailed solution. Executives review progress from time to time and provide input as needed, and on occasion request course corrections. Once the detailed design is completed and approved, implementation starts. At this point, senior management moves on to the next challenge. The design is often handed over to the line managers who are charged with executing the plan. Change and communications efforts kick into high gear, aimed at convincing those impacted that the change is necessary, a really good idea, and quite frankly inevitable.

Moving from issue identification to implementation often takes several years, with the expectation that once fully implemented the organization will enjoy the benefits for many years to come.

Executives today live in a VUCA world – volatile, unpredictable, complex, and ambiguous:

• More change efforts: In most large organizations, at any given point in time, there are hundreds of significant change efforts underway, ranging from large-scale corporate programs (creating shared services or integrating acquisitions) to functional or local efforts. Initiatives to reduce the number of active programs almost always fizzle out after a few months. Coordinating all these projects to avoid overlap, conflicts, confusion, and fatigue requires Herculean effort.
• Longer project durations: The time required to execute on a major change effort has increased substantially. The drive to have “business led” change efforts has dramatically increased the number of stakeholders whose opinions and perspectives need to be considered. The increased dependencies and complexities of today’s challenges and solutions means initiatives take longer.
• Shorter solution lifespans: At the same time, the life expectancy of the solutions once implemented are a lot shorter than they used to be. The rate of technological progress has accelerated to the point where major information systems need to be replaced every couple of years. Organizational structures are often only valid until a new leader arrives or a major acquisition occurs.
• Limited bandwidth: During the last financial crisis, companies across all industries dramatically reduced staff. As a result, many firms now have a very limited pool of discretionary resources available to execute projects in addition to running the current business. These limited resources are often stretched so thin across multiple projects that it further slows down project execution.
• Frequent leadership changes: It is rare to have the same executive oversee problem identification, analysis, design, and implementation. New leaders almost always slow down projects already underway as they review the progress made or make course corrections.

The result? Many transformation efforts are abandoned half way through or require extensive course corrections. Others limp to the finish line, delivering only a fraction of the expected business value. And even if the effort is completed as planned, the resulting solution is often obsolete by the time it can be implemented or rejected by those who have to live with it as no longer fit-for-purpose.

Various studies put the success rate of business transformation at less than 30%. Yet, most executives persist with the traditional model in the belief that the organization will execute better next time.

Take an Agile Approach to Drive Business Transformation

In the domain of software, many companies have experienced the power of Agile, where motivated, self-organized individuals deliver working software quickly, collaborate closely with customers, and respond to changing requirements rapidly. Applying the agile framework to business transformation suggests a number of core principles leaders can use to overcome the limitations of the traditional model:

Accept ‘good enough’: Most transformation efforts assume that once the change is implemented, the organization will be able to reap the rewards for an extended period of time. The reality is that most of these efforts have a very limited lifespan. Changing the perspective from “build to last” to “a workable solution for the next two years” can be powerful: instead of overinvesting in analysis to get it 100% right, good enough becomes the new design principle. Instead of assuming that the solution to the problem needs to be complete and address all the requirements, the focus is on ‘satisficing’ – satisfying the minimum requirements and maximizing the amount of work that will not get done.

The principle of ‘good enough’ not only means narrowing the scope to a small number of specific objectives that really matter, but also limiting the analysis and design efforts to what is truly critical. Focusing on designing and implementing working solutions prevents agile organizations from analysis-paralysis. For many, this is a huge mindset and behavior change as it will also require leaders to make timely decisions, with not all information at hand and the willingness to make trade-offs. Most change efforts start with a long diagnostic phase during which huge amount of data is collected, analyzed and nicely summarized in beautifully crafted presentations. This is usually followed by long discussions of the findings and multiple revisions of the presentation until everyone ‘can live with it’.

Often, a small number of initial stakeholder interviews is sufficient to determine ‘true north’ – the direction the project needs to take. Consider the analogy of driving from New York to Montreal – heading north is probably not a bad idea, and the course can always be adjusted as the journey proceeds.

Focusing on a general direction instead of mapping out every single step creates degrees of freedom for those chartered with helping the organization get there.

Design concurrently: The actual work that needs to be done to deliver the transformation is often broken up into separate work streams. The organization work stream looks at the design, the process work stream analyzes the current process and designs the future state, the change management work stream considers how to sell the employees on why this change needs to happen (often with poor results), program management makes sure everybody is coordinated, and so on. But by focusing on the parts, crucial connections are not made and the result is often a piecemeal approach that – while on paper looks logical – rarely comes together and delivers the expected results. The agile model commits to a concurrent design approach by having interdisciplinary, co-located teams address all the dimensions of a change effort, breaking down artificial barriers. As most change efforts are complex by nature, work is organized into discrete deliverables that can be accomplished within the confines of a sprint.

Provide real-time leadership: A culture where executives sit in judgment and wait for polished reports from the teams is ill-suited for an agile transformation model. Success with agile requires leaders to provide direction and make decisions with limited information in real time. If the organization’s culture is heavily geared towards careful planning and orchestration, an agile approach is likely to fail. Agile requires a willingness of those overseeing the effort to accept failures, work with ‘duct tape’ prototypes, and take risks. Program sponsors must accept the responsibility of providing a safe environment for the project team.

Run sprints: Whereas traditional transformation efforts typically run for many months, an agile approach is based on short, focused sprints of no more than three to four months. Compressing the timeframe helps to ensure focus on what really matters, allows for course corrections, and minimizes the risk of disruption due to unanticipated events such as mergers, reorganizations, or changes in business conditions. The agile model breaks the overall journey into manageable chunks, each designed to deliver value, and allows for incremental adjustments based on timely stakeholder feedback. This requires a change in funding models to reflect the incremental nature of agile, shifting from a detailed analysis and business case towards a ‘good enough’, high-level case for funding and ongoing refinement of the business case based on the learnings from each agile sprint.

What makes the Agile model so appealing is that is avoids the many wastes associated with the traditional model:

• Resources wasted on efforts abandoned prior to full implementation
• Over-investment in analysis given the inability to accurately forecast the future
• Time lost due to over-planning and over-documentation
• Delays in decision-making due to lack of real-time executive involvement

No Silver Bullet

A word of caution: this approach is not appropriate for every transformation effort and for every organization. Using a ‘pure’ agile approach in an organization whose culture, processes, and structure are not ready for the challenge is a recipe for disaster and chaos. Agile is not easy – it requires active executive involvement, employees willing to take ownership, decisions to be made with limited data, the ability to execute quickly, and the willingness to make mistakes and learn by doing. Some efforts require a very careful analysis and benefit from a waterfall approach. If experimentation and failure is not an option, an agile approach is ill suited and should be avoided.

Give Agile a Chance

Both the traditional and the agile approach are viable – and smart leaders will rely on both to execute on their change agenda. We suggest applying an agile mindset towards making the transition – incorporating some of the principles and using carefully designed, well supported experiments to build agile competencies and muscle.

In an ever-changing, unpredictable, world where business targets and expectations are in constant flux, it takes a nimble, flexible – agile – approach for transformations to succeed.