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.

“Deficient requirements are the single biggest cause of software project failure.”

(Hofmann and Lehner, 2001)

We’ve probably all been on a project where the requirements have been deficient or where the business has articulated a solution instead of a need. As an example, a requirement that I’ve often heard articulated on projects in the past has been; “The solution must be delivered via the Intranet”. This appears to the business to be a very clear requirement and, if left unchecked, it’s what the development team will eventually deliver.

However, is it what the business actually needs? Why did they request a web site? Did they want to avoid the need to install software on client machines or was it to reduce the processing that has to be done on the end user’s laptops. If so the project will either fail or become much more expensive if all the computers in an organisation need to have the flash player installed for the Intranet site to run or if all the processing is done on the client machine to reduce the stress on the web server.

Projects with requirements that are clearly deficient, such as the one above, are doomed to failure as Hofmann and Lehner stated, so it’s important that the person gathering the requirements, the Business Analyst, ensures that they are accurate and clearly articulate a business need. The following five tips cover areas where requirements usually fail and offer advice on how you might improve your requirements:

1. Improve the Clarity of your Requirements

Defining requirements is a tricky business. In my experience the business owner will either not read them or go through them word by word looking for ambiguous requirements, hoping that they will give them a get-out clause or room to negotiate change at a later stage of the project.

I also find that when a development team are faced with a half decent set of requirements, they will instill a lot of faith in those requirements and interpret them very literally. It’s only later when issues arise that they will look for ambiguity in the requirements.

Employing the following tactics should help improve the clarity of your requirements:

- Read your requirements out loud. This will highlight where grammar needs to be improved and will make you think about what a requirement really means.

- Use fewer words. When writing a requirement, I try to use as few words as possible. A blank piece of paper cannot be misinterpreted is my motto when writing requirements.

- Avoid big words. Your parents may have spent a fortune on your education and I could have typed polysyllabic words instead of big, but you should avoid assuming anything about your intended audience, go for plain language that is easy to understand without a dictionary or being a native English speaker. Also, avoid technical language unless you include a glossary. In the world of requirements, big beats polysyllabic, simple beats complicated and short beats long by a country mile!

2. Ensure your Requirements are Complete

An incredibly expensive mistake to make when creating requirements is to overlook one. Discovering at the last possible minute that you need to include a brand new requirement will be expensive, painful and damaging to your reputation. Employ the following strategies to help avoid this potentially disastrous error:

- Correctly identify your Stakeholders. At the beginning of any project, draw up a list of potential stakeholders in your project, talk to everyone on that list and ask each one of them not only if they should be on the list, but who else they believe should be on the list. When you think that you have a final list, be sure to review it one last time with the same attention to detail that you would a set of requirements. Finally, once you believe that you have identified all stakeholders, don’t forget to talk to them and get their input into the requirements.

- Review, review and review again. The requirements gathering phase of a project is often the most time constrained part of any project. A well run analysis phase may well save big money on any project, but it is often difficult to sell the benefits of this phase, especially where a project is IT led. Whatever the pressures though, don’t compromise on the number of reviews. Get your first draft out early, no matter how bad and make sure that you go through at least three iterations before the final review. Set expectations early about how long this process will take, see point 5 for details!

3. Avoid Stating Solutions

“I want a web site” is not a requirement, it’s a solution. Defining a query that will generate results for a report, is not requirements gathering, it’s solution definition. The development team will rave about ‘requirements’ like these. They are easy to deliver and don’t require much thought at all. As a Business Analyst, you should be wary of these kinds of requirements as they narrow your focus and prevent you from defining the best solution to resolve the business need. Next time your confronted with a solution instead of a requirement, try the following:

- Why, what, when, how? When faced with a solution, don’t give up, be persistent, keep asking why?, what?, when?. You’ll know when you finally hit the requirement when the stakeholder states either a problem or a genuine need that a solution that you can design will address.

4. Don’t take Knowledge for Granted

A Business Analyst is often at their most effective when they have little or no domain knowledge. This lack of knowledge will force the you to ensure that you have correctly understood how a business works and will help you to document requirements in a way that will be understandable to the technical teams that may also have very little domain knowledge.

Over time in a particular area you will inevitably pick up a lot of domain knowledge, so it’s important that you keep in mind that not all of the people that will use your requirements document will have the same knowledge as you, or your business. Once you find that you can talk fluently and knowledgeably about a business, try to employ the following tips to ensure that you are still communicating at an appropriate level:

- Add a glossary to your requirements. And make sure that your stakeholders review it. In this way, you can ensure that you have correctly documented any jargon that is used within a domain in a way that will be understandable to any audience.

- Review early with the test team. Get the test team or test manager to review your requirements at the earliest opportunity. They will not only have to test your requirements later, but the very literal way in which they think will help you to identify where you have made assumptions about the knowledge of non-business stakeholders.

5. Plan the Requirements Gathering Phase

Every Business Analyst has felt the pressure to complete the requirements gathering and analysis phase in the shortest time possible. This pressure, whilst understandable, risks forcing the BA to take short cuts in the process. Reduce the pressure on yourself and the project by following these steps:

- Create a plan. Create a plan for the requirements phase showing at least the following; when you will reach each milestone, when the first workshop is, when each review is scheduled for and when the final draft will be delivered. This will set expectations amongst all stakeholders and gives them no excuses for not clearing their diaries.

- Book the appointments now. You’ve devised an aggressive plan that conforms to the time-lines that you’ve been given, so now book each of the meetings as per the plan. Don’t let diary conflicts nearer to the actual dates derail you.

- Keep an issues log. Every open question, every missed attendance at a review, every action taken. Make sure you log all issues, who owns them, when they were opened and when they need to be closed by. Use the issues list to hold your stakeholders to account, don’t let their lack of commitment be the reason why the requirements phase gets squeezed. Flag all issues and their potential impact to any stakeholder with responsibility for delivery.

- Set expectations. You’ve created your plan and booked the meetings, now don’t let things slip. Keep track of your deliverables and notify the project manager and relevant stakeholders as soon as you believe that you may miss a deadline. Use your issue log to help you get the support you need in getting things back on track and to explain any slippage.

If you have any of your own tips on how to improve requirements, 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.