Skip to main content

Author: Cecilie Hoffman

Bad-Ass BA on Steroids

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:

Requirements Document Activity Estimated Hours
1 Interview stakeholders and SMEs 24
2 Graphical representations
2a Context setting diagram 4
2b As is and to be cases 4
3 Prepare high-level Use Cases 24
4 Prepare 1st draft of document 24
5 Conduct peer review of 1st draft 4
6 Conduct formal review of working draft 4
7 Prepare final document 8
8 Obtain document sign-off 8
Total hours 104
Total days (8 hours in a day) 13
Total weeks (5 days in a week) 2.6

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

Scale 1 2 3 4 5
Assessment No control Some control Full control
Time Multiplier 400% 300% 200% 150% 100%

Requirements Document Activity Initial Estimated Hours Degree of BA Control Refined Estimate
Best Case Expected Case Best Case Expected Case
1 Interview stakeholders and SMEs 24 4 3 36 48
2a Context setting diagram 4 4 3 6 8
2b “As is” and “to be” diagrams 4 4 3 6 8
3 Prepare high-level Use Cases 24 4 3 36 48
4 Prepare 1st draft of document 24 5 4 24 36
5 Conduct peer review of 1st draft 4 4 3 6 8
6 Conduct formal review of working draft 4 4 2 6 12
7 Prepare final document 8 5 4 8 12
8 Obtain document sign-off 8 4 2 12 24
Total hours 104 140 204
Total days (8 hours in a day) 13 17.5 25.5
Total weeks (5 days in a week) 2.6 3.5 5.1

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 She can be reached at [email protected].

Bad-Ass BA Caution!

badassweasel1Weasel Words Will Send You to the Requirements Dog House

The holy grail of writing requirements is for the requirement to be validated before the application or system is released. Quality Assurance analysts inherit the work of Business Analysts. QA analysts are looking for something they can measure. All too often we business analysts are guilty of allowing what I call “weasel words” to nest in our requirements. Just as catching a wriggly weasel is hard, so is trying to validate a requirement that has no boundaries.

Weasel words are qualitative descriptors that are typical of that most difficult of categories of requirements, User Requirements. User requirements are often given to us with a wave of the hand, “Oh, you know what I mean. I just want it to be good.” “Good compared to what?” you ask, knowing in your heart this is going to be an uphill climb. “Well, better than what we have now. We’ll talk next week, okay? Bye!” With that farewell, the customer has just weaseled out of giving you something quantifiable, and, when the QA analyst looks at your BRD or Functional Requirements document, you will be in the Requirements Dog House.

Cultural Note: “In the dog house” is an idiomatic expression for being in trouble. Dog houses are a small shelter separate from the main dwelling. In the middle 1900s, if a wife knew her husband was out drinking, she might lock him out, forcing him to sleep it off in the dog house.

Here is a list of my favorite weasel words. I’m sure you have some to add.

average optimize
best-of-breed optionally
best-in-class preferably
easy probably
efficient rapid
etcetera reasonable
fast robust
flexible simple
improved state-of-the-art
intuitive sufficient
maximize user-friendly
minimize usually

These words may creep in from the original benefits statement. There’s more to creating a requirement than just restructuring a benefits statement into the Trigger Actor Action Condition syntax and removing the weasel words from the text. Weasel words indicate that the customer’s thinking in a particular area is fuzzy; there will be a lot of work to help them articulate their intentions and true needs. As business analysts, we must ask,

  • “Maximize? Do we have a baseline to maximize from? How much do we need to maximize before the improvement is satisfactory? Are we looking for a 25% improvement or a 65% improvement?”
  • “When we say, ‘state of the art,’ do we mean that we want an application that is in the Leadership quadrant of Gartner’s Magic Quadrant?”
  • “When we say, ‘flexible,’ what attributes do we anticipate needing to change?”
  • “When we say, ‘usually,’ that implies that sometimes ‘such and such’ will not be true. Could you tell more about the circumstances when it is true and when it is not true?”
  • “Rapid? Fast?” what part of the user-system interaction are we talking about? Could we focus on the time it takes the system to process the transaction request and respond back to the user? Fast meaning sub-second response?”

Customers don’t understand that weasel words weaken the BRD. Weasel words deprive the system designer of clear performance boundaries. Weasel words make test script writing a nightmare for the QA analysts. And, when conducting User Acceptance Testing, the BA may wish she could run to the dog house to avoid the customer’s disappointment.
So, how do you catch weasels words and address them properly? Try conducting a peer review of your BRD or Functional Requirements document with your friendly QA analyst or another BA. Neither needs to know the domain of the document, just give them your list of weasel words and promise them a doughnut for every one they find.

Cecilie Hoffman is a Senior Principal IT Business Analyst with the Business Analysis Center of Excellence, 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 She can be reached at [email protected].

More Bad-Ass BA Techniques

Guidelines for Interviewing Candidate BAs

You have just been told by your manager that you will be interviewing a candidate for a mid-level business analyst position on your team. “We can’t hire full-time employees right now, but we can bring on contractors for this project. Make sure they have the skills we need, okay?” is the only direction you receive in the email other than the candidate’s resume.

Among us are few who have been taught how to conduct an interview, and I’m not talking about the “don’t ask these questions, ever!” memo from Human Resources. Just how do we determine whether a candidate, who has dressed properly for the interview, and seems like a nice person, could be a great contributor to our team?

I look for fundamental traits and indicators. Many people will use the term “soft skills” to describe these traits. I hate the term “soft skills” because it implies that the difficult skills are the domain-level technical skills, while the problem-solving and human interaction skills are “easy.” In my humble (ha!) opinion/experience, the problem-solving and human interaction skills and fundamental traits are the most difficult attributes to find in a candidate, and the most difficult to teach to an already hired employee.

Candidates are usually interviewed for their knowledge of a business domain, like, finance applications, or medical service auditing. There are plenty of people with the subject matter expertise who can interview a professional level candidate to determine if they have the right knowledge. Few people have been trained to interview a business analyst candidate for the critical thinking and communication skills that are indicators for success.

Here is my list of questions for a professional level candidate, an intern candidate (no previous professional experience) and a list of traits that I have found most successful BAs to possess. I hope this will be helpful for your next encounter with a candidate.

General Interview Guidelines for a BA

These suggestions are in no specific order.

  • Use the Dilbert cartoon:

    Ask the candidate to explain why it is funny, and ask for an example of how they resolved a difficult requirements elicitation situation.
  • Ask the candidate to describe what information goes into a Business Case, and how does that information relate to a Requirements document.
  • Ask the candidate to explain the difference between the role of the BA and the role of the PM, and how they have managed when they had to play both roles on a project.
  • Ask the candidate how they go about obtaining success criteria for requirements, and for bonus points, how they determine what metrics to associate with those success criteria.
  • Ask the candidate to describe their group facilitation skills.
  • Ask the candidate to describe the difference between functional and non-functional requirements.
  • Ask the candidate to describe the difference between a requirement and specification.
  • Ask the candidate to describe the most interesting problem they ever built a model for, and what the model showed.
  • Ask the candidate if they are an “ask for forgiveness or wait for permission” type of person, and why.
  • Ask the candidate what they enjoy about being a business analyst.

Interview Questions for the BA Intern Position

People who interview for an intern position are not expected to have previous professional-level experience. Keep in mind that while you, the hiring group, are hoping for high-quality and low-cost labor, the candidate is evaluating you as a potential mentor.

  • Do you know what a business analyst is, and what a business analyst does?
  • How does being “in between” the business and technical world sound to you?
  • Do you write? Poems? Short stories? Keep a journal or a blog?
  • Tell me about a situation where you and some friends were trying to solve a problem. I’m looking for a situation in which some people wanted to go about dealing with the situation one way, and you or someone else had a different idea.
  • planning a team effort for a school project
  • planning a social gathering, party, sports event
  • Tell me about a project that you worked on that you enjoyed a lot. Would you give me the big picture first then tell me about one detail-level part of the project.
  • Is there a technical device that you really enjoy using? How would you describe that device, and what it is good for to, let’s say, your great uncle who won’t use an automated bank teller?
  • How do you feel about asking questions in a group situation? 
  • When you have been in a group, and people are arguing, how do you feel? Do you try to resolve the conflict? What if you are responsible for the group coming to an agreement?
  • Have you used flowcharts or process maps in your school work? How do you decide when to use words to describe something and when to use graphics/pictures?
  • In school you found yourself with multiple “priority one” tasks. How did you decide what to work on? How did you decide how to manage your time and energy?
  • Sometimes you have to make decisions in the absence of guidance. Are you more comfortable taking the initiative or do you prefer to wait until guidance is available? Tell me about a situation where you had to make that choice.
  • How would you describe your leadership style?
    • authoritarian
    • participative 
    • delegative
    • I don’t consider myself a leader

Traits of Successful Business Analysts

  • Has a strong interest in problem identification and problem resolution
  • Able to determine when solutions are being presented as problems, and can drill down to the underlying problem
  • Able to comprehend both big picture and detail-level information, and know when to work at which level
  • Able to abstract a big-picture from detailed information
  • Able to translate between business and technical ways of talking about something
  • Able to function with both fuzzy and crisp representations and know when to use which
  • Able to ask the dumb questions
  • Able to appreciate the need for process even when it will mean possibly missing a deadline
  • Able to mediate or temporize when serious conflict arises 
  • Able to remain collected and productive during conflict 
  • Able to generate alternative solutions for consideration to facilitate the decision making process, even if the analyst has a strongly preferred solution
  • Able to play the role of advocate for a weakly-represented group or alternative that needs more consideration
  • A high degree of honesty and integrity
  • Able to engender trust and confidence from all the various parties involved
  • Maintains a sense of detachment from the influence of power mongers
  • Sensitive to politics and power structures
  • Tolerant of ambiguous situations 
  • Respectful of each individual
  • Has a warped sense of humor
  • Predisposed to work collaboratively while still being able to work independently
  • Able to modify own leadership style so that it is appropriate for the project and the parties involved
  • Able to take initiative appropriately (do the right thing in the right situation), that is, decide whether to ask permission or to act and then seek forgiveness

Cecilie Hoffman

is a Senior Principal IT Business Analyst with the Business Analysis Center of Excellence, 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 She can be reached at [email protected].

Ten Bad-Ass BA Techniques

Plus Four Fundamental Principles

Principle #1. Leave your ego at the door

  • You are a business analyst – you have a license to ask dumb questions; it is your responsibility and your job! So ask the dumb questions, admit you don’t know, ask for input, show work at early stages, don’t let your own ego-fears-pride get in the way of problem solving.
  • Put your team in the spot light, put yourself behind the curtain.

Principle #2. Authority is 20% given & 80% taken – take it!

  • Don’t wait for permission, ask for forgiveness.
  • Manage those meetings!

Principle #3. Acknowledge people

Sometimes you have to push people or ask them to do more than is normal to expect. You can thank them for their help but over time, your thanks may develop a hollow tone. Take the time to recognize people’s efforts in a way that means something to the individual; creative ways of saying “thank you” are remembered for a long time and create a positive impression and a good relationship.

  • Nominate them for an award
  • Send a message to their boss – what you needed, why the person’s professional conduct and timely response saved your butt
  • Send a message to the person
    • A “thank you” card – there are many cyberspace sites that offer electronic cards
    • A simple email message acknowledging the person’s effort
      Include a .jpg of a plate of tasty goodies like cookies, chocolates, or samosas

Principle #4. If you don’t fail on occasion, you aren’t trying hard enough

Progress and innovation come from holding on to the idea despite the inevitable series of failures. If the consequences of your taking initiative results in a backfire

  • Acknowledge verbally that you may have gone too far in your attempt to actively engage in moving the project along the path to success
  • Ask the person if there is a better way for you to accomplish your goal. Smile; deflect any barbs that might come your way.
  • Learn from the failure. Don’t get defensive – nothing ventured, nothing gained!

The Ten Techniques

Remember, these are the “bad-ass” techniques. Use them with care, especially if you are risk-adverse.

Managing meetings

1. Use “roll call” to obtain explicit decisions. In meetings (telephone or in person), do not accept silence as a response! Instead of asking, “do we all agree?” instruct people to express their concerns with this prompt, “If you disagree, speak up now.”

2. Provide a suggested agenda to focus activities at a standing meeting.

3. Use Actions-Decisions-Issues to record meetings.

Facilitating communication and understanding

4. Share bad news early

  • The sooner “management” or “leadership” knows there’s a problem, the sooner they can start working on it. 
  • If you use the red-yellow-green flag paradigm: extend the paradigm, “Pale Yellow” means “warning, this could get worse”; “Orange” means “one step away from Red”.

5. Did they read the document?
For documents that are in a draft form, include an unexpected phrase in a strategic location in the document, e.g., “300 Pink Elephants” – people will comment on it if they see it. Take care to remove the phrase before the document becomes a deliverable!

6. Treat requirements templates as guidelines

  • Provide all the information that is asked for, or explain why you can’t.
  • Don’t ignore the gaps, missing or unknowns, identify them!
  • Add the sections or references you think are missing

Conducting interviews

7. Send the list of topics you plan to cover in advance – no more than five general topics. If you have specific questions that will require research, provide those questions in advance.

8. Paraphrase as a way to keep a person talking without agreeing with what they are saying.

Establishing trust-based relationships

9.  Make a personal connection

  • Extend yourself beyond normal bounds to make a personal connection with the individual regardless of social group, ethnic background, and gender.
  • Ignore what you may have heard about an individual; do not allow another person’s negative assessment of that individual to prejudice you – make your own assessment, based on how that individual conducts him/herself with you.

Managing requirements

10. Get the Success Criteria and Success Metrics

  • Offer outrageously low or high metrics for targets to elicit a more realistic expectation for “success”
  • Accept the “solution” with grace; but continue to ask questions. Play the fool until the requirement (need) has success criteria and a way to measure it.

Cecilie Hoffman is a Senior Principal IT Business Analyst with the Business Analysis Center of Excellence, 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. Her personal passion is cross-country motorcycle riding. She can be reached at [email protected]