Part #5: The Role of TIMING in Change
In the final component of this 5-part series, we’re looking at the role timing plays when a business is undertaking significant change…. like the change scenario we’ve suggested here of new software integration into your construction business.
When undertaking a big-scale change project, it’s common for change managers to initially believe the biggest focus must be future-state. As in, when the software is implemented, up & running, and all project tasks are complete, how will the business look? This is, of course, important. This thinking is often focused around a common hypothesis: if the end-game is so compelling, so attractive & appealing, then the business will follow.
Of course, human nature can get in the way – as in mistakes, resignations, oversights or otherwise. Or unexpected turbulence in the business, or your market, occurs. Unforeseen ANYTHING occurs. Which throws the big proverbial spanner in the works. And never has timing been so critically valuable; so perfectly capable of settling the dust of a change project. Timing both from a chronological perspective, but also from a linear, flow perspective.
What are we talking about here?
The sequential nature of what and how you communicate, consult, execute and deliver change, will make or break your change project. If the aforementioned spanner is thrown into the picture, a good project change manager will have predetermined how to pivot in response to that event, so that the change project isn’t compromised, unnecessarily accelerated or pushed aside: they’ll have the planning in place to continue project communications, consultation, execution and delivery. And what drives ALL of this, is timing.
But the unforeseen isn’t ALWAYS a factor (although, it’s very common). Let’s look at the other elements that go into the timing of your change project.
There are a couple of schools of thought around instituting sweeping change in an organisation, without offering any prior project visibility or change assimilation. What does that mean? Take this for an example: there’s evidence of record success of sweeping change-particularly in the technology space-that rides on the back of a not-dissimilar organisational change. Say, for example, a new CRM is introduced, but only 30% of its functionality is made known live and accessible to staff. What’s unknown to staff, is that a piece of technology attached to this CRM is where the BIG change will happen in their business. But they’re focused on the CRM, what that’s doing for their day-to-day, and learning it – which for them, seems achievable, fairly painless, and not too time-consuming.
When it comes time for the REAL change to happen, they’re already assimilated to the baseline product-the CRM. Hence, this next stage is largely acceptable, palatable, achievable, and simply, quite okay(caveat: although there will be some who will ALWAYS find it painful).
The alternative is the sweeping ‘big bang blow-your-head-off change. The type of change that makes you nervous to turn on your computer in the morning. Not surprisingly, this type of change meets the greatest amount of cultural, emotional and attitudinal resistance.
Timing for change, in terms of paving the way for a gradual assimilation, seems to be the ticket.
The other issue with timing is this: the business needs to have an adequate appetite for change (refer to our post in this series on the cultural impact of change). The best inventions in the world, never happened, because of poor timing. It’s that simple. Factors to consider in our software implementation example include:
- a readiness to accept the new software
- an understanding that current state is no longer feasible
- an ability to see beyond current-state to a better situation for the business
- a willingness to want to do things better
- a need for less frustration
- a dissatisfaction with current job/requirements in the absence of this change)
Once you’ve determined the timing is right (the chronology we mentioned before), THEN mapping out the linear or flow of the change project needs to be completed. This timing needs to sit within the agreed map of project deliverables, giving all stakeholders adequate room to do both their day-to-day jobs and to deliver their responsibilities to the change project. Keep the timing allocation tight but not mean. Be generous in your giving of time, but only to a point.
Finally, once you’re on the road to change, stick with it. Nothing ruins a project’s credibility or likelihood for success like a stop-start scenario:i.e. where timing is all over the place. Deal with crises with predetermined response strategies. Visualise all potential roadblock scenarios. Be prepared. THEN you know your project timing will be just right.