Brainstorming Techniques

by Marsha Hughes, PMP, CBAP CSM

Do you use brainstorming in meetings? You might want to try different brainstorming approaches, such as the double reversal. In the double reversal, write your goal, such as “Increase customer satisfaction” on a flip chart or board, and then reverse the goal to “Decrease customer satisfaction”. Ask the group to brainstorm ideas for the reversed goal, which may be easier (and more fun) to do than for the real goal. After the brainstorming, reverse the ideas generated, and you will end up with ideas that can help you meet your original goal. For example, “don't ever talk to customers” becomes “talk to customers often”.

Other variations on brainstorming techniques include: popcorn, where anyone in the group can call out an idea at any time; go-around, in which the group contributes ideas (or passes) in order; walk-around, in which the group walks around in a circle and writes their ideas on a flip chart when they pass it; and brainwriting, in which each person in the group writes their ideas on a piece of paper and passes it to the person next to them, who then adds their ideas.

Getting to Consensus

by Marsha Hughes, PMP, CSM

In requirements workshops and other meetings, getting consensus on a decision or proposal can be a difficult process if the participants have different needs and agendas. If the group can't reach consensus, the gradient of agreement scale can be used to judge how far from consensus the group is on a decision. The gradient of agreement scale is shown below:

Putting this scale on a flip chart or white board and asking meeting participants for a number representing where they stand will allow you to see the degree of support a decision or proposal has in the group. Different polling methods can also be used.

Here are some guidelines for interpreting the scale:

• Enthusiastic support is indicated if the majority of the group;s members are at numbers 1 or 2, with a few at numbers 3 or 4. This level of support indicates that the group will be committed to the proposal or decision.

• Lukewarm support is indicated if most of the group are at numbers 3 and 4, with a scattering at 5 or 6. This type of spread still indicates unanimous agreement, but less enthusiasm. When achieving a goal that will require high motivation and effort, this type of support could indicate a problem with the level of commitment in the group.

• Ambiguous support is indicated if the members are evenly distributed along the scale. Ambiguous results often indicate that the original problem was poorly defined.

• Majority support with outliers is indicated if most of the group was at the left end of the scale with a couple of people on the right end. In this situation, the leader of the group needs to decide whether to try to reach a compromise that would meet the needs of the outliers, or to disregard their objections.

For more information on the gradient of agreement scale and other facilitation techniques, please refer to the wonderful book The Facilitator's Guide to Participatory Decision Making by Sam Kaner et al.

Back to Top

Using Data Nicknames

by Marsha Hughes, PMP, CSM

Are you writing use cases or requirements like this one?

• The system prompts the bank customer to enter information.
• The bank customer enters the following information:
  • First name
  • Last name
  • Street address
  • City and state
  • Zip code
  • Phone number
  • Email address
  • Etc.

Long descriptions of data in a use case or a requirement distract from the flow and readability of the use case and make them difficult to maintain. Chances are, the same data will be used in other use cases or requirements—so if the data changes, you will need to find and update all references. Data nicknames are the perfect solution.

Using our example, the bank customer would enter “customer information”. The data nickname customer information is a pointer to a data dictionary entry describing the data included, the format of the data, field, length, and any validation checks that should be performed on the data. If the data changes, you only need to update the data dictionary definition, not each use case or requirement that uses it. You can underline or italicize data nicknames to indicate that they are being used as a reference, or hyperlink them to the data dictionary entry.

Back to Top

Best Study Tips for the CBAP® Exam

by Julie Chaloner, Marketing Programs Manager, Watermark Learning

What is the most helpful way to study for the CBAP® exam? We asked a group of newly certified CBAP® practitioners that question and here is what we learned...

Topping the list for most helpful—practice questions—with 80% indicating “they help a great deal.” 64% of respondents cited reading the BABOK® as extremely useful, and 60% indicated reading a study guide to be very helpful. Other study material mentioned as useful include: exam prep courses, flash cards and study groups. On average, students spent 100 hours studying for the CBAP® exam.

Looking for even more great study idea? Read: Foolproof Plan for Passing the CBAP® Certification Exam by Richard Larson, CBAP, PMP. Or visit Watermark Learning's CBAP® resources page for additional study aids, including a CBAP® Online Study Exam. This online tool will house over 700 practice questions to help you ace the real CBAP® exam. This exam simulator and study guide will increase your odds of passing the exam, minimize test anxiety, and save you study time.

Back to Top

Using Acceptance Tests as Detailed Requirements

by Marsha Hughes, PMP, CSM

Agile methods are user stories to represent requirements. A user story is a short description of the requirement from the user's point of view, and usually takes the form of “As a <user role>, I want t to <goal> so that I can <motivation>.”

For example, “As a tip writer, I want to provide useful tips to business analysts so that they can become more agile.” In agile methods, you don't work on the details of a requirement until you start working on a user story in an iteration. User stories are selected for iterations based on priority—until a story is important enough to implement, don't waste your time trying to understand it in more detail.

When you start working on a story, one of the first things to do is write acceptance tests for it with the user or customer. The acceptance tests are written from the user's point of view and may take the form given <a condition>, when I do <some action), I expect <this result). Each story typically has multiple acceptance tests. Rather than writing detailed requirements and acceptance tests, you use the acceptance tests to flesh out the details of the user story.

Acceptance tests provide details on the user's expectations and provide guidance to developers on how to handle different situations or conditions. This approach saves time (and money) since you already have to write acceptance tests to determine if you have met the requirements. If you are obligated to deliver requirements documentation, record the acceptance tests for each requirement instead of using a traditional SRS approach.

Here's an example of what an old school SRS document excerpt might look like:

3.1.2 Apply for Membership
The system shall allow users to apply for membership in the rewards program. To apply, the user must enter the following information:

• First and last name

• Email address

• Physical address

• User name

• Password

If the user name has already been used, the system should prompt the user to select a different user name. If the user has already applied for membership, the system should prompt the user to enter their user name and password, etc.

Using an agile approach, the same requirement and details might be documented like this:

User Story: As a frequent shopper, I can enroll in the rewards program on the website in order to receive rewards points for purchases. To enroll, I will enter my name, phone number, physical address, and email address. I will also enter a user name and password to use when logging in.

Acceptance Tests:

• Given that I have not enrolled previously, when I do so, I expect the system to confirm my enrollment.

• Given that I have enrolled, when I log in using my user name and password, I expect the system to recognize me and allow me to log into my account.

• Given that I have enrolled previously, when I try to enroll again, I expect the system to detect a duplication and inform me to log in.

While both approaches provide the same information, the old school method requires you to write both detailed requirements and acceptance tests—wasting time and money.

Back to Top

15 Tips to Help Pass the CBAP® Exam

by Richard Larson, CBAP, PMP

With the increase of popularity of the CBAP® exam, we know many people are diligently studying. To help you prepare, here are 15 great tips:

Before the Exam

• Tip 1: Read the BABOK® completely!
• Tip 2: Use BABOK® terms, even if they are “wrong.”
• Tip 3: Memorize all the Knowledge Areas (KAs).
• Tip 4: Memorize the Tasks within the KAs.
• Tip 5: Pick KAs that have only a few tasks to start with (e.g., Enterprise Analysis, Elicitation).
• Tip 6: Studying outputs are more helpful than inputs, if your time is limited.
• Tip 7: If a task is short, just skim it.
• Tip 8: Re-read portions of the BABOK® that you had trouble on in the practice exams.
• Tip 9: Prepare for the four main question types:
  • Definitions (e.g., “a model that depicts domain information is…”)
  • Sequences (e.g., “what is the first thing you do…”)
  • “Lists of Lists” (e.g., “which of these contains correct attributes?“)
  • Synthesis (e.g., “given this situation, what is going on?”)
• Tip 10: Get plenty of rest the night before and don't cram (sleep will help you more).

Exam Day

• Tip 11: Stay hydrated, but not too much. You don’t want to waste valuable exam time running to the bathroom.
• Tip 12: Stay relaxed. Eat a healthy breakfast or go for an early walk. One of our students said she was going to check into a hotel the night before and pamper herself!
• Tip 13: Do a “brain-dump” at the start of the test: list the KAs, tasks, techniques, and other things you memorized. This will help you relax and serve as a good reference during the exam.
• Tip 14: Arrive early so you have plenty of time to check in.
• Tip 15: Take your time answering questions. At the end of the exam, you can always go back and review and/or change your answers if necessary. Don’t answer a question until you are confident, and don’t second guess yourself!

Above all, try to enjoy the experience. Obtaining professional certification is an enriching experience, and one to be savored.

Back to Top

Business Analysis Tip

by Susan K. Heidorn, CBAP, PMP

A problem that continues to plague Business Analysts during requirements elicitation is getting a clear understanding of the “true” requirements from the stakeholders. Business analysts often take the “stated” requirements at face value, failing to clarify their understanding of the stakeholder's real need, or they jump to solutions before hearing the stakeholder out. This leads to erroneous assumptions that eventually lead to the incorrect solution. Here are 10 tips that can help you elicit the better requirements and reduce the possibility of getting to the wrong solution:

1. Always begin the interview with open-ended questions that focus on understanding the stakeholder’s problem and the context of the current situation as well as their “ideal” future state.

2. Encourage the stakeholder to expand on their ideas. "Please tell me more about …."

3. During the interview just “listen” to the stakeholder rather than thinking of what question you are going to ask next or jumping to a solution.
   
   
4. Allow the stakeholder to fully explain his/her need before responding.
   
   
5. Once you get a sense of the problem and situation, you can then get specific details by using clarifying questions or closed-ended questions, such as who, what, when, where or how much questions.  Beware of using closed-ended questions at the beginning of the interview unless you are conducting follow-up interviews because it immediately narrows your options and may cause you to jump to a solution that may not fully meet the needs of the stakeholder.
   
   
6. Paraphrase what you heard back to the stakeholder to ensure you have the correct understanding. “So what you’re saying is…”,  “do you mean…”, or “let me see if I understand.”
   
   
7. Use both process and data questions to ensure you have captured both data and process questions.  “What do you need to be able to do?”  “What do you need to know (information)?”
   
   
8. Ask pairing questions.  “best/worst”, “easiest/hardest”, “when/when do you not…”, “what/what not”, etc.  This allows you to understand their boundaries and helps you avoid jumping to assumptions about the opposite.
   
   
9. Avoid leading questions “what about…”, “don’t you think that…”, “have you ever thought about …” or “isn’t it better to …”
   
   
10. Close the interview by asking a closing question such as “is there anything I didn’t ask that I should know about?” "What additional information can you give me?"
    

Back to Top

Determining the True Definition of a Term

by Timothy C. Ward, CBAP, FLMI, FFSI, Business Consultant

I have a plaque on my desk that reads "Data Myopia - Those who can't see data for its worth are blind to its value". This is an important concept for Business Analysts to remember. Data is the foundation of any enterprise. If data is not defined properly then the enterprise that relies on it is being built and changed over time on an increasingly unstable foundation. Like an infestation of termites, sometimes it isn't until you undergo some large scale analysis of your enterprise data such as a system conversion that you realize you've uncovered a long term systemic problem with data definition.

One way to help mitigate that problem is to engage your business partners in the concept of Data Stewardship. Part of Data Stewardship is establishing and practicing standards for effective data definition. Your business partners need to understand that data has attributes. Those attributes are key to the proper development of functionality that will perform a business process that will use that data.

Take the example of a piece of data that represents a dollar amount. Seems simple enough. But all is sometimes not what one first sees. Are there any attributes that could be associated to that amount? You, as the Business Analyst might start asking questions such as:

Is this strictly a whole dollar amount or should it reflect both dollars and cents?
Is there a maximum and minimum range of amounts that apply here?
Is the amount supposed to represent a Gross or Net Amount?
Can the amount be a positive or a negative?
       
By engaging your business partners in a thoughtful discussion about the intended use of this data you are more likely to raise awareness about these possible data attributes. This in turn could hopefully  give rise to discovery by your business partners of additional attributes as yet unseen. This Data Stewardship process and the tangible benefits it provides both short and long term will be recognized and more readily embraced by your business partners. It shows them the true value of data and teaches them to see how to effectively define data going forward.

Back to Top

Do You Know IIBA's New Policy?

by Richard Larson, CBAP, PMP

The IIBA® has instituted a new policy clarifying the minimum number of hours needed per Knowledge Area (KA).The IIBA® has always had the requirement that one needs “significant” experience in 4 out of the 6 Knowledge Areas. However this spring, the IIBA® released a new handbook stating applicants need a minimum of 900+ hours in 4 or more KAs. Click on the links below to download a PDF of the new handbook to see the current requirements:

New IIBA Handbook

The new application is also now based on version 2.0 of the BABOK®. When you apply, be sure to report all project hours on which you performed BA tasks, not just the 7500 minimum hours. For any non-BA tasks you specify for a project, the IIBA® deducts a proportionate percentage of hours from your reported number of hours for that project. It could result in fewer than the overall minimum required hours, and could cause a rejected application, which happened to one applicant I know. You can appeal, but the IIBA® will not let you add additional projects, even if you have some that are eligible, and even if they would give you enough hours over the minimum. Visit the IIBA® FAQs web page (search for the word: “deduct”) to read about the new formula.

The bottom line:

1. IIBA® is rejecting applications if you don't document 900+ hours in 4 of the 6 Knowledge Areas. Make sure meet this requirement before applying, and make sure your applications show that.

2. Report all projects on which you performed BA tasks, not just the projects that give you the 7500 minimum. If the hours you report are only BA hours, then do not select any non-BA tasks.

3. If your application is rejected, you can't reapply for three months. For now that means you have to wait for the new exam based on the BABOK® Guide 2.0.

Back to Top

Fuzzy Boundaries: Do you Pre and Post?

by Richard Larson, CBAP, PMP

When defining or improving processes, it's essential to have clear and fixed boundaries for all processes. Otherwise, how do you know what steps to include? A process modeling truism is: process boundaries are usually (heck, let's say always) fuzzy in workers' minds until you document them. Since a process always transforms inputs to outputs, you can use inputs and outputs as one way to define the boundaries. Better yet, list the pre-conditions and post-conditions to get a better grasp of processes boundaries. A pre-condition specifies what is true for a process to begin, and a post-condition is what becomes true when the process is done.

For example, a process to buy a new car might need a pre-condition of the old car breaking down, or it might begin when your lease is 3 months from expiration, or it might be when the old jalopy has 100,000 miles. A post-condition could be when an agreement with a car dealer is made, or after financing is complete, or it could be as late as when you take possession of the car. The pre- and post-conditions always clarify processing steps that take place in (and out) of the process, and are a huge benefit to defining the framework of any process. It's an easy way to find process overlaps and gaps, too. Don't define a process without them!

Back to Top

A Picture is Worth a Thousand Words

by Susan K. Heidorn, CBAP, PMP

Drawing a picture, creating a model, or creating a paper prototype of a user interface or report goes a long way to help a stakeholder articulate their requirements or their problem situation. Many of us are visual learners so a picture or image often gives people a creative way to express ideas or concepts that they may have trouble describing.

When to use:

1. When your stakeholders are having difficulty describing a situation, a problem, or eliciting requirements.
2. When you need a fresh approach to solving a problem
3. When your stakeholders are highly visual (a high percentage of us are visual learners)
4. When your stakeholders are stuck in a “status quo” and need a creative jump start
5. When you need to make sure that your mental model matches their mental model of the system, process, or requirements.

A Few Tools:

• Scented markers
• Post it notes (colored, different shapes and sizes, etc.)
• Pictures
• Paper (white, shapes, different colors)
• Print outs of user interfaces and reports
• Modeling software
• Flip chart paper

Suggested Processes:

1. Have stakeholders draw a picture of their ideal system, process, report, etc. Ask them to describe their picture, ask clarifying questions to understand all potential requirements.
2. Print out an existing report or user interface. Work with the stakeholder to make changes or paper mock up a new report or user interface.
3. Have stakeholders draw a picture or create a collage that represents their problem, their existing system, etc. Have the stakeholder explain their image. Capture the information.
4. If you are working with a team, divide participants into small groups and have each group create an image that expresses the situation, problem, or issue that is the focus of your meeting. Then have each group describe their picture.

The next time you facilitate a session or elicit requirements– think about adding visuals.

Back to Top

Time Management Tip

by Susan K. Heidorn, CBAP, PMP

Have you ever been in a meeting where time seems to stand still—the meeting drags on and on and nothing gets accomplished? Do you struggle to get through every agenda item on the list? I'm sure many of you can sympathize with this scenario.

Although important, unexpected issues may arise in a meeting, it's important that you be in control of them—instead of the other way around. Here are some expert time management tips to help you achieve maximum effectiveness and productivity in your meetings:

1. Don't let your meeting run amok. Avoid “agenda creep” by assigning alternative times to discuss new, important issues that arise during your meeting.
2. At the beginning of your meeting, review agenda topics, key outcomes for agenda topics (i.e. decisions, discussions, reporting) and planned time allocations for each topic. Adjust items as needed per the needs of the group.
3. If the group is ready to close on a topic, provide a quick summary. If time is up for that specific agenda item, try one of the following:
   • Run overtime for this specific agenda item, and defer other, less important items for another time.
   • Defer the topic to another meeting.
   • Have a few people work on the agenda item offline, and report back to the rest of the group at the next meeting.

There are several types of information that can be recorded at a meeting. It is valuable to preserve the key points of discussions and the ideas in a brainstorm. Here are some additional ideas labeling action items and recording key information:

1. Parking Lot: The Parking Lot is a place to record ideas, questions, or future agenda items. Using a flipchart, the meeting facilitator records important items that are to be addressed at a later time.
2. Post-It Notes: Provide sticky notes for team members to capture ideas during the meeting that are off topic. The facilitator collects the notes at the end of the meeting, records them and then assigns them as topics for later sessions.

Back to Top

Reaching Consensus Successfully

by Susan K. Heidorn, CBAP, PMP

Contrary to popular belief, consensus is not getting 100% of the people to agree about an issue, talking an issue to death, nor is it reaching a majority vote. As a matter of fact, consensus is not about voting at all. Rather, Consensus is a form of decision making whereby all participants are willing to support an idea or decision that was made. The key success elements in reaching consensus include: open listening, personal reflection, mutual respect and trust.

How to use:

• After a full discussion of the topic, have the participants determine their level of consensus. 
• 1 finger = unqualified yes
• 2 fingers = the decision is acceptable
• 3 fingers = I can live with the decision
• 4 finger = I don’t fully agree with the decision
• Full hand = I don’t agree with the decision and I will stand in the way of the decision being accepted.
• If participants have 4 fingers or a full hand indicated – then there is more discussion that needs to happen to reach unity because there are still concerns about the decision that have not been resolved.
• It is a good idea to always ask for any further comments after the participants indicated their level of consensus, even if all the participants indicated they could live with the decision.
• Remember, it is extremely important to hear those participants that are not fully endorsing the decision, even if it is just one person.  This should not a witch hunt; we often need to hear consenting opinions or concerns to make the decision even better.  Ask them what the concerns are and what needs to be changed for them to be comfortable in joining the group on agreement.
• If the dissenting participants cannot agree with the group, the group needs to determine whether they postpone consensus to a later time, continue the discussion to find an agreeable solution or to choose use another decision method.

When to use:

• When  full buy-in is critical to the success of the decision
• When you need to find out where everyone stands on the issue
• When you want to make sure everyone has been heard and had their say

Alternatively, a majority vote is a way of making decisions based on a majority of the participants agreeing to the decision. 

When to use majority vote:

• You need a quick definitive answer
• When buy-in is not critical to the success of the decision
• Where it is stated by law (board of directors, councils, government, etc.)

Back to Top

Documenting Data Requirements

by Richard Larson, CBAP, PMP

The best way to document data requirements for software projects we feel is through logical data modeling. With this modeling process you start by identifying high-level business requirements for the data. If you understand the purpose and value of the data, it will help you ask good questions and make good decisions as you "sculpt" the model. The high-level requirements will typically help you uncover the initial entities in the model. These are the business objects that are meaningful to the business and that the business desires to track and report on details of those objects. They will typically turn into tables in a relational database.

Other sources of entities involve the other "concurrent" models we prescribe for BAs to create: 1) business process models and the handoffs they contain, 2) use case models and the nouns that are referenced, and 3) user interface models and prototypes with the detailed data elements that can lead you to entities. Speaking of details, after you define and document the entities, the next steps are to uncover the relationships and document the attributes for the model. The entities, though, are crucial for forming the underlying structure for your data requirements.

Back to Top

Secrets to Passing the CBAP™ Exam

by JoAnne Sabin, CBAP

Have you been thinking about or are you already preparing for the CBAP exam? Well, we can share the “pain” of the preparation and hopefully the relief that comes from passing it! I’m very glad to have just found out I passed – Yeah!!  - and wanted to share a few thoughts with you about it.

First, READ the BABOK!  Most questions are straight from the book!  Read it a chapter at a time and take notes on each section as you read to organize it in your mind.  Highlighting or underlining helps too, but my own outline was a concise study aid. 

When one chapter is solid, read the next one and do the same until you can summarize key points to someone else (and recite details to yourself, cause no one else will want to listen to your details).  Flash cards can help you with this, also, and you can do those yourself. Doing one chapter at a time helps you keep them straight and lets the material sink in without overwhelming you.  Having a buddy to keep both of you on track helps too.  Or, join a study group if your company or local IIBA chapter has one.

Back to Top

Get the Most From Your Ground Rules

by Susan K. Heidorn, CBAP, PMP

Ground rules (or operating norms) can help set the behavioral expectations of a group. Often conflict and frustration arise because people have different expectations of each other. Establishing acceptable group behavior can minimize some of the frustrations that occur because of behavioral issues in the group.

1. Establish ground rules for reoccurring meetings or for meetings lasting at least a half day. Ground rules are typically unnecessary for short meetings (1 or 2 hours) unless you anticipate a behavioral conflict or misunderstanding.
2. Have the group determine the ground rules/operating norms—this puts the onus on the group and allows the facilitator to make sure the group adheres to the operating norms they've established. When a group establishes their own ground rules, they will often self monitor and keep behavior in check.
3. Establish only 5 to 6 key rules. In most cases, ground rules with similar themes can be combined. Most people will usually not remember more than a few rules; so having too many becomes too onerous to manage and may restrict the groups work.
4. Post the ground rules either on the meeting room wall or in the agenda so they are clearly visible.
5. Quickly review ground rules at the beginning of each session.
6. As meeting facilitator, it's important to be a good role model; thus adhere to the rules you expect others to follow.
7. Should the ground rules be violated, bring this to the attention of the entire group. Then, as a group, either make the decision to conform to the ground rules as they were created or change the rules to suit the group going forward.

Back to Top

Learn to Write Expert Use Cases

by Richard Larson, CBAP, PMP

Struggling with writing Use Cases? While different organizations may have different Use Case requirements, there are some essential elements inherent to all well-written Use Cases:

• Use process-oriented and descriptive names, using a strong Verb-Noun combination. Example: Search Properties.
• Assign a unique identifier to each Use Case. They will be easier to track and manage. Reference the IDs in the corresponding Use Case diagram.
• Write short descriptions for each Use Case narrative. This gives readers a quick introduction without having to read the whole document.
• Always document Use Case pre- and post-conditions. Pre-conditions are states or what is true in order for a use case to begin. Post-conditions are the state or things that will be true when a Use Case ends.
• Document the primary path first, followed by all alternate paths, then exception paths. Consider using a scenario map that shows the primary, alternate, and exception scenarios in table form.
• For complex logic and decision-making, consider diagramming with an activity diagram to supplement the narrative.

Want some more great Business Analysis information and resources? Click here.

Back to Top

Tips to Prepare for the CBAP™ Certification Exam

by Richard Larson, CBAP, PMP

If you are studying for the CBAP™ Certification exam (or the PMP® for that matter), here are some tips that will help you prepare for and successfully take the exam:

Pre-exam...

• Prepare well in advance by reading the BABOK™ (or PMBOK®)
• Take a class
• Join a study group
• If time allows, re-read portions of the BABOK™ (or PMBOK®)
• Get plenty of rest the night before: don't cram for the exam

During the exam...

• Don't dwell on questions that seem difficult or complicated
• Complete the questions that are easy to answer first, then go back and answer harder ones
• Don't second-guess your answers
• Narrow down your choices to two viable answers and then choose from there
• If you don't know an answer to a question, it's better to guess than to leave it blank

These and many more tips for passing the CBAP™ exam are in Watermark Learning's "CBAP™ Certification Preparation Guide," which goes on sale May 1, 2008. Contact us for more information.

Back to Top