IT Change Management Redux: The Importance of Time

For two of my most recent blog post articles, IT Change Management and Key Stakeholder Relationships, I received wonderful feedback on specific details that I either neglected to include or did not explain in enough detail.  Thanks to everyone who commented to me directly or on the Slack and Discord boards.  I am working on my second response (Key Stakeholder Relationship Changes) and hope to have that out next week.

In the meantime, regarding the June 17th article on standardizing your approach to IT Change Management, several folks told me I was too vague regarding providing time assessments in that article.  Some of the points I made were:

“...if you don’t measure the changes, how will you know if your change management efforts are truly successful? The answer lies in measuring key metrics and KPIs that provide valuable insights into the effectiveness of your initiatives…”

“...by tracking the percentage of employees who have embraced the change and are actively utilizing the new tools, you can gauge the effectiveness of your change management efforts. High adoption rates suggest that your communication, training, and support strategies are working, while low adoption rates may signal the need for additional interventions…”

“...One key strategy for managing change fatigue is carefully prioritizing and sequencing change initiatives. Rather than launching multiple projects simultaneously, IT leaders should assess the urgency and impact of each initiative and develop a phased approach that allows employees to adapt to one change before introducing another…”

“...By providing a clear roadmap and timeline for change, leaders can help employees understand what to expect and reduce the sense of uncertainty and chaos that often contributes to change fatigue.  There is no secret formula for how many changes an organization can withstand in a given time period. Still, as you learn how well your organization adapts, you should calculate time buffers between appropriate changes and ensure that fatigue does not set in…”

As you can see, it is far easier to throw around a few abstract sentences about the notion of time when it comes to change management. It is certainly far easier than to plan and actually account for it on an operating scale. I certainly did leave too much on the table. My bad!

However, the same nebulous nature of time allows everyone who oversees IT Change Management to adapt the entire concept to their specific culture. Therefore, there is no one perfect timescale or equivalent that will work for everyone. Still, that weak excuse doesn’t absolve me from at least trying, so I wanted to take a bit to explain, from my perspective, how the concept of time most likely would apply to change management.

I like the precise nomenclature of algebra.  Here’s the calculation I use for determining the effectiveness of change management:  t = P + I + A + R

In this solution (which would undoubtedly be cooler if it were an acronym like BADASS or something)...

• [t] is total time

• [P] is planning and communication time

• [I] is implementation time

• [A] is adoption time

• [R] is review and adjustment time

Once we solve for each of P, I, A, and R, we can calculate t and understand the lifecycle of a change as it relates to time, which is Σt.  When Σt/year is known, your company can efficiently calculate how many changes it can handle in a single year.  Got it?  Good, we are done here.

Or not.  I still haven’t solved for P, I, A, and R, so we have to backtrack and solve for those, and to do that, additional questions need to be asked and answered.  I tried to think of every possible question that would need to be asked, but I am sure I missed a few.  The upside is that if you attempt to use this same framework, you could amend the questions or add your own additional questions to solve for t.  The more that is known about the other four variables, the closer you will come to an ideal understanding. 

Q: In terms of time, does the change “clock” officially begin at some point before the project starts, at the actual start of the project, some specific milestone in the middle, at the go-live/conclusion of the project, or some point in the transition period between projects?  

A: In my experience, the change clock typically begins at the start of the project's planning phase. Once the project is “approved” to start (by those responsible for approving such changes), it may still be several weeks or months before you get to the start line. Still, the preparation for change management (itself change management) would begin immediately and coincide with the approval.

Helps to solve for: P (Planning and communication time)

Q: How do you measure whether or not your prior or current change management period is long enough or appropriate? 

A: Measuring the appropriateness of a change management period involves tracking KPIs such as adoption rates, productivity levels, and user satisfaction over time. If these metrics stabilize or improve, it may indicate an appropriate duration.  Important: low user adoption and low user satisfaction may not always directly correlate to time.  People may just hate the change or find it unwieldy or unnecessary.  So, ensure your metrics and KPIs are attributable to time change elements.  For instance, do not just ask if the user is satisfied with the platform. Ask them if they are satisfied with the change's timeliness and effectiveness, which surrounded the rollout of the change.

Helps to solve for: A (Adoption time) and R (Review and adjustment time)

Q: Let’s suppose I have already made [x] substantial changes in the business. How many more do I need to make to determine the appropriate amount of time between changes?

A: While having data from numerous projects is valuable and will help get to a much better answer, it most likely will not be sufficient on its own. Every change is unique, and factors like organizational culture, change complexity, and external circumstances all play crucial roles in determining appropriate timelines.  If you are constantly applying changes to a singular group or function, it may be easier to review past data and have a better understanding of how future changes would be calibrated to achieve the same positive results with that group or function.  However, on the whole, as your audience evolves with the business, you would still need to make sure that you also use other available data to calculate.  

Helps to solve for: R (Review and adjustment time)

Q: What if you never provided any time between changes and simply "slow rolled" between changes? Does there need to be actual stoppage time for the burn-in period?

A: The concept of "slow rolling" between changes can work.  I have done it before, though only on what I typically categorize as minor to medium changes.  However, in a slow-rolling model, I don’t just announce the changes one at a time but all at once in bulk and each during its respective period.  So, it’s equivalent to me applying change management on two levels.  First, I am applying change management on a macro level - “We are going to do project X, but it has three phases with only four weeks between each.”  Second, for each phase, I am applying change management on a micro level - “Phase 1 is 50% complete, and we have started planning for the kickoff of Phase 2.”  Slow-rolling has a few small advantages if your representative customer base has proven to absorb and adapt to the style.  However, it's important to ensure that each change has adequate time for adoption and stabilization (aka t). While there may not need to be complete stoppage time, there should be periods of reduced change activity to allow for consolidation and reflection.

Helps to solve for: A (Adoption time) and R (Review and adjustment time)

Q: How does the complexity of a change impact the time required for implementation and adoption?

A: Obviously, more complex changes = longer implementation periods. Why? You need more planning, testing, and system modifications; that's why. Similarly, adoption time increases with complexity as users may need more training, support, and time to adjust to new processes or technologies. For instance, a simple software update might take days and weeks to implement, while a major ERP system change could take months and potentially a year or more for full adoption.  However, the complexity of a change also has a lot to do with the time domain in which it is allowed to happen.  Consider the following example: Suppose I had a very complex change to implement but a full year (or some other very long time) to complete it.  Wouldn’t it be advantageous for me to break it down into such small parts that the complexity was eliminated, at least in the eyes of the adoptees, and therefore ensure that the change was successful?  Complexity itself is a tough concept to calculate because you also need to calculate for expertise, but that’s too much damn algebra for this addendum, so, in this case, we will all just have to stipulate.

Helps to solve for: I (Implementation time) and A (Adoption time)

Q: Is there a correlation between the total duration of a change process and its success rate?

A: There is often a correlation between the duration of a change process and its success rate, but it's not always linear. Generally, allowing sufficient time (again, t) for each phase of the change process (planning, implementation, adoption, and review) increases the likelihood of success. However, excessively long change processes can lead to change fatigue or loss of momentum (see my prior Q/A above). The key is to find the right balance - enough time to properly execute each phase, but not so long that the organization loses focus or the change becomes obsolete. In my experience, changes with well-paced, adequately timed phases tend to have higher success rates.

Helps to solve for: P, I, A, R (All variables, as this question relates to the overall change process)

Q: How do different organizational cultures affect the pace at which changes can be effectively implemented?

A: Cultures that are more adaptable and open to change can quickly implement changes. For example, a startup with a culture of agility might implement changes in weeks, while a more traditional, hierarchical organization might need months for the same change. Cultures that value consensus-building may require more time in the planning and communication phase, while those strongly emphasizing data and analysis might spend more time in the review and adjustment phase. As the change leader, you should understand your organizational culture before setting timelines for each phase of the change process.  Overall, companies at the far ends of the spectrum perfectly represent the expected pace, while companies in the middle will have a wide range of variables.  For instance, entrepreneurial companies live in a state of such chronic change that it is ironically often impossible to conduct any level of appropriate change management.  At the other end of the spectrum lie companies that have become institutionalized due to size, length of existence, or both.  The amount of bureaucracy required to commit change also often makes it extremely difficult to conduct an appropriate level of change. By the time a change has been approved, a new change must be initiated to supersede the one currently underway.

Helps to solve for: P (Planning and communication time) and I (Implementation time)

Q: What role does the organization's size play in determining the appropriate timeline for change initiatives?

A: Larger organizations typically require more time for each phase of the change process due to several factors:

• Planning and communication (P) often take longer due to more stakeholders and complex approval processes.

• Implementation (I) can be more time-consuming due to the rollout scale and potential technical complexities.

• Adoption (A) may take longer as more people must be trained and adapt to the change.

• Review and adjustment (R) might require more time to gather and analyze feedback from various parts of the organization.

However, just saying “more time” does not satisfy the full nature of the answer.  You should have answered many prior questions to know whether the “more time” effect is 1.5x, 2x, or greater.  It is not as simple as saying that a company that has 1000 people will take 2x longer to implement a change than a company of 500 committing the same change.  Certainly, however, the larger company would have at least a smaller degree of expanded complexity simply due to the increased number of stakeholders and expanded breadth of communication.

Helps to solve for: P, I, A, R (All variables are affected by organizational size)

Q: How can we account for and measure the "hidden" time costs of change, such as productivity dips, staff turnover, or similar effects during transition periods?

A: Accounting for hidden time costs is crucial for accurate change management planning, but it is more of an art than a science since predicting events far out of one person’s control is nearly impossible. However, to the degree that these can be measured, they can be grouped into logical buckets.  For instance, you could track productivity metrics before, during, and after the change implementation.  This would give you an understanding of a future variable you could use in time assessments for similar projects.  You could conduct regular surveys to assess employee time spent on change-related activities.  This would only help if you already have a culture inured to surveys, but sometimes, there is no better time to start than the present.  A common fallback approach is to monitor support ticket volumes and resolution times during the transition, but that introduces a new variable that can be overly dependent on the effectiveness of your incident management team and their specific approach to categorizing and resolving incidents. Hidden costs are exactly that - hidden - but they affect the Implementation (I) and Adoption (A) phases of a change and, therefore, directly impact t. For example, productivity might dip by 20% during the first month of implementation, gradually recovering over the next 2-3 months of adoption.  This would be a useful metric, especially if you realized the same or similar resulting value over several changes.

Helps to solve for: I (Implementation time) and A (Adoption time)

Q: What is the relationship between the time invested in change preparation (communication, training, etc.) and the overall success of the change?

A: I have found that there's generally a positive correlation between time invested in change preparation and overall success. You would rarely see a substantial time investment in a key change not pay off in achieving the designated success unless someone is grossly negligent or making a series of wrong assumptions.  Implementing the appropriate amount of time upfront for change preparedness (itself a change) incorporates the time taken to have conducted:

• More comprehensive stakeholder engagement

• Thorough training programs

• Detailed risk assessment and mitigation planning

• Development of clear communication strategies

I must stipulate that there's a point of diminishing returns where excessive preparation time can delay or negate benefits realization.  Again, each company will be different, so it takes an appreciation for the urgency of the project, its expected impact, the scope and resources required, and the net benefits of simply achieving success as the customers want versus making it the flagship project of your career.

Helps to solve for: P (Planning and communication time) and A (Adoption time)

Q: How does someone effectively measure and account for the long-term impacts of change beyond the immediate implementation period?

A: Measuring long-term impacts involves extending the Review and Adjustment (R) phase beyond the initial implementation. No change will be the last change.  At any point, you are either in a change period or a “between change” period.  How your company handles and measures Continuous Improvement (CI) will significantly contribute to measuring the time benefits of any change committed to and completed.  If I implement an ERP, I may have a longer period of time until my next major change to ERP, but how I measure the effectiveness of the change and its CI effects will contribute to the overall R of the change.  I would always recommend that, for any change of note, set long-term KPIs aligned with the change objectives (e.g., productivity improvements, cost savings) and then conduct periodic assessments (e.g., 6 months, 1 year, 2 years post-implementation) against those KPIs.  We already discussed the use of employee surveys. Still, you can now amend them to track sustained behavior changes and, ideally, use the same focus groups to ascertain the positive (or negative) change rate.  You can monitor business outcomes targeted by the change and determine if the changes have a net positive downstream impact.  Lastly, you could just analyze trends in relevant operational metrics over time and compare them to those between pre-change and post-change.

Helps to solve for: R (Review and adjustment time)

Q: Is there a point of diminishing returns regarding time invested in change management activities?

A: While it may seem obvious, there is most definitely a point of diminishing returns in change management activities. Excessive planning (P) can lead to analysis paralysis or planning for unexpected scenarios. Drawn-out implementations (I) can cause change fatigue and loss of momentum, and while initial support is crucial, over-supporting (Adoption - A) can create dependency and hinder self-sufficiency. Continuous review (R) is valuable, but at some point, resources are better invested in new initiatives. The key is to find the balance where additional time investment no longer yields proportional benefits. This often follows an S-curve, where benefits increase rapidly with initial time investment, then plateau. The exact point varies by organization and change type, but monitoring progress against predetermined milestones can help identify when this point is reached.

Helps to solve for: P, I, A, R (All variables, as diminishing returns can occur in any phase)

There is no question that change management is a complex and nuanced process that requires a deep understanding of its various components, particularly the role of time. The equation t = P + I + A + R is just one of an infinite number of possible frameworks for conceptualizing the time required for effective change management.  However, as we've explored (albeit in a semi-Socratic way), these variables are influenced by numerous factors, including organizational culture, size, the complexity of the change, and the specific context in which the change occurs.

If you take away only one thing from this amendment, it is that there is no one-size-fits-all approach to timing in change management. Instead, successful change leaders must comprehensively understand their organization's unique characteristics, the nature of the proposed changes, and the interplay between various factors affecting the change process. This holistic view allows for more accurate planning, implementation, and measurement of change initiatives.  IT Leaders and change management practitioners in organizations can balance thoroughness and efficiency by carefully considering each phase of the change process and the factors influencing its duration. This balanced approach helps avoid the pitfalls of rushed implementations and drawn-out processes that lead to change fatigue.

I have learned a few things by writing this.  One is that I am almost positive I will never nail down a precise way to calculate change management and its impact on time and how it is impacted by it, regardless of whether I use a formula or not.  However, when change management is done enough and aligned with using the answers I have written above, you can take the most empirical evidence and then apply a final interpretation to it using your instinct and experience.  This should nearly always result in a close enough approximation of “when” and “how much.”  Effective management of the pace and quantity of change over time requires an understanding of change management principles and a keen awareness of organizational dynamics, a willingness to adapt strategies based on feedback, and the ability to measure and learn from both short-term and long-term outcomes.  I hope that this answers the question and was helpful!