Business Analysis Coaching

Change Requests are the inevitable consequence of trying to document requirements and to fulfil the needs of others. Minimising the number of change requests on any given project is an admirable goal, but eradicating them all together is never going to happen and is probably going to be detrimental to your project.

Try to imagine what a project without change requests would look like. It’s going to be quiet for a start, no change requests means the business are going to have to settle for what they asked for, so there’ll be no need for weekly change boards for starters. Now imagine the paralysis that will accompany a project that does not endorse the concept of change. Would any business ever sign off their requirements? If they did, would you not want to find out why? What’s in if for them? What have you missed that means that they are willing to sign off?

Never forget, that the goal of the requirements gathering process is not only to get a complete and accurate set of requirements, you also have to get them signed off by the business. In my experience, actually asking a business to sign off their requirements induces a sense of dread in whoever has to sign them off. It’s at this point when a Business Analyst has to put their natural instincts to one side and reassure the business that even after sign off, things can change.

While this may feel unnatural, at some point you have to accept that every project has to move out of the requirements gathering phase if it’s going to be successful. Thankfully, a robust change management process can give both your business and you the confidence to move forward, knowing that there is a process in place to both capture mistakes, adapt to a new business environment and to accommodate real change that could not possibly have been identified at the beginning of a project.

In my opinion, it should be the role of a Business Analyst to actively seek out change requests by constantly checking that the project is on the right tracks. Looking for change requests is an excellent way for a BA to challenge their own requirements and to let the business know that you are on their side and are prepared to embrace change if it’s needed. The downside to this is that you risk alienating both the test and development teams, especially if they believe that you are actively trying to move the goalposts whilst they are knocking themselves out trying to deliver.

Resistance to change from the development and testing teams is understandable, they’ve put a lot of effort into delivering against your requirements and will be understandably upset to discover that a lot of their work may no longer be required. On the other hand though, they also want to deliver a successful product, just like you, so if the change is justfied in terms of business benefits and will be funded by the busines, you will eventually get their support.

Bugs are always easier and less expensive to fix the sooner they are identified on a project. The same is true of change, act in the best interests of your business and don’t be afraid to admit that things need to change, embrace that need. Change is the reason the project exists in the first place.

If you have any of your own thoughts on how rigourous we should be in the pursuit of change requests, then please feel free to let me know by leaving a comment below. If you’re interested in seeing more articles related to the role of a Business Analyst, then why not subscribe via the RSS feed.