Busting a Requirements Document Planning Myth

Writing a requirements document – where does the time really go?

Have you noticed that requirements documents always take longer than expected to complete? Even when we follow the best practice of planning the activities, the reality is that even the most experienced of us blow our schedule. But why? There’s a perception that the BA is “in control” of all the events, and in control of the document’s progress from start to finish. We know that’s a myth. Let’s be bad-ass BAs and bust the myth.

You probably already know about the best practice of preparing a requirements work plan for your requirements document. A requirements work plan is essentially a mini-project plan that has one deliverable, the completed requirements document. By identifying the tasks needed to complete your requirements document, you can estimate the time needed to produce the deliverable. Moreover, you can negotiate the tasks from an objective basis instead of waving your hands and asserting that there’s no way you can get this done in two weeks.

To frame our requirements document authoring project, let’s establish a starting point and an end point, and examine the events in between. The starting point is the moment you receive the request from your manager to prepare the requirements document. For the sake of argument, let’s assume that the manager provides some level of input documentation which outlines the problem that the project is addressing, for example a business case or project charter. The end point is when you deliver the approved requirements document. So, in a typical work plan, you would identify tasks like these:

• Interview stakeholders and SMEs to elicit customer “needs” and explicit success criteria
• Prepare the graphical representations for the document, e.g., a SIPOC, or another context-setting diagram that gets everyone on the same page, so to speak, and the “as is” and the “to be” diagrams.
• Prepare the high-level Use Cases, process maps,
• Prepare the first draft of the requirements document, which includes Project Scope, assumptions, risks, the diagrams, the use cases, and oh yes, the requirements statements themselves.
• Conduct informal (peer) review of first draft
• Conduct formal review of working draft, e.g., with customer and stakeholders
• Prepare final document (update working draft, tweak graphical representations, identify targets and limits for the highest priority success criteria, make subjective pronouncements about the usefulness of the word processing application)
• Obtain document sign-off from customer, stakeholders and designated approvers

Now you estimate the number of hours to complete these high level activities, or we may take even more care and create a work breakdown structure so that we can assign hours at the sub-activity level. For example, we may know that there are five primary use cases, the first two will take about eight hours each to draft, review, and stabilize, one will take only four hours, and the other two will take only two hours each because essentially they are the “exception handling” cases for the first two big use cases. For the sake of simplicity, we’ll keep our example to mostly one level. When we assign hours to our tasks, our table looks like this:

No doubt for your own particular situations, you would add some additional tasks. At this point our manager thinks we’ve done a great job. And we have done a great job. For example, when we reviewed the list of stakeholders with our customer, we found out that one person on the list had transferred to another group, and didn’t need to be on the interview list. We also found out that a stakeholder would be on holiday during the month that we were hoping to get the document approved, and now we know who to work with in that person’s stead. And, we were able to keep the number of use cases from exploding. So we’ve calculated the hours, and under the best circumstances, we could accomplish the completion of requirements document in the three weeks that we’ve been given.

Ah, but we BAs know the dark truth about this lovely plan. We know that even if our manager cleared everything off our plate, the plan still has cracks in it. There are at least two types of cracks.

First, there are potential delays. From a project management perspective these are risks. Unfortunately we do not itemize them because no one wants to acknowledge that the risks are real. These “risks of delay” are in fact activities that are out of the control of the BA. Here are some examples of uninvited, unloved tasks that are never welcome on a requirements work plan.

• Review business case (hope like heck that you don’t have to rewrite it because stakeholders aren’t identified, and the validation criteria for the benefits are missing; causing a delay to obtain this information)
• Meeting(s) to resolve conflicting customer stakeholder requirements; causing delay(s)
• Meeting(s) to resolve IT stakeholder issues; causing delays
• Validating that third party vendor’s commercial off-the-shelf solution can support the newly updated projected capacity needs; causing a delay
• Meeting(s) to resolve the perception that the most recent changes to the requirements in this document now put the project in conflict with another project; causing a delay

This is just the tip of the iceberg. If you have a friendly project manager who is an expert on predicting and representing project delays, now is the time to ask for input.

You may have guessed that the second factor is the presumed degree of BA control over the known activities. The BA role is a hub role, that is, we coordinate as well as analyze information. Under ideal circumstances, the information we collect is complete, accurate, and agreed to by all parties – all we have to do is wave our wand of analysis, et voilà, we have requirements. The reality is the information is evolving (partially complete), somewhat accurate, and only partially agreed to by some of the parties. Our magic wand sometimes seems more like a wire whisk; we have to keep stirring the information to get an acceptable mix.

The previous table only showed an estimate of hours to complete the task. What if we took into account the degree of control a BA has over the task? We can do that by factoring in an assessment of the BA’s control, and associating a time multiple to that assessment. If the BA has full control, then the multiplier is 1; if the BA has only some control, the multiplier is 2. For our worst case, the time multiplier is set at 4. The table below shows an example where the time it takes to complete the requirements document doubles if we acknowledge that some tasks are out of the BA’s realm of control.

Let’s walk through item 1. Interview stakeholders and SMEs. We estimate that we can talk to the three stakeholders and five SMEs in two small-group interviews, write up our findings, and do some follow up, and be done in 24 elapsed hours. In the best case, we would have nearly full control of this activity. But we know that these individuals’ calendars are already fairly full, so we expect to only have some control. In this situation we might multiply the 24 hours by 150% which gives us a best case of 36 hours, and multiply the same 24 hours by 200% which gives us 48 hours for our expected case.

Walk through the remaining line items, calculating best and expected cases. You’ll notice that the only activity that the BA is in full control over in the best case is preparing the first draft. If you don’t know all the intricacies of Word, you may want to give yourself some slack in the schedule to deal with Word’s unhelpful numbering and tendency to size the columns of a table such that the edge of the column is off the visible page.

Range of BA Control on Requirements Documentation Tasks

Our original requirements work plan predicts that we can complete our requirements document in 2.6 weeks if this document is the only project on our plate. If we consider the typical delays, and account for them by factoring in the degree of control we anticipate, we come up with a more realistic 5.1 weeks. Tune this chart to reflect your situation, your activities will be different, your estimates will vary, the time multiplier is just a variable you can tune. You may want to add an additional column to show the number of people involved in a task. Be sure to provide both best case and expected case scenarios in your work plan to make the risks obvious to your manager and the rest of the team.

The requirements work plan is still a best practice; the additions I have suggested give us a dispassionate way of bringing to light the normal scheduling delays that are a challenge to every requirements document. Be gentle the first time you try using this model, it might give your manager a heart attack. Or, it might give you the opportunity to give your manager some insight into your concerns about the target date you are being asked to meet. There’s no guarantee that even with this much disclosure your manager will change the target date. There is a chance that your manager may work behind the scenes to prepare people to be responsive and avoid the delays.

And wouldn’t that be great!

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion motorcycle riding at balsamfir.com. She can be reached at [email protected].