5 Critical Requirements Steps that get Missed: What Business Analysts Are Not Doing

 

But don’t blame the analysts. They are missing these steps because business analysis is still a collective practice and not a formal profession with standardized tasks, metrics and tools. Many of the analysts are simply borrowing tasks, tools and techniques from other development areas.

 

The lack of professional formalization means that there is no single tried and true set of business analysis best practices. There are indeed some commonalities, but without a standardized set of best practices, there can be no real assurances that enough has been done to ensure that we have captured the right requirements for the right products. This is exactly where we get stats that illustrate only 20%[2] of features are used all the time and 42%[3] are never used!

 

So what tasks could your BA’s be doing that can change all this? These tasks are research, gap assessment (vs. gap analysis), ambiguity management, requirements validation (including facilitated sign-off) and quantifying the effectiveness of requirements activities.  More importantly, how can you tell that your BA’s are not doing these tasks? Let’s examine each of these to understand what they are, what they look like and what the direct quantifiable results are.

 

 

There are a lot of components that need to be understood in order to build accurate requirements, and only one of those is user input. Going to the users should be the LAST task a BA does in requirements elicitation, yet, when interviewed, the single-most common answer for they determine requirements, is “I go to the user.” The fact is that there is already a lot of detailed information contained within the project documentation, existing application and environment documentation. The BA needs to study this and understand business problem, goals & objectives of the project, scope, the environment the new application will reside in and how it will interact with and impact other applications within that environment.

 

By the time the user gets involved, the BA should already have a draft of context diagrams, workflow, requirements management framework, peripheral gap analysis, a high level draft of requirements and a plan of how they will accomplish the work on this particular project.

 

Gap analysis is a small sliver of the work that comprises Gap Assessment. Where gap analysis analyzes individual gaps on a given project, gap assessment takes it further and manages gaps in the same way that issues would be managed, assesses risk & impacts and draws links between gaps and the areas that are impacted by those gaps.

 

Ambiguities are a common part of life.  How many people can program the clock on their VCR? Ever read the directions for putting together a new toy or piece of furniture? Have you ever had a conversation with someone and gotten the wrong message?

 

All too often, we speak before listening and listen without hearing. In writing, our brains complete thoughts that aren’t there and in general, we forget to look at things from other perspectives and get feedback from others. In requirements, this creates ambiguities. Evidence suggests that ambiguities are the leading cause of our low project success rates, missed functionality and unused features. In a nutshell, ambiguities are risks!

 

The only way to ensure that ambiguities in requirements are exposed and addressed is to put a solid process for Ambiguity Management that is comprised of a set of clear steps that deals with each of the reasons that ambiguities even exist. Further, ambiguities as risk must be managed in the same way the risks are managed throughout the project to reduce occurrence and mitigate the impacts and effects.

 

During the hundreds of interviews I have conducted, I always ask the candidate how they validate their requirements. Again, 99%[4] say they “Go back to the user”, and are completely stumped when I ask them what they do when the user doesn’t know. The fact is there are lots of proven tools and techniques out there that will support validation. The analyst just doesn’t know how to apply them to achieve the best result. They simply can’t see the value of using them when they are not sure how the tools work and how it will impact the quality of their work.

 

Egos aside, candid conversations with business analysts tell me that everyone is struggling and learning by the seat of their pants. This is a direct result of the lack of practice formalization. Very few analysts are actually going to come out and say it. We all want to have a level of job satisfaction and feel like we’re competent and to be seen as competent by our colleagues. This means they are not going ask for help and advice on which tools and techniques they should be using to validate requirements.

 

You can uncover this problem by looking at the numbers of projects within your organization that have scope creep, users and stakeholders complaining about missed functionality, projects are taking longer to develop than estimated and your break and fix cycles are off the map. If you notice these patterns, my best advice is to work with your analysts to educate them and bring in a formal methodology that encompasses specific validation techniques. Any methodology that does not include a specific set of validation steps is incomplete and not worth the money you will spend on it.

 

Thorough requirements validation also requires something that some are actually doing, but not necessarily doing well: facilitated sign-off. I can’t tell you how many analysts, including the most senior, have asked me how I get stakeholders to read the requirements document. Despite all of the unknowns, this is one of the most significant challenges facing an analyst.

 

First, I have to share that I assume that stakeholders will not read it even though I give them time to do so. I also assume that those who do generally do not read it thoroughly enough to understand the details. That’s okay. I don’t need them to. I do need the stakeholders to understand the functionality represented by the requirements. The best way for them to really understand this is to participate in a facilitated walk-through of the functionality and sign off on that.

 

The final step that business analysts are missing is the compilation of quantifiable metrics associated to requirements that will illustrate the effectiveness of the requirements activities. It’s one thing to recognize that requirements need to change and improve and completely another to target exact areas for improvement and understand the degree of improvement needed. There is a lot of controversy on requirements improvement and traceability, but there doesn’t seem to be a lot of discussion about how to measure and quantify those improvements.

 

In order to understand what aspects of requirements need to be improved, you have to approach it the same way you would any other improvement project. Determine the kinds of metrics you can gather for requirements and then analyzing those metrics to determine and understand the starting point.

 

Setting a benchmark allows you to illustrate the current situation and determine the levels and types of professional development your business analysts will need. Establishing milestones provides you with the ability to perform a comparison at various points during the improvement process, and determine the effectiveness of your efforts.

 

In order to do this, it is important to understand the tools that will provide the metrics you want to use for assessing your requirements. Some requirements tools will come with a couple of built in metrics for traceability, but the reality, there is yet to be a single tool that will compile a full set of standardized metrics to support a true requirements improvement initiative.

 

At the basic level, you can very easily identify the volume of requirements. This volume becomes more precise when you follow a standard numbering and classification protocol. Quite simply, it is a count of the documented low level requirements.

 

The next basic metric you can gather, is the time to complete each stage of the requirements life cycle (as a separate subset of the software development life cycle). This will take some dedication on the part of your staff to report if you are not using a tool that will provide timestamps at various points during the cycle.

 

During a typical life cycle the next quantifiable metric that you can compile is the volume of requirements actually designed, built and implemented by the design and development team. Ideally, this information is available in your traceability tool and traces back to both the mid & high level requirements and project scope. If it’s not, it will take some wrangling and negotiating to survey the designers and developers to extract this information from them.

 

In most organizations, you be able to compile the volumes of passed and failed testing. While this will give you an approximate sense of how well you did overall during requirements, it is simply not detailed enough to help you understand trends in requirements and identifying the specific activities for improvement.

 

So what do all these pockets of metrics mean? How can we compile, analyze and compare them to understand how effective your requirements practices are? Well, in and of itself you can use the volume of requirements divided by the time it takes to complete each step to understand how many requirements are completed in a day.

 

However, compiling ambiguity metrics using a formal ambiguity log allows you to identify, understand and monitor trends in specific types of requirements issues that crop up and impact the overall quality of requirements. By adding this metric to the formula, you will be able to measure the full effectiveness of your requirements techniques and activities.

 

By comparing the metrics of individual projects across your organization, specific opportunities for improvement will become apparent. In fact, this understanding of organizational requirements effectiveness will enable targeted areas of development for your business analyst team, improved collaboration between project teams, and support organizational agility.

 

All in all, missing any of these critical steps not only increases the risks your project will face, but will add to development and maintenance costs and decrease the overall ROI realization. On top of this, you will not have the detailed information required to support focused requirements remediation efforts. All of this translates into a reduced ability to support your core business and an inability to remain innovative.

 

Sure you’re busy. But can you afford not take action and change the outcomes of your projects? Why not make 2010 the year you become a corporate hero and help your organization rebound from the economic down-turn by hitting the ground running?