Old and New Story’s: Why Business Analysts and the Change Management Team must Collaborate

Please ensure you read the all the articles in this sequence: 

1. Old and New Story's
2. Old and New Story's: Navigating the Gap, Where Change Actually Happens
3. Old and New Story’s: Why Business Analysts and the Change Management Team Must Collaborate
4. Old and New Story's: A Practical Example of Collaboration
5. The Art of Asking: Why Questions Matter in Stakeholder Interview

Traditionally, Business Analysts (BAs) and Change Management (CM) teams have operated in separate lanes, each focused on their distinct deliverables with minimal interaction.

The BA's world centered on technical accuracy and organisational readiness from a systems perspective. They mapped current processes, identified gaps, designed future state solutions, and ensured technical feasibility. Their primary concern was getting the solution right, building something that worked from a functional and technical standpoint.

The CM team's world focused on people and adoption. They worried about communication, training, stakeholder engagement, and ensuring people were ready and willing to embrace the change. Their primary concern was getting people ready, preparing the organisation to accept and use the solution.

These teams often worked independently, with BAs handing off their completed designs to CM teams who would then figure out how to "sell" the solution to users. Collaboration was limited to occasional check-ins or last-minute reviews when problems arose. Each team spoke its own language, followed its own methodologies, and measured success by its own criteria.

The result? Technically sound solutions that people resisted or couldn't effectively use. Change initiatives that looked good on paper but failed in practice.  The change narratives felt like marketing spin rather than authentic acknowledgement of the journey ahead.

Old and New Story’s and Collaboration, The Way Forward

The development of Old and New Story’s recognises that this documentation must serve dual purposes.  Providing technical specifications for implementation while also forming the foundation for compelling change narratives that drive human adoption.

This requires Business Analysts (BA) and Change Management (CM) teams to collaborate from the very beginning of documentation efforts, co-creating materials that are both technically accurate and humanly meaningful.

The most successful change initiatives occur when BAs and CMs work as partners, not in silos.

Here are the key areas where collaboration is essential:

Stakeholder Engagement

BA Needs: Interview stakeholders to understand process requirements, pain points, and desired functionality

CM Needs: Assess stakeholder readiness, influence, concerns, and resistance patterns

Overlap Challenge: Both need stakeholder time; uncoordinated outreach causes fatigue and confusion

Best Practice:

• Conduct joint interview sessions where appropriate
• Share stakeholder contact plans to coordinate timing
• Exchange interview insights (BA shares process details; CM shares sentiment data)
• Create unified stakeholder map showing both process role and change influence

 Old Story Documentation

BA Focus: Technical "what" and "how", the mechanics of processes and systems

CM Focus: Emotional "why" and "who", the human experience and organizational context

Overlap: Both need to deeply understand current reality, just from different lenses

Best Practice:

• BA conducts process mapping workshops; CM observes for cultural insights
• CM shares organizational history to help BA understand why processes exist
• BA provides process maps that CM uses as basis for impact assessment
• Combined documentation tells complete story (technical + human)

 Gap Analysis

BA Focus: Process efficiency gaps, system capability limitations, data quality issues

CM Focus: Skill gaps, behavioural changes needed, organizational readiness gaps

Overlap: Both identify what needs to change between current and future

Best Practice:

• Conduct combined gap analysis workshops
• BA presents technical gaps; CM facilitates discussion of people implications
• Create integrated gap register showing both technical and human dimensions
• Use BA's gap analysis to inform CM's training needs analysis

 New Story Definition

BA Focus: Technical solution design, how the process/system will work

CM Focus: People experience and adoption approach, how it will feel and be adopted

Overlap: Both articulate the future, but from different perspectives

Best Practice:

• BAs design process flows; CMs translate into "day-in-the-life" narratives
• CM provides input on user experience requirements that affect adoption
• BA validates that CM's stories accurately reflect technical capabilities
• Create paired deliverables: process design + experience story

 Impact Assessment

BA Focus: Process changes, new system functionality, changed data flows

CM Focus: People impacts: role changes, skill requirements, behavioural shifts and reporting lines

Overlap: Understanding what changes and who is affected

Best Practice:

• BA provides detailed list of process/system changes
• CM analyses people implications for each change
• Create integrated impact assessment showing technical change + human impact
• Use assessment to prioritize training and communication needs

 Requirements and Design Input

BA Focus: Functional requirements based on business process needs

CM Focus: User experience requirements that drive adoption

Overlap: Both influence solution design to ensure it's technically sound AND usable

Best Practice:

• CM participates in requirements sessions to voice adoption concerns
• CM provides "adoption requirements" (e.g., "must be intuitive for occasional users")
• BA evaluates feasibility of CM's user experience requests
• Balance technical optimization with change adoption needs

 Training Content Development

BA Focus: Process documentation that becomes training material, eg SOPs and job aids

CM Focus: Learning strategy, curriculum design, training delivery approach

Overlap: Creating content that helps people learn new ways of working

Best Practice:

• BA provides technical process documentation and system details
• CM designs learning experience and instructional approach
• BA reviews training materials for technical accuracy
• CM ensures materials address emotional and practical learning needs
• Collaborate on job aids and quick reference guides

 Benefits Realization

BA Focus: Quantitative metrics and KPIs; efficiency, cost reduction, error rates

CM Focus: Adoption metrics including usage rates, proficiency levels and behavioural indicators

Overlap: Measuring success and demonstrating value

Best Practice:

• Create combined metrics dashboard showing both technical and adoption measures
• Recognize that technical benefits don't materialize without adoption
• BA measures process performance; CM measures user adoption
• Jointly analyse why benefits are or aren't being realized

Why This Collaboration Is Essential

The activities outlined in this Collaborative Activities Matrix demonstrates how interconnected this work truly is.

Lets consider the critical touchpoints:

During Process Mapping, BAs need CM input on organisational pain points and cultural factors that might not be visible in workflow diagrams but are crucial for understanding how work really happens.  This ensures Old Story documentation captures not just what people do, but why they do it and how they feel about it.

In Stakeholder Interviews, conducting joint sessions minimises stakeholder fatigue while ensuring both technical and adoption perspectives are captured simultaneously. The BA can probe technical details while the CM listens for emotional undertones, resistance signals, and adoption concerns.  A BA might hear "the system doesn't support this workflow" while a CM professional hears "people have found workarounds they prefer."

Technical Gap Analysis, while the BA focuses on organisational readiness from a systems perspective, CM adds the people dimension. A technical gap might be solvable from an IT perspective but represent a massive cultural shift from a change perspective.

For Impact Assessment, both technical and people dimensions must be integrated. Understanding organisational readiness for the technical change is just as important as understanding the technical feasibility itself.

When designing Future State Processes, BAs must receive CM input on adoption feasibility. A technically perfect process that requires behavioural changes people aren't ready to make will fail regardless of how well it's engineered.

As New Story Narratives are created, the CM crafts compelling messages, but BA validates technical accuracy. Nothing undermines change adoption faster than promising capabilities the solution can't deliver or describing a future state that misrepresents how the system will actually work.

Throughout Training Strategy development, BA content expertise combined with CM design experience creates learning experiences that are both accurate and effective. Training that's technically correct but instructionally poor won't develop the capabilities needed.

During UAT Coordination, CM ensures users are actually prepared to test effectively, not just showing up because they were told to. BAs rely on this preparation to get meaningful feedback rather than confusion.

At Go-Live, coordinated support planning is essential. Technical support and adoption support must work seamlessly together to address both "how do I make this work?" and "why isn't this working?" questions.

Communications Flow

The typical information exchange should flow as follows:

1. BA discovers process changes, system capabilities, technical requirements
2. CM analyses people impact, adoption barriers, resistance points
3. CM communicates using BA's technical information with human translation
4. BA validates that CM's interpretation is technically accurate
5. Both measure different aspects of success (process performance + adoption)

Critical Hand-Off Points

BA to CM:

• Process maps (old and new)
• Requirements documentation
• Detailed change lists (what's changing)
• System capabilities and limitations
• Technical training content
• Performance metrics

CM to BA:

1. Organisational context and history
2. Cultural considerations
3. Adoption constraints (e.g., limited training time)
4. User experience requirements
5. Resistance themes and concerns
6. Change capacity assessment

Joint Outputs:

• Integrated impact assessment (technical + human)
• Combined readiness plan
• Coordinated go-live support plan
• Unified success metrics

Why This Integrated Approach Matters

When BAs and CM teams collaborate:

The Old Story becomes more than a process map. It becomes a narrative that acknowledges where people are starting from, technically, emotionally, and culturally. This validation of current reality builds trust that makes people willing to consider a different future.

The New Story becomes more than a specification. It becomes a vision that people can see themselves in, that acknowledges what they'll need to learn and change, and that articulates why the journey is worthwhile. It's technically feasible because the BA ensured it, and humanly achievable because CM validated it.

The gap between the Old and New Story’s is mapped realistically. Both teams understand what the transition requires:

• New systems AND new skills
• Technical implementation AND human adaptation
• Process redesign AND identity adjustment.

Communication throughout the change journey stays grounded in reality. Because CM was involved in creating the documentation rather than just translating it, messages remain accurate as they're simplified for different audiences. Because BA understands the change narrative, they can reinforce key messages in technical discussions.

Training and support are better targeted. CM knows exactly what technical changes are coming because they helped document them. BA understands what human challenges people will face because CM brought them into the documentation process.

Making Collaboration work

This collaboration doesn't happen by accident. It requires:

Start together from day one. Don't have BAs complete the process mapping documentation and then bring in CM. Both teams should be involved in the first stakeholder interview.  BAs and CM teams need to plan the change journey together from the beginning, with clear touchpoints and joint deliverables built into the project plan.

Common Language: Both teams learn to understand and use each other's terminology, bridging the gap between technical and human-centered perspectives.  Avoid purely technical jargon that CM can't translate and avoid change management frameworks that BAs don't understand. Create documentation that both teams, and eventually end users, can comprehend.

Create shared documentation templates. Current and Future State documentation should have sections that capture both technical specifications and human factors. Don't maintain separate documents.

Conduct joint analysis sessions. After gathering data, BAs and CM teams should analyse findings together, looking at both technical and human implications.

Co-author the narrative. The New Story shouldn't be a CM translation of BA documentation. It should be a jointly crafted narrative that both teams own.

Validate together. When reviewing documentation with stakeholders, both BA and CM perspectives should be present to ensure technical accuracy and adoption feasibility are both assessed.

Joint Accountability: Success metrics that reflect both technical implementation and adoption outcomes, with both teams accountable for the full result.

Mutual Respect: Recognition that both technical excellence and change management expertise are equally essential to transformation success.

Structured Collaboration: Clear frameworks like the Collaborative Activities Matrix that define who leads what, and where joint work is essential.

The Path Forward

The Collaborative Activities Matrix provides a roadmap for this partnership, showing exactly where and how BAs and CM teams need to work together throughout the change lifecycle.

• Business Analysts lead Process Mapping with CM input on culture and pain points.
• CM leads New Story Narrative Creation with BA validation of technical accuracy.  

It's not about one team leading and the other following.  I's about genuine collaboration where both perspectives inform and strengthen the outcome.  Because both perspectives are essential at every stage.

Moving from separate documentation to integrated story development requires intentional partnership:

• Schedule joint stakeholder interviews rather than having each team interview separately
• Create shared workspaces where both teams contribute to documentation in real-time
• Hold collaborative analysis sessions where technical and human implications are discussed together
• Review and refine both Old and New Story narratives as a joint effort
• Celebrate when the integrated approach produces better outcomes than siloed work ever could

Because the most compelling change stories are those that are both technically accurate and humanly meaningful. They acknowledge the reality of where we are while painting an inspiring and achievable picture of where we're going. They specify what needs to change technically while honouring what needs to change humanly.

Creating these stories requires Business Analysts and the Change Manager Team working as true partners, each bringing their expertise to craft documentation that serves as both implementation blueprint and inspirational narrative.  Documentation that guides both the technical build and the human journey.

Please read the next article in this sequence, Old and New Story’s:  A Practical Example of Collaboration   Old and New Story's: A Practical Example of Collaboration