Change, scope creep, expectations etc can be managed while a project is in-flight by implementing good process.   A problem with poor requirements however is different.  There are always ways to improve how requirements are elicited and how they are written, others have mentioned this and I’ve talked about how to do this on my blog, but if you inherit poor requirements on an in-flight project, you options are limited and the impact is potentially catastrophic.

You face three big issues when you inherit poor requirements on a project:

1. The business has already invested the time in creating the requirements that currently exist.  You won’t get that sort of quality time with them again; in truth they thought the analysis phase was a waste of time anyway.

2. You risk alienating both the development teams and the business if you start raising the number of change requests that are actually required to fix situations like this.

3. A strange sense of inertia will descend upon the team when you start pointing out how deficient the requirements are.  It’s amazing how many people would rather deliver rubbish than what the business actually need.

So, faced with inertia, disgruntled stakeholders and a skeptical business, what is a conscientious Business Analyst to do?  Let’s face it, at this stage the odds are stacked against you and you should probably be looking for a new project anyway, but if you fancy a challenge, you could try turning to an old friend, the test team.

Yes testers.  This might seem a bit strange when you consider that in a traditional waterfall diagram, testing comes somewhere at the end of the development cycle especially being that the longer a bug goes identified the more expensive it is to fix.  Don’t forget though that testers test requirements, not code.

This gives you license to let the testers loose on the requirements that do exist and challenge them to come up with suitable test cases.  Once this happens, things are going to get very painful for everyone, but you will have found yourself a very potent ally.

A developer won’t be so keen on moving forwards with coding once he or she has a sense that their code will never get out of FAT testing.  Likewise the business should be in test case review meetings and be faced with a barrage of questions, that will, hopefully, open up doubts in their mind that this requirements phase is as closed as they initially thought it was.

Like I said, it’s going to be a painful process, no one is going to be happy, but this is your last chance to salvage something from the project.  I’ve only been in this position once myself and it will take all of your skills just to deal with the political fall out from this approach.

How did it work out for me?  We de-scoped a lot of work and concentrated on what little we could safely say was required.  While this was a success, it also resulted in timelines being slashed to allow the start of the new development cycle to begin, only this time with proper requirements.  Definitely a victory, but a very painful one.

I’d be very interested in hearing how other Business Analysts have dealt with this challenge?

If you’re interested in seeing more articles related to the role of a Business Analyst, then why not subscribe via the RSS feed.

This article originally appeared as a comment on Linkedin in the IIBA discussion group.

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.