Tag: Communication

How to Safely Escape from the Assumption Trap in Requirement Analysis?

Written by Sumi Prasad on February 1, 2023. Posted in Articles.

There is a saying “Assumption is the mother of misunderstandings”. With that being said, it is common for business analysts to make assumptions to move forward with the requirements analysis. Because assumptions can help improve the efficiency and effectiveness of requirement analysis, reduce uncertainty, and identify potential risks, if not properly managed and communicated, It can become a double-edged sword.

Let’s evaluate,

What are assumptions in business analysis?

Assumptions are statements without evidence or verification that are accepted to be true.

For instance, assuming that the new software will be compatible with existing hardware and operating systems. Or assuming that the user will find the new feature easy to use or assuming that the product will meet non-functional requirements, such as security and accessibility.

Based on the business, context, time, customer, process, etc. assumptions can vary. Some examples include the following:

Assumptions about the customer: their needs, motivations, preferences, market segments.
Assumptions about the requirements/problem: nature, impact, pain points, tasks involved.
Assumptions about internal resources: culture, technical capabilities, time, budget, availability.
Assumptions about the solution: ease of use, UI design, technical constraints, functional and non-functional aspects.

What are the advantages of making assumptions in requirement analysis?

Enhance the efficiency and effectiveness of requirement analysis by focusing on the most critical and relevant aspects.
Ensure that scope is confined and complexity is avoided.
Provide better insight into the customer’s requirements. Considering different scenarios and making educated guesses can help in gaining a deeper understanding of the customer’s needs.
Create flexibility in the process of gathering requirements. As such, ability to adapt to changing circumstances and respond better to unexpected challenges and opportunities that may arise during the development process.
By documenting and communicating assumptions, stakeholders and team members can ensure that everyone is on the same page, making informed decisions.
Identify potential risks during the discovery phase and avoid surprises at the last minute.
Reduce uncertainty by allowing analysis to continue even if you don’t have a complete picture

What are the downsides of making assumptions in requirement analysis?

If assumptions are not clearly stated or communicated, it can lead to misunderstandings among stakeholders and team members. This can result in misaligned expectations and rework.
If assumptions are made with biases for example the business analyst assumes that the stakeholder has a certain level of knowledge or understanding, they may use technical language or make assumptions about the stakeholder’s needs without verifying them, which can cause misunderstandings of the requirements.
If assumptions are not clearly documented or communicated can lead to confusion and a lack of clarity about the requirements. This can make it more difficult for the product team to accurately plan and execute the project.
If assumptions are not properly addressed, it can result in incomplete requirements, which can lead to issues during the development phase. For example, if a key assumption is not considered, it could result in the development team building a solution that does not fully meet the needs of the users.
If assumptions are not properly managed, it can increase the risk of project failure. For example, if an assumption about the availability of resources turns out to be incorrect, it could lead to delays or other issues that impact the schedule and budget.

The above list of downsides is presented using an “If” statement intentionally in order to emphasize that making assumptions is not a pitfall but rather an important part of requirements analysis and gathering. It becomes a problem if not effectively managed and communicated with the stakeholders.

Business analysts should be explicit about their assumptions and verify them with relevant stakeholders. Various techniques can be used to accomplish this, such as asking questions, using user stories to describe requirements in detail, and involving the customers in the requirement gathering process.

Some tips for effectively managing the assumptions that you are making during the requirement analysis.

Spend time and critically evaluate the assumptions that you are making as you progress with the analysis.
Write down the assumptions that you are making in a concise manner at all stages. This will help to ensure that they are easily understood by others and can be referred back to later.
Make sure to communicate the assumptions that you have documented with the relevant stakeholders.
Review the assumptions that you have made to ensure that they are still valid. If any assumptions turn out to be incorrect, be sure to update them and communicate the changes with stakeholders.
Mention date when documenting the assumptions, which will help to review and validate the assumptions at later stage (E.g.: As of <date>, At the time of writing <date>, As at the <date>, At the <date> of writing/drafting/reporting).
It is important to be proactive in asking questions and verifying understanding, and to be aware of one’s own biases and seek out diverse perspectives.
There are times when assumptions are made unknowingly or by overlooking certain factors. It is possible to uncover such hidden elements through careful analysis and attention to detail. No matter how obvious and straightforward something seems, it still needs to be mentioned. In some cases, simple statements and questions can reveal hidden assumptions.
Make realistic assumptions. For example, assuming that the new product will be 100% efficient with no waste or errors is unrealistic.

To summarize, taking assumptions into account is an essential element of business analysis because it simplifies problems and accelerates analysis. Nevertheless, it is imperative to understand the pitfalls of assumptions and carefully consider their validity. Explicitly acknowledging, managing, communicating, and reviewing assumptions helps businesses minimize the risk of making inaccurate decisions.

Bad Bosses for BA’s

Written by Christina Lovelock on January 11, 2023. Posted in Articles.

Our relationship with our manager has a massive impact on our work, health and happiness. What makes a good leader for BAs and what can we learn from bad bosses?

Project Managers

PMs are often attracted to their role because they are skilled at delivery. It is very difficult to balance the competing demands of meeting delivery milestones with nurturing and developing individual team members. Having the combined roles of line-manager and delivery-manager puts project managers in an unenviable position, and if the performance evaluation of the PM is primarily concerned with project delivery, it is clear which role will take precedence.

Some of the worst examples of PMs managing BAs include:

Treating the BA as deputy PM
Assuming the BA wants to become a PM
‘Hoarding’ the BA on their project, despite requests to expand horizons and develop
Vetoing analysis tools and techniques the BA wants to apply
Preventing the BA from speaking/presenting to senior stakeholders, reducing the visibility of the BA and unintentionally (or intentionally) taking credit.

If the person doing these things is also your line manager – how can you address the behaviours or find appropriate support?

Learning points

Where a BA is line managed by their PM, there needs to be recognition that there are two different relationships at play. The ‘best’ outcome for the project (BA assigned 100% of the time, forever) is unlikely to be the best outcome for the individual BA. PMs will sometimes have to put the needs of the individual above the project, or risk losing them from the organization entirely.

BAs may want to partition meetings or request separate ‘line management catch-ups’ which have more emphasis on personal development and wellbeing and less on project delivery.

The PM/BA relationship works best when they are a professional partnership. The roles have different skills and approaches, but are working towards the same delivery goals. This can be severely compromised if the PM is the only ‘boss’ for the BA.

Product Specialists

Product managers and product owners sometimes find themselves managing BAs. They may also want to ‘hold on to’ their BA indefinitely. They often value product knowledge over the BA skillset and expect BAs to become subject matter experts. If the only training and development opportunities they can imagine for the BA is ‘more product knowledge’, then BAs are not getting the support and encouragement they need from their boss. They may not understand the breadth of the BA role and skill set, and subsequently only allow the BA to operate in a very narrow role with a constrained set of tools, techniques and relationships.

Learning points

Refer to job descriptions to keep both BA and boss focused on the wide remit of the role, not narrow product knowledge. The BA should build strong relationships with business stakeholders and relevant teams, so they have easy access to business knowledge, but don’t become the keeper of this knowledge. Encouraging regular discussion of succession planning and rotation and re-assignment normalises the idea that a BA will not stay with a particular product for the long term, and what we are providing is a business analysis skills-based service, not a product knowledge-based service.

The Absent Executive

Whilst it may be appealing on paper for a BA to report directly into a CIO or other senior executive, it comes at a price. It can be very difficult to get their time, leading to an inattentive and shallow line management relationship. The BA is often faced with the choice of a distant relationship, with irregular catch-ups and never knowing if something more important may overwrite one-to-one time OR attempting to become the right-hand-man of the exec, picking up a range of problems and projects, but is subject to rapidly changing priorities. Neither of these are particularly appealing situations and neither provides considerate and consistent line management support for the BA.

Learning Points

Reporting into a senior executive requires a high level of autonomy and independence. Some BAs enjoy working in this way so this can work well. However, everyone deserves to have a positive and supportive relationship with their boss and not see themselves as the lowest priority item on a very long to-do list. Investing in other meaningful relationships with more accessible colleagues may help to address the gap if a management void occurs. This could include a mentor, coach or trusted and supportive peer. Developing the community of business analysts helps to provide support and direction if there is an absence of management.

General Manager

There has been a rise in the belief that ‘a good manager can manage anything’. The problem is, this is not actually true and multiple studies spanning many sectors find that:

A manager who has skills and experience of a function leads to a higher performing function
People whose boss has skills in their discipline are happier and are better at their jobs!

A manager who does not understand or value business analysis is the worst possible boss for a BA.

Learning Points

BAs can help managers to understand the role and remit of business analysts and can champion the application of repeatable, rigorous analysis to aid decision making, understand customers, avoid risks, identify opportunities and improve services. It is always worth investing the effort to raise the profile and highlight the impact of good business analysis.

Organizations with sufficient numbers of BAs (5+) should be investing in a BA leadership role such as:

Head of Business Analysis
BA Manager
BA Team leader
BA Chapter lead
Head of profession for business analysis

Having individual BAs reporting to a range of roles and scattered throughout the organization does not allow the consistent application of business analysis, the opportunity to continuously improve or appropriate development and support of BAs.

Successful BA leaders are skilled and experienced in business analysis. They understand how to recruit and develop BAs and enable appropriate utilization and retention of BAs, saving the organization time, effort and money.

Conclusion

While there will be many examples of successful line management relationships from all of these roles, it is important to recognise the potential pitfalls and how they can be addressed. Not everyone is cut out to be a manager of people. Having a boss who cares about us as an individual, is interested in providing support and offering development and values the contribution we make should be the minimum we expect from our line managers.

Having a bad boss is bad for your health and career, so if you can’t change you manager, change your manager.

Are you Losing BAs? C Lovelock, February 2022

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.

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.