Tag: Elicitation

BATimes_Dec1_2022

The Beautiful Game as a Modern, Event-Driven Business Process Structure

The Beautiful Game

Whether you call it football or soccer, “the Beautiful Game” as it is widely known, has simple rules of play. But playing soccer is another matter. It is a highly dynamic, agile process. In the flow of a single match, an eleven-player professional team can make more than 500 passes and there can be dozens of game stoppages.

In the eyes of process analysts, quality improvement professionals, and business analysts, who still rely on the more than 100 years-old, strictly procedural notions of a process and on flowcharting notations that were also invented in the last century, IT IS IMPOSSIBLE to perceive and model something like playing soccer as a sequential process.

The Modern Business Process Modeling Solution

The most effective business processes are not only structurally sound and efficient but also highly dynamic and agile.  A high-quality business process structure today is one that has been conceived, structured, and can be readily configured as a network of specialized, collaborating, event-driven, and outcome-oriented services, not just as a sequential procedure.

If a business analyst, process analyst, quality analyst, or manager adopts that modern business process paradigm and a modeling notation that is aligned with how today’s business relationships and processes work, then perceiving and modeling something as dynamic and agile as the beautiful game as a process, IS NOT ONLY POSSIBLE, BUT ELEGANT.

Universal Business Process Definition[1]

The Universal Business Process Definition is not constrained to a strictly procedural notion of a process. It is an event and outcome-oriented business process paradigm. The Universal Business Process Definition’s four common-sense rules define all processes, workflows, and activities, regardless of a process’s scale, the overarching project methodology, the model’s required degree of abstraction, the modeling participants, and the organizations and the technologies that will implement the process or workflow.

The Universal Business Process Definition, and the Business Process Normalization technique are defined in the Universal Process Modeling Procedure (UPMP), published by ProcessModelingAdvisor.com.

Business Process Modeling and Notation[2]

Business Process Modeling and Notation (BPMN) is a graphical notation for illustrating modern business process elements.  It overcomes the limitations of the last century’s procedural flowcharting and process mapping notations.

BPMN was defined by the Business Process Modeling Initiative (BPMI) and is maintained by the Object Modeling Group (OMG). BPMI states that the goal of BPMN is:

“To provide a notation that is readily understandable by all business users.”

BPMN is the best-suited notation for illustrating modern business process and workflow structures. It includes sequential flowcharting elements, but BPMN also includes symbols for illustrating concepts that are relevant to today’s dynamically collaborating systems and business processes. Namely, events and messaging.

 

Advertisement

 

The Beautiful Game as an Example

We don’t need process models about playing soccer. We’d rather be playing or spectating. But we’ve all observed enough about playing soccer to use it as a commonly understood example.  Playing soccer happens to be similar to how modern-day business processes and operating relationships work. Let’s use soccer to demonstrate how to apply a modern business process modeling paradigm and modeling notation to discover and illustrate a sound, modern business process structure.

Event-Driven Business Process Flow

A contextually and structurally sound model of the Play Soccer process can be discovered by answering the Universal Basic Business Process Flow Elicitation Agenda[3] and the Universal Event and Outcome-Oriented Business Process Flow Elicitation Agenda[4], found in The Universal Process Modeling Procedure.

This basic, event and outcome-oriented (non-procedural) BPMN process flow diagram communicates the normal, dynamic flow of Play Soccer as a set of collaborating, specialized activities.

The Play Soccer process is initiated by a kick-off at center field. It is comprised of 4 activities: Tend Goal, Defend, Play Midfield, Play Striker. Activities are performed by the players of two teams. The expected outcome of Play Soccer is that a match has been played to its allotted time limit, according to its rules.

A free kick from center starts a match.  Once the match starts all players in their assigned positions maneuver freely, whether they possess the ball or not.  The expected succession of the keeper’s, defenders’, midfielders’, and strikers’ activities is determined dynamically, by the players, while the match is played, by receiving or intercepting passes, stopping shots, and by making passes or taking shots.

The player with the ball will pass the ball to any one of up to 10 other teammates or take a shot; Either the intended teammate will receive a pass, or an opposing player will intercept a pass or stop a shot, to possess the ball. Any player that possessed the ball will then maneuver (according to their assigned position level and their own skill) and then pass the ball to any one of up to 10 other teammates or take a shot. This succession of activities continues, until a stoppage in play.

The success of the expected outcome (pass made or shot taken) of one Play Soccer activity will determine the initiating event (pass received/intercepted or shot stopped) of another Play Soccer activity. The actual flow of a game is determined dynamically, by the players who are assigned to perform Play Soccer’s activities.

This basic, event and outcome-oriented process view of Play Soccer is contextually and structurally sound, but still basic. It is upon this solid, defining structure that one can elicit, add and communicate logical details that are relevant to how the Play Soccer process will “flow” and, that this model’s readers likely expect to see. What about conditional activities, like throw-ins, corner kicks, penalty kicks, substitutions, fouls, out-of-bounds, injuries), and delays (like injury time-outs, and half-time)?

 

Logically Refined Business Process Flow

The logical details about the periodic conditions, activities, and delays in the execution of the Play Soccer process can be straightforwardly discovered by asking and answering simple agendas that are defined in The Universal Process Modeling Procedure[5]. This refined BPMN process flow diagram communicates the conditional activities and delays that are expected to periodically occur throughout the dynamic flow of Play Soccer.

The BPMN process diagram shows that game events, not a sequential procedure determine what and when certain activities are performed in the Play Soccer process.

Even with all those refinements made, the contextually accurate and sound basic structure of the Play Soccer process, that we previously established, has not changed. These refinements can be graphically included or excluded, without any rework of the basic contextual meaning or basic diagrammatic structure of Play Soccer.

Activity dependencies are contextually accurate, without depicting a sequential procedure and sequential flows. Dynamic, alternate activities, paths, and timings throughout the process are accounted for in the model. Undue model complexity, and the analyst’s time that would have been spent on it, has been avoided. Process navigation decisions, and alternate flow paths are in fact modelled, but need not be explicitly illustrated as sequence flows.

Conclusion

The Beautiful Game serves us as a beautiful example of a process that is a set of dynamically collaborating sets of specialized services. It is not a sequential procedure.  Modern business processes are not just sequential procedures either.

The Universal Process Modeling Procedure, with its Universal Business Process Definition and elicitation agendas, provides a modern process modeling paradigm, capable of event-driven as well as sequential business process elicitation and modeling. BPMN is a modern process modeling notation, that includes the graphical elements to represent business event-driven, not just sequential process flows.

With these tools in-hand, process analysts, quality improvement professionals, and business analysts, are capable of eliciting, perceiving, normalizing, defining and graphically illustrating structurally sound, modern business process structures.

Copyright 2022, Edmund Metera

[1] Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN (Metera, 2018, 2022) www.ProcessModelingAdvisor.com
[2] Object Modeling Group, www.OMG.org
[3] Universal Process Modeling Procedure, Step 3 – Define Basic Business Process Flow (Metera, 2018, 2022)
[4] Universal Process Modeling Procedure, How to Specify Event/Outcome Oriented Business Process Flow (Metera, 2018, 2022)
[5] Universal Process Modeling Procedure, Step 5 – Refine Business Process Flow(s) (Metera, 2018, 2022)
BATimes_OCT13_2022

To BA or Not To BA: Why Every Team Needs Business Analysts

The importance of having a business analyst (BA) on your team can’t be overstated. Acting as the bridge between stakeholders and technical teams, the BA wears many different hats. On any given day, a BA can be expected to work on a number of different tasks, whether that’s defining business cases, validating solutions, or even working with data (See this article on the role of BAs in an increasingly data-driven landscape). Able to straddle both worlds and speak the language of businesspeople and techies alike, BAs really are one of the most versatile members of the team.

 

The Story of an Ask

Many businesses are concerned with their ideal state, while the nitty gritties of how to actually get there are very much back of mind. “Often, the client is not able to fully explain what business problem they wish to solve and how to translate their business requirement into language the technical teams can understand,” explains Lizande Botha, a BBD project manager for a major financial services client in Africa “which is why BAs are a vital part of the process”. Put simply, BAs are responsible for translating a business ask into detailed requirements that can be understood and actioned by technical teams.

But how do we get to this point, when the ask itself is unclear? “The first question I tell the BA to ask the client is: What is the problem we’re trying to solve?” explains Botha, adding that the cardinal role of the BA is to ensure that the client ask is clearly defined. “For clients who really are unsure of what it is they want, the BA needs to keep digging and asking questions to truly get to the core of the problem” she adds.

 

Advertisement

 

Once this key piece of information has been gathered, the BA can start drilling down into the different possible solutions, what the budget is for the project, and other confines or expectations the client might have. Understanding the requirements and clearly defining the scope of any given project from the get-go can be make or break – so much so that CIO magazine reports that up to 71% of failed software projects can be attributed to poor requirements. Thus, consulting with a BA at the start of a project can avoid potential stumbling blocks.

While this early engagement is vital, the job of the BA doesn’t start and end there. Leveraging rapport built with business stakeholders, they must check in regularly to provide progress updates, while ensuring that on the engineering side things are running on course and to the requirements of the client’s business. They’re even able to partake in platform or application testing. Truly, the BA’s impact is felt throughout the project lifecycle!

 

BBD’s Drive to Help and Resolve

BBD’s teams are all complemented with BAs who are well equipped with experience and a thorough understanding of the industry they’re operating in. As each industry offers complexities unique to its environment, BBD strives to best match their analysts to sectors where they can bring their experience and real-life learnings to the table, explains Botha. This is a high priority for BBD, a software solutions company which delivers software solutions for clients across the industry spectrum, from financial, education, public sector, gaming, and beyond. Assigning BA’s that already understand the nuances, jargon and processes of a particular industry enable us to expedite the solution process” says Botha

But beyond managing teams to ensure the best hands are on board, BBD is ready to tackle any problems their clients have. And when it comes to understanding what those problems are, BBD has BAs on call to bridge the client-engineer gap and ensure the success of all of their solutions.

Looking for a software partner to help you on your next ask? Get in touch with BBD.

 

BATimes_Aug25_2022

Add some UMPH to your UML

In the world of analysis, at least one thing is true: if you like diagrams, you have probably come to be close with Unified Modeling Language (UML). UML Diagrams are helpful to show flows and relationships of information. This helps to illustrate data points, structure and interactions. Here are some ways to enhance their effectiveness when dealing with stakeholders at all levels:

 

Clean Connectors

Showing directions and connections is helpful, but connectors crossing over can quickly turn a diagram into a confusing web. Because UML Diagrams can vary in complexity and granularity, crossing streams can be unavoidable. Lines should cross as minimally as possible, but if they do have to cross, they should show as a “hop”. Most programs default to this feature when connectors go through each other without a particularly specified intersection. If connectors are not looking separated enough and have too many unnecessary hops, consider the component or class layout being used and see if the objects/items can be better sequenced.

Connector types should also be utilized where necessary to show the nature of interactions, whether it is to illustrate direction or dependencies. This can allow for some detail that could be taken out of the explanation pieces of your documentation.

 

Advertisement

 

Know your Domain

UML diagrams have a specific best-case utility and are strongest when they are describing and modeling objects and displaying aspects of system views. Alternatively, Business Process Modeling Notation (BPMN) helps to show or describe the business process. Understanding how the two differ and how to best use them in your modeling can help to optimize the effectiveness of your documentation and communication. Depending on the project, UML diagrams may be helpful in creating documentation to detail functionality and object interaction. BPMN diagrams can be useful communication aids, especially since they can tailor to the audience; for example, a BPMN that shows a high-level view of the process may be best to use in presentations to individuals that have executive governance in a project.

 

Speaking of Communication…

Using the correct pieces of UML diagrams can also help to keep any text requirement of information appropriately concise. This means avoiding having to describe your intention of objects or classes to a reader, and instead, simply using the standardized shapes and connectors to represent the information being illustrated. A good UML should have minimal text detail in the itemized areas, and the rest of the information conveyed through the standardized language UML provides.

BATimes_June22_2022

Requirements Gathering: Pants or not?

It’s been a long time since I’ve had to wear real “business casual” pants to work. Not since the Before Times has a client seen me from the waist down. Well not anymore! For the first time since February of 2020 I will sit down with a client…in person…in a room…with pants on. I can’t tell you how happy that makes me.

We BAs are social creatures. Being locked-up in my house for the better part of 2 years was not…shall we say…optimal. Don’t get me wrong, It was great spending every minute… of every hour… of every day with my lovely wife of 32 years. Really…it was…great. It’s just that I struggled to do my job well… heck, I struggled to get out of bed sometimes.

I have spent 30 years splashing around in the wading pool of process design and improvement…and almost every day was spent interacting with live human beings. A June 1st article in the BATimes by Lee Templeton, listed “10 Soft Skills You’ll Need To Be A Successful Business Analyst” (check it out, it’s a good read). As she points out, these soft skills are people related skills…you know…for working with people. I have these skills! I’m really good with these skills! But now that the world has seen that working from home actually…er… works from home… there’s a perception that getting together in a brick and mortal room is no longer necessary (as if donuts and coffee weren’t necessary). Unfortunately most, if not all, of the skills on the list… the skills I have… suffer in both application and effectiveness during a virtual meeting.

We all know that rapport building is the poster-child for BA skills. It’s number 1 on Ms. Templeton’s list for a reason. We can’t do our job without it. Clients need to trust us. We’re going to get them to air their dirty laundry… to tell us the bad and the ugly as well as the good. They say “you can’t read the room on a Zoom”. A more truthful statement has ne’er been uttered. I need to pick up on the vibe in the room so I can adjust my strategy, delivery, and approach. Where are people sitting? Is their body language open or defensive? Who’s giving furtive glances to whom? Well let’s see…people are sitting at their kitchen tables…their body language is, well …slouchy… and they can’t glance at anyone. Of course, I can see that much only if they have their cameras on! A quick show of hands…who’s had their initial meeting with a group of SMEs where everyone had their video turned off? I swear I lose a little piece of my BA soul every time a window goes dark. Oh, I can build that rapport, and those relationships… eventually… but what I could do in 30 minutes in person can take hours online. C’mon SMEs! I don’t have all day!

Back to the list…Enthusiasm. Great…I’m enthusiastic. This should be an easy one. But just how enthusiastic can I be when I’m a head in a box? I’m talking with my hands like an Italian grandmother…showing how this flows into that, where this step loops back to here…and no one can see it! OK…Creativity… creativity… maybe I should throw up a whacky virtual background… break some ice… get a chuckle from the guy sitting out on his deck. What do I have that wouldn’t A) offend someone, B) make me come across as goofy and unprofessional, (as opposed to goofy but professional?), or C) make my head disappear? Ugh. Boring corporate logo it is.

So what’s a BA to do? Well, we need to Adapt (another soft skill from Ms. Templeton’s list). We need to find new tools and techniques that not only allow us to do what we did in the Before Times, but to do it better. We need to embrace the new reality, jump on the bandwagon, go with the flow, and do some other catchy phrase that hopefully involves the word “paradigm”.

Remote learning for school was the necessity that drove the invention of new types of learning software. The glazed-eye inducing PowerPoint deck was joined by game-based and interactive Q&A platforms, concept visualization tools, old-people-friendly software for creating short videos and animation, and my favorite…virtual whiteboards. I have fond memories of the smell of a new dry-erase marker in a room with whiteboard walls… of gliding around the room scribbling this over here, laying down an arrow to that over there, drawing a cow in the corner while everyone’s on a bio-break…ah, the good ol’ days. But we must Adapt, right?

Advertisement

My first go at Adaptability was to find an online whiteboard. Boy howdy! There’s a lot of ‘em. Here’s as far as I got before succumbing to virtual overload. (deep breath, here we go)… Microsoft Whiteboard… Miro… Explain Everything… TutorialsPoint… Educreations… Limnu… Mural… Groupboard… Ziteboard… ConceptBoard… LiveBoard… StormBoard… ThisBoard.. ThatBoard, and TheOtherBoard… and my favorite “we’ve run out of whiteboard names” board: FigJam. It was interesting to see the differences in functionality…and by extension, the requirements the BAs wrote. Some were straight up blank boards (i.e. lazy BAs), some were big on templates, some had magic Post-It notes, some allowed you to embed files, some had voting and cute little avatars, and some tried to do everything…and failed spectacularly. I even bought a graphics pad and pen to see if my horrible handwriting was just as horrible in the virtual world. It was worse.

OK, so I spent so much time on the virtual whiteboard tool investigation that I stopped there… but my point is that there are options out there for adding virtual tools to our BA toolbox. Software, however, is not a soft skill. It’s only part of the picture. We need to consider what new people skills we might need. One example is Virtual Contributor Management (I just made that up).  We’ve all had to deal with the “Dominant Contributor”. You know, the guy who takes over the conversation, is first to jump in with the answer or a comment, and routinely interrupts polite people. He’s hard enough to manage in a room, but in a virtual meeting, he can shut down the highly knowledgeable, but introverted, SME with much greater efficiency and speed (not a process improvement, by the way). We need to learn, and get comfortable with, how best to “mute” a Dominant Contributor (without using the actual “mute” button…although…) and invite others to join in. We also have to sort out the “You go; No, you go; No, you go…” politeness pit of doom. Our audience is now scattered to the four winds, and we have to be able to wrangle them into a cohesive, responsive source of information. What? Are you looking at me for the answer… Good luck because I don’t know. That’s a soft skill I’m working on.

But I don’t need know how to do that just yet, because next week I’ll dust off my neglected khakis, pack up my Big Bag o’ Real World Soft Skills and go meet with actual warm bodies in a real room with a real whiteboard! Maybe I’ll even bring donuts.

 

Note to self: Socks…don’t forget socks.

Techniques for prioritizing requirements

One of the major challenges that Business Analysts face is getting stakeholders to prioritize requirements. Everyone is used to high syndrome – where the stakeholders say everything is a high priority.

The key to dealing with this problem is for BAs to understand the drivers of the project and then create priority evaluation criteria to assess each requirement. This is a key step that is often overlooked when starting the business analysis deliverables of the project.

Let’s say the objective of a project is to optimize a business process for an operations group. As a BA it’s important to understand what constitutes an optimized process. It’s a simple upfront question that will surface criteria that the BA can use to help the business prioritize the requirements. For example, the stakeholders may indicate that the optimal process would be one in which the To-Be process has fewer manual hand-offs, reducing the amount of paper that flows through the process, reducing the number of steps requiring manual entry of data, etc.

Advertisement

These criteria can then be used to develop a framework with which to evaluate and prioritize requirements. My preferred approach is what I call the scale approach. With the scale approach, you get the stakeholders to call out how well each requirement aligns with the assessment criteria on a scale of 1,3 and 5 (where 1 means the requirement is poorly aligned with the criteria, 3 somewhat aligned, and 5 highly aligned). This gives a numeric priority assessment of the requirement and a quantitative method of comparing requirements. This helps to get stakeholders out of the “high” trap mode.

Scale Approach:

Here is an example of the scale approach. The scaling approach uses a 1,3,5 scale where 1 is poor alignment, 3 is some alignment (in the middle) and 5 is highly aligned. The max score for any requirement is 15 and the minimum is 3. I’ve tried more granular approaches like 1 to 10…but it just causes a lot more sitting on the fence when you have that many values to apply to a criterion…and it’s not as “distinct” an outcome as the 1,3,5 scale. I specifically avoid using numbers instead of High, Medium, and Low because I find that a numeric approach makes things more subjective than a High, Medium Low evaluation approach.

# Requirement Evaluation Criteria 1 (Reduce Manual steps) Evaluation Criteria 2 (Reduce paper through the process) Evaluation Criteria 3 (Reduce number of manual steps) Total Criteria Score
1 Requirement 1 3 5 1

9

2 Requirement 2 5 5 3

13

3 Requirement 3 1 3 1

5

4 Requirement 4 3 3 3

9

 

Typically, with the above scoring system I would then map it to the more traditional High, Medium, and Low using the following ranges:

Low – score equal to 5 or lower

Medium – score of 6 to 10

High – score of equal to 11 or higher

Based on the above you would then prioritize the requirements as follows:

# Requirement

Priority

1

Requirement 1

Medium

2

Requirement 2

High

3

Requirement 3

Low

4 Requirement 4

Medium

Heat Map Variation:

Most stakeholders are very visual. So sometimes I’ll combine this with a heat map approach. With the heat map approach, each score on the scale is associated with a color.

Score of 1 – shade the cell red

Score of 3 – shade the cell yellow

Score of 5 – shade the cell green

So, if we take the above example and add colors, it will look like:

#

Requirement Evaluation Criteria 1 (Reduce Manual steps) Evaluation Criteria 2 (Reduce paper through the process) Evaluation Criteria 3 (Reduce number of manual steps) Total Criteria Score

1

Requirement 1 3 5 1

9

2 Requirement 2 5 5 3

13

3 Requirement 3 1 3 1

5

4 Requirement 4 3 3 3

9

As you can see above – it really jumps out at you that there is a “strong” fit with requirement 2 and a poor fit with requirement 3. I find the heat map approach helpful when there are a lot of requirements because it’s a lot easier to gauge and compare requirements based on colors than numbers. Also, a lot of times with a heat map you don’t need a total criterion score at the end. It just jumps out at you.

You can further simplify things by just using the colors instead of the numbers.

Does it take more time?

The simple answer is no it doesn’t take more time. All it takes is a little bit of prep, a prioritization meeting and then you have prioritized requirements. When you compare that to having numerous emails, meetings, and discussions about what the requirements priorities are you’ll see it’s a much simpler and effective approach. It also forces stakeholders to really think about the requirements and how they want to achieve their objectives – so less second-guessing of requirements in the future.

One final note:

When I use this approach, I put the actual scoring matrix into the appendix of the requirements document and not in the main body to enable a wider audience to more easily read the requirements document.