The Restructure Everyone Heard About on Friday
A utility company is merging two customer service teams into one and introducing a new case management system. You are the business analyst. The merger was announced at a Friday all-hands with a go-live date of five months. Staff in both teams will be redeployed; some roles will disappear. The two teams have different service level targets, different escalation paths and different shift patterns. Union representatives have not been consulted. Absence has risen 15% since the announcement, and two experienced supervisors have resigned. The programme manager wants you to focus on the system requirements and "leave the people stuff to HR".
1. How should you respond to the programme manager's instruction to focus only on system requirements?
Read the worked answer
Explain that the people and process dimensions are not separable from the system requirements in this situation, and that ignoring them increases delivery risk.
- Evidence the risk: rising absence, two supervisor resignations and no union consultation are indicators of change resistance and knowledge loss. Requirements elicited without experienced staff will be poor, and adoption of the new system is at risk.
- Clarify boundaries, not abdication. HR owns employment terms and consultation process; you own business analysis, which includes process design, stakeholder engagement and readiness for change. Propose a joint plan with HR and a named change lead.
- Reframe the request: the two teams' differing service levels, escalation paths and shift patterns are business process issues that must be resolved to specify the system. This is squarely your work.
- Escalate the union consultation gap to the sponsor as a programme risk, since it can halt or delay implementation.
Agree with the programme manager what you will do, what HR will do, and what the sponsor must decide. Document the agreement so responsibilities are clear.
2. How do you plan stakeholder engagement for this change?
Read the worked answer
Use a structured stakeholder analysis and tailor engagement accordingly.
- Identify and analyse stakeholders: staff in both teams, supervisors, team managers, HR, union representatives, the programme manager, the sponsor, and customers affected by service changes. Assess interest, influence, attitude and impact.
- Prioritise: staff and supervisors are high-impact and currently anxious; unions are high-influence and not yet engaged; the sponsor is high-influence and needs to own the change narrative.
- Plan engagement per group: regular two-way sessions with staff (not just broadcasts), involvement of experienced staff in process design and requirements, early and formal contact with unions through HR, and a clear sponsor communication plan.
- Address the Friday announcement problem: the communication was one-way and early, without consultation. Rebuild trust through listening sessions and visible response to concerns.
- Plan for knowledge retention: capture process knowledge from experienced staff before they leave, and consider retention measures with HR.
- Review and adjust as attitudes change.
Engagement is continuous, not a single event, and should be proportionate to impact and influence.
3. The two teams have different service level targets, escalation paths and shift patterns. How do you approach this as an analyst?
Read the worked answer
These are business process and business rule differences that must be resolved to design one operating model and one system.
- Document both current processes and the rules behind them, including why the targets differ (customer type, risk, regulation, or simply history).
- Distinguish justified difference from inherited inconsistency. A differing target for vulnerable customers may be justified; differing escalation paths may be historical accident.
- Facilitate agreement on the target operating model with the future process owners, using workshops and process models to make options concrete.
- Model the impact of each option on customers, staff workload and system design.
- Record the agreed rules as business rules with owners, and trace system requirements to them.
- Consider transition: shift patterns and escalation paths affect training, rota design and go-live sequencing, which are change management dependencies.
Resolving these differences is a prerequisite for credible system requirements, not a distraction from them - which is why the 'leave it to HR' instruction cannot stand.