Tag: Planning

Reinventing the Swim Lane Diagram. Part 2.

Written by Mark Jenkins on May 14, 2012. Posted in Articles.

Please click on any image to view an enlarged copy

This article is a continuation of the “Reinventing the Swim Lane Diagram” process. Part 1 concentrated on ways to increase the efficacy of the swim lane diagram. Methods such as using color in a sparse and efficient manner, clearly defining each color’s meaning, and the induction of labels and annotation led us to realize to a more profound exchange of information.

Before we start Part 2, let me take pause to respond to some of the feedback from Part 1.

With any diagram, standard or best practice, it is vital to ensure that whatever you use, it’s appropriate for your audience. The typical audience for my swim lane diagrams is business users. At Websense, we are lucky to have an architectural and design group to handle the technical interpretation of business requirements. My group concentrates on understanding how a process is performed today, and then working with business users to decide how it is going to work in the future, providing insight into the complexity of the process. For the business stakeholder, the system they use of the utmost importance as it is a major contributor to their success. For example, performing a process in the slick CRM system might be a very different proposition to the clunky Quote System. We use the template for both “as is” and “to be” process documentation; and we generally communicate it through an analysis review or in the context of the final requirements document, although the diagram has its own standalone value.

In addition, my goal in Part 1 was to create a mock diagram, from which you could conjure ideas for a variety uses and applications, each tailored to individual demands.

In Part 2, I’ll explore some further additions to the swim lane diagram, which will help place a process in the context of a wider business picture. I’ll also cover how to increase and maximize the use of the swim lane by creating a Visio stencil. I’ve decided to add a Part 3, where I’ll cover an effective way of demonstrating the underlying data in a simple format, which builds the swim lane further.

The finished diagram from Part 1 is used again in this article.

Scott had mentioned in his comment about Part 1 that it is important to show the inputs and outputs of a process, and I agree. I achieve this by adding “process link” boxes, again with an appropriate color and label.

In the example below, I added the start feed as well as the output. For the detail-oriented, I also updated the version number and date.

This diagram now easily shows a Marketing start process as well as an output order process, initiated by the sales person. You could also consider annotating the bottom corners of the process boxes with numbers, but I think it’s unnecessary unless you had multiple start points or confusing decision trees.

In order to increase and maximize the use of the swim lane diagram, I’ve found it effective to develop a Visio stencil. Creating a Visio stencil for this purpose can “template” or “palate” shapes for use in future designs, therefore drastically reducing the time it takes to create swim lane diagrams.

Make sure you have the majority (if not all) of your systems identified beforehand, this will help you when choosing color groups. If you are using a Visio stencil in group environment (i.e. a team of BA’s) then proactively meet and set up the stencil together. This should prevent divergence when you later come across a new or overlooked system. Using primary colors to designate certain system groups is also effective. For instance, you can use different shades of your primary color to indicate systems which “hang off” of a main system, as shown in the example below.

If your group has a team logo and/or a company logo, add this to the swim lane frame (which we also created as a stencil shape).

Another nice touch is to use the company color scheme on the frame borders and swim lane headers.

These two small points allow you to produce something that looks official, which adds major percentage points to the credibility of the diagram. You can end up with final version of the diagram that looks something like this.

The great advantage of the Visio stencil is that it provides a framework on which you can build tailored stories that clarify process meaning and purpose. The first step, for my group, was to consistently use, adapt and improve the stencil. At this stage, you are basically road testing, ensuring that you have included everything you need. As the diagram is used in documentation or meetings, you are generating awareness and hopefully interest in the diagram. The business users’ benefits of seeing a consistent diagram format are also significant, reducing the comprehension time of changing diagram formats.

Once you’ve ironed out the kinks, got BA’s or colleagues consistently using the diagram, and your stakeholders comfortable reading it; you can start to drive it as a company standard for documenting business processes (keeping in mind my first point: use it when it makes sense and is appropriate to do so). For my group that meant building a store of business processes that can be accessed by the business stakeholders across the company. We also published the stencil to our Sharepoint team site, with instructions on how to install and use it (this assumes that you have enough users with Visio knowledge), so anyone can create their own process flows. This sort of implementation creates a language in which all involved are fluent. There really is no more powerful tool for a BA than having stakeholders able to express themselves using BA documentation standards.

For the majority of business users, this is as deep into the swim lane as you would want to go. We’ve pushed up the boundary of what I think most users can realistically comprehend, but for BA’s and technical users, there’s even more detail we can add to a swim lane base, to track data use within a process.

A lot of information will be displayed within a single diagram, so it is important to keep in mind that when using this technique, the audience and situation must fit.

In the following example, there are likely to be alternative techniques to demonstrate data usage, but again, the goal of my article is to challenge the standard way we look at diagrams.

As you will see, a larger paper size than the standard US Letter is generally required; ledger sized paper or larger is ideal, which tends to guide usage of this swim lane adaptation for higher level focus diagrams that illustrate key, stable processes. For example, this approach is not best suited for projects “under construction,” and would be better matched for situations where you want, for example, to mount a finished document to a wall for reference.

The goal of this technique is to portray the process flow as it relates to underlying data while simultaneously identifying the primary data store. This technique facilitates business users’ understanding of report origin and process interrelations, which in turn, procures their comprehension of report generation.

Without further prefacing, let us discuss the aforementioned technique which begins by reviewing the completed swim lane, identifying data change points within the process, and then matching them to a broad-level view of the data. By broad-level view, I mean condensing relevant fields together such as Customer Address, which may be 5 or more system fields, and referencing them under a single umbrella of “Address.” Regrouping applies across all data objects; “Contact Details” may be sufficient to capture “Address,” “Phone,” “Fax,” and “Email”. Reorganizing some of the process boxes may be required, but the increased page size should allow for more freedom.

Having identified data change points, I can now annotate the normal swim lane with sections, separated by vertical dotted lines.

At the bottom of the swim lane, data groups are added. In this example, 3 key data points are of interest (of course there are others): 1) Account – the company a customer works for. 2) Contacts – the individual contacts who work at the company. 3) Pricing – the Quote produced by the sales person.

Data storage systems are now added to the intersection of data (X axis) and process sections (Y axis). I typically identify the system of record as the first system in a section. If the system of record changes, I highlight it in red in place it as the first system in the section.

Your final completed diagram might look something like this.

This article has covered a lot of detail. In the first section of this article, we looked out how creating a Visio stencil provides numerous possibilities for collaboration. In the second section, we discovered that adding further detail to a standard swim lane illustrates the underlying data usage of a process. I hope that these two articles have been helpful in lending new techniques and have assisted in the adaptation of your own diagrams.

Don’t forget to post your comments below

Mark Jenkins is Manager Business Analysis Group at Websense. Mark has spent the last year establishing this formal business analysis group that now plays an active role in all major business projects at Websense. As part of the development, he created new process and documentation standards, which assisted in the overhaul of IT Project processes, placing the BA Group at the forefront of the IT to business interactions. He can be reached at [email protected].

Mark would like to acknowledge the help and editorial assistance of Skylar Waldman in producing these articles.

Short on Time? Have MORE Meetings!

Written by Bob McGannon on April 23, 2012. Posted in Articles.

OK, before you think we have gone crazy…we recommend more SHORT, FOCUSED meetings. As project managers and business analysts we often find ourselves with pressing deadlines, frantic team members who are juggling many tasks with little time, and senior stakeholders who place increasingly challenging demands upon us. At the same time, we face unchanging statistics showing that communications issues are at the core of project failures. How do you manage these two imposing situations? Have MORE meetings, but make them count, and do them quickly. Let’s examine why we need these frequent, focused meetings, and how to best conduct them.

The type of meetings we are discussing here are usually no more than 15 minutes; on rare occasion they may take half an hour. Often they are run as daily “stand-up” meetings, in conference rooms with the chairs removed or pushed to the side of the room. This is optional, however, for some the “stand up” aspect of these meetings help keep the attendees focused. These quick meetings are usually first thing in the morning to prepare for the upcoming day, or they are the final thing done at the end of the day, to prepare for activities that will take place early the next business day. So, given this, why are more frequent meetings a useful tool?

1. Your team needs as much efficient heads down time as is possible

Rarely do any projects allow team members to operate in a vacuum. Conditions change, problems and unexpected circumstances surface. Communication from the project’s various stakeholders is virtually constant. Team members need to a) know what their mission is on the project and b) have the information they need to get their tasks accomplished in the best way possible. With this constant flow of needed data, the forum to communicate all of this information requires frequency and efficiency. The short, focused, and regularly scheduled meeting can accomplish this. The project manager can also receive information from team members relative to status, risk management and issue information in an efficient fashion as well.

2. Team members need to know about dependent tasks, and required interactions

In our formal project management training, we spend considerable time (appropriately) on risk management. Classical risk management talks about potential events that may affect the project, the completion of project tasks, or the project mission as a whole. In the fast paced, increasingly technical area of product development, it is just as important that we treat information about dependent tasks and other potential interactions with other team members, major stakeholders or vendors, like we do for risks. We need to recognize these interactions, plan what we need to do to address them, and be prepared if the interaction event takes place. These interaction events can cause us to have to review data, review status, alter our approach, or in the most significant instances, re-plan how we are accomplishing our tasks. Only through interaction with our peers and leaders, and obtaining timely information from stakeholders can this be accomplished efficiently and effectively. We don’t need extensive ‘interaction management plans” to do this; however we do need to interact frequently about the potential, so we can be prepared for upcoming project situations.

So, given these meetings are so important, how do we make them effective in both maximizing team members’ “heads down time” and preparing them for these potential “interaction events?”

1. Don’t make them mandatory – make them “conditional” and you control and communicate the attendance conditions.

The legitimate complaint that most people have about meetings is that they are a waste of time. They go too long, and they aren’t useful. We get into the habit of inviting the “standard team set” to every meeting. When your team is crazy-busy, we need to step to the plate as leaders and make the effort to determine WHO needs to be at our short, focused meetings. So, set the conditions for your team members as to who should attend, communicate those expectations, and share the conditions before every meeting so those that don’t need to be there won’t need to attend. When you first start this technique, fail on the side of conservatism and have people attend. As time progresses, and you get feedback on the usefulness of the meeting, you can fine tune your attendance condition setting. The key to this is simple…if YOU can’t identify the critical piece of information they will take away from the meeting, then they do not need to be there. If YOU need a piece of information from a team member – collect that at the very start of the meeting. Carl Pritchard’s “Wall Walk Protocol” is a great approach to doing this for larger project teams.

2. Hold more than one daily meeting – with different attendees

This might not be as efficient for you as the project manager or the lead business analyst, but this isn’t about you. It is about the productivity, effectiveness and efficiency of the team. If you do this well, and your team feels you are conducting effective meetings that are worthwhile and they get the information they need, you will benefit from a) not having to chase people down to get or share information and b) they will work with better data, which will reduce the issues that you will have to deal with. This usually saves you more time than you will spend on setting attendance conditions and holding separate meetings. Holding separate meetings – and doing this well – avoids the biggest time waster in meetings…that of having to listen to someone drone on about something that isn’t meaningful to them. Divide your team into sub-teams of people that work together often, and have separate daily meetings. To maintain “a whole team” consider having the entire team attend one of the daily meetings each week. Set the agenda for that team meeting be things of relevance to the entire team.

3. Take the meetings seriously, but don’t force yourself and your team to be serious

Efficiency not only comes from getting and giving information effectively and in a manner that is valued by team members. Efficiency also comes from team members that know and understand each other in more than a professional capacity. Take time to recognize birthdays, significant accomplishments, not so significant accomplishments, and times when you acted as a team. Bring cookies or breakfast to the weekly whole team meeting – be human yourself as the leader and encourage your team members to do the same.

4. Talk about the “elephant in the room”.

Because the group of people will be small, take advantage of the intimate size. Cut to the chase and bring up topics that might be “taboo” in a larger group situation. The more open and forthright about providing information you are, the more the team will feel comfortable doing the same. Information is key to our success and the earlier people open up to share “bits of vital information” the better positioned the project will be for success.

Don’t forget to leave comments below.

Five Ways to Know When You’re Done with What You’re Doing

Written by Jason Womack on March 26, 2012. Posted in Articles.

If you often feel like you’ve barely skimmed the surface of what you should have accomplished on a given workday, I have a secret for you. When you learn to “know when you’re done” with projects, tasks and everything the workday throws at you, you’ll free up a lot more time to focus on those things that truly matter.

The curse for many of us modern-day movers and shakers is that we never seem to have enough time to do everything that needs doing. There simply aren’t enough hours in the workday (or even the work week!) to accomplish everything on our to-do lists. Worse yet, when we finally do get on a productivity roll, there always seems to be a distraction (or two, or three) waiting in the wings to throw us off course. But the reality is that we could actually accomplish a lot more each day if we would just learn to recognize and acknowledge when we’re done with what we’re doing.

One of the biggest time wasters we all face is spending too much time on those things that don’t require it. When we do so, we lose the time we actually should be spending on more difficult or time-intensive tasks. But when you learn to recognize when you’re done with a task, you’ll have valuable minutes and maybe even hours added back into your day.

It often seems that we put off the most important things on our to-do lists until we feel like we have the ‘time’ to work on them. When you learn to recognize when you’re done with projects, big and small, you’ll immediately find that you have a lot more time than you thought you did. Time you can use to focus on those things that truly matter. Read on to learn more about how to know when you’re done:

Stop majoring in the minors. Many of us spend a lot of time on those projects and tasks that are easy for us. Then we convince ourselves that we “just didn’t have enough time” to get to the harder stuff. But when it comes to knowing when you’re done and freeing up time during your day, completing these easy tasks quickly and efficiently is essential.

Before you start your workday, think about what your high-leverage activities are and what your low-leverage activities are. For the low-leverage activities, force yourself to move through them as quickly as possible. With these tasks — for example, writing an email to a colleague — perfection isn’t necessary, and there’s no need to waste time wringing your hands over every word. When you can accomplish these minor tasks more efficiently, you’ll have the time you need to do those major tasks justice.

Don’t overwrite emails. Much of your time — probably too much — each day gets eaten up by email. Make a conscious effort to keep your emails as short and sweet as possible. Get to the point quickly and use action verbs in subject lines so that both you and the recipient know what needs to happen before the email is even opened. And while long emails waste the time it takes you to write them, keep in mind that the person receiving the email doesn’t want to have to spend so much time reading it either. Chances are your boss doesn’t want or need a three-paragraph rundown of how your client meeting went. He just wants to know if the client is happy and continuing business with you.

Quit over-staying at meetings and on conference calls. Often, meetings and conference calls will take as long as you’ve allotted for them. Set an hour for a meeting and you’re sure to go the full hour. Pay close attention to how much of your meeting is actually spent focused on the important stuff. If you spend 15 to 20 minutes at the beginning or end of the meeting discussing your coworker’s golf game, then next time reduce the amount of time allotted for the meeting. And always know the meeting’s or call’s objectives before you begin. That way you can get to them right away.

Set your own deadlines and stick to them. It’s very easy to get distracted or sidetracked by things you think you should do or things others think you should do. Having a self-imposed deadline will help you ignore those distractions. If a colleague calls you about a non-urgent task, you can let him know you’ve got a 3:00 p.m. deadline that you have to meet. There’s no need for him to know that it’s self-imposed! And then as 3:00 p.m. draws near, start wrapping up that particular task.

Know when it’s time to ask for help. Have you ever been stumped by a certain project or task? Did you walk away from it for a while and then come back to it hoping you’d suddenly know what to do? Sometimes knowing when you’re done is knowing when you, specifically, can’t take a project any further. You simply might not have the right expertise to finish a certain project completely. And that’s okay. Wasting time on something you’re never going to be able to figure out is much worse than asking for help!

When you put in place steps to help you know when you’re done, you’ll be surprised and pleased with how much, well, you can get done. It will truly free up time in your day that you can use to focus on areas where it’s really needed. As a result, you’ll have a more gratifying workday and you’ll be happier overall.

Don’t forget to leave your comments below.

Jason W. Womack, MEd, MA, provides practical methods to maximize tools, systems and processes to achieve quality work/life balance. He has worked with leaders and executives for over 16 years in the business and education sectors. His focus is on creating ideas that matter and implementing solutions that are valuable to organizations and the individuals in those organizations.

Author of Your Best Just Got Better: Work Smarter, Think Bigger, Make More, Jason shows that working longer hours doesn’t make up for a flawed approach to productivity and performance. Entrepreneurs need to clarify their habits, build mindset-based strategies and be proactive. Womack’s signature workplace performance techniques offer specific strategies to improve performance consistently and incrementally.

The Business Analyst: When Not Knowing the Answer is OK

Written by Josh Jones on March 5, 2012. Posted in Articles. 1 Comment on The Business Analyst: When Not Knowing the Answer is OK

A new project has spun up and you’ve been assigned as the Business Analyst (the same scenario outlined below could happen if you are added to a project that was already in flight). You’ve done your diligence preparing; you’ve read the scope, reviewed the charter document and called your first requirements gathering meeting with the business partners and IT representatives. Your meeting is underway and while you’re attentively listening to the business SME explain the detailed process for transferring a policy from one agency to another, you find yourself feverishly jotting down notes as the nuggets of information being thrown out are too juicy not to capture. Then it hits you: you have no idea what the business SME is talking about!

Though your notes are word-for-word with what the business SME is saying, they might as well be a foreign language that you don’t speak. The fear of looking foolish or not wanting to lose creditability in the eyes of the project team, you do your best to keep writing while desperately trying to grasp the concepts that the SME is laying out in front of you. When first assigned to a project, this is where most BAs get tripped up.

In my experience (ten years in the BA and PM space), I’ve been there many times. And it wasn’t until a few years ago that I finally figured out how to handle the situation described above successfully. No matter how seasoned of a Business Analyst you are, a situation like the one above will happen. It’s inevitable. It’s very rare for a BA — no matter how much experience they have — to start every project with knowledge that will allow them to know what’s going on at all times for all scenarios.

The hardest parts of when you don’t know the answer is 1) trying not to look dumb in the eyes of fellow project team members 2) knowing how to make sense of what is being said and 3) being able to take the information given to you — at a time when it makes no sense whatsoever — and produce relevant (and accurate!) requirements.

There are four simple tricks you can use to get you out of the jam of not knowing the subject matter yet still get something out of the meeting.

· First, use your “Veil of Unfamiliarity.” As a contracting BA, I have many clients. And most of the time, when I work with a client, I know very little about the interworkings of their internal process, knowledge workflow and system-to-system linkage. But that doesn’t stop me from quickly picking up the things I don’t know. When I find myself new to a client, I often stand behind my “veil of unfamiliarity.” What I mean is even though you have all the best analysis skillsets in your toolbox, they are useless unless you know how to use them on a project. When I find myself on a brand new project that I know very little about, I will often say (out loud), “Since I’m new to this subject matter, I’m going to step behind my veil of unfamiliarity for a moment, could you explain that in more detail?” This is similar to asking the client, “Would you mind putting what you just said into easier-to-understand terms/language?” The reason you want to use your veil is so you can understand the unfamiliar topic at a higher level (less detail) before later diving into the weeds of that particular process flow or UI functionality or whatever it is that you’re trying to understand. In other words, you are openly admitting that you aren’t familiar with the details of the subject matter…yet. Being open and honest by asking the client to make the topic easier for you to understand will further strengthen that trust relationship with the project team and business partners. Using your “Veil of Unfamiliarity” is another way of saying, “I don’t know what you’re talking about yet, but I will soon,” all the while saving face (protecting your integrity) with the project team.

· Second, look for action items — even if they aren’t for the BA — and insert yourself into them (when it makes sense, of course). Another trick I’ve found to work well is to associate myself to follow-up action items that come out of a meeting even if they don’t directly involve me. Take the opportunity early in a new project to absorb and learn as much as you possibly can. It doesn’t matter where the source is either; just immerse yourself in anything topical to the project. Of course, it goes without saying that you should take care of your BA responsibilities first, but if you have the chance to sit in on a meeting with IT as they review a design document or sit with the business partners as they figure out how they want to incorporate their needs into deliverables, do it. Even though some of the action items aren’t directly tied to your BA work on the project, you’ll be building that background knowledge that will come in handy later on in the project.

· Next, create a partnership with the Business SME (or wherever the knowledge is). While it’s always important for the BA to have a healthy partnership with the Project Manager, it’s just as important to have a healthy, open partnership with the Business SME. After all, they are the ones whose needs must be met by the project. More often than not, this relationship is overlooked, not in place or undervalued, and can lead to limited — or in worst cases broken communication — between you (the BA) and them (the owner’s for the needs/business requirements). If you want to be successful in the BA space, you must value the partnership with the business SME. It will be so much easier to get vital information quickly when the partnership with the Business SME is healthy, strong and open.

· Lastly, and probably the hardest trick of all, is to be humble and ask. This is the simplest trick to grasp, but also the hardest to actually do. If you are like me at the start of a new project, you’re cautious of exposing your proverbial underbelly to a new project team. By that, I mean you’re hesitant to let your colleagues know that you have a vulnerability around fully understanding the subject at hand right out of the gate. However, if you don’t speak up now (at the beginning of when you start a project), it’s too late. Because the role of the BA is so vital to the overall success of a project, you should never pass up the opportunity in the beginning to ask the business SME — or anyone else on the project team for that matter — to clarify their comments if you do not understand them. It could be comments about scope, business needs, requirements, functional specs or anything project related. The point is, it doesn’t matter what the topic is: if you aren’t crystal clear with your (the BA’s) understanding, ask them to clarify their statement(s). More often than not, the requirements phase of a project moves at light speeds, so it’s important to level-set expectations of understanding the subject matter early and often in order to avoid getting left in the dust. And if you’re worried about losing creditability in the beginning of a project for not knowing the subject in detail, just imagine how much creditability you’ll lose when you get three weeks into requirements gathering sessions and you still don’t know what’s going on. Trust me, I’ve seen it happen and it’s not pretty! In the end, the business SME — or whoever is providing the clarity — would rather provide more clarity on a topic that you asked about than find out you (the BA) did not fully understand it.

Too often, I’ve seen good business analysts lose credibility with a project team because they aren’t willing to admit that they don’t know something. Fearing they will be ridiculed, the BA will play along like they know the subject matter, but when it comes down to crunch time on a project and they aren’t as well versed in something they’ve said they are, then that is when the requirements are at risk of being incomplete, or worse, incorrect. It doesn’t have to be that way! The next time you find yourself sitting in a project meeting or requirements gathering session and you don’t know the answer to a question or don’t know how a business process works, try using one of the tips in this article to assist you with gaining a better, clearer understanding of the subject. In the end, you will thank yourself for being bold enough to put aside your fear of losing credibility and doing what it takes to have a clear, concise understanding of the topic at hand. By doing that, you will have put yourself in the position to produce solid, real and most importantly, accurate requirements.

Don’t forget to leave your comments below.

Josh Jones is a seasoned BA with over 9 years of experience in the BA and PM space. Josh has successfully applied project and analysis leadership expertise to deliver project initiatives in a wide variety of industries (including product fulfillment and distribution, insurance, broker dealer management, Life and Annuities products, information technology, network services, financial services, investment/retirement products, and agriculture).

As a mentor and BA coach, Josh’s hands-on, “create a solid partnership” approach blends his desire to share his business analysis expertise with his passion for helping others improve.

The Business Analyst as Explorer, Part 6 of 6 – Why Ask Why?

Written by Karl Wiegers on February 21, 2012. Posted in Articles.

(adapted from More about Software Requirements by Karl Wiegers)

“Why?” is an excellent question to put in the business analyst’s bag of tricks. During a reengineering project, a BA named Dawn asked one of the developers why a utility company fee calculation was being performed a certain way in the existing system. “There’s a government statute that dictates how we have to calculate these fees,” was the reply. Upon investigation, Dawn discovered that in fact the current system had not implemented the computation correctly according to that statute. The system had calculated these utility fees incorrectly for an embarrassingly long time. This discrepancy never would have come to light had Dawn simply accepted the stated need for the current formula. Asking “why” revealed a major error that the replacement system corrected.

The shrewd BA asks why a lot. It’s important that “why” explorations be expressed in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin this way: “Can you please help me understand…” This phrase is longer than why and means essentially the same thing, but it has a more collaborative feel to it.

When a user representative presents a requirement that contains an embedded solution idea, asking why can let you know whether the solution idea is a true design constraint or just an idea or suggestion. Asking why several times in succession is a way to drill down from a superficially proposed customer “want” to the real underlying need. This helps the software team address the real issue, not just a superficially presented issue. Gently probing with why can reveal other sorts of useful information:

The answer to why might point out a business rule that affects the project. Then you can check to see whether the business rule is still pertinent and whether the information you have available for it is complete and accurate. You can discover whether and where the business rule is documented, who’s responsible for maintaining the information, and whether there are related rules you need to know about.
Asking why sometimes surfaces assumptions held by the person you’re questioning. An assumption is a statement that you regard as being true in the absence of definitive knowledge that it is true. It’s important to try to identify assumptions that various stakeholders might be making. Those assumptions could be incorrect or obsolete. They could be at odds with assumptions other people are making. Such conflicts make it harder for the stakeholders to have shared project expectations.
Asking why can reveal implicit requirements that no one thought to mention yet.
The answer to “Why is this requirement included?” supplies the rationale behind the requirement. It’s always a good idea to know where each requirement came from and why it needs to be included in the project. This can help the BA learn about requests that lie outside the project scope. This question sometimes also exposes that the “requirement” is really a design idea for an unstated higher-level requirement.
Suppose you encounter a requirement that a user representative presented as being high priority. It doesn’t look that important or urgent to you. If you ask why it’s high priority, perhaps you’ll learn that it’s logically connected to other requirements that also are high priority. Without this knowledge, someone might unwittingly defer the requirement that doesn’t seem so important, thereby crippling the related requirements that are scheduled for early implementation.
Sometimes the BA thinks she understands a requirement, only to discover upon further investigation that she really doesn’t. Asking why a requirement is necessary a few times could provide additional details that solidify the BA’s understanding of that requirement.
Asking why or similar questions can help the BA distinguish essential requirements knowledge from extraneous information.

Asking why might save you a lot of work. One project was replacing an existing customer relationship management (CRM) system with a package solution. Senior management directed the team to use out-of-the-box features from the package as much as possible and to limit the extent of configuration or changes to the package. One user representative asked that a specific function be added, a counter that indicated how many times a customer had used a certain product feature. It would have cost a significant amount to modify the core package to accommodate this requirement.

When the BA asked why that function was needed, the user said that the function was present in the current CRM application. The BA probed further: “What exactly does this counter show?” “Why do you check it?” “What action do you take depending on what it tells you?” This discussion eventually revealed that several stakeholders all thought that someone else was using the data. In reality, no one used it at all! By asking “why” a few times, the BA and user representative agreed that the function wasn’t needed, thereby saving a significant amount of money.

A BA needs to be a bit of a skeptic. Don’t believe everything you hear, and don’t accept it all at face value. Ask “why” enough times to give you confidence that you’ve got the real requirements in hand.