the
CONNECTING BUSINESS REQUIREMENTS TO TECHNOLOGY
Spring 2006
New Course Facilitating Requirements
BA: From Practitioner to Professional Kathleen Barret
A Case Study by Author Ellen Gottesdiener
Iteration Happens, Simulation Saves iRise
letter from the editors ith 2006 in full swing, we are very excited to offer you another issue of the bridge with articles written by leading experts from our industry. We frequently hear that Business Analysts are being asked more often to assume the role of the facilitator. While some people are comfortable and fluent in this role, there are many BAs who are looking for tips and guidance in this area. Our main article, The Art of Facilitating Requirements discusses the benefits of using facilitation sessions and highlights some challenges for the BA using these sessions.
W
Author and consultant, Ellen Gottesdiener of EBG Consulting, shares TINA JOSEPH and BARBARA CARKENORD her experience with requirements workshops. Her article, Workshops Work: Requirements Workshops Yield Business Value and Healthy Teams, gives an example of how a workshop can assist in getting the right requirements fast and can help ensure that no requirements are missed. Additionally, you will note that her book, Requirements by Collaboration, is reviewed in this issue. We always like to share best practices from our readers’ organizations. This month BMO Financial Group shares an experience using a mock requirements gathering 3-day session to assist in developing business analysis skills and capabilities. This session helped reinforce their training and proved to be an excellent way to assess their BAs’ competency level. With the fast-paced growth of the business analysis profession, new tools are becoming available. iRise, who offers a simulation platform for business people, shares how simulation can assist a BA in defining accurate requirements. With the focus of this issue being facilitation sessions, Ask the Experts provides some tips to ensure a successful facilitation session. The IIBA has grown phenomenally over the past several months. A large portion of this growth is due to the inception of US Chapters. Matt Etling, President, Central Iowa Chapter, shares his experience in getting a chapter up and running in his article, Starting an IIBA Chapter. Although this process was challenging, it is one that Matt will tell you is worth the effort. The IIBA Update includes the latest US Chapters that are forming. We encourage you to continue to visit our website often to find new resources for your profession. If you wish to provide articles or materials that we can share with your peers, forward them to sales@b2ttraining.com.
TINA JOSEPH
Certified Woman Owned Small Business
BARBARA CARKENORD
the Spring 2006
volume 3 l issue 1
table of contents 3
The Art of Facilitating Requirements Article by Barbara Carkenord
5
Starting an IIBA Chapter Article by Matthew Etling
7
From Practitioner to Professional Article by Kathleen Barret
10 11
Facilitation Brain Teaser Workshops Work Case Study by Ellen Gottesdiener
Page 13
12 13
Page 3
New Certified Business Analysts Iteration Happens, Simulation Saves Article by Maurice Martin, iRise
15
Ask the Experts Tips for the Facilitator
15
Book Review Requirements by Collaboration by Ellen Gottesdiener
18
B2T’s Course Alignment with BA Body of Knowledge
t
Page 15
To subscribe to the bridge, please visit www.b2ttraining.com.
B2T Training • 11795 Northfall Lane, Suite 601 • Alpharetta, GA 30004 • 866.675.2125 B2T Training is a woman-owned small business based in Atlanta, GA. Our training focuses on proven skills and techniques to define and scope the business problem, gather and analyze requirements, document the requirements, model the requirements, and follow through with the development of business requirements test plans to ensure the project has met its defined objectives. Our training is offered nationally and on a limited international basis. Most of our classes are taught onsite and are tailored to the unique environments of each organization. Public classes are also available in various cities around the US. CEO, Executive VP, Sales/Marketing Tina Joseph
President Barbara A. Carkenord
VP, Business Development Angie Perris
©2006 B2T Training. All rights reserved.
the bridge l Spring 2006 2
The Art of Facilitating
BY BARBARA A. CARKENORD, PRESIDENT, B2T TRAINING,
Using formal facilitation sessions to elicit requirements
3 Spring 2006 l the bridge
oday most of our core business processes are already supported by software; most organizations have moved away from large development projects. Our projects are smaller, more incremental. There is much more focus on interfaces, integration with existing systems, and change management. Also, developers can develop faster and users can see prototypes earlier due to more sophisticated development tools. These changes are driving the increase in the number and sophistication of Business Analysts (BA). BAs must have a sophisticated understanding of their business needs and the current operating environment to be able to recommend business and software solutions that will work with existing systems.
T
Requirements Facilitation sessions are a great way for BAs to gather complex business requirements and help their business teams understand and articulate needs. Using facilitation sessions to gather and analyze requirements is a key task of many BAs. It is important to recognize that a BA acting as a facilitator on his or her own project is not independent or completely objective as are traditional professional facilitators. The BA brings his or her business area knowledge, understanding of technological options, and understanding of the organizational environment to the session making the BA not only the facilitator, but also a valuable member of the group.
• Multiple versus individual input. As stakeholders listen to other stakeholders describe their requirements, they may all be reminded of additional requirements that might have been missed with oneon-one interviews.
What is a facilitation session? Webster’s New World College Dictionary defines the word facilitate as to make easy or easier. This is a very nice way of explaining why facilitation sessions are often considered during project initiation and requirements gathering. To make requirements gathering easy or easier is a goal towards which we all strive. A facilitator is one who is a planner, designer, helper, instrument, or agent. Facilitation sessions are not meetings. They are very structured, planned, working sessions where every participant is carefully chosen and has a critical role to play. Planning and preparing for a facilitation session is a significant task that, if not done well results in a poorly run session and a huge waste of time for the participants.
parties together, the BA can help them discuss their disparate points of view. Often these differences result from something as simple as different uses of terminology or different assumptions. When the requirement is discussed by the group, these differences may be quickly resolved. True differences in requirements are identified immediately and the team becomes aware of issues that will need to be addressed. The entire group recognizes that the ultimate solution must be able to address a variety of needs. When it becomes clear that stakeholders have conflicting requirements the Project Manger and Business Analyst must review the project scope and plan to make sure there is time to address these conflicts.
• Resolution of differences. Individual interviews with stakeholders often result in different answers to the same question. This causes the BA to reinterview people and try to resolve the discrepancy herself. By using a facilitation session with all involved
Facilitation sessions are not meetings. They are very structured, planned, working sessions where every participant is carefully chosen and has a critical role to play.
Why use a facilitation session? When a project involves two or more stakeholders, conducting a facilitated requirements gathering session may be useful. There are several reasons why a facilitation session might make requirements gathering easier:
• Balancing priorities. Different stakeholders often have different priorities with respect to the requirements. Leading the group through a discussion of priorities results in everyone being aware of other stakeholder needs. The facilitator can
direct the negotiation between stakeholders to arrive at one shared priority list. • Scope the project. A facilitation session is very beneficial at the beginning of the project as a way to develop the scope and/or area to be studied. This session is planned and prepared by the Project Manager and the Business Analyst working together and can increase the likelihood of project success by having all of the stakeholders understand and agree to the project boundaries. • Team building. As with any wellorchestrated group work, the team develops rapport with each other and team members become more vested in the success of the project. • Process improvement identification. Occasionally as people from two different departments talk about how they do their work, one may learn of a different procedure or policy that could solve a business problem right away. Challenges for the Business Analyst as the Facilitator There is one unique challenge of using a BA as a session facilitator. A BA cannot be completely independent or neutral about his or her project while conducting a facilitation session. This is because the BA: • Has in-depth business knowledge. • Has an understanding of the unique business environment. • Has organizational technology knowledge. • Is responsible for communications between business stakeholders and the solution team; they are an integral part of the project team. • Will help to identify alternative solutions. • Has a stake in the outcome. (Continued, See Art on page 9) the bridge l Spring 2006 4
Starting an IIBA Chapter BY M AT T H E W C ROY U S ET L I N G , B U S I N E S S A N A LYST, ITA G ROU P , I N C . , P R E S I D E N T, C E N T R A L I OWA I I BA C H A P T E R
“Who wants to join a committee?” Silence. Even the neon lights above me were quiet—and that wasn’t the worst part. For the second meeting, the only topic I had was to go over the material that I presented in the first meeting. I felt that I needed hot, relevant topics, but all that I in the Des Moines area. I contacted IIBA had to offer was the same presentation. to learn the basic information about After I completed my second iteration starting a local chapter. The documentation of IIBA’s kick off meeting PowerPoint that I received was very open-ended and it presentation and more silence, something was apparent that there wasn’t a standard began to procedure to happen—a follow in starting You have to start with small discussion. a chapter. The simple tasks before main objective you can grow into something I was was to determine big and complex. proposing the idea of whether there forming five starting committees and this was significant interest in the area to form was too grandiose in scope. The group and maintain a chapter. But how do you decided that it would be easier to focus on do that? organizing one committee, the Executive Fortunately, the IIBA keeps track of Committee. From that committee, we their members, plus B2T Training has an would assign responsibilities for each subextensive network for which they offer committee to a member of the Executive business analysis training and this network Committee. Thus, we would have at least can be utilized to get the word out about one active member working on each vital the local chapter. One big hurdle was to attribute of a chapter. determine where the initial meeting would That was seven months ago. Currently, be held. Some chapters hold their first the Executive Committee meets every month meetings at restaurants, hotels, or even and our monthly chapter meeting has an coffee shops. Fortunately, my employer ever growing number of attendees. Local recently redesigned our work space and software vendors have presented interesting created a large room that I could use topics and B2T Training presented a session during the lunch hour. With a place and on facilitation. We are working with other time set for the kick off meeting, all I vendors for future speaking engagements as needed were people to show up. well. Our bylaws have been submitted to the As I mentioned, B2T Training was IIBA Executive Committee and soon we instrumental in getting the word out to a will become an official chapter. We have couple of the large employers in the Des even started branching out as one of our Moines area. The IIBA website was Executive Committee members is going to invaluable in offering free advertising for help start a chapter in Chicago. the meeting. I received over 40 emails from It’s been a lot of work, but from the people expressing interest. I began to get a relationships I have formed and the little nervous about the large number of methodologies I have been exposed to, it people who might attend the meeting. has been a worthwhile undertaking. It is The topic of the first meeting was easy. great to be a part of something that helps The IIBA has a great PowerPoint mold my chosen profession. n presentation to introduce the organization and a list of steps to follow to formalize the If you are interested in starting an IIBA chapter organization. At the kick off chapter in your area, contact Tina Joseph, US meeting, I presented the information, got Chapters Chair at USchapters@iiba.com. to my last slide, and asked enthusiastically,
The International Institute of Business Analysis (IIBA) has experienced phenomenal growth. Creation of local chapters has been the primary vehicle for this growth. Following is a summary of Matt Etling’s experience starting the Central Iowa IIBA Chapter. n any large project I am associated with, I always like to say that Amazon.com was not built in a day. In other words, you have to start with small simple tasks before you can grow into something big and complex. That is exactly how you create an IIBA chapter. In the case of the Central Iowa Chapter of IIBA, it started with one member—me. I joined the IIBA in early March 2005, with little knowledge of other Business Analysts
O
update The IIBA continues to grow at an exciting pace. Currently there are approximately 1600 IIBA members and this is largely due to the inception of chapters. There are currently 11 chapters in Canada and 15 in the U.S. The following U.S. cities have held chapter kick-off meetings and are either established chapters or are working on their bylaws: • • • • • • • • • • • • • • •
Atlanta Boston Columbus Dallas Dayton Des Moines Detroit Hartford Louisville Minneapolis Philadelphia Phoenix Rhode Island Seattle Washington, D.C.
Many other cities have expressed interest in setting up local chapters.
5 Spring 2006 l the bridge
“
”
From Practitioner to Professional: Using a project simulation to accelerate the maturation of BY K AT H L E E N BA R R ET,
Background
B M O F I N A N C I A L G ROU P, C O N S U LT I N G
On February 1, 2006, BMO Financial Group completed the pilot of its Requirements Management/Business Analysis Simulation. Twelve business analysis professionals from across the various lines of business within BMO Financial Group participated in three teams of four to meet the objectives of this interactive learning event: 1. Experience the requirements development and management process from inception to completion within a “project” framework 2. Leverage the knowledge and experience of peers within a team structure 3. Build on all learnings, experiences, and environment (e.g., organization, culture) to build the desired products (e.g., plan, high-level requirements documents, and detailed specifications) The simulation was structured to mimic a real project. A business issue was identified and articulated using current business tools and deliverables. The Operational Vision with the associated implication statements described the future state of the organization once the business issue had been addressed. A Letter of
M A N AG E R , B U S I N E S S A N A LYS I S C E N T R E O F C O M P ET E N C Y, I I BA P R E S I D E N T
This article describes one company’s experience with utilizing a project simulation to model behaviors and principles required by Business Analysts. The company used this as a means to reinforce their training and as an assessment tool.
day one
MORNING • Project kick-off (which included the schedule for the three days, simulation rules, team schedules for presentations and interviews) • Team presentations of their draft requirements management plans (RMP) • Team scope interviews with the project sponsor
day two
A L L D AY • Completion of the high-level requirements (i.e., High Level Requirements Document, HLRD) by end of day • Assignment of a specific activity from within the HLRD for further decomposition within the Detailed Requirements Specification (DRS)
Engagement between the “project sponsor” and project team detailed the background of the project and reasons for initiating the work. These two documents provided the three teams with the necessary raw material in order to begin the planning of their requirements work. The background material was provided and pre-work was assigned two weeks in advance of the three-day, on-site component of the event. Due to the compressed timeline of the simulation, the pre-work was designed to give the teams a chance to get acquainted and to help them work through the “storming phase” of the project start up. The expectation was that once the teams arrived on-site, they would be able to focus on the primary objectives of the simulation. Ten faculty members, playing various roles and/or performing administrative tasks, were available on-site for the duration of the simulation. This number was deemed necessary for two reasons: Given that this was a pilot, with all the associated risks, there might be a need to potentially redesign the activities “on the fly.” As well, the simulation design team wanted to ensure that the project
day three
MORNING • Completion of DRS • Presentation of the final requirements document
123
AFTERNOON • Four consecutive team interviews with subject matter experts to complete the business activity use cases and to identify high-level requirements. The interviews were conducted in 45 minute sessions with a 10 minute break in between sessions. The teams were expected to submit the final RMP for review by the faculty at the end of the day
7 Spring 2006 l the bridge
AFTERNOON • Debrief
business analysis skills and capabilities requirements teams would be successful so it wanted to ensure adequate resources were available. Throughout the three days, other resources were also utilized as needed to support specific simulation activities. The simulation was comprised of different learning activities designed to assess the maturity of the ten discipline competencies identified as necessary for the effective execution of the Business Analyst/Requirements Manager role. Those skills are: • Analyze & solve problems • Facilitate discussions • Negotiate & build consensus • Model data & processes • Plan & manage activities • Communicate effectively (both written & verbal) • Manage client relationships • Evaluate alternatives and analyze potential decisions • Facilitate & develop business strategy • Understand & manage organizational change While not all of these could be objectively evaluated during the simulation, the design team mapped each competency to the various activities in order to help in the evaluation of performance and development of feedback to the individual teams. The three days were broken into the major components on the chart on the opposite page.
Debrief Output While the learnings from the simulation were ongoing by the three “project teams” and the faculty, the output from the debrief period captured the key points (see chart this page).
In Hindsight While the simulation experienced a few bumps over the three days, it met its primary objective – enable the participants to build on all their learnings and experiences and synthesize it to create new learnings. Very rarely, does an organization provide
this type of learning opportunity. Twelve moderately competent practitioners came into the simulation; twelve business analysis professionals left three days later. This is not to say that all twelve don’t still have some fairly significant gaps in their knowledge. However, their level of
Betters.” More time was needed up front to enable the teams to better understand the project goals and objectives. While each team met in advance and was able to create their draft requirements plans, there was still quite a bit of ambiguity. A few more weeks of project review and high-level
debrief output DID WELL
DO BETTER
1. Met the objectives of the simulation
1. Amount of time for pre-work
2. Simulation design • Having participants work as a team • Working through an entire life cycle
2. Clear articulation of evaluation criteria for each learning activity
3. Residential nature of the training away from home and office
awareness to effectively perform their role increased substantially. The team structure was also highly effective. Most of the business analysis professionals within BMO Financial Group work in requirements teams of one or two people. By working with individuals from across the different lines of business with different specializations (e.g., data warehousing, Internet), the team members had an opportunity to see how other practitioners address problems based on their own frame of reference. Quite a few best practices were identified and shared, not only within the teams, but across the teams as well. The life cycle approach helped clarify for a number of participants why certain activities and deliverables are required during the requirements process. By seeing how one activity contributed to the success of another, the participants were able to move from a task-level understanding of their role to a big picture perspective. The residential component was also very important. While the simulation was not designed to keep teams up all night, completing documents, the extra time afforded at the beginning and end of each day, encouraged better deliverables and fewer distractions from home and work. All this being said, there were a few “Do
discussions with the “project sponsor” might have eliminated or minimized the churn that happened once the simulation got started. Clearer articulation of evaluation criteria used for each learning event was also required. Not having defined criteria made it difficult for the teams to know what to focus on as they were completing their activities, it also made it more difficult for the team to give appropriate feedback. The team identified this oversight before Day 3 and the final presentations reflected the clearer objectives that were set for the three teams. Future sessions will have standard criteria for evaluation based on the results from the pilot.
Overall The simulation was a great success. The design team hopes to run the simulation again after the changes have been incorporated into the material. As well, based on the visible maturation of the participants during the simulation, the design team will present a plan to management that will articulate the value of accelerating the simulation program across the practitioner base in order to realize benefits of a better executed requirements process. n the bridge l Spring 2006 8
(Art continued from page 4)
Because the BA cannot be completely independent or neutral, she must be very careful when conducting the session. The BA must allow the project stakeholders to provide the requirements and keep them within the project boundaries. She also must lead the session in the direction that makes the best use of the participant’s time and meets the objectives of the project. This often means that the BA must allow the group to explore areas that the BA knows are “going nowhere,” allowing the group to figure that out for themselves. But if a BA sees that the group is heading in a completely wrong direction, she can “facilitate” the group back on the right path. This requires excellent communication skills and a good sense of group momentum. One way to minimize the challenges faced by the BA acting as the facilitator is to use two BAs to run the session. One BA may act as the facilitator and the other as the scribe. This is referred to as BA Pairing, where two BAs work together on a project. In the ideal situation, one BA would have extensive business area knowledge and the other BA would have an IT background. This pair of BAs would be able to listen to requirements, quickly identify the areas that need further discussion, and then tailor and refine their questions to lead the group in the most productive direction.
Example 1: During a facilitation session the BA realizes that a business stakeholder has an idea for a solution about which he feels very strongly. He has come to the session with this idea and his goal for the session is to convince everyone else that it is the best solution. While the BA is listening to his idea, she realizes that his solution is not technologically feasible in their environment. This is an example where an outside facilitator might not realize that the solution idea is not feasible and may allow the group to discuss its merits and details for an extended period of time. The benefit of having a knowledgeable BA leading the meeting is that she can lead the discussion away from that solution and get the focus back on requirements gathering and idea generation. “That’s an interesting potential solution Frank, I do foresee that may be difficult to implement in our environment so let’s make sure we really understand the problem and consider other possible solutions.” In this case the BA has saved valuable session time and prevented the team from getting vested in a solution that will not work.
Example 2: While facilitating a session on a new product idea with the Marketing Department, the BA listens carefully as the group discusses how they might sell the new product to their existing customer base. The BA hears one stakeholder mention that customers who have purchased or inquired about product XYZ might be interested in the new product. She also hears that customers in a certain geographic location are likely to be interested in the new product. Since the BA knows that order history data and customer profile information is already stored in existing corporate data stores, she can begin asking questions about the existing data to determine how it might be used here. She might ask questions like “How reliable are the customer addresses in our database?,” “Where did the data come from?,” “Have we kept track of product inquiries?,” and/or “How much history is available?” In this case the BA’s knowledge allows the group to progress toward a solution. The art of facilitation sessions is becoming more vaulable in gathering requirements and gaining consensus on solutions. With their unique knowledge and skills, the BA is able to tailor questions, hone the discussion, and keep the group working toward solutions that she knows are feasible and cost justifiable for their organization. This makes the BA as facilitator a valuable member of the group in addition to helping the group provide requirements. n
t
Benefits of using the Business Analyst as the Facilitator Although it is challenging for a BA to also be the facilitator, the benefits are often worth the extra effort. A BA’s knowledge,
sophisticated analysis skills, and powerful communication skills allow her to subtly change the direction of a group discussion to make the best use of the group’s time together. An experienced BA can listen to the group’s input; analyze it and understand the implications, see the next logical step in the process; and tailor her questions to lead the group in the most productive direction. Let me present a couple of examples.
Upcoming Business Analyst and Related Events
• June 19 – 22, 2006 – Project Summit & Business Analyst World – Washington, DC For more information visit: www.projectsummit.com/DC/
• October 21 – 24, 2006 – PMI Global Congress North America – Seattle, WA For more information visit: www.pmi.org
9 Spring 2006 l the bridge
• October 30 – November 2, 2006 – Project Summit & Business Analyst World – Boston, MA For more information visit: www.projectsummit.com/bos/
• November 6 – 9, 2006 – World Congress for Business Analysts – Lake Buena Vista, FL For more information visit: www.iirusa.com/BAW/
• November 13 – 16, 2006 – Project Summit & Business Analyst World – Chicago, IL For more information visit: www.projectsummit.com/chi/
Additional conferences are scheduled for Canada. For a complete listing please visit www.b2ttraining.com.
facilitation brain teaser
ACROSS 1 Key player in the session who contributes ideas 5 One-on-one questioning 9 Person that ensures the availability of funds and resources 12 This role’s documentation yields the session results & outputs 14 Determining when to hold the session 17 Gather a large number of ideas in a short time 19 Used to begin discussions 20 Guidelines for a session 21 Helps the facilitator keep track of time and agenda 22 Preparation for the session 24 Type of engaging listening 26 _______ Plan for outstanding issues 28 A list of topics out of the scope for the session 30 A facilitated ______ may be used to gather requirements 32 Post-session feedback
33 Final intended outcomes of the session 35 Potential project or business problems 36 Clearly stated reasons for the session DOWN 2 Business, Functional & Technical needs 3 Repeat in your own words 4 Analysis used to find holes 6 Different types of participants 7 Working together toward a common goal 8 Person who documents ideas on a flip chart for a session 10 List in order of importance 11 Nonverbal language 13 Setting in which the session takes place 15 Activities that help set the tone of a session 16 People who attend but do not participate in the session
18 Session leader 23 Disagreement that must be managed 25 Collective agreement supported by the group 27 Technique for graphically representing steps in a process 29 Means of gathering anonymous information 31 Referred to as nonconcrete skills 34 ____ Field Analysis assumes a situation is the result of forces acting upon it 37 Facilitation process developed by IBM
Answers on page 14
the bridge l Spring 2006 10
Workshops Work: Requirements Workshops Yield Business Value and Healthy Teams BY E L L E N G OT T E S D I E N E R , P R I N C I PA L C O N S U LTA N T, E B G C O N S U LT I N G
et the right requirements, quickly. Rethink your requirements assumptions to help the business operate smarter. Build effective collaborative teams. Sound good? These are the compelling benefits of requirements workshops. I recently planned and facilitated a series of requirements workshops to elicit and reach closure on requirements for a web-based technology-enabled system (TES) project to handle millions of dollars in transactions each month. The new software, intended to replace a rat’s nest of manual and automated processes, needed to interface with multiple internal and external software applications.
G
Over five weeks, we: • Scoped the requirements, delivering a context diagram, requirements in/out of scope table, stakeholder categories, policy groups, and a glossary • Generated high-level requirements—use cases, actors, and a data model • Built detailed requirements—atomic business rules, prototype screens, a state diagram, and scenarios These deliverables defined user requirements for a specification used to take bids from external vendors. The results? The application is rolling out across customer groups based on our use cases. Test cases and scripts for each release have been created from our use cases, scenarios, and business rules. IT and business participants are communicating their mutual needs more clearly. What’s more, the organization has decided that requirements workshops are a must for any significant enhancement or new development. You could say this: repetition is the sincerest form of flattery. Getting the Right Requirements, Fast
What do the team members think about the process? At the end of the scoping workshop, I facilitated a retrospective, a 11 Spring 2006 l the bridge
session to enable teams to document their learning. The team members discussed how tough the process was—how much mental effort it required—and their amazement at how much information and clarity they had gained in a short time. It was easy to see—the walls were covered with posters, diagrams, and sticky notes. Our recorder had captured and organized all this using soft tools. “I want to say something,” Jane said. One of the key business participants, Jane reported to Maria, the unit supervisor. Maria was also a subject matter expert and had decision-making authority about the requirements. “Maria resisted making the time to do these workshops—you know, taking five hours out of each day,” Jane went on. “If she had her way, she’d do it the usual way, and that ends up never getting us what we need.” “What’s ‘the usual way’?” I asked. “She would usually do this with the IT people.” Jane glanced, half smiling, at Maria and then at the IT lead. “She’d say, ‘You build something, show it to me, and I’ll tell you what’s wrong with it!’” Everyone, including Maria, laughed. “So, Maria, what do you think about defining requirements this way?” I asked. “Oh, this was really hard,” Maria said. “But now I can see it is necessary. It has actually made me rethink some of the things I thought we needed, and some of the priorities.” Everyone nodded. “Actually, it has saved me time and effort,” she added. “It used to take weeks or months, going back and forth with IT, for them to figure out what we needed.” Requirements workshops are hard work, but they’re worth the effort. As I explained in Requirements by Collaboration, workshops are a cost-effective, critical technique for reducing project risk.
Rethinking Your Business to Work Smarter
Our high-level workshops produced requirements representations that helped us understand the system’s functionality and interfaces, including the needed data. I then planned the most detailed and challenging workshops—those to define atomic business rules (precise, formal statements of a single discrete business rule). The input to these workshops included: • Scenarios from prior workshops and prework with additional scenario details produced by the business participants • Screen prototypes and logical data model produced by IT • Business rule templates (I had designed these based on what I learned in the workshops about the company’s rules) Each of the four workshops took four to five hours. Between sessions, I worked with the recorder and Business Analyst to “clean up” the rules, ensuring they were atomic, consistent with other rules, and traced to each other, and to the use cases. In the workshop we reviewed the cleanedup rules before tackling new scenarios and prototype screens. It quickly became clear that the business rules were overly complicated. They were confusing, not only for internal business staff but also for customers, who were constantly calling with questions about payments, invoices, reconciliations, and more. After the first workshop, Maria proposed to Meyer, the business sponsor, that the company simplify its business rules. She walked him through several pages of atomic rules we had created, all of them applying to only one scenario. Meyer was both appalled and intrigued. After research on costs (none) and customer reaction (enthusiastic), the simplification was approved.
New Certified Business Analysts We are pleased to be able to highlight the latest individuals who have earned the title of Certified Business Analyst since the last issue of the bridge. To date, we have more than 2,500 people in the program, with over 150 who have completed and received certification and an additional 290 individuals in the final stage of the process. Carol Booth Connie Cannon Francisco Carvallo Mike Davis Kimberly Davis Nitza Dovenspike Carlton Elder II Valerie Gaines Mark Galetto Nancy Harders Paula Harris
Build Collaborative Teams
Requirements workshops also go a long way toward establishing and sustaining healthy teamwork between business and IT project members. “We don’t usually expect the IT people to figure out what we want,” Maria explained. “But I like this approach. It’s hard work, but I feel more confident that they understand our needs.” Then she confessed, “Actually, I wasn’t sure what I needed until we did these workshops!” For its part, IT learned to not worry about technical solutions before understanding the business problem. During the final retrospective, we heard from Wayne, the manager of architecture and planning: “We have to focus on the implementation and interfaces, but I think this process helps us understand what you are trying to achieve.” The models built in the workshop had another benefit: helping the business people articulate their needs. One day Maria told us she was looking forward to the “Show and Tell,” when project sponsors
and stakeholders would be briefed by the participants. “I can’t wait to show our sponsor that context diagram,” she said (see photo above). “I’m gonna show him this and say to him, ‘See why I am so busy and deserve a raise?’” n Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps teams collaboratively explore requirements, shape their development processes, and plan their work, and she teaches business and IT people about requirements, facilitated workshops, retrospectives, and peer reviews. Her book Requirements by Collaboration: Workshops for Defining Needs (AddisonWesley, 2002) is reviewed in this issue of the bridge. Ellen is contributing author to Scenarios, Stories, Use Cases Through the Systems Development Life-Cycle. Her latest book is Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements (Goal/QPC, 2005). She can be reached at ellen@ebgconsulting.com and http://www.ebgconsulting.com.
Shane Helsel M. Todd Hilliard James Hundley Andrea Jackson Kristen Johnson Jodi L. Keane Vickie J. Keeney Karen Klein Dianne Launspach John Lundborg Margaret Notaro Chase Petsche Kelley Pollard Robert Prentiss Ebony Price Betsy Reliford Carole Rinks-Harrell Lillian D. Scott Allison Soroka Faye Stevens Terry Tracz Sheila Turnbull Lata Walsh Kim Whitfield Brad Wolff the bridge l Spring 2006 12
Iteration Happens, Simulation Saves Iteration Happens, Iteration BY M AU R I C E M A RT I N , P R E S I D E N T, C OO A N D F OU N D E R , i R i s e
teration happens. Reiteration costs money, big money. Business and technology people have learned that errors found up front, prior to deploying solutions, save time and money. The cost of reworking a project, fine tuning it until the code finally meets the needs of the various stakeholders within the enterprise, can be astounding. According to the Standish Group, only 29 percent of IT projects succeed, meaning they are delivered on time, on budget, and with all the promised features and functions in place. More than half (53 percent) are “challenged,” meaning they arrive late, over budget and/or without all their required features and functions. The realization of projects struggling to meet expectations is a primary reason the Business Analyst profession is growing. The Business Analyst works to bridge the gap between business stakeholders and information technology developers by gathering and documenting requirements for business solutions. The tools available to the Business Analyst to document requirements are usually limited to MS Word® and Visio®. While these tools are helpful to a Business Analyst, sometimes they don’t fully represent the requirements—especially for large complex projects.
I
How Simulation Can Help Complex projects can result in 500 page documents, plus supporting notes. I have even heard of companies who have to use hand trucks to transport these requirements from the business office to IT. This makes it extremely difficult for the development team to have a clear picture of the project. It is also difficult for the user to review. The growing complexity of IT projects presents challenges in communication
for fewer dollars. Clearly, a more robust tool is needed to help BAs and IT people straddle their communication gap. Both groups need tools and techniques that will help them define specifications more clearly, enable them to collaborate in real-time on product development, and thus deliver applications that work right the first time. Business people like to test drive applications before they’re built, like a flight simulator, only for business systems. Software simulation is a A more robust tool is needed to technique that is gaining help BAs and IT people straddle popularity among developers of enterprise applications. Smart their communication gap. businesses today, like Fireman’s channels between business and IT people. Fund, SunTrust Bank and Sentara There are more technologies, more Healthcare, are taking a page from largeapplications, more interconnectivity, and scale industrial firms. They are using more user mobility issues to deal with. sophisticated simulators to design and test Then there are regulatory and security new enterprise products before actually concerns. building them. Just as Boeing will model Add to these challenges the matter of and test an aircraft design extensively in a time. Nearly every enterprise today works multitude of virtual environments before around the clock. Few factory whistles cutting the first piece of sheet metal, banks blow at five o’clock for IT and business and other large organizations are gathering managers. In today’s global 24/7 economy, systems definitions and building software both groups face constant and increasing simulations before writing the first line pressure to deliver projects in less time and of code.
ba resources B2T Training strives to bring value to the Business Analyst community. We recently redesigned our website to a format that is easier for you to use. As a Business Analyst you may find that our BA Resources section is a tremendous help to providing the latest information. BA Requirements Package Templates Recommended Reading Business Analyst Tools Upcoming Events and Conferences Subscription to the bridge Magazine Conference Presentations Updated IIBA Information
Visit www.b2ttraining.com
13 Spring 2006 l the bridge
Happens, Iteration Happens
Figure 1
Software simulation allows business people to test-drive modules and components of the application before the coding process begins. Expensive ambiguities, omissions, and mistakes can be avoided when BAs can actually see how the application will work before a version is given to them as “code complete.” Simulation software can help Business Analysts get specifications right the first time, avoid costly rework, and deliver successful IT applications on time. And no
Submit an article to the bridge!
Figure 2
matter where the IT team is based, visual simulations help business and IT people communicate and collaborate more effectively. Better communication and collaboration means a better product. Figures 1 and 2 show how simulation can help you visualize the look and feel of a webpage prior to development. This allows business stakeholders and developers to visualize and interact with their webpage before development. Iteration does, and must, happen. But
now organizations have a choice on when to do it—early in the software development cycle via simulation when it’s inexpensive, quick, and fun, or late in the cycle when it’s expensive, time-consuming, and very painful. Too bad most decisions in business aren’t this easy. n Maurice Martin
Answers to Brain Teaser puzzle on page 10
Each issue of the bridge focuses on a particular area of interest within business analysis. Articles relevant to the topic area are preferred; however, any articles about best practices, project success stories, BA resources (books or tools) will also be considered. We will post submission deadlines for each issue so keep an eye on our website. To submit an article send an email to sales@b2ttraining.com.
the bridge l Spring 2006 14
ask the experts Tips for the Facilitator Question: What advice can you give to a facilitator to ensure a successful facilitation session? Answer: 1. Plan the session—distribute and post an agenda somewhere in the room so you can refer to it. As you complete agenda items check them off. If possible, set time limits on the agenda items so that you get through the agenda in the allotted time. 2. Maintain an issue log—for posting items that cannot be resolved in the session. At the end of session be sure each item is assigned to someone with a due date. 3. Establish a parking lot—this is for posting items that are in scope for the session but not in scope for the current agenda item. When you get to the item for which it is in scope you will not forget to address it. 4. Post decisions on a flip chart so everyone can see them. 5. Write notes on flip charts to ensure participants can see what is being written and can make corrections as you go along. It is sometimes helpful to repeat back to
the group what you have just heard. 6. Date and number flip chart pages. 7. Have a scribe. A scribe is separate from the facilitator and is necessary for the session, as their notes will be much more detailed. The scribe is not a participant, but he or she can ask questions at the discretion of the facilitator. 8. Establish rules – Read them to the whole group at the beginning and gain consensus of everyone agreeing to abide by the rules. This will help control the room. Question: What decision making techniques should be used during sessions? Answer: There are many decision options depending on the decision needed and the group dynamics. Consensus building is one of the best options for important issues because it allows the group to discuss and collaborate on a solution that everyone can support. Through collaboration, the entire team agrees on a decision. Compromise is the technique where someone or everyone
has to give up something during the negotiation process and should only be used when consensus can’t be achieved. Unanimous agreement is another option when it is 100% and it is recommended when there are very clear cut issues that do not require discussion. Unanimity is not often realistic if a decision requires careful thought. Majority voting is useful for quick, trivial decisions such as, “do you agree that we should take a break now and go out for lunch?” Sometimes one person decides if there is not enough time for consensus building and a subject matter expert makes a decision. This may be used without harming the team dynamics. Multivoting is when everyone gets to vote and is often used when there are lists of things or where items need prioritization. This technique is very objective, everyone gets heard, and it can be used effectively to work through many items. n Send your questions to Ask the Experts at sales@b2ttraining.com.
book review Requirements by Collaboration: Workshops for Defining Needs by Ellen Gottesdiener R E V I E W E D BY BA R BA R A A . C A R K E N O R D, P R E S I D E N T, B 2 T T R A I N I N G ,
equirements by Collaboration is an extremely useful book for Business Analysts and should be part of any BA library. Ellen Gottesdiener brought together her extensive knowledge of requirements with her experience in working with groups to give us a great resource for eliciting requirements on any project. Ellen’s belief that no one model will be able to completely represent the requirements of a project shows how well she understands the complexity of requirements and the difficulty in
R
15 Spring 2006 l the bridge
accurately documenting them. Her recommendations reflect the reality that most business requirements are very complex. The book describes the “ingredients of a successful requirements workshop” with the focus on collaboration. The book brings together proven facilitation techniques, requirements models, and human psychology to explain exactly how to conduct a successful requirements gathering workshop. Best of all Requirements by Collaboration is very accessible and entertaining in its
tone and attitude. It is a great reference because topics are easy to find and explained using clever phrases like “doneness tests” and “groups are wise.” There are a lot of tables, lists, and sidebars that allow the reader to quickly look up a problem area and get some help. n Barbara A. Carkenord is the President of B2T Training. She has worked in the requirements gathering and documentation field for over 20 years and has conducted hundreds of seminars for Business Analysts. Comments are welcome at bcarkenord@b2ttraining.com. B2T RATING: HHHH (scale is 1-4; 4 is the best)
new course
3 Days
Facilitating Requirements for Business Analysis This course teaches students to plan and conduct a facilitated session to gather business and functional requirements. As projects involve more people from various departments within an organization, the art of bringing people together to gather requirements and gain consensus on solutions becomes a critical success factor for all BAs. The class is limited to 8 students, giving each an opportunity to practice facilitating a requirements gathering session. Students have the opportunity to play each of the key roles in at least one session. The workshops require students to conduct a requirements gathering session for at least one requirement deliverable. Over 60% of the class time is spent on interactive, real-world business case study facilitated sessions.
Intended Audience This course is designed for experienced, knowledgeable Business Analysts who understand process, data, and business rule requirements. Prerequisites Students should have attended B2T Training Courses: Detailing Business Data Requirements and Detailing Process and Business Rules Requirements or have equivalent experience.
Course Outline Introduction • Define requirements facilitation • Define participant roles in the session • Learn guidelines for requirements facilitators • Set session rules and manage the session • Learn reactive techniques to use during the session • Workshop: Conduct a mini-facilitated session Requirements Session Feasibility • Determine session feasibility • Determine need/requirements deliverable desired • Determine commitment level • Determine risks • Discuss phases in the project life cycle where facilitation is most useful • Discuss types of requirements deliverables for which facilitation is most useful • Review the core requirements components and discuss how they are best gathered • Learn when not to use facilitated sessions
Conducting the Session • Learn the stages of group development/ productivity • Facilitate decision making - working towards consensus • Conducting the session • Introducing the session • Managing the session • Creating a follow-up action plan • Give feedback to participants • Review/approve requirements deliverables Student Workshop • Plan and conduct a requirements gathering facilitated session • Produce the requirements deliverable • Receive feedback from instructor and fellow students Session Follow-Up • Produce the final requirements document • Share session feedback • Determine the next steps to finalize the requirements
t
Planning a Facilitated Requirements Gathering Session • Plan the session • Determine the number/length of the session • Document the purpose of the session • Identify potential participants • Define session requirements deliverables • Prepare for a session • Outline the goals and requirements deliverables • Select session participants and determine if pre-session interviews are appropriate
• Develop questions to gather requirements • Create a detailed agenda for the facilitation team • Learn group-oriented facilitation techniques • Create a formal agenda for the session participants • Orient the facilitation team • Prepare the facilities • Workshop: Plan a facilitated session to develop project scope
For more information on this course visit www.b2ttraining.com the bridge l Spring 2006 16
IIBA body of knowledge B2T’s Course Alignment with the BA Body of Knowledge B2T Training actively participates in furthering the mission and growth of the IIBA. Many people are curious about the IIBA’s Certification program in comparison to our training program and certification. The B2T Training program will prepare you for both the B2T Training Certification and the IIBA Certification when it is available. The B2T Training program is a comprehensive program that aligns with all areas of the IIBA Body of Knowledge, as currently defined in the draft version 1.4. The BOK is a collection of business analysis tasks categorized into like groupings called knowledge areas. The BOK is not a methodology and does not infer any particular order of performing the activities. The B2T Training program is taught in a series of courses that reflect the order of work and iterative nature of business analysis. The graphic below illustrates the alignment between the current version of the BOK and B2T Training courses.
IIBA Business Analysis Body of Knowledge Enterprise Analysis
Requirements Planning & Management
Requirements Gathering
Requirements Analysis & Documentation
Requirements Communications
Requirements Implementation
Fundamentals
B2T Core Course Alignment
Essential Skills for the Business Analyst
Detailing Business Data Requirements
Detailing Process and Business Rule Requirements
Additional B2T Training Course Alignment
Advanced Business Analysis Techniques
Facilitating Requirements for Business Analysis
Requirements Testing for the Business Analyst
The IIBA is not a training organization and as such will not offer training or preparation for its certification. The IIBA will offer an Endorsed Education Provider program in which training vendors whose programs support the IIBA mission and the IIBA BOK will be listed. When this program is available, B2T Training will work to be an IIBA Endorsed Education Provider. We are confident that the B2T Training Certification is currently the most recognized certification in the industry and has value to you as a Business Analyst and to prospective employers. Please review the comparison information above and if you have any questions please contact us at sales@b2ttraining.com.
the bridge l Spring 2006 18
certified core courses Essential Skills for the Business Analyst
4 Days
A Business Analyst acts as a liaison between business people who have a business problem and technology people who know how to create solutions. A Business Analyst's main responsibility is to gather, detail, and document requirements in a format that is useful to their business stakeholders and the technical developers. This course covers the critical skills for the Business Analyst and is appropriate for new and/or experienced Business Analysts. New Business Analysts will learn the tasks they are expected to perform and why each task is important. Experienced Business Analysts will learn new techniques and more structured approaches to improve their requirements development activities.
Detailing Business Data Requirements
3 Days
Understanding and documenting business data requirements is a critical component in defining complete requirements. Every process uses data and almost all business rules are enforced by data. Missing a critical piece of data or incorrectly defining a data element contributes to the majority of maintenance problems and results in systems that do not reflect the business needs. This course teaches students an in-depth approach to identify and define all necessary data components using both textual templates and an entity relationship diagram.
Detailing Process and Business Rule Requirements
4 Days
This course continues the development of the requirements package by defining the processes and business rules for the project. Business Analysts are expected to analyze and understand business problems and be able to make recommendations to help the business stakeholders solve problems. The most effective approach to ensure success is to understand the business environment and document the business requirements, and then use functional requirements to document how software automation can support the business.
t
Functional requirements document how the software should “behave.� These requirements must specify how users will interact with the software and how the software will respond. Business Analysts are uniquely qualified to document these requirements because of their understanding of the business needs and the user's work environment. These requirements will be used to articulate the technology needs of a quality software application that will meet the business needs.
More detailed outlines are available on our website, www.b2ttraining.com
19 Spring 2006 l the bridge
t t t t t
In this course Business Analysts will learn to: • Scope the project from the Business Analyst’s perspective. • Identify and gather the requirements that are critical to the business mission. • Learn how to ask the right questions. • Identify the five core requirements components. • Know when a requirement is excellent. • Plan an approach for documenting, categorizing, and packaging requirements. • Verify that requirements are testable and generate testing objectives. • Conduct a requirement review. • Gather requirements in a group setting by preparing an agenda and managing the group discussion.
t t t t t
In this course Business Analysts will learn to: • Identify core data requirements beginning with project initiation. • Identify excellent data requirements at the appropriate level of detail. • Identify and detail attributive, associative, and subtype and supertype entities. • Detail complex data related business rules. • Discriminate between Business Data (Logical Data) and Database Design (Physical Data). • Transition business data to database design. • Utilize easy normalization techniques (without all the mathematical theory). • Validate data requirements with activity (process or use case) requirements.
t t t t t
In this course Business Analysts will learn to: • Understand and document the business environment using a suggested structure, including detailed templates for defining the business and functional requirements for processes and business rules. • Look beyond the current technology or procedures to discover the true nature of the business activity. • Ask the right questions to identify the core business processes and the business rules that control or guide them. • Document functional requirements which describe how the software should “behave.” • Utilize several diagrams including the decomposition diagram, Use Case diagram, and workflow diagrams. • Look at the business area from an objective perspective after business requirements are documented and organized to present alternative design solutions that meet the customer needs. • Validate business processes against data requirements.
the bridge l Spring 2006 20
additional business analysts courses Requirements Testing for the Business Analyst
3 Days
This course provides an excellent foundation for Business Analysts to achieve best practices in software quality assurance (SQA). The course will improve the Business Analyst's development of requirements so that they can be used to build quality test cases. It will also enable the Business Analyst to create specific test cases from the requirements. The course includes a workshop case study that provides a cohesive learning experience.
3 Days
Advanced Business Analysis Techniques
This course enhances the efficiency and effectiveness of Business Analysts by giving them additional techniques and strategies for gathering, documenting, and reviewing requirements. Techniques such as advanced data definition, traceability, and gap analysis help Business Analysts to document more accurate and complete requirements. The course also presents the concept of requirements management and requirement reuse. Implementing a requirements management process into your organization can significantly reduce the time required to make software changes and develop software interfaces.
management/technical seminars Overview of Business Analysis
4 Hour Seminar
This seminar presents the Business Analyst role to managers and others who lead and work with Business Analysts. In order for the Business Analyst to be successful, both the IT and business community must embrace the business analysis process. The seminar can be used as a working session to discuss how your organization will implement the business analysis process and approaches for documenting the requirements.
Developer’s Introduction to Business Analysis
1 Day
t
This class provides an overview of the Business Analyst role and a detailed review of the requirements document provided to the development team. To ensure an integrated team, IT developers need to understand the role of the Business Analyst. They should also be familiar with the requirements that Business Analysts are gathering and documenting. This includes understanding categories of requirements, the core requirement components, and the documentation formats used for each type of requirement. IT team members must also understand the testing life cycle and the personnel involved. This course gives students an overview of the role of the Business Analyst, requirements documentation, and software testing. For more information on these courses visit www.b2ttraining.com
21 Spring 2006 l the bridge
2006 public class schedule Essential Skills for the Business Analyst - $1,980/per student • Apr 24 – Apr 27, 2006 New York, NY • May 1 – May 4, 2006 Seattle, WA • Jun 12 – Jun 15, 2006 Atlanta, GA • Jul 17 – Jul 20, 2006 Louisville, KY • Aug 7 – Aug 10, 2006 Chicago, IL • Sep 18 – Sep 21, 2006 Atlanta, GA • Nov 13 – Nov 16, 2006 New York, NY • Dec 4 – Dec 7, 2006 Atlanta, GA
Facilitating Requirements for Business Analysis - $1,485 per student • May 8 – May 10, 2006 Atlanta, GA • Sep 11 – Sep 13, 2006 Louisville, KY
Advanced Business Analysis Techniques - $1,485 per student • Apr 18 – Apr 20, 2006 Louisville, KY • Oct 16 – Oct 18, 2006 Louisville, KY • Nov 6 – Nov 8, 2006 Atlanta, GA
Requirements Testing for the Business Analyst - $1,485 per student • Aug 21 – Aug 23, 2006 Atlanta, GA • Dec 11 – Dec 13, 2006 Louisville, KY
Detailing Business Data Requirements - $1,485/per student • Apr 24 – Apr 26, 2006 Houston, TX • Jun 12 – Jun 14, 2006 New York, NY • Jul 24 – Jul 26, 2006 Atlanta, GA • Aug 14 – Aug 16, 2006 Seattle, WA • Sep 11 – Sep 13, 2006 Atlanta, GA • Sep 18 – Sep 20, 2006 Louisville, KY • Oct 23 – Oct 25, 2006 Chicago, IL Detailing Process and Business Rule Requirements - $1,980/per student • May 15 – May 18, 2006 Louisville, KY • May 22 – May 25, 2006 Houston, TX • Jun 5 – Jun 8, 2006 Chicago, IL • Sep 25 – Sep 28, 2006 New York, NY • Oct 2 – Oct 5, 2006 Atlanta, GA • Nov 6 – Nov 9, 2006 Seattle, WA • Nov 13 – Nov 16, 2006 Louisville, KY • Dec 4 – Dec 7, 2006 Chicago, IL
B2T Training 11795 Northfall Lane, Suite 601 Alpharetta, GA 30004
Please check our website for additional public class offerings and to check availability and register – www.b2ttraining.com. On-site classes are also available. Call 866.675.2125 or email us at sales@b2ttraining.com.
Prsrt Std U.S. Postage PAID Permit #309 Knoxville, TN