While the factors leading to success or failure of an IT project are many, the choice of an appropriate development methodology is among the most important. These days, most companies are choosing to use “Waterfall,” “Agile,” or some combination of the two.
The Waterfall methodology is the traditional approach to software development. It follows a sequential blueprint laid out in an initial project plan, with all work streams agreeing to a single set of relatively fixed milestones. In addition to being inflexible, a disadvantage of this approach is that the intended business user (the primary customer) only gets the opportunity to provide feedback right before go-live during User Acceptance Testing. As a result, the Waterfall approach often leads to software delivery that is outdated, does not meet current customer needs, and/or requires rework due to misaligned expectations.
Given the rapid change driving today’s digital economy, customer preferences and needs often shift after that initial project “blueprint” is created. With the COVID-19 pandemic, for example, the business world has arguably seen even more disruption in the last year than in the last decade. Increasingly, the Agile software development methodology has become the framework of choice for many businesses where continuous change is the norm. By design, Agile is flexible, puts the customer (user) at the center, and demands collaboration. Agile facilitates frequent communication and alignment of goals among customers, developers, managers and testers, which helps software teams stay nimble and react quickly to shifting priorities.
Agile’s biggest contrast to Waterfall is that instead of working toward a single release at project close, it utilizes short, iterative release cycles known as “sprints” to facilitate concurrent requirements gathering, design, development, and testing activities in the software development process. While incorporating Agile methodologies into your software development lifecycle can go a long way towards aligning user and organizational needs in today’s quickly changing business environment, it takes more than a development framework to make an IT project successful. Systems, after all, are operated by people—ideally according to an established process and workflow. Hence, without effective change management to transform an organization’s operating model and equip users to be successful with a new technology, the desired value of the future state will be difficult to achieve. A survey conducted by the Society for Human Resource Management (SHRM) revealed that employee resistance (76%) to change is in fact one of the top reasons transformation efforts—like the ones underpinning system implementation—fail.
Organizational Change Management (OCM) practitioners apply a people-focused structure to business transitions to increase the likelihood that a transformation’s anticipated value is fully realized. Focusing on a path toward user adoption, OCM systematically addresses stakeholder discomfort with cultural, business, social, or other non-technical changes related to software implementation. However, traditional change management, built for a Waterfall environment with heavy process and lengthy timelines, doesn’t work well in an Agile project where collaboration and adaptation happen daily.
We often see our clients struggle with how to adapt change management approaches for the demands of an Agile project. In this blog, we’ll share our recommended best practices.
OCM Best Practices in Agile Implementations
Because of the iterative nature of Agile methodology and the level of churn this creates for users, the need for change management doesn’t go away but rather shifts in its nature and cadence – from a progressive, growing crescendo of significant interventions to brief, repeated interjections for a cyclical rhythm of software releases. Some unique challenges present themselves as a result. We recommend incorporating change management into your Agile project using the following guiding principles:
Start change management activities early in the project. While change management should be incorporated into every system implementation project plan from the earliest stages, it is particularly important to do so in an Agile environment where the lead time for change preparation is brief. As such, the OCM role should be viewed as an integral project team member from the start, with a voice in ongoing sprint prioritization and strategy discussions. A change manager should be able to speak to the mitigation of and preparation for user impacts in each release, acting in an advisory capacity throughout backlog prioritization and release preparation—rather than being a downstream resource for dissemination of information only.
Integrate change management into your project management methodology. Regardless of your project methodology, project managers in general are tasked with planning, preparation and risk assessment. Bearing in mind that employee resistance is a significant factor in IT project failure, organizational readiness should be tied into the project management strategy and assessed continually like any other risk. This risk assessment approach is especially important in an Agile project, where user preparation for change happens not at a single point-in-time but continuously, with varying degrees of impact to the business along the way that may be cumulative in nature. Organizations can help by providing structured tools and templates based on industry best practices and frameworks such as ADKAR (awareness, desire, knowledge, ability, and reinforcement) to assist the project manager in identifying and mitigating risks before they materialize.
Make change management cyclical. Change management in a Waterfall environment typically focuses on preparing for organizational readiness at a fixed endpoint (go-live). Change management in an Agile framework needs to equip users for a regular rhythm of changes over time, while also staying attuned to the overarching goals and business drivers associated with the product’s long-term strategy. Every good change management approach has common activities (e.g., leadership and stakeholder alignment, communication, training, and operating model design). In an Agile framework, these activities need to be performed in alignment with each sprint. Training, for example, must be focused and concise with an emphasis on delivering just-in-time user support and accessible, real-time learning aids that evolve with the product. Given the increased risk of change fatigue with a cyclical approach to change, every user interaction must be targeted, meaningful and meticulously efficient.
Make change management flexible and agile. Creation of a set change management plan and schedule doesn’t work in an Agile environment where system capabilities are constantly being developed, piloted, and adapted. Change management templates are less useful in an Agile framework as well, as the constant reprioritization of user-facing features offers less opportunity to predict and standardize. Instead, change practitioners in an Agile project must be creative and able to think on their feet; gauging how, when, and where to focus their efforts to achieve greatest user impact. In place of fixed change plans, we come prepared with a toolbox of strategies and client-tailored approaches that we mold and leverage in partnership with business leaders, to address the greatest opportunities and risks associated with each incremental change. Monitoring the effectiveness of change management through regular surveys or other user touch points becomes absolutely critical in an Agile environment as well so that the team can continuously refine and improve organizational readiness tactics.
Flexible resourcing. OCM resourcing needs vary across an Agile project, and the size and scope of the team may need to be adjusted based on user impact of any given sprint. Ideally, the OCM work stream will rely heavily on influential business representatives who can more quickly disseminate information through existing channels rather than relying on complex, formal training curricula. The use of a change network becomes particularly important in these projects where the turnaround time for assessing and reacting to organizational impacts is abbreviated. Relying on internal business experts who have already built spheres of influence within their organization will lend real-time insight and speed to the whole process.
Educate on Agile. Corporate cultures that are used to traditional phased development release cycles can feel overwhelmed by the shift to more frequent sprints and ongoing collaboration required by the Agile framework. If your organization is new to Agile, creating alignment and buy-in among project partners will be a change initiative on its own – one that will be critical to the ultimate success of your project(s). Engage OCM practitioners to provide education on both the software and the Agile process for all the teams who will be responsible for playing a role in delivering on the framework. This may include the project manager, business analysts, executives, users, developers, etc. The OCM lead should have extensive experience with the Agile approach and be able to explain both the process and benefits to key stakeholders. The OCM lead should also take an active role in evaluating and managing the Agile process impacts on project sponsors and key stakeholders. As in any transformation initiative, a formal resistance management plan that features increased communication emphasizing the “why” of both Agile methodology and the project can help build stakeholder buy-in for both concurrently and equip team members to harness the full power of what Agile has to offer.
Conclusion
As described in this blog, Agile requires more OCM activity than traditional approaches, not less. Agile OCM practitioners apply a flexible, constantly evolving collection of tools that, like the software itself, begins with a minimum viable product (MVP) and then expands and evolves based on key performance indicators (KPIs) and user feedback. Important factors to look out for that will indicate whether your organization is managing a digital transformation well include:
- Risk mitigation – Risks associated with organizational readiness are accurately anticipated and mitigated timely.
- Business engagement – Business leads are engaged early and often in the requirement and testing processes, and their teams are aware of the change.
- Active Leadership – Leadership sponsors are visible and enthusiastic about the value of the change.
- Collaborative Support – User support plans for during and after implementation are documented in advance, with business partnership.
- User Adoption – User participation and compliance rates achieve targets quickly after implementation and are sustained.
Companies looking to accomplish effective OCM in an Agile development environment will need more than just a collection of change specialists. Organizations should seek to develop a mature internal OCM capability that can plug into and deliver rapid value within Agile projects on an as-needed basis. Where internal expertise is lacking, skilled external OCM partner(s) should be engaged to facilitate effective OCM and help lend credibility to agile methodology within your organization through stakeholder education.
