Business analysts help organizations implement changes. Requirements define what needs to change to achieve a desired future state. If organizations did not need to change and transform, business analysts would have very little to do.
Why then do we, as business analysts, get flustered by change?
Why do we expect the business system to freeze in time and stay stable while we are doing requirements analysis?
And then when processes, business rules or requirements change after we’ve put all that effort into capturing them, why do we take it personally?
Much has been written on the topic of change management. Projects have to recognize and mitigate the risks, and one of the persistent risk categories across all types of projects is business and requirements changes. To be successful as business analysts, we must learn to expect change and master strategies for handling it.
The role of a business analyst is to help business stakeholders:
- Assess the changes – their value, impacts and risks
- Identify requirements for implementing changes
- Propose and evaluate options for adapting to the changes within the context of work in progress
- Assist the clients – the business stakeholders – in making the right decisions about handling change
A business analyst must view change from a wider angle than a project manager. While the project manager’s primary focus is on specific parameters of the project (scope, quality, timeline, resources and budget), business analysts should look more broadly at the business system as a whole, at the business value beyond one specific project or phase.
The distinction between a business analyst’s and a project manager’s perspective on change is critical. While they work towards the same goals within the project, they don’t always serve the same master. A project manager is accountable to the project sponsor, while the business analyst should be accountable to the larger group of business stakeholders impacted by the change, whether they sponsor the project or not.
Depending on the organizational culture, business analysts may feel or are made to understand that they have to take the project’s side. This sometimes means making it very difficult for the business to request changes and include them in the scope of projects that are underway.
Taking sides may be less applicable to the agile methodology, where there are opportunities to introduce the change in subsequent sprints. However many organizations practice a very rigid version of what they call “agile”, where funding is tied to a specific scope that is then broken down into sprints. That “hybrid agile” methodology can make incorporating discovered changes just as difficult as in a pure waterfall.
What we, as business analysts, have to understand and accept is that denying or resisting changes within business systems is ultimately futile and counter-productive. When the change is driven by forces outside of the organization’s or project’s control, the change will happen whether we like it or not. We would provide a valuable service to our clients by helping them analyze the change instead of looking for justification to postpone dealing with it or ignore it altogether.
Here is what resistance to change may sound like – and how our business analyst mindset should guide us to best serve our clients.
“It was not in the original scope, so it will have to be a change request”.
The original scope of a project rarely defines the boundaries of a business change perfectly. Some impacts, dependencies and relationships can only be discovered during analysis. Those should not be considered changes to scope, rather they are just requirements – a product of requirements analysis, e.g. an expected outcome of business analysts doing their job. Remember, business stakeholders have needs, and you, the business analyst, have to identify and synthesize the requirements from your analysis.
“No changes will be accepted after requirements are signed-off”
Do not use requirements sign-off as a stick. If it is still required by your organization, think of it as a soft milestone, not a hard one. After all, your clients may miss important information that will be discovered after the sign-off. And you, the business analyst, are also human – you may miss things and make mistakes.
Would you rather learn about missed or incorrect requirements as soon as possible so that you can rectify the gap, or should we forever bury our mistakes under the concrete slab of the requirements sign-off?
If a missed requirement is discovered after sign-off, don’t blame your client for not realizing mistakes or gaps earlier. Remember, your stakeholders are not the experts in business analysis – you are. If a requirement was missed – then accept that you and the business missed it together. Whatever the methodology for dealing with missed requirements, it must be reasonable and support correcting mistakes.
“We will have to implement the current scope as is, and only then will be reviewing any new business changes”
If you are involved in a large waterfall project with a timeline over 12-18 months, where original requirements were frozen and implemented exactly as signed-off, expect that at least some parts of the solution will be out of date by the time the solution is implemented.
Sometimes the project management practices are so rigid, and the change management process is so heavy and cumbersome, that even small changes with low schedule and budget impact become impossible to accommodate. This results in a lot of expensive rework later on, instead of absorbing the change with lesser overhead during the current project. It is not a secret that post-implementation changes may have to come from a different budget or become a problem for another project manager… But from your business analyst’s perspective, such reworks are still your client’s problems.
The business analyst is in a unique position to be the voice of reason. You can provide an objective assessment of the change, its value, pros and cons of including it in the scope. Without this analysis, the cost of adding changes may look prohibitive, but you can provide a business value assessment to counter the project resourcing assessment. Then your client (the business) will need to make a decision that makes the most sense – after all, it is the client who provides funding for the project.
“Provide any feedback before this date or forever hold your peace”…
These may not be the exact words, but the meaning behind them could be pretty close. However, change is a reality that is impossible to ignore. Viable and progressive organizations have to change and adapt all the time to remain competitive and successful. It means that various components of business systems undergo changes as new products are developed, new markets are discovered, efficiencies need to be implemented and unsuccessful initiatives are closed down. The larger the project you are working on, the more the chances that it will be impacted by changes that happen in the wider organization multiple times.
Don’t get angry at your clients who request changes to business requirements or the scope of the project. It is unrealistic to expect that the scope of your particular project can stay untouched and stable.
So, what should a business analyst do?
Deal with change as an advocate for business:
- Accept that changes are a reality – without anger
- Learn about the change, discover and collect information – without prejudice
- Apply analysis techniques to identify and assess the impacts from your client’s perspective – without resentment
- Help identify (and if possible, quantify) the value, the cost and the risk of different options for accommodating the change – with objectivity
- Facilitate a discussion of options – with an open mind
- Help clients make the decisions that are right for them in the long term – with your client’s best interests at heart
Expect and anticipate changes. When doing analysis, ask:
- Does the organization undergo cyclical changes driven by external forces, e.g. related to taxation, government regulations, seasons, electoral cycles or similar?
- How often do certain business rules change?
- How stable is the business process, when was the last time it needed to be revised?
- Are there specific activities or process steps that need to change more often, due to seasonal, regulatory or other change drivers?
- What drives changes to reference data?
- How do changing relationships with suppliers and customers impact the business system, what are some examples and scenarios?
Include requirements to support changes efficiently as part of doing business:
- Request business rules to be configurable by business users
- Include requirements to support changes to process parameters and steps with minimal software impacts
- Include requirements for optimized managing of reference data
- Request support from the enterprise architecture group to ensure that the requirements you are defining are best aligned with existing architecture building blocks within the organization
- Work closely with the architects and software developers to come up with an adaptive and flexible solution to the business problem
To wrap up, I am not attempting here to summarize various change management philosophies and methodologies or list all the methods of building the most adaptive systems. Rather, my goal is to emphasize that analyzing changes in business systems is an important part of business analysis. You may be in the middle of requirements analysis when you learn about a change. Don’t feel resentful! Be glad that this information reached you, allowing you to adjust the results of your analysis and adapt to the change.
The guiding principle for analyzing and managing change must always be to maximize long-term business value for your client within available resources and timelines.
Want to succeed in business analysis? Apply the twelve principles of the business analyst mindset. Sign up for the Why Change newsletter for more resources and to receive your free copy of the BA mindset poster.
Explore the #ba_mindset in other formats: books, videos, or courses. Or contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.
2 comments