Skip to main content

Tag: Facilitation

How to Stop the Long-Winded: With Class

Written by Kupe Kupersmith on . Posted in Articles.

I was on a call the other day with people from around the world. Usually, these calls are awesome. The fact that I get to work with people from Australia, New Zealand, Canada, Italy, and beyond is amazing to me. Life is not always awesome, though.

This last call was not fun. Apparently I was one of those long-winded people. A reaction from the meeting chair ended up hurting my feelings. I felt shut down. I stopped sharing my ideas. Some of you may be saying, “good, you and the other long-winded people need to keep quiet for a while.” Maybe you have a point. The short term goal of shutting me up moved our agenda along. The long-term impact was I stopped providing ideas in the meeting. That is not a good thing.

What happened was we were discussing a topic and asked to provide questions if we had one. I had a question, so I started in. My question was not yet well formed. I started talking trying to formulate the question. I am an extrovert, so I talk to think. At some point during my dissertation, the chair of the meeting piped in “Kupe, Kupe, Kupe!” I don’t know maybe there were 10 Kupes before he got my attention. I was trying to talk fast so I could get to my question. I was not rambling for the sake of rambling, I promise! I finally stopped and he said, “Kupe, you are going on and on, do you have a question? WHAT is your question?” That’s when my feeling got hurt, that’s when I stopped talking out loud and said “whatever” in my internal voice. I think I even threw up the “Whatever” sign. You know, making a “W” with your 2 hands. We didn’t have video, he couldn’t see me. I’m 44, but I can still act like a child! I ended up asking a question. But you could hear a new tone in my voice. I became disengaged. For the rest of the meeting, I shut down.

I know some of you are saying to yourselves, “jeez Kupe, man up. We need to have thicker skin than that.” Believe me, I know. I do have pretty thick skin. My kids say that they love that I don’t care what others think. The context there is I do goofy things trying to embarrass them. Needless to say, I am very comfortable with who I am, my thoughts and beliefs and don’t get my feelings hurt often.

The point is, even people with the thickest skin can get their feelings hurt or get defensive. You need to make sure you are facilitating meetings where people feel they have input. Where they feel comfortable sharing their thoughts. The goal is buy-in. I talk about this more in a post titled “Your goal is not to shut people down just for the sake of sticking to an agenda.”

Related Article: It’s Time to View Your Role as a Communication Expert

There is a real problem here. You need to make people feel comfortable sharing their thoughts. You also only have so much time. The long-winded are a challenge. The ones that don’t speak are a challenge too, but they don’t take up any time. What are you to do?

In a face-to-face situation, peer pressure comes into play. When you have a long-winded person going on and on, people start shifting in their chairs, looking at their phones, etc. People start to see their team’s reactions and may adjust. In a remote session that peer pressure is gone. Many people are on mute and you don’t see anyone. It actually makes the long-winded even longer-winded because they are not getting feedback. In my case, I was not sure people on the call were understanding where I was going with my thoughts, so I kept going. That is until the rude “KUPE” to the tenth power came from the chair.

Some would say, it’s all about relationships. If you have a good relationship with the people you work with, then you can be less politically correct. I am a huge believer in relationships and promote it all the time. Even if you have great relationships with others, you need to be careful. I have a great relationship with the chair of this meeting. I have a really good relationship with the others on the call. In my situation, the chair did need to stop me. In hindsight, I was really long-winded. In many of your meetings there may be a person or two that needs to be stopped.

Is there a better way than coming across as abrasive? Is there a way to do this without hurting others feelings? More importantly, is there a way that does not stop engagement from others?

My tip is don’t leave it up to the person running the meeting. That puts all of the pressure on one person to keep a meeting running smoothly. Eventually, that person snaps and comes out with a statement that can shut down the talker. It needs to be clear in the meeting that everyone has the right/ability to get the long-winded to wrap up. Come up with a code word or sound. When that sound is made or word spoken the talker needs to wrap it up. This can be used for face-to-face meetings too, although it is critical for remote meetings. Make sure everyone knows it is not personal. It’s about making meetings more efficient.

Don Palmer from The Dallas Federal Reserve Bank recently told me about an analogy he used to show his executives the effect of showing displeasure when project managers present project status reports that included issues. He refers to it as hitting the goalie. Don explained there is a rule in hockey that prohibits players from hitting the opposing team’s goalie. This originates from not having many people want to play goalie. Kids want to play offensive, goal-scoring positions. So, there were not a lot of goalies out there from which to choose. If a team hit the goalie and the goalie was injured, teams would have to go to a backup goalie. Then if the backup goalie was injured, there was no one else left to play the position. This would completely alter games. In the project status world, Don explained if you badgered the project manager for bringing up issues during status reporting, PMs would begin to present all positive results during the project. Then in the end the projects would fail because they were hiding the truth all along to avoid the public badgering. This behavior did not allow executives to make decisions along the way to get the projects back on track. Don explained that badgering a PM is like hitting the goalie and pushed to have a “no hitting the goalie” rule. Now in status meetings if one executive is badgering a PM, another executive will say, “you are hitting the goalie.” I think this is brilliant. This is now a term that everyone understands and respects. It also results in PMs sharing the information as it is and not sugar coating the status of their projects.

There is no silver bullet. Feelings will get hurt. Your goal as a leader is to work consistently towards obtaining full participation. The outcome you are looking for is buy-in from the group. You gain buy-in by allowing the team to share their thoughts.

To not hitting the goalie,

Kupe

The Value of Business Analysis: Storytelling

Written by Aaron Whittenberger on . Posted in Articles. 95 Comments on The Value of Business Analysis: Storytelling

One of the main duties of the IT Business Analyst, or Business Systems Analyst, is to document requirements for software development projects.  Many organizations believe this is the only role of the IT Business Analyst and utilize them only in this very narrow scope of duties.  Organizations that recognize the true strategic value that Business Analysts can bring to the organization will gain a competitive advantage in the marketplace. 

However, even if the organization defines the role of the Business Systems Analyst very narrowly to requirements documentation, those Systems Analysts can put the word “business” back into their role and show the organization the value they can bring to the table.  They can show management and the organization their value by going beyond documentation of requirements to telling the story of the project and its business solution.  Document the requirements of the project as management and the organization expects you to, but then package those requirements into a story that will tell anyone, even those unfamiliar, all about the project. So how do you start?

Business Case

The business case for the project defines the business problem that the sponsor wishes to have resolved.  It should define the benefits of the project and costs – thereby a cost-benefit-analysis, strategic alignment with organizational goals, business requirements, rough duration estimates, and if known at this time, alternative solutions.  The document is the one that the organizational project approval board reviews to approve and prioritize projects. These approved and prioritized projects make up the project portfolio that needs to be managed to deliver the maximum value and competitive advantage to the organization.  This is another value of business analysis, but that is a story for another day.

Define the True Business Need

Often, symptoms of the true business need or problem are included in the business case.  They are often statements of business stakeholders, what they experience in their work, or their pain points.  This is where the Business Analyst will ask “Why” to drive to the true business need.   Once you get to that true business need, you should also define the contributing conditions that are causing this business need.

Scope

It is true that the Project Manager defines and manages project scope, but the Business Analyst defines and manages solution scope.  Solution scope may be defined more narrowly, or more widely than project scope.  There may be multiple components to the solution to a project; each component will have the scope of that solution.  Solution scope may become wider than the project because the solution interacts with downstream systems.  When you tell the story of a project, you must mention the scope of the project and the solution.  These may be links to scope documentation, but should include more definition that is learned during the project.

Related Article: The Power of Story in Business Analysis

Requirements and Business Rules

Business rules are defined prior to project initiation.  Define stakeholder, solution, transition requirements and business rules during the discovery phase of the project.  These may be defined in multiple documents like a Business Requirements Document, Functional Requirements Document, System Design Specifications, or documents of other names.  Include any assumptions, constraints and dependencies related to those requirements.  Defining these requirements and business rules is the main duties of the Business Systems Analyst and should be included as the meat of the requirements package.

Business Glossary (Glossary of Terms)

An often missed part of a requirements package is a glossary of terms important to the project.  These are often business terms for the business unit(s) for which the project is to deliver a solution.  For product or software project, a technical team is assisting to deliver the solution to the business unit(s), and may not be familiar with the business terms of that business unit(s).  As noted in the introduction of this article, the requirements package should tell the story of the project to those unfamiliar with the project; therefore a business glossary is necessary to ensure your audience understands the package.

Pictures

A picture is worth a thousand words.  They also help the audience consume and understand content much quicker than text.  This should start in the scope section with some type of scope diagram, such as a project functional decomposition or context diagram.  There are several business analysis techniques that deliver a picture or diagram to its audience; these include business model canvas, data flow diagrams, data modeling, decision modeling, mind mapping, organizational modeling, state diagrams, process flows, and prototyping to name a few. Any picture, model or diagram developed during the project should be included in the requirements package.

Use Cases

Use cases are an effective business analysis technique to understand the interaction between an actor, or actors, and a system.  Use cases can be used to highlight a specific process within the scope of the solution to help the audience understand the specifics and reasons for the process.

Lessons Learned

The project team learns a lot during the discovery phase of the project.  Some organizations may call this the analysis and design phase(s) of the project.  These lessons are usually learned after the creation of the business case and scope documents; and therefore, should be included in the requirements package.

Why?

Hopefully by now you are asking yourself “why would I create this one all-inclusive document in addition to all the other documentation created during a project?”  It may even sound to you like duplication of effort or documentation, and I hope you don’t dismiss it as such.  The value of creating this one package was outlined in the introduction to this article – to tell the story of the project.  It should tell someone unfamiliar with the project, or business unit(s) involved, all about the project, its purpose, scope, business problem, requirements, and solution. 

As a person unfamiliar with the project, how would you find out these things about the project?  How would you know what documents to read? In what order would you read these documents?  The requirements package wraps all this documentation into one neat package for easily readability and shows in the order that documentation of the project should be read in order to know what happened during the project.  This is how you tell the story of the project and increase your value as a business analyst to the organization.

Recertification Woes

Written by Shirley Sartin on . Posted in Articles. 1 Comment on Recertification Woes

Having obtained IIBA’s Certified Business Analysis Professional™ (CBAP ®) designation in 2006 (first group tested) I have had to recertify every 3 years which means I am recertifying for the third time.

This requires a review of efforts that have kept me involved in and learning about my profession for the past 3 years. It also includes identifying relevant work experiences, training, and volunteering by giving back to the Business Analysis industry. To retain my designation I must document at least 60 Continuing Development Units (CDUs) in those areas.

Today I began the recertification journey in earnest – even though after the last painful recertification efforts I promised myself that I would track relevant experiences as I acquired them. Sadly I did not keep that promise. To make matters worse I was notified 90 days before my recertification anniversary date and yet I did not begin recertification efforts at that time. Now I must undertake herculean efforts to meet the deadline in about a month while also working as a Business Analyst and conducting non-Business Analysis volunteer activities. Woe is the life of a serial procrastinator.

Related Article: Business Analyst – Born or Made?

I reviewed the 6 categories for reporting the requisite 60 CDUs and considered those areas for which I can provide supporting documentation. Unfortunately I was unable to attend a conference (Category 2A or 2D worth 30 CDUs), I did not write that book for which I had been considering (Category 3E worth 30 CDUs), and for certain I attended 0 (zero) formal academic education courses in Business Analysis (Category 1 worth 30 max CDUs). With my IIBA volunteering days in the past (Category 5 maximum 30 CDUs) and no local IIBA chapter where I could attend meetings (Category 2C maximum 30 CDUs) I realized I was going to hit a deficit for required number of CDUs using only Category 6 Professional Experiences (maximum 25 CDUs) and Category 4 Self-Directed Learning (maximum 15 CDUs). That is only 40 of the minimum 60 CDUs! I began stressing out but then I recalled the internal 1 week training for agile requirements I attended this past summer. Yay! Category 2 is saving the day because I will be able to claim up to 30 CDUs in that category.

I have other professional designations for which I must recertify every 2 or 3 years and I have trained myself to retain documentation for self-directed learning efforts. However, it is going to be painful documenting related work experience and describing the activities as they relate to the BABOK®. For every 1,000 hours documented I will receive only 5 CDUs.

That means for the maximum 25 CDUs I must identify over 5,000 hours work experience as it relates to the BABOK®! The work was tough enough the first go-round and now I will be reliving those experiences by analyzing and documenting the tasks during every available moment for the next few weeks.

I have already made myself another promise not to procrastinate for the 4th recertification efforts. I am going to develop a strategy to earn a balanced number of CDUs across several of the 6 categories in the next 3 years with a plan for when and how I will earn them and also to document the CDUs by completing the spreadsheet provided by IIBA as I earn each CDU. I will not wait until the last minute again! My advice to CBAP®s and CCBA®s? Don’t do as I did…do as I am planning to do. Best of luck to you all!

Business Analysis Core Concept Model (BACCM) – The “Big Picture” for a Strategic BA job!

Written by Suraj Panicker on . Posted in Articles. 1 Comment on Business Analysis Core Concept Model (BACCM) – The “Big Picture” for a Strategic BA job!

In my view BABOK (Business Analysis Body of Knowledge) v3.0, by introducing the BACCM framework, has provided the world of BAs the equivalent or extension of the famous triple constraints (scope, time and cost) that once revolutionized the project management world. BACCM, in fact, encapsulates the triple constraints and goes beyond by empowering the BA in their daily task to ask fundamental yet powerful questions at every stage of business analysis work. BABOK summarizes them as:

  1. What are the kind of changes we are doing?
  2. What are the needs that we are trying to satisfy?
  3. What are the solutions that we are creating or changing?
  4. Who are the stakeholders involved?
  5. What do stakeholders consider of value?
  6. What are the contexts that we and the solution are in?

I am sure this framework will be much discussed and deliberated in the faculties of management and business analysis in the days to come. BABOK emphasizes that neither one of these six core concepts is complete without the other. A continuous and holistic evaluation of the relationship among these six concepts is suggested for robust business analysis work. For the first time, we have a BA framework that supports the consulting role of the BA professional in unlocking true value proposition of organisational change drivers. The ability to influence, negotiate, and communicate at the strategic level will be tested as BAs rise to be strategic partners.
Coming from a Blue Ocean strategy consulting background, I am tempted to view the BACCM framework as a “Blue Ocean” treasure house for the often undervalued Business Analyst. BACCM emphasis on the six core concepts and its variations (in BABOK words “No single concept holds greater importance or significance over any other concept”) empowers us to plot the “strategic canvas” of Blue Ocean Strategy, probably for the first time ever. By carefully choosing and building competencies around the six core concepts BAs can unlock the strategic potential and chart interesting career options. There is no wonder that in the recent years, BA professional competency is climbing the charts and is rated consistently in the top leadership traits. The BACCM framework is an academic endorsement of the same. It takes true leadership mettle and enormous behavioural strengths to tie together the constantly changing and interacting landscape of value generation, while being mindful of the organisational context, focused on stakeholder needs, and solution options, aligned to the change to which businesses aspire.

In my view, this is a true game changer! This elevates the BA profession perception from monolithic elicitation, analysis and management of requirements to a “trusted advisory” consulting art. It calls for competencies to evaluate the complex, continuously changing and integrated web of value drivers. It is worthwhile to note, as always, “With great power comes great responsibility”. As the industry starts embracing this strategic role of a BA in enterprise design, business architecture and business leadership, it is imperative BAs prepare (quantitatively and qualitatively) to be the business analysis pioneers of this new value exploration.

To summarise, in IIBA chief Kevin Brennan’s beautifully crafted words, “Through the BABOK® Guide v3, IIBA is advocating for the importance of business analysts as leaders who contribute to enterprise-wide success through alignment of change with strategy, and innovation in business architecture, processes, and information technology” .

An Approach to Requirements Elaboration in an Agile Environment

Written by Aditi Sharma on . Posted in Articles.

Requirements gathering is the cornerstone to the success of any Agile project. There is no denying the fact that stakeholders often struggle in providing the functions and features that they expect from a system but rather provide the details and system behaviour. The key to achieving clarity is progressive elaboration. Interviews and workshops with stakeholders conducted by the business analyst can achieve this progressive elaboration.    

Agile projects often use user stories, which act as the starting point for further refinement in terms of requirements elaboration, design, risks, and costs. User stories are usually captured using informal techniques and as such are not available to all the team members until it is segregated and scaled to fit in traceable stories. The use of informal techniques suggests the need for an elicitation process and a supporting tool that helps to share the artefacts as and when they are created, reviewed and approved.

Most organizations would need to invest in tools to support the Agile way of working. To be effective, the tools should be used to create a virtual platform to connect teams to each other.  They can then use the tools to share information, keep it up-to-date, track and review information packets, and to keep the momentum of the project without losing focus and pace of deliverables. Utilizing this tool leads to real-time sharing of information and better transparency and visibility of workloads and ultimately, of the schedule.

 If teams adopt the above-mentioned way of working then a few potential issues get addressed early in the project lifecycle. These include issues like blocked information flow, use of old and redundant information, the blurred view of work items, and low traceability. Addressing these issues mitigates a lot of problems with which a business analyst (and other team members) may struggle. However, to address this completely from the business requirements point of view, the base has to be laid out properly and completely. This need puts requirements elicitation and elaboration in the spotlight.

As mentioned, requirements elicitation often starts in the form of user stories. At this level, it is comparable to an outline of the expectations from the system in terms of functions and features. Once the outline of expectations is created and agreed with stakeholders, the focus should quickly move to the elaboration activity.  The extent to which detailing is required varies depending on the team’s needs, however, this elaboration activity must achieve complete and correct documentation of business requirements, design, its rationale, and traceability (since if a task does not trace back to a user story, then it is not required).

However, the requirements elaboration activity is easier said than done. Depending on the stakeholders involved, different tools and techniques may have to be applied. Unlike in a traditional project where the requirements elaboration phase consists of detailed analysis and complete specification document, in Agile, this is done differently.  The requirements elaboration phase of an Agile project focuses on identifying the user stories first,  then detailing them as the project moves ahead. Essentially, the elaboration activity initially concentrates on high priority features and then progressively incorporates details. Storyboards and prototypes are powerful ways to gather feedback and quickly incorporate it. Allowing users to see details early on reduces rework costs since integration with other systems has not yet been done.

Since further iterations of elaboration build on user stories, the business analyst should ensure that certain key information points are captured upfront while creating the user story, avoiding the need to re-visit these stories later. Key information includes actors, pre-conditions, triggers, benefit, acceptance criteria and if possible, non-functional requirements.  Ensuring the capture of these data points early in the phase helps build the understanding of the requirements and avoids the pitfalls that transform simple oversights into multiple issues at a later point in time. This data capture also allows the business analyst to start documenting the requirements using formal techniques and begin creating a document for review, sign-off and trace.

Another buzzword that comes up is “collaboration”. To understand this, think of scenarios where the business owner will probably provide his expectations on the system behaviour but leave the system design considerations to the technical teams. Collaboration is the essential thread connecting these teams. Any one team working in a silo is a recipe for disaster; we need open communication channels leading to high levels of trust. The need for collaboration needs to be factored in by the business analyst. Note that requirements documentation may take any form – spreadsheets, documents, presentations, diagrams, use cases. The driving force here is not the format, but the content (what), context (when, where), and collaboration amongst different teams say, IT & Business Analyst and Business Analyst & Development team.

It may also help to elicit, elaborate, and segregate the “must have” requirements from “good to have” requirements early on. This information can be used for prioritizing in sprints considering business user needs and value, and from change management point of view. Readily available information translates to quicker turnaround times for next actions or decisions.

Being Agile during the requirements process allows projects to develop more efficiently by having work tracks running in parallel rather than waiting for fully developed requirements that may have little interaction with business and little opportunities for mid-course corrections. There are heaps of benefits compared to the traditional Waterfall way of requirement elicitation and elaboration. This definitely marks a big change in the way solutions are designed and delivered in shorter time frames by various organizations.