Skip to main content

Author: Dip Bhattacharjee

Change Management in Project Delivery

A key deliverable of Business analysis in transformation projects is a successful roll-out of the Change.

Rolling out Change is a far outcry, and easier said than done. In Large organisations, rolling out the Change in an acceptable way and the associated communication about the delivery of the Change is as vital if not more important when stacked up against other deliverables in a Project. In the past, it has been noticed that when organisations could not deliver the transformation as successfully as they wished for, one of the primary reasons was that effective change management and change delivery was not among the top priorities.

It has resulted in end consumers of Change, disillusioned with the upcoming Change. Many a time, this has lead to resistance towards Change adoption, and in a few rare situations’ organisations had to revert the changes. When a change roll-out is shelved, it takes more than expected resolve and grit to take them out and re-deploy. Time has moved since it was suspended, and so does the priorities and resources.

I’ve listed below a few of the best practices that Business Analysts/Change Analysts can follow to get a more successful outcome when it comes to change roll-out and associated communications.

Impact Analysis: Firstly, conduct an Impact analysis to review what is changing, the scale of the Change, and assess the impact the Change will have on the Organisation and Consumers of the Change. The outcome of this impact analysis can be documented along with the business requirements or can be managed separately based on the project delivery approach.

As part of Impact analysis, the first step would be to conduct a high-level review to identify the impacted touchpoints. Once touchpoints are established, the next step is to identify the impact. In simpler terms, determine what is changing in the system, process, collateral, organisational structure, or people? Or any other implications such as increased or decreased workload.

Sentiment Survey: An excellent methodology to start this assessment process is to identify how people perceive the up-coming Change, a survey would provide a starting point. An important aspect to note that the study should not exceed more than 3 Questions (Ideally 1) and an optional comment section. Analyse the outcome and categorise that into five buckets viz Exciting, Happy, Comfortable, Worried, Sad.

When a certain number of feedbacks is in the last two categories, that is “Worried” or “Sad” that would provide fair food for thought for the project team. This feedback will clearly articulate the upcoming challenges and would set the tone for the Project on how to overcome this challenge. This methodology is more preventive rather than a detective. Once this survey is complete, that would set the premise for the next steps.

Identify Impacted Population: The next step is to identify the impacted consumers of the Change. This exercise must be completed at initial stages, ideally as a precursor in the project initiation phase, and will set the baseline for future scope of work. You can, however, continue to refine this outcome during the life cycle of the project delivery.

As-Is Analysis: Once the baseline is defined, the next step is to hit the As-is and to-be state definition. An As-is assessment is more important to set the tone to understand the change context and content of what activities are performed today and establish the magnitude of Change when compared against the to-be state. Unless clearly articulated, one cannot be sure to ascertain what is going to change for consumer/stakeholder when we move from current state A to future state B.


Stakeholder Engagement: This is the next logical step in the set of activities. Engage with stakeholders/delegates who are the end consumers of the Change to understand how best the Change can be delivered seamlessly with no or little disruption. Be diligent in ensuring that those conversations align with the overall organisational strategy. Project stakeholders and delegates are vital to endorse end-user feedback. Getting buy-in from the right set of stakeholders is a necessity to deliver successful project outcomes

Change Strategy: The objective of this step is to outlay the change delivery strategy. The strategy should call out for 1. Impacted Areas, 2. Stakeholders 3. What is changing? 4. How the roll-out would be perceived, 5. Mode of change roll-out, 6. What uplifts are required – who needs to be told and 7. What needs to be said. 8. Change content, and 9—the Change delivery vehicle.

A well-articulated Change strategy helps establish the next set of deliverables and work items.

Change Content: There are two primary artefacts in this space. (a) Communications of the Change and (b) Content of the Change. Communication is about how you say to the consumers about Change. It can be in one or many forms. Change Analysts must identify the best methodology that suits their project delivery timelines and budget.

Few of the communication mediums are

  1. Emails
  2. SMS
  3. Notifications,
  4. Flyers
  5. Bulletins on Internal / External websites
  6. Video messages from Leadership teams on upcoming Change

Similarly, with the content, there is a wide array of how the information is shared. Again a few stock standard mediums are

  1. Help files
  2. Animated Videos
  3. PowerPoint packs
  4. Reference Guides
  5. FAQs
  6. Dictionaries/Procedures

8. Training: There may be situations where it may become essential to train the users on the upcoming transformation/Change. There are generally a few ways to deliver that.

  1. Train the trainer: When the complexity of the Change is high, or the volume of people impacted is high, a reasonable approach to train people across locations and geographies is to upskill a select group of people and cascade that downwards till everyone has been trained.
  2. Train the end-user: Use this methodology when there are limited end-users, but it is a must to provide them with some form of training which they can attend, to better understand and participate in the upcoming Change.
  3. Learning Modules: When the methodologies, as mentioned above, are deemed as not fit to purpose, one may consider publishing a training course or a Learning module. A Learning module provides flexibility and creativity that is required to upskill the people. It can be set as one with/without a test and can make it a compulsory or optional training based on the scope and scale of Change.

To summarise, change roll-outs are vital to successful project deliveries. Projects that invest in change management are more focused on ensuring a hearty handshake between Project and its target audience. Those projects generally are poised to more successful outcomes compared to ones where change management is not a consideration.

Agile Business Analyst Mindset

The paradigm shift from waterfall to agile methodology has put traditional business analysts at cross-roads.

Like any other disruption – Business analysis as a profession has been challenged as never before. Business analysts sometimes struggle to answer the following question of how is the agile world different from the traditional methodology of business analysis and how to adapt and respond to this change.

Let us first look at why and who is a Business analyst. A business analyst is someone who helps solve Enterprise problems – someone who bridges the gap between Customer and Technology. Business stakeholders seek those Business analysts (s) who can efficiently perform Enterprise analysis, conduct elicitation to bring out the real business need and deliver a solution which will solve those business-critical problems.

To respond to this paradigm shift and still be the trusted partner to our Customers and Business stakeholders, we ( business analysts) need to introspect the roles and responsibilities as well as the mindset that we bring to the table when we work in the Agile world. In traditional project delivery methodology, Business analysts are responsible for documenting business requirements and develop the functional/non-functional specifications and heaps of other documents and processes. Obviously, over a period of time, Business analysts start to feel that they the real owners of the project. To technology team Business analysts are face and voice of Customers. Without a doubt, this approach means heaps of responsibility on the shoulders of Business analysts and makes them an integral part of the project, but at the same time, there are few major pitfalls of that approach as described below.

Firstly, there is more than required dependency on the Business analyst(s) for a successful outcome of the project which sometimes may be demotivating for other team members. To add to that requirement put forth by traditional BA(s) to the team are documented in a way that it not only specifies the “WHAT” but also that is documented in a way that guides the “HOW” of the solution. which may not deliver the best Customer outcome(s)

As stated the four values of agile delivery are:

  1. Individuals and Interactions Over Processes and Tools. …
  2. Working Software Over Comprehensive Documentation. …
  3. Customer Collaboration Over Contract Negotiation. …
  4. Responding to Change Over Following a Plan.


What that means to for Agile Business Analysts is People, Interactions, Collaboration and ability to adapt and change. How that will help us deliver to business goals.

Firstly, the willingness to adapt and learn. A business analyst has to deal with a new set of problems on a regular day to day basis and no two business or Customer will have exactly the same problem, nor they want exactly the same solution. At the least, the stakeholder expects a better solution. A key to achieve a successful outcome for a business analyst is to have those interactions with Customer and understanding the real need as well as facilitate discussions which will help deliver a better end result for the Customer. A mindset which focuses on the willingness to learn and change – will have key traits of Respect, Collaboration, and interactions, which in turn will help deliver better customer outcomes.

Secondly, People and Interactions. A traditional approach to business analysis is focussed around processes and documentation – what is not documented does not make its way to the solution, and that is the last thing that we would like to deliver as a valued outcome. They ( Customers ) want us to read their mind and deliver a solution which would solve problems which were not documented. A mindset which is people focussed over processes – will focus more on interactions and understanding the real needs as opposed to documentation – as well as work as an enabler who helps facilitate positive and healthy interactions inside and outside of team – thereby bringing in more brain power and valuable insights into each and every discussion. This translates into a healthy team culture, where people will take ownership and be open to ideas and interactions. A people-focused Business analyst will restrict themselves from dictating what and how but transform them as an enabler of how to achieve a better customer outcome. A big win of this mindset is getting insight into real Customer need and deliver a solution which not only meets business criteria but also delivers a value to our Customers

Lastly but not the least, responding to change. Any business problem is subject to change over a period of time, be it not being a problem anymore or change of priority or how to solve it. A key to success for an Agile business analyst is to understand this pertinent fact that requirements can change over time and hence deliver is short chunks to not only deliver quick wins but also de-risk the outcomes and at the same time have the willingness to respond to changing situations. This is a change of mindset over traditional approach but also enables the Business analyst with the flexibility of dealing with changes in a more collaborative manner.

To summarise, given the world we are in today, the skills of traditional Business analysts still hold good but it is about customer-centric delivery, where our outcomes must meet or exceed the expectations, and a true way to do deliver on that promise for an Agile Business analyst is to adapt to agile mindset.