Technology leaders are often asked to deliver change while keeping the business running. That might mean an ERP implementation, a post-acquisition integration, a new security process, or a different structure for the IT organization.
The plan may be technically sound. The harder questions are often about people: who supports the change, who is affected, how much the organization can absorb, and what will make the new way of working last.
These seven questions help turn an initiative into a conversation the leadership team and the people doing the work can act on.
1. How much change can the organization absorb?
Look beyond the initiative itself. What else is happening in the business? Which teams are already carrying a heavy workload? Where will the proposed change compete with customer commitments, operations, or another major program?
Be candid about the destination and the disruption along the way. If the plan assumes capacity that does not exist, sequencing or scope needs attention before delivery begins.
2. Who is sponsoring the change?
Name the executive who is accountable for the business outcome. Then check whether the wider leadership team understands the reason for the change and is prepared to support the decisions it will require.
A sponsor’s role includes resolving competing priorities, making decisions, and explaining why the work matters. An initiative assigned to IT still needs business ownership when it changes how the business operates.
3. Who may resist—and what are they telling you?
Resistance is useful information. A concern may point to a practical problem, an overlooked dependency, uncertainty about a role, or a previous change that did not deliver what was promised.
Ask what people are worried about before treating disagreement as an obstacle. You may need to change the plan, explain a tradeoff, or acknowledge a real loss. Understanding the reason makes the response more useful.
4. What changes for the people doing the work?
Translate the initiative into someone’s working day. Which tasks become easier? What will they need to learn? Which responsibilities or decisions will move? Where might the change initially create more work?
Explain the business benefit and the personal impact. Avoid promising that everything will be better for everyone. A clear, honest account gives people a better basis for participating.
5. What problem are we solving, and why now?
Describe the problem in terms management and staff recognize. Then connect the proposed change to that problem. Buying a new platform or adopting a new process is an activity; the reason for doing it should be clear.
Make the timing explicit too. What makes the issue a priority now? What happens if the business waits? Those answers help people distinguish an important change from another competing request.
6. What will success look like?
Agree the outcome before delivery begins. Choose measures that reflect the business problem and include evidence that the new way of working is being used. A system going live is a milestone, but it does not automatically demonstrate that the intended improvement has happened.
Revisit the definition as the work progresses. If circumstances or expectations change, make that visible rather than allowing different groups to work toward different versions of success.
7. How will the new way of working stick?
Plan for adoption alongside the technical work. Three practical steps are worth making explicit:
- Find credible advocates. Involve people respected by the colleagues who will use the new systems or processes. Give them a real opportunity to influence the approach.
- Communicate throughout. Explain the reason, the next steps, and the decisions. Share setbacks as well as progress, and make it easy to raise questions.
- Train for the actual job. Focus on the tasks people will need to perform, the support available after launch, and who owns the process once the project ends.
Use the questions before the plan is fixed.
You do not need a perfect answer to every question on day one. You do need to know where the uncertainty is and who will resolve it.
Use these questions with the sponsor, the leadership team, and the people closest to the work. The discussion can expose assumptions that a project schedule alone will miss—and give the business a more realistic basis for execution.
Refreshed from Aaron Higley’s original article published November 6, 2017. Updated for technology leadership, M&A integration, and organizational change.