Business Analyst Times

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!

Comments (12)

Subscribe to this comment's feed

...
written by bamad, May 12, 2009

Bloody bloody good article Cecilie. Something all managers, project managers, co-ordinators and everyone else left in the world should be aware of.

More BA steroids please!

• 
• +0
• 
• 

...
written by reynardb, May 12, 2009

As a new BA this article was damn good and helpful. I am from a tech background, then a Systems Analyst, then moved country and became a BA. I struggle to find the right balance between what to present technically and functionally (I do both Functional Specs and Design Docs). Can someone maybe help me with some links for info on understanding the money budget side of projects better...as this article already helped with the time budget side...

• 
• +0
• 
• 

...
written by anandsd, May 12, 2009

Cecilie,

This is Real Analytical article.

Much impressed with the way of representation.

• 
• +0
• 
• 

...
written by charlieboz, May 12, 2009

I see several problems with your methods. Your approach is rather naive. First you are giving your estimate in terms of effort not duration. A professional always gives the estimate in terms of duration. That is what is expected - because that is what will impact the project. Secondly a professional always over delivers and under promises. It is naive to give tight estimates for so many uncontrollable events. Thirdly and most importantly your methods say nothing about what the project needs or what the team needs. This is the most fundamental mistake you can make. What if the project only has 2 weeks for you to do the work - PERIOD? What would you do? Refuse to do the work? Of course not. You would find a way. Now ask yourself, why don't I work like I only have 50% of the time that I need all the time? That way I would always bring the intensity and the focus that the job requires.

Doing more with less time is what a Bad Ass would do. I should know. I work circles around BA's all day long who think just like you. BA's that explode timelines kill projects. Plain and simple.

The solution is to use more effective methods - not more time.

• 
• +0
• 
• 

...
written by ultrafuchsia, May 13, 2009

oh, yeah. That old 'elapsed time' verses 'duration' problem. This is also why we BA BAs are generally juggling multiple projects at a time, as well.

I'm often tempted to add in a task for "meeting rescheduling and shuffling" to account for the time required to schedule, reschedule and re-reschedule meetings with high level, high priority stakeholders and with the project champion. To minimize this, when I create or review the stakeholder list, I also try to find out who the high priority stakeholders listen to. Who acts as their right-hand person? That person is often easier to get time with, and can be used to increase my priority level with the stakeholder.

The other point that your boss may miss is the fact that so much of this work must be done with the stakeholders or their representatives. Your point about adding a column to show the number of people involved in a task helps call that out. As a newbie BA, I used to try to do most of this stuff myself, thinking that proved I was good at my job. Now I know that being the facilitator and getting the stakeholders together to do the initial work (SIPOCs, as-is process maps, etc.) results in much higher quality deliverables and goes a long way toward implementing change management.

Keep up the good work....

• 
• +0
• 
• 

...
written by cecilie.hoffman, May 13, 2009

Charlieboz, even the most effective methods cannot guarantee a high quality BRD in a short period. When the customer has only a "hand waving" idea of what they want, and has not thought carefully about how the functionality desired will affect their business proceses, it takes time to help them articulate more precise needs. We all face the dreaded "get it done in two weeks". When we are given the time to plan our work, the result is (usually) a higher quality BRD. When we are time constrained, the quality of the information in the BRD will suffer.

• 
• +0
• 
• 

...
written by GavinL, May 13, 2009

CharlieBoz, I think your assessment of the article is a little harsh. Clearly based in reality and is certainly my experience of real life. Surely professional should strive However this is a great article, as it does addresses the key issue - you have to manage the stakeholders and project managers to ensure you spend enough time on requirements. Classic failure projects work on the principle that we know what we want and Requirements gathering is the process or writing it down. In reality the requirements gathering process then continues later in the project (controlled or otherwise). I apply a similar technique at the beginning of most of my large projects to ATTEMPT to negotiate sensible windows of requirements gathering (getting realistic effort and duration). I don't itemise tasks like in this article but do attempt to highlight how long it takes for stakeholders and contributors to mentally digest, communicate amongst each other and make decisions on requirements. That all requires BA effort and involvement as facilitator as well.
The key to making this approach (longer window of requirements gathering) work is keeping the 'pressure' on the stakeholders to use the time to work examples and explore potential solutions to the stated requirements - rather than to use the time to sit back and not make decisions.

Great Article.

• 
• +0
• 
• 

...
written by ultrafuchsia, May 14, 2009

charlieboz, don't mistake shrewdness for laziness. A Bad Ass BA would not only deliver a decent quality requirements document in two weeks, she would also present a risk analysis outlining the precise dangers faced by the project due to the inadequate time allowed to gather the requirements, and the steps she would lead the project team to perform to decrease that risk to a tolerable level.

A truly Bad Ass BA would, if the situation required it, get the project shut down because it’s going to fail anyway.

• 
• +0
• 
• 

...
written by khourya, May 16, 2009

Well I am new to comment on articles, but I felt that I had to. I totally agree with you Cecile, sometimes business just drop a thought and then leave us to build a whole document on. Such an event may take a day or a week to analyze what are the unknowns and who are the stakeholders.
We try to solve this, in our office, by having specilized BAs who handles requests coming from specific departments against handling everything hence the famous line "A joker of all trades is a master of none". The bank I currently work can afford it, but others cannot.
Finally, CharlieBoz, when you have a pool of BAs, you can kick ass and ask for delivery; however, if you are the center point of all requests then you have to prioritize them. A BRD might take one day to finalize if it is a small enhancement; however, if you are replacing a process then Cecile's 24 hours requires a bad ass BA to do it.

• 
• +0
• 
• 

...
written by Anniemac, May 17, 2009

Charlieboz, I have generally found that people who harp on about being 'professional' are more concerned about their reputation and appearances than their work. I doubt that it is particularly professional to write such a condescending, sneering comment. Estimation always starts with effort. It is the effort that is charged to the project budget so the PM needs to know that not just the duration. No matter how much time contingency you put into your work plan it still needs to go into the project plan and there will be other dependencies that will alter the estimated duration. Lag time due to review turn arounds etc needs to be taken into account in the schedule and the BA can contribute to that process using Cecile's formula (tho I think there is a bit missing) but the ultimate delivery date is driven out of the PM's schedule, dependencies, resource allocations and contingency. As for the dreaded two weeks, ultrafuschia is on the money. It is well documented that skimping on requirements is the primary cause of project rework, cost and schedule overruns. If you are forced into that position the risks must be clearly called out so that the stakeholders can make an informed decision. Providing a task based estimate and feeding it into this decision process makes it quite clear what will be done in that two weeks.

• 
• +0
• 
• 

...
written by varsha.varsani, May 18, 2009

A well drafted very good article, Cecilie. Though, I have not used this much detailed approach for planning the BA task assigned to me for the major projects, but I still prefer to give my manager the idea about, the time a task is going to take. This does help in providing the insight to the manager the delays possible, the hurdles in the tasks and this in turn helps in getting more inputs from the manager in terms of easing out the process, making the things available on time and also in worst conditions helps him/her to find the answers he/she should be ready with to reply to sr. management.
And moreover, this activity also helps in building better rapport with the manager as well as other team members and helps in stream lining the process further. Keep up the good work Cecilie.

• 
• +0
• 
• 

...
written by mparkerCS, May 19, 2009

Very good article. Probably one of the Top 3 I've read on the BA Times website. I like your technique and it helps give more fuel to the fight we constantly have with Managers and Business Owners on exactly how long our analysis and documentation process should and does take.

My company believes in the "cookie cutter" approach, which is "Project XYZ took only 3 weeks to document. Therefore, every project should take 3 weeks to document." These metrics help them to see that not all projects are the same.

• 
• +0
• 
•