Read the fine print.
Terms are subject to change.
Results may vary.
We do not guarantee hair growth.
There is no such thing as a sure thing. Every purchase comes with a warning label. Caveat upon caveat. That’s the lawyers talking and they’re no fun.
But they’re right. Every project carries risk. I’ve witnessed two major risk-related errors when implementing change: Failure to take it seriously (no risk log, poor mitigation plans) and failure to advise stakeholders about risks. The second is particularly bad when projects inevitably get off course, or worse, come completely off the rails.
I don’t care how vanilla your implementation is, restructuring efforts, transformations, and enterprise application launches are complex and time-consuming. Obstacles seem to come out of nowhere.
1. Get help predicting possible futures
The best defense is a great offense. Prepare to lead change through disasters by asking your stakeholders – not just the project team – where they see potential problems. By the very nature of the way our brains work, we are all tuned to detect threats. Employees are particularly good at it because no one wants change that puts their performance or job security at risk.
When working on what we thought was a minor change to project naming conventions, engineering told us how it would mess up their filing system, accounts payable told us how it could increase invoice processing time by 500%, and customer service predicted longer response times. With that knowledge in hand, we were able to prevent disaster and manage through some of the inevitable problems during transition.
2. Make pain a possibility
But we can’t foresee all of the risks. That’s why when leaders point to a future where life is better after a change, they must also make mention of the likelihood of pain along the way and the potential for shifts in scope. When rolling out change, we never plan to fail, but we do plan for failures. It’s called managing risk. When discussing change wise leaders some version of the famous quote:
No plan survives first contact.
With the pace of change being so high, it’s likely that circumstances will change along the way which may trigger a shift in project priorities. Tell your stakeholders in advance.
These strategies are best for inoculating your project and stakeholders against the inevitable shifts that come with budget cuts and implementation challenges. But what if the whole project starts to crumble? Developers hit a brick wall. A sale or acquisition changes the playing field. Implementation partners go bankrupt. Regulatory changes render the goal useless. You flipped the switch on the change but it just doesn’t work well. Everyone hates it.
Now what? The answers are in part two next week!
Thoughtfully yours,
Jeff Skipper
