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.

“It is not necessary to change. Survival is not mandatory”~ W. Edwards Deming

I’ve discussed in a previous post how it’s the role of the business analyst to seek out and embrace change. However change is often chaotic, expensive and unless you happen to be the stakeholder sponsoring the change, it’s usually about as popular as a tester at a developer’s convention.

As enthusiastic proponents of change, our challenge as Business Analysts is to sell the need for change to sceptical stakeholders and budget holders alike and also to point out when a change is neither desirable nor in the best interests of a project.

Enter then, the humble Change Request, a BA’s most trusted tool in the change process. A tool that allows the Business analyst to detail what the specific business problem is that caused the need for a change, what can be done to resolve the business problem and what impact those changes will have on a business or project.

This post delves into the change request itself and describes what a Business Analyst should include in their change request to ensure that key stakeholders are in a position to decide if change is really necessary and if so, how should the change be implemented.

1. Why Change?

When creating a Change Request, the first question that we, as Business Analysts, have to answer is, ‘Why is there a need for change?’. Business Analysts are keen on change, it’s what keeps us employed, but change is difficult so a Change Request needs to establish very quickly that a change is really required. Try to answer the following questions when describing the need for a change:

- Who is the Sponsor?: The very first question to answer in a Change Request (CR) is, ‘who is sponsoring the Change Request?’. A CR needs to be raised by the right person, a key user is unlikely to get much buy in for changing business requirements, but may justifiably want to change the layout of the user interface for instance.

- What is the problem?: What problem will any change actually solve? Are there new regulations that change the nature of the project does functionality not work quite as anticipated. Whatever the problem, describing it in detail will allow stakeholders to decide if it’s a problem worth solving.

- Can you Justify the Change?: Can you explain why this problem should be fixed? What benefits will it deliver to the project or business? If you were a stakeholder, would you consider fixing this problem a change worth making?

2. Identifying Solutions

The next step in completing a Change Request is to work out how to fix the problem. A required change with no clear solution or next step can often lead to paralysis on a project, so it’s the role of the BA to offer solutions and possible ways for the project to move forward. The following points describe the things you need to pay attention to when identifying solutions:

- List Multiple Options: Always try to include more than one solution for consideration by the responsible stakeholders. Even where no other reasonable option exists, you should always include the option of doing nothing.

- Do Nothing: Doing nothing is often the least expensive approach to any change and should always be an option for discussion. This challenges stakeholders to consider if a project really needs to go through the pain and expense of implementing a change.

- Articulate the Solution Clearly: Treat the solution like you would a requirement, clearly state what each solution will entail in an articulate and unambiguous way. The change board responsible for picking a solution must have a common understanding of what a change entails, in the same way as they would need a common understanding of a business requirement.

3. Analysing the Impact

Each solution identified by the Business Analyst should include an impact analysis. This analysis should help the stakeholders to identify the solution that has the most positive impact on their business or project. Listed below are the areas that the BA should cover in their analysis:

- Tasks & Milestones: Identify the steps required to implement a solution, even if this can only be done at a high level. This has two benefits, firstly, detailing each task will allow reviewers to understand the solution and make a more informed decisions as to whether or not it is possible to implement. Secondly, by identifying the activities required, the BA has begun the process of re-planning that will have to take place once a solution has been selected for implementation.

- Costs, Time & Resources: Estimate the time that a solution will take to implement, the resources required and most importantly the costs involved. These are the key indicators that any stakeholder will look for when making a decision. Don’t forget to specify what types of resources (testers, developers, etc) will be needed, not just the total amount of people. Also, be clear about whether or not you are specifying actual time taken or the duration of time required.

- SWOT: Complete a SWOT analysis. This will allow you to highlight other points of interest to stakeholders about a solution that may not be immediately clear by simply looking at the cost involved. Regardless of the cost of a solution you should document clear pros and cons for each solution as well as any opportunities that may present themselves

- Quality: Finally, be clear how stakeholders will know that they have got what they paid for. State clearly how a solution will be tested, if it will need business acceptance testing or will technology sign off be enough to push any implementation live.

4. Selecting an Option

Even when we get a say in the option selection, it’s unusual for Business Analysts to actually select the final option to be implemented. What we can do though is present the options to the key decision makers and make our recommendations based on what we’ve learned.

- Identify Key Decision Makers: Assuming that your project doesn’t already have a change review board in place that will take decisions on all changes, then you’ll need to identify who can sign off on and agree to implement a change. All of the important stakeholders, including IT, business and users, should be represented on the Board. The main stakeholder, typically the one that owns the budget, should chair the board and have the deciding input into the eventual solution selection.

- Recommended Solution: After completing the Change Request, conducting the analysis and considering their understanding of the requirements, you are well placed to recommend a solution for the change board to consider. Make sure that your justification stands up to close scrutiny and be prepared to present your recommended solution to the Change Board.

5. Implementing Change

As with any implementation, once a change has been selected by the Change Board, it’s your role as the Business Analyst to ensure that what is required by the business is actually delivered. Tracking changes associated with a Change Request can be a challenge, so here are a few points to keep in mind.

- Store Change Requests: Keep the Change Request, along with a record of which solution was chosen, under lock and key. This document is your proof to show that a change has been requested and has been approved by the proper authority.

- Conduct Further Analysis: You may have had to put a change request through quickly or sketched out the exact steps that need to occur which require a lot more detail to be added before they can be implemented. Now is the time to do that analysis. Get back into the requirements gathering mentality and ensure that you understand exactly what the business want and why.

- Update your Documents: This is always a big step for me. You are about the change signed off documents, so make sure you update the document versions allowing you to track how requirements have changed over time. Include the CR itself as a new appendix in any documents that change. Also, go to the trouble of getting sign off for any changes that you make to your documents, your business will be reluctant to go through this process again, but in terms of ensuring clarity it’s vital.

One thing is for sure, embracing change can create a lot of work. Creating a Change Request with the right information will help make sure that the right change happens for the right reasons.

If you have any of your own tips on how to create a Change Request, 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?