Tag: Skills

Best of BATimes: Does Networking Hurt Your Hands? The Power Of A Glossary

Written by Adrian Reed on January 4, 2023. Posted in Articles.

A few weeks ago I was working away from home, and I was able to attend an IIBA UK event in the evening.

It was a really enjoyable event, and after meeting a whole bunch of new people and chatting about all things BA related, I went and checked in to my hotel. As I was checking in, the receptionist asked me how my day had gone. I explained that it had been busy, and I’d spent a few hours networking late into the evening. As much as I enjoy networking (I love meeting new people and sharing/learning), I do find it exhausting. As he handed me my key, the receptionist said something that really surprised me:

“Ah, I used to do a lot of networking. Kills the hands, doesn’t it? All that terminating. I used to work for a communication company so I did a lot of networking”.

Perhaps it was because I was tired, but I did the typically British thing and just smiled and accepted the statement that he’d made without questioning it–but on my way to my room I was puzzling over what he’d said. Why would networking hurt his hands? Too many handshakes maybe? And why would you terminate something at a networking event… that sounds pretty serious! And why is the fact he worked for a communication company important…

Then the penny dropped. Networking has different meanings, and I suspect he was referring to laying physical networking cables in a data center or communication room, where cables have to be crimped and (presumably) ‘terminated’. Perhaps using some of the tools is uncomfortable after a while. “An evening networking” to me means meeting other BAs and having a coffee. To him it meant navigating cables in a comms room ‘out of hours’ getting everything ready before people arrive the next day.

The Illusion Of Communication

As William H. Wyte once wrote “The great enemy of communication, we find, is the illusion of it.”. This is often the case inside organizations and between organizations too. With our plethora of acronyms and words with ‘special meanings’, it is easy to appear that we are agreeing on a particular issue, idea or requirement, only to find out that each person at the table has a subtly different understanding of what is being discussed.

Even words that appear, on the surface, to be obvious can have different meanings depending on who you ask. The word ‘customer’ might seem clear and obvious, but it is quite possible that different people attribute different meanings to it. Who is the ‘customer’ of a training course? The delegate who attends it? The company that employs the delegate (assuming they are paying)? Probably both–although both will have subtly different needs and requirements, only some of which overlap. This is made even more complicated in intermediated industries where there might be an end customer, and one (or many) intermediaries. If a financial service company sells products via brokers, some might refer to the broker as a ‘customer’, others might refer to the end investor as the ‘customer’. Again, they’ll have very different needs and requirements.

This can lead to all sorts of crossed-communication throughout the business change lifecycle, not least when it comes to requirements. Whether we’re writing user stories, use cases or even a heavy-weight requirements catalogue, it pays to think about terminology. This is where the good, old, trustworthy glossary comes in.

A glossary perhaps isn’t the first thing that springs to our minds as business analysts. It’s something we know we probably should do, but with the pressures of a project it can be easy to let it slide. This simple experience, with a misunderstanding over the word ‘networking’, reminded me how important they are. After all, with a clear glossary, writing just about any type of requirement artifact becomes easier. If there is a clear and agreed meaning of “Investor” and “Broker”, for example (rather than using a term like “Customer” that might mean either, or both) we can be concise and precise in our requirements writing.

This potential for misunderstanding also highlights the need for techniques that don’t rely on the written word. Visual techniques, including formal modeling, can help explore the problem space and requirement scope too. All of these activities help us cultivate conversations and help us ask “what exactly do you mean by ‘x’?”. Not only this, but a well-defined glossary can help inform the production of other artefacts such as a concept model (these are clearly different things, but defining terms up front helps a great deal).

In Summary

A glossary might take some time to create and maintain, but it’ll help avoid ambiguity and ensure we can create concise and precise requirements. It is an investment in time worth making.

Best of: 6 Personal Traits That a Professional Business Analyst Should Have

Written by Mark Delarika on December 29, 2022. Posted in Articles. 1 Comment on Best of: 6 Personal Traits That a Professional Business Analyst Should Have

Business analysts are facilitators, communicators, agents of change and negotiators.

They have to understand the needs and purposes of a business in order to consider technology solutions.

They need degrees and certifications, skills, experience and domain knowledge but they also need critically important soft skills to be most successful and become CEOs in the future. Here are some of the personal skills they need.

1. Good communication skills

Business analysts must have communication skills as they have to communicate with a variety of stakeholders. They need to understand why what they’re doing has value and then articulate that to stakeholders. This includes convincing people to work on activities that may not be their top priority.

For example, a business analyst might have to persuade a Sales Director to help define performance metrics for the upgrade of a CRM database.

Good communication skills involve both verbal and written communication. Business analysts who have excellent verbal communication skills but battle with the written words may decide to receive help from writing services with skilled writers at Essay Mama.

Various forms of communication, such as workshops, meetings and other informal methods may be necessary to bring every stakeholder on board.

2. Active listening skills

Business analysts use active listening skills to make sure that all stakeholders are heard. They understand the importance of making eye contact with speakers and always attempt to identify exactly how they feel about what they are saying.

Observing words and body language is important for them to get to the bottom of what is being said. To do this, they must know how to dial out any internal or external distractions.

Business analysts can keep an open mind and acknowledge different opinions as well as know when to move the subject along. They are able to take all input into account without being too ruffled by disagreements. There will always be disagreeing stakeholders and part of their skill is in being able to handle this.

Holding excessively lengthy sessions is not necessary for them and they understand that these often lead to a lack of interest and attention. They prefer web conferences over traveling to different offices and hold meeting. This saves times and shows that you believe in working fast and don’t mind being tech-savvy.

They and honor confidentiality agreements and are generally seen as being above listening to any office gossip. This enables them to establish trusting relationships where they follow through on commitments.

3. Problem-solving skills

Many business analysts say that what they love most about their work is solving problems. Problem-solving can combine analytical thinking and creative thinking. It involves resolving cases of conflicting information, incomplete information, missing information etc.

Solutions aren’t always simple when problems occur within a company. Analysts often have to examine multiple scenarios and operations to find a solution. Understanding the problem usually involves exploring the overt symptoms, in the form of the effects on costs, sales, and performance metrics.

Examining every aspect of the situation provides context and a greater understanding of the big picture. All parties need to have input and give feedback. They have to answer many questions posed by the business analyst such as “why do you need this?”, “what does this mean?”, and “what happens next?”

Finding a solution involves some kind of change within the organization. For example, putting the change into practice could involve augmenting technology or improving a process. The ideal scenario when solving a problem is not only to solve the current problem but to ensure that it never occurs again.

4. Analytic skills

Analytic skills are necessary to be able to interpret business needs and translate them into practical, operational requirements.

Business analysts have to analyze information from a variety of sources, such as documentation, surveys, existing systems and requirement gathering sessions. EssayHave is a reliable custom writing service that’s available to write papers, such as research papers, if necessary.

Business analysts are passionate about analyzing data and usually have a variety of different ways to analyze it. They want to see what they can do with it and how they can tease different facets of meaning from it.

Everyday interpretations of data can easily fall into patterns that can hide shades of meaning. Critical thinking and valuable analysis are not necessarily straightforward. Good analysts will resist trying to come up with a neat solution to solve the problem before extensively analyzing data. Of course, analysis paralysis can also occur and they have to understand when to stop analyzing.

5. Multi-disciplinary skills

Many business analysts have expertise and experience in IT and their domain. However, it also helps to have experience in performing tasks in unrelated fields across various industries.

Those with such experience are more easily able to elicit information, interact with stakeholders and identify opportunities. They know more about the world, business trends, tech updates and have a deeper knowledge of the processes of business.

They can leverage this knowledge to apply information and techniques to their current project. Their wide range of knowledge affords them with innovative ways to deliver value. They tend to be more versatile and to avoid the thinking that certain tools, techniques and work products are suitable for every situation.

Business analysts wanting to change jobs and looking for a new resume should consider reading a ResumesPlanet Review. Find out about expert resume writers who understand exactly what to include in a business analyst resume.

6. Decision-facilitation skills

In consulting with managers and offering advice to developers, business analysts need to exercise sound judgment. After they have received input from all the stakeholders and assessed a situation, they need to facilitate the making of certain decisions.

The goal is not just to bring about change but to bring about the right change. Business analysts need to help others to make the right decisions so that the right needs are met. If a decision isn’t made, nothing happens.

Good business analysis involves defining all the decisions that need to be made, who will make the decisions and the information the decision-maker will use to make the decision. When multiple people need to make a decision, they are not always on the same page. Getting buy-in from all decision-makers takes some skill.

Concluding thoughts

Finding the best business analysts can take some time and effort. The above traits can help to identify individuals who have the potential to be great, even if they don’t have the experience yet or are in different roles.

Individuals who have a unique blend of the right hard and soft skills are usually most successful as business analysts. They know the importance of communicating and listening properly and are adept at managing and analyzing large amounts of detailed information. They know how to present and articulate value to stakeholders enabling them to make the right decisions.

Best of: 8 Tips for a Successful Requirement Elicitation

Written by Dhanya Nair on December 28, 2022. Posted in Articles. 1 Comment on Best of: 8 Tips for a Successful Requirement Elicitation

The key to a successful requirement elicitation session for a business analyst starts with asking the right questions.

This is not a natural skill for many but something that needs to be perfected over time. For starters, keeping a checklist of questions can be an effective measure. So here are few tips to help you get started.

A Business Analyst’s involvement in a project usually starts with the kick off meeting. When you do your introduction to the client, face to face or over a con- call, make sure to explain who you are, your role in the project and what you would like to achieve through this meeting.
While addressing the client, please address them by their first names; especially those from a different country/culture. For e.g. please do not second guess if Robert is Rob or Bob and end up annoying the client. The best you can do is ask them.
Be an active listener. Do not interrupt the client unnecessarily. Towards the end of the meeting, paraphrasing what you have heard will make sure you both are on the same page. For the elicitation to work well, you need to understand what people are saying and also try to read between the lines to understand what they might be hesitant to say.
You need to gather aspects based on the Who/What/Why/When/Where model. Always ask the right questions. While talking to stakeholders, what robs the BA of her credibility is the use of fillers such as, “umm, ahh, like, so, you know…” between sentences that communicate uncertainty and can be quite distracting. If you tend to use these, try to replace them with thoughtful pauses between your sentences. It’s best to avoid hedgers such as, “kind of, sort of, I feel, I gather” and “I suppose”. Instead replace them with strong words, facts, statements of “I know” or “In my research I found that”.
The questions should be framed based on the current state of the system in question, the goals and objectives, pain points, the desired future state, users, success criteria and assumptions.
Some of the clients might ask you to hand over the questions in advance so that they can be well prepared for the call. There is no harm in doing so.
Please do not follow templates blindly that are being used by your organization. Do not try to fit into a model. Rather try to create one based on BA best/good practices.
Do not use technical jargons while dealing with business stakeholders. A BA should be able to speak the language of the audience she is talking to.

Conclusion

To do an effective job while eliciting the requirements, it is necessary that all the stakeholders involved share a common vision regarding the requirements. Be aware of the above mentioned loop holes that can lead you off track. For a successful requirement elicitation, the BA needs to understand the overall business picture/product vision and should be able to relate how the individual project objectives support this big picture.

An Introduction to Business Process Normalization

Written by Edmund Metera on December 22, 2022. Posted in Articles.

Business Process Normalization[1] is an analysis technique that leads to sound, modern business process and workflow structures.

Business analysts, process analysts, systems analysts, and process owners use Business Process Normalization to more effectively elicit, perceive, unequivocally define, and model sound, modern business process structures, and workflow configurations. Proficiency with this analysis technique benefits their process management, digital transformation, and regulatory compliance projects.

What is a Business Process Anyways?

For decades, business analysts, process analysts, and their projects’ stakeholders have tried to define business processes according to various characteristics. Business processes have been said to transform inputs into outputs. They can be decomposed into smaller parts. They start. They “flow”. They end. They have customers. They can cross organizational boundaries. They can be automated. They can be manual. They are measurable. While all those statements may be true, none of them are sufficient enough to elicit, perceive, and unequivocally define and produce high-quality business process structures.

There will be about as many points of view and opinions about what any business process is as there are stakeholders in that process, at least at the start of the process analysis. As always, business analysts and process analysts need to be able to consistently perceive processes and facilitate the journey of business process elicitation, definition, and modeling, with their stakeholders. However, the pace and the technologies of modern, digital transformation, low-code and no-code projects demand that business process and workflow elicitation, and definition be done in an efficient, competent way, instead of ad-hoc questioning and trial and error.

Times have changed

Traditional procedural notions and flowcharting notations have become archaic. They were invented in the days of procedural language programming – in the last millennium. Those notions don’t always work in today’s business and technical environments. Today’s distributed business structures (has anyone been working remotely recently?), technologies like the Internet of Things (IoT) and Edge, mobility, and cloud computing services have radically modernized the business process landscape. Today, a high-quality business process structure is one that has been conceived, structured, and can be readily configured as a modern, collaborating network of event-driven, outcome-oriented services, not just as a sequential procedure.

The Universal Business Process Definition

Let’s look at housing. Any house, no matter its scale, degree of abstraction, location, building materials, and all its unique details, etc. must have a foundation, walls, and a roof to be a house. If it’s missing any of those, it is not acceptable as a house. And for obvious productivity and quality reasons, those basic structural elements are established first, before it is practical to invest time and money in a home’s other architectural, engineering or construction refinements.

The same is true for business processes and workflow structures. Any business process must have a sound, cohesive structure of basic elements to be considered a business process. Its basic structural elements should be elicited and consensus reached, before pursuing all of a process’s possible details and refinements. Even after all desired process refinements have been applied, the process will still have its defining structural elements. This holds true for any process structure or model at any degree of abstraction (i.e conceptual, logical, or configuration), a process’ scale, or the unique details about a business process or workflow.

So, what are the basic business process-defining elements? Paraphrasing the Universal Business Process Definition[2], any business process (i.e., business activity for that matter) is 1) a repeatable collection of work activities, 2) initiated in response to a business event that, 3) achieves an expected outcome, 4) for a customer of that process. These four common-sense rules define all processes, workflows, and activities regardless of a process’ or activity’s scale, the process model’s degree of abstraction, the overarching project methodology, the modeling participants, and the organizations and the technologies that will implement the process or workflow.

Uses of the Business Universal Business Process Definition

Business analysts and process analysts use the Universal Business Process Definition’s four common-sense rules throughout their business process modeling journey and they work out and arrive at high-quality, robust, predictable, and operational business process structures. They use it to guide their elicitation agendas with business stakeholders. They use it to frame their observations of business processes. They use it to normalize what they and their stakeholders have named as candidate processes. They use it to resolve ambiguity among stakeholders and to organize business activities into the optimal, modern business process and workflow structures. This is akin to understanding and applying the Business Normal Forms[3], long used by business analysts and systems analysts to work out and optimally organize data attributes into entities and to produce high-quality relational data structures.

The resulting business process structures are high-quality structures because they have been elicited, perceived, and defined by asking and answering the right questions. They can be implemented equally well as traditional sequential procedures or as today’s, distributed business structures and networked technical (like cloud services) architectures. As event-driven, outcome-oriented business process structures, they are consistent with modern networked, collaborative business relationships and cloud technologies.

Business Process Normalization

Business Process Normalization is the analysis technique of testing the contextual meaning of a candidate business process according to the Universal Business Process Definition’s four rules.

A business analyst or process analyst need not ask a lot of questions to normalize a business process or workflow. They only need to ask a few focused questions (four in fact) and doggedly pursue and gain consensus to the four, sometimes-elusive, answers. The assumed basic structure of a business process will either be affirmed or restructured by the answers to the normalization questions. If any of the four tests have not yet been satisfactorily answered, then the analyst will need to elicit more clarity to satisfactorily answer the four process-defining tests.

Once all four tests have been sufficiently answered, the process has been normalized. Ambiguities have been resolved. A sound, fundamental business process or workflow structure has been understood. The answers to the four tests can then be used to write a contextually accurate, unequivocal, plain-language process definition. No two processes will likely have the same definition within the same domain of analysis. The normalized process’s defining structure will be the foundation of a contextually accurate, high-quality business process model, configured business procedure, or automated workflow.

Benefits of Business Process Normalization

The benefits of using the four-part Universal Business Process Definition’s rules and the Business Process Normalization technique are that they are relevant for today, it is efficient, it boosts contextual quality, it minimizes redundant and non-value-adding activities, it aids in well-written process descriptions, and it improves the potential for reusable business services.

Relevant for Modern Business Structures and Technologies. Processes that have been normalized according to the Universal Business Process Definition are event-driven and outcome-oriented. They are structured so that they can be readily implemented across enterprises’ geographies and boundaries. They are easily modeled using modern notations, like BPMN. They can be readily translated into modern networks of collaborating services (such as SaaS services in the cloud), just as well as traditional sequential procedures and workflow designs.

Efficient – Whenever discovering and defining business processes among a group of stakeholders, it’s more effective to be asking the right questions than a lot of questions. The Universal Business Process Definition frames the elicitation and normalization agenda with four simple questions. The process modeling work comes down to doggedly pursuing and getting consensus to the questions’ answers among the right business stakeholders.

Boosts Contextual Quality – Assuming that everyone will understand the same meaning for the name of a business process is insufficient. By normalizing a business process according to the Universal Business Process Definition’s four rules, the contextual knowledge and consensus about that process become unequivocal among readers of that definition.

Minimizes Process Redundancy. An enterprise may have different processes that do the same thing. They are just named differently. Any two candidate business processes that, through process normalization, answer Business Process Normalization’s four tests with the same answers are very justifiably two different names for the same process. They should be closely re-examined to decide if one of them can be, in due course, feasibly eliminated.

Minimizes Non-value-adding Activities. People, departments, and enterprises tend to propose or perform activities that they do, instead of what is needing to be done. The value of their activities toward achieving a process’ or workflow’s expected business outcome may be unclear. According to the Universal Business Process Definition, a process includes the activities that lead to a process’s expected outcome. Candidate activities that are not needed to achieve a process’s outcome should be closely re-examined and either be discarded, or they may belong in another process.

Aides in Well-Written Business Process Descriptions. The answers to the four business process normalization questions can be simply written in plain-language sentences to form consistently written, clearly written, and contextually meaningful, process descriptions. (Examples of such process descriptions can be found here.)

Improves Potential for Reusable Services – According to the Universal Business Process Definition, activities are themselves perceived and defined as event-driven and outcome-oriented processes. Each is defined in part and bounded by its initiating event and expected outcome. Because of this event and outcome-oriented structure, activities have the potential to be recognized as reusable services, which may be reused in more than one larger process.

Learn more …

You can establish or improve your business process modeling competence and learn the Business Process Normalization technique, by reading:

Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN, (Metera, 2018, 2022). This how-to guide’s topics include the step-by-step Universal Business Process Modeling Procedure, razor-sharp elicitation agendas, the Universal Business Process Definition, Business Process Normalization, basic and refined process modeling patterns using BPMN, and Universal Business Process Model Quality Checklists.

Find related topics at ProcessModelingAdvisor.com. The site’s purpose is to help you establish or improve your business process modeling competence. It includes articles, process model examples using BPMN, checklists, and access to out-of-the-box IIBA-endorsed and bespoke business process modeling training.

[1] Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN (Metera)

[2] Universal Process Modeling Procedure – The Practical Guide to High-Quality Business Process Models Using BPMN (Metera)

[3] The Data Modeling Handbook (Reingruber and Gregory)

Good at Drawing or Good at Visualizing – There is a Difference!

Written by Line Karkov on December 15, 2022. Posted in Articles.

I often use simple diagrams and icons enhanced with text done with pen on paper instead of long presentations. It is a skill that I have practiced over some years now. Sometimes, colleagues tell me that I am good at drawing, but the fact is that I am not good at drawing. I am good at visualizing, and I am also fairly good at listening. This article is about what I mean by that.

Let me demonstrate with an example. The two drawings below are similar to two illustrations I did earlier this year. They are translated into English and made generic in content to make them understandable without knowledge of our business. I have also left out the detailed text that is included on the originals. Not only do they make no sense out context, but it also emphasizes the simplicity of the actual drawing.

Earlier this year, my manager asked me to do a drawing of our IT strategy. We work in an organization that is in the non-profit sector and we are not an IT organization. Out of 200 employees, 10 of us work with IT – all development is outsourced. The audience of this strategy was a management team where only my manager has a background as an IT professional. So, we needed to make it visual and easy to relate to. Part of our strategy is to rely as much as possible on software-as-a-service, so that we always have evergreen applications, and we don’t need to take care of upgrades etc. ourselves. “Evergreen” is a great image that is easy to understand and also easy to draw. I decided to include that in the visualization. When we talk about enterprise architecture and strategy, it is common to perform gap analysis and plan for closing that gap. A gap is also easy to draw. So, my first draft looked like the drawing below, with some text added on each side to about the goals of the initiatives and the applications that were impacted.

My manager presented this to our CEO, who said: “It’s a pit that we are filling with dirt?”. Having primarily worked in IT organizations, I have never questioned this metaphor of the gap. But he was right. When you think about it, it isn’t really that inspiring to just fill a gap. Ok, we needed something else. I have earlier used a Greek temple to illustrate IT architecture strategy. I like the comparison of solid, sustainable IT architecture with classic architecture with its timeless qualities. My first thought was an aqueduct transporting water to our evergreen application landscape. But I liked the idea of something that could transport our organization and was afraid that the aqueduct was too abstract. So, I decided to illustrate it with a bridge inspired by Roman architecture. The pillars of the bridge are made out of the initiatives on our roadmap. One pillar is made up of the initiatives for improving our services, and the other the initiatives for improving administration. Together, they will enable the organization to walk across from a withered to an evergreen field. That resulted in this drawing (again, with additional text next to the side of the pillars related to the goals):

This was the drawing that was presented to the management and later to the board. I think it is a better drawing than the first one and that is not because it technically is a better drawing than the first one. But because the metaphor was more fit for purpose. This is what I mean, when I say that my strength is not drawing, but visualizing. The ideas for how to visualize various topics comes from listening to how people talk about their work, the topic for the visualization, and the feedback that I get. You might notice that the first drawing includes seven initiatives, the second only six. This is an example of how the structure can sometimes dictate content. We had to prioritize and leave an initiative out that is more related to infrastructure but was included for its significant impact on business users.

Below is a drawing that my son Thorbjørn did recently. He is 10 years old.

I think we can all agree that he technically is better at drawing, than I am. Look at the facial expressions and walking legs as examples. So, just to emphasize the point even further: You do not need to draw as well as a 10-year-old to apply your drawing skills at work. You probably do to be a professional graphical facilitator, but that’s a completely different story.

As business analysts, many of us are well trained at visualizing. We use this skill when we do process maps, application landscapes, mockups, conceptual models or logical data models. Use this to your advantage, and you will find, that it is possible to learn the drawing skills that enable you to apply visual thinking in your business analysis practice.