Tag: Best Practices

Meet Your Business Analysis Influencer

Written by Kupe Kupersmith on March 6, 2012. Posted in Articles. 1 Comment on Meet Your Business Analysis Influencer

My goal in life is to meet everyone in the world. I know that goal is not SMART (specific, realistic, etc.). It is not reaching the goal that is important; it is the effort I go through to try and meet the goal that counts. The goal goes deeper than just “meeting” people. I try to meet everyone I can and establish a relationship. Building strong relationships is a constant, consistent goal of mine. Some grow deeper than others, but I don’t discriminate. I meet and engage with people sometimes without knowing how I will add value to that person or how they will add value to me. For some this is a hard concept to grasp. Some feel so busy and can’t fathom spending time getting to know someone new without knowing why you should get to know them.
We work in a highly collaborative work environment. You don’t have to do everything on your own. If you build strong relationship people are more willing to help you. So if you are too busy to build relationships it is because you are not building relationships.

If you still need some convincing regarding building relationships, here is one big reason you should bother. Build relationships to ensure your message is delivered. This thought popped into my head after seeing an interview with Bono, lead singer of U2. He is a huge advocate to reduce or eliminate the AIDS virus. He has helped raise money and awareness that is dramatically helping the cause. But Bono is not a doctor. He does not work for the Center of Disease Control. He is not trained to do the research, administer tests or provide medicine to patients. What he does do is use his influence to help raise money to support the cause. He uses his influence to convince lawmakers they should allocate funds and resources to support the cause. He delivers the message.

I speak with many BA professionals that get frustrated when they can’t convince their management that they need more focus on the BA practice. I speak with many BA professionals that realize projects are not going well, but are not sure how to get their message to the right person. Sometimes you don’t have the influence necessary to get your message across. Does that mean you should stop? Of course not. You need to detach the message from the delivery of the message. The point is not who delivers the message; the point is that the message gets delivered.

Most likely Bono won’t be stopping by your office anytime soon trying to convince your management that they need to fund your effort to start a Business Analysis Community of Practice. Go out and meet some new people in your company at all levels. Who knows, maybe they’ll be delivering a message for you.

Don’t forget to leave your comments below.

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 Commandments

Written by Tim Ward on January 24, 2012. Posted in Articles. 1 Comment on The Business Analyst Commandments

Eliminate ambiguity. If you can arrive at more than one understanding or conclusion, chances are so can a developer or tester.
When using terminology, don’t assume everyone has the same understanding. Get immediate confirmation to avoid misunderstandings. A glossary of terms and related aliases are very helpful.
Promote “plainspeak”, the use of common (English) language when describing business facts, rules, regulations, processes, data, etc. If it is necessary to document something in business or IT jargon then paraphrase its true meaning in plain English.
When business or IT terms are used to describe something, always confirm the definition (e.g., when we say “transfer” we mean …).
Don’t ask for permission, ask for forgiveness.
Understand cultural differences within or between business organization entities and IT. It will help in following other commandments.
Requirements should describe what something isn’t as well as what it is.
When eliciting requirements, ask clarifying questions to confirm the requirements are being clearly captured.
When eliciting requirements, it is important to identify the audience affected (e.g., line of business, products, plan types, etc.).
When documenting requirements, decisions or issue resolutions, it is equally important to document the “why” as much as the “who”, “what”, “when”, “where” and “how”. If you don’t, it is more likely that no one will remember later why we went down a certain path.
When defining requirements, remember that it has to be testable. If you can’t adequately test it then the requirement is not adequately defined.
There are no assumptions, only a current understanding of the facts. Use of assumptions only promotes growth of undesirable anatomical features.
When writing (or speaking), put yourself in the reader’s (or listener’s) shoes. Would they really understand what I’m trying to convey based solely on the words I’ve written or spoken? Is there an unrealized expectation that they audience has some level of implicit knowledge in order to understand the subject matter?
Treat your developers and technical support staff as you would like to be treated: as a trusted ally and good friend.
Understand that people requiring your services as a BA don’t always know what they want and/or are unable to effectively articulate their needs. That’s why God invented BAs.
As a trusted subject matter expert, people will usually believe what you say as fact, especially if you are good at clear communication. Being in this position of trust, there is an inherent risk that sometimes you may be wrong in your understanding (and are unaware[RC1] ). However, you are persuasive enough to convince everyone of this truth. You need to rely on others to be able to detect the conveyance of false truths before it’s too late.

Don’t forget to leave your comments below

Tim Ward is a Business Analyst with over 30 years of experience in the financial services market dealing with group retirement plans. He is also a member of the IIBA and received his CBAP certification in 2009.

7 Trends in Business Analysis and Project Management to Watch for in 2012

Written by Elizabeth Larson on January 10, 2012. Posted in Articles.

The close of one year tends to make one reflect on what has occurred in the past year related to and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.

Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:
1. Business analysis is maturing as a profession. As the IIBA has gained traction, more organizations have become aware of the BA role and its importance. From 2010 to 2011 the number of IIBA members increased about 50%.
2. Organizations have found that even with successful project management, many projects fail because of dissatisfaction with the end product. Having business analysts helps ensure that the product is a solution that works and is one the organization needs.
3. PMI has recognized the importance of the business analyst role. In 2010 they undertook a study to determine areas of overlap, handoffs, and how the two roles could collaborate.

Combined Agile methods. We predict that Agile methods will continue to change and merge as organizations take advantage of the benefits of Agile. In our 2009 Trends blog we stated that “Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue.”

In the two years since we wrote that article, Agile methods have continued to evolve. Although organizations have widely adopted Scrum as the predominant Agile method, they still struggle with its implementation. We think that organizations will continue to adopt Agile methods, but that these methods will continue to evolve. Combined techniques, such as Scrum-ban (which combines Scrum with the Lean technique Kanban) or Scrumerfall (a combination of Scrum and Waterfall) will be adopted for different kinds of projects.

PM and BA on Agile projects. We predict that the role of the BA and PM on Agile projects will solidify. When Agile started to be adopted, some organizations thought that the roles of PM and BA were obsolete. However, more and more organizations have recognized that the need for both roles, even if the titles are new. The Scrum Master role is best filled by someone with the expertise to coordinate the initiating, planning, executing, monitoring, & controlling, and closing each iteration and release. In other words, the work typically done by a PM. The designations of Certified Scrum Master (CSM) from the Scrum Alliance and Agile Certified Professional (ACP) from PMI have solidified this role.
The role of the BA on an Agile project has not solidified. BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Going against most of the current thinking, we predict that organizations will realize in the next few years that business analysis is essential to Agile projects. Agile projects still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the needed functionality. Organizations will realize that this in-depth analysis cannot be completed during an iteration, that it has to happen just prior to development. This is called grooming the product backlog and is the perfect role for the business analyst.

The BA as management consultant. We predict that in 2012 BAs will actually function as described in the BABOK® Guide, version 2.0. That is, more BAs will “recommend solutions that help the organization achieve its goals.” They will do that in a variety of ways:
1. Business cases. More organizations will recognize that the BA is in the best position to develop business cases. Although often performed by PMs, this function happens prior to the initiation of a project and is input to project initiation (PMBOK® Guide – Fourth Edition). The PMBOK recognizes that the performing organization (business owner) is accountable for the business case, but it is the BA who is in the best position of developing it.
2. Ability to Influence without Authority. We are seeing more organizations tell us that they want their BAs to move away from taking customer orders and start using their expertise to recommend solutions. This need correlates to the enthusiasm we have seen around the need to influence without authority.
3. In her keynote at the BBC conference in Ft. Lauderdale last year, Kathleen Barrett, CEO of IIBA mentioned that one of the key competencies of the enterprise BA is management consulting.

BAs as change agents.We think that BAs will be more involved in change management. At the BBC conference in Ft. Lauderdale last year Kathleen Barret announced a new tag line for IIBA—that business analysis was about changing how organizations change. In other words, BAs will be more involved in change management. Changes might include changes in business processes, job descriptions, reporting structures, software, and more. Here are some of the ways we see this happening:
1. Enterprise analysis. Before projects are initiated, BAs determine the business need across the enterprise and recommend solutions, which need to include the ways in which organizations will need to change when these solutions are implemented.
2. Project work. While the identified at the enterprise level are by necessity high-level, the changes resulting from each project will be specific in nature. We predict that BAs will develop better tools for assessing whether or not the organization is ready for the change. We think that they will act as management consultants once the project has been defined to ease the pain associated with implementing the changes associated as with implementing the solution.
3. Post-project follow-up. We believe that BAs will be called on to monitor the post-implementation changes and continue to consult with the organization on the best way to make the solution work, even when there is some organizational resistance to it.

The virtual environment.Now that it is here, the virtual environment will continue to flourish, even if the economy improves. There are a variety of reasons why organizations will continue to rely on the virtual environment for completing projects, for training, and for webinars to replace live conferences.
1. Travel budgets. Spurred by a sluggish world economy, many organizations have reduced travel budgets for team meetings, training, and international conferences, relying instead on the virtual environment. Although colocation of teams is ideal and preferred, it is not always possible. More teams communicate and collaborate virtually, more virtual training will occur, and more webinars will take the place of live conferences.
2. Globalization has made travel impractical. Although face-to-face time, particularly during project initiation, is helpful in building trust, respect, and relationships, it is not possible to be together for all project meetings and/or requirements elicitation interviews and workshops when the team is located across the county or world.
3. Collaboration tools have made the virtual environment not only possible, but practical. Net meetings, as well as more robust training and webinar tools have supported virtual teams, so that real work can be accomplished. In addition, teams have learned how to build relationships and trust in the virtual environment. Building relationships and trust in a virtual environment is easier and quicker once people accept and feel comfortable with the virtual tools available.

“The economy, stupid,” a past political slogan said. During a slumping economy, organizations look of ways to maximize efficiencies. Focus turns to business processes and how to improve and manage them. During more prosperous times, interest in business process management tends to wane. We predict that business process management, with an emphasis on eliminating waste in organizations, will continue throughout 2012, even as the economy (hopefully) shows signs of improvement. We also predict that there will be no dominant tools for managing processes and recommend that project professionals doing business process work focus on core concepts and skills and be flexible when it comes to using BPM tools.

Don’t forget to leave your comments below.

Elizabeth Larson and Richard Larson are Co-Principals of Watermark Learning, a project management and business analysis training company. They have over 30 years of industry experience each, and have helped thousands of PM and BA practitioners develop new skills.

They have published numerous articles and papers and have co-written two books together on Requirements Management and CBAP Preparation. Both Rich and Elizabeth are CBAP and PMP certified through IIBA and PMI, and are contributors to the BABOK® Guide, Version 2.0 and the PMBOK® Guide – 4^th edition.

Open-Ended Questions

Written by Karl Wiegers on January 3, 2012. Posted in Articles.

The Business Analyst as Explorer, Part 5 of 6 by Karl Wiegers

An effective business analyst is not simply a scribe who records whatever customers say. The BA needs to stimulate the thinking of the people he’s interviewing to get below the surface. The BA should ask questions such as “What else could happen that we haven’t already discussed?” and “Would anyone ever want to ?” and “Could ever occur?” These are ways to discover possible lower-probability scenarios or options the system should provide to the user.

In their book Exploring Requirements: Quality Before Design, Donald Gause and Gerald Weinberg describe “context-free questions.” In their words, context-free questions “are high-level questions that can be posed early in a project to obtain information about global properties of the design problem and potential solutions. Context-free questions are completely appropriate for any product to be designed….” The BA can use such questions to explore both processes and products. They’re a valuable complement to specific questions about the capabilities and characteristics of the product being specified.

In my experience, requirements elicitation discussions typically emphasize the expected normal behavior of the system. However, anyone who has ever done any programming knows that a good developer writes a lot of code to deal with exception conditions. An important aspect of requirements elicitation is to identify things that could go wrong, determine how the system should detect an error, and describe how the system should respond to the error. As a BA, you need to probe around the exceptions during your requirements discussions. Ask questions such as “What should happen if ?” This is a way to detect missing requirements that haven’t come up in the discussion yet. It’s also a way to surface previously unstated assumptions. Testers are particularly adept at spotting exception conditions, so I like to have someone with testing experience participate in requirements elicitation sessions, if possible. I also engage a tester to review the emerging requirements documentation and look for exceptions and alternatives we haven’t considered.

Beware of asking questions that solicit a yes/no or multiple-choice type of response. Such questions can unnecessarily constrain the answer so that the requirements discussion misses an opportunity to discover (or invent) something that goes beyond the BA’s preconceptions. Of course, this doesn’t mean you can’t ever ask a question with a closed list of possible responses. Just make sure you aren’t prematurely constraining the exploration.

The last question I typically ask in a requirements elicitation discussion is, “Is there anything else I should be asking you?” This is an example of a metaquestion, a question about a question. I freely admit that I don’t know all the right questions to ask. Sometimes the person of whom I’ve asked this question realizes that we haven’t yet discussed some important topic. I simply didn’t know enough to bring it up.

I use this same question in daily life. A few years ago I had new kitchen counters installed in my house. I’d never done any home remodeling before and didn’t know that much about the process. Near the end of my discussion with a contractor, I asked, “Is there anything else I should be asking you about this job?” He thought for a moment and then brought up an issue we had not yet discussed. This is also a collaborative question to ask. It acknowledges that you rely on the expertise of other people to work toward a mutually satisfactory project outcome.

Business analysis is hard! Because it is intrinsically a communication-centric human activity, I don’t know of any shortcuts. Business participants in the requirements elicitation process can get frustrated by the number of questions the BA asks and how long the process can take. But that’s just the way it is. And it’s a whole lot cheaper and less painful to have those discussions before you’ve actually built the software.

Don’t forget to leave your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.