Skip to main content

Tag: Project Management

Crafting a Compelling Business Case: A Practical Guide for Business Analysts

Developing a business case is akin to telling a compelling story—one that captivates your audience and persuades them to invest time, resources, and support in your idea. As a Business Analyst, mastering the art of creating a persuasive business case prior to crunching the numbers and making the pitch is essential for driving successful projects within your organization. Here are eight major points that will help you navigate the intricate landscape of business case development (i.e. “make the case”).

 

  • Basics of Making a Business Case

Let’s kick things off with the foundational principles of constructing a business case. Regardless of the nature of your proposal or the industry you’re in, the process remains surprisingly consistent.

First and foremost, abandon the idea of diving into logical arguments or grappling with intricate numbers right away. Instead, envision yourself as a storyteller, beginning with the identification of a problem or opportunity. Ask yourself: What business need are you trying to address? Once you’ve pinpointed this, it’s time to introduce the characters in your story—stakeholders, beneficiaries, and subject-matter experts.

Stakeholders, often high-ranking decision-makers, hold the power to greenlight or reject your business case. Beneficiaries are those who stand to gain from your proposal, while subject-matter experts provide insights into problem-solving. Collaborate with these individuals to explore various alternatives, considering efficiency, cost-effectiveness, and alignment with your organization’s culture.

Having chosen the best option, create a high-level project plan to estimate the time and resources required. Finally, clearly articulate the value your solution brings, setting the stage for the subsequent number-crunching phase, including ROI, break-even points, payback periods, net present value, and internal rate of return.

 

  • Learn How Your Organization Evaluates Business Cases

Understanding how your organization reviews and approves projects is crucial for tailoring your business case effectively. Answer questions such as: Does your company have a formal evaluation process? Is it connected to other processes, and how detailed do stakeholders want the information?

Leverage the knowledge of a colleague familiar with the evaluation process. In large companies, formal templates and specific review times may exist, often tied to annual budgeting. Some organizations use a “tollgate” process, where approval is sought for project phases, allowing gradual commitment of resources.

Smaller organizations follow a similar pattern, albeit with less structure. Identify decision-makers’ authority levels, and if your organization lacks a defined process, seek insights from successful colleagues who navigated similar challenges.

 

 

  • Know Who’s Calling the Shots

Understanding who holds the fate of your project is paramount. Whether it’s an individual or a small committee, knowing your audience allows you to tailor your case to their priorities. Your boss might have insights into the decision-makers, whether it’s the CFO, division head, or a committee representing various organizational facets.

Identify the dominant department, as their goals often carry significant weight in decision-making. Find a champion within that department or committee who can advocate for your proposal. Remember, the goal isn’t just approval but informed decision-making, even if it means rejection.

Once you know the decision-makers, understand their priorities. Senior leaders look for projects aligning with the company’s strategy, emphasizing the importance of ensuring your case dovetails with broader objectives.

 

  • Understand the Audience’s Objectives

Aligning your business case with your company’s objectives is pivotal. Begin by identifying these objectives through sources like annual reports, CEO letters, and all-staff communications. Grasp the overarching themes—whether it’s growth, cost-cutting, global expansion, or regional focus.

Those evaluating your case are likely responsible for meeting these objectives. Clearly demonstrate how your proposal contributes directly to these goals. Understand the priorities, values, and decision-making styles of stakeholders by engaging with experts from various functions and consulting your boss.

Remember, stakeholders may not always agree on how to achieve company goals, emphasizing the need to involve experts from diverse functions when building your business case.

 

  • Clarify the Need

Before delving into team-building and solution brainstorming, the business need must be crystal clear. Referred to as the “pain point,” it’s the urgent problem or opportunity driving your proposal. It could be a sales force losing bids, service desk requests falling short, or an opportunity for substantial cost savings.

Document the pain point(s) thoroughly, noting the origin, impact, and the solution’s objectives. This documentation serves as the basis for your recommendations, making it easier to present a compelling case to stakeholders later on.

Whether you identify the need yourself or stakeholders present it to you, rigorous research is essential. Document everything, keeping notes on paper or digital files to refer back to when faced with conflicting or partial information.

 

Advertisement

 

  • Build a Cross-Functional Team

Developing a business case is not a solitary endeavor. Relying solely on your perspective risks overlooking crucial aspects. Instead, assemble a cross-functional team comprising individuals from various departments and perspectives.

While you may not have a dedicated team, bring together individuals at different points in the process. Include a finance representative to provide a big-picture view of costs and benefits. Engage beneficiaries to voice their concerns and ensure a holistic problem-solving approach. If the project impacts customers, involve customer-facing representatives like account managers or customer service representatives.

External experts can offer valuable insights, whether sourced from your network, online communities, or vendors. The key is to form a tight team of experts focused on the specific case, respecting the organizational chain of command and securing support from reporting managers.

 

  • Consider Alternatives

The brainstorming phase is where your cross-functional team shines. Encourage the exploration of potential solutions, using problem statements as a starting point. Look beyond individual departments, considering how other organizations or departments might have addressed similar needs.

Emphasize that these sessions are working sessions—opportunities to generate options without delving into detailed project plans or specific vendors. Facilitate creative thinking while reminding the team of limitations and constraints. The goal is to consider all viable options before narrowing down to 2-3 choices.

Thought-provoking questions guide this process. Which option costs the least? Is it the fastest to implement? Does it have the fewest risks or bring in the most revenue? Present each option with at least one significant advantage and be ready to share rejected options and the reasons behind their dismissal.

 

Think Through the High-Level “How”

Paint a vivid picture of how your proposed solution will be implemented within the organization. While not a detailed project plan, this outline provides a realistic basis for estimating costs and benefits. Consider what tasks need to be done before, during, and after the project switch.

Engage subject matter experts and stakeholders in this process. Anticipate potential roadblocks and resource requirements, securing buy-in from involved departments. Validate your proposed solution with your cross-functional team, ensuring feasibility and uncovering any hidden costs or constraints.

This high-level planning stage helps you identify whose support you’ll need and ensures that all costs, including one-time expenses, are accounted for. It sets the stage for detailed financial calculations and further strengthens your business case.

 

Here’s to crafting a compelling case that resonates with stakeholders!

Best of BATimes: 3 Reasons Why the BA/PM Hybrid Role is So Difficult

There are many variations of the BA Hybrid role, but the Business Analyst/Project Manager hybrid is the most widely discussed.

 

While there may be disagreement on whether there should be a blended BA/PM role and where the two roles differ and overlap, I think we can all agree on one thing: this hybrid role can be very challenging. It is also a hybrid that is gaining popularity as organizations look for ways to become leaner and more flexible. In this article, I will highlight the top three reasons why this hybrid role can be difficult for many and some suggestions to overcome the challenges.

 

1. The BA/PM role requires expertise in both disciplines.

The BA/PM role requires highly developed competencies across both disciplines which require education and experience across both to execute well. The problem is, many organizations, whether intentionally or circumstantially, assume that a good BA can quite naturally take on project management responsibilities and the same goes for PMs being able to take on business analysis tasks. The reality is that while one person could do both, there will most likely be a marked difference in the level at which they execute if they are experienced in one and not the other.

For example, an excellent PM with limited BA experience will likely get the project done but the value delivered may be less than initially expected by the stakeholders. Why? Because project management focuses on delivering the project according to the project requirements, but business analysis looks deeper at the meaning of the requirements and how the solution will be best implemented. A PM who is inexperienced in business analysis may take the requirements as stated by the stakeholders at face value, something that a more experienced BA would look deeper at and inquire more about. A BA with little or no PM experience may produce well-defined requirements but would likely struggle when it comes to managing multiple project constraints because they do not have the experience needed to make professional judgments that will keep the project on track.

 

2. This role only works well with small changes.

The IIBA Competency Model states this concerning hybrid roles, “The dual hybrid role is typically associated with small or less complex work efforts, where it is possible for a single person to perform both roles effectively.” This is true when it comes to the BA/PM hybrid and those performing these roles are certainly aware of this reality. This becomes an issue when an organization is immature in either discipline or is undergoing organizational restructuring. While it may be well understood that smaller is better with this kind of role, when an organization is not mature in performing project management and business analysis, the cost of failure and the loss of value is not easily identified.

When an organization is undergoing organizational realignment, they often take an “all hands on” approach to getting things done, which may leave one person managing large or risky efforts while holding multiple responsibilities. From the outside, it can appear as a great way to maximize resources because no one truly understands the real costs of having one person doing both.

 

Advertisement

 

3. The role may not be well-defined or adequately supported.

Any role that is undefined or poorly defined is likely to cause problems. With the BA/PM role it can be even more evident. Many BA roles already have a lot of presumed tasks that impact the nature of their work. Many PMs have roles loaded with other responsibilities outside of project management. When the two roles are combined into a BA/PM role that is ambiguous and undefined, it can produce a lot of issues, not only for the individual in the role, but also for the organization.

Many times, the BA/PM hybrid role is not even officially acknowledged as a hybrid role and appears out of necessity where the person keeps the same job title but assumes more responsibility in the other domain. These situations can also make it hard to find the right person for the role. It is not enough to simply take two full-time job descriptions and merge them together into a double job description. There must be much thought given to what they will be asked to do and what they will not be asked to do. If this boundary is not created, it will set up the BA/PM to manage their work by urgency only, because there won’t be enough time to do everything they are assigned.

 

Increasing the Odds of Success

To ensure that the BA/PM role is successful, organizations must pay attention to the role and what is needed to increase the odds of success. It is not enough to merely assign additional responsibilities to an existing role. Organizations must take the time to define the role considering the value they expect to receive and the inherent limitations of the role. Once the job is defined, there must be a concerted effort to keep assignments within the size and complexity that will best enable success and have mechanisms in place to measure that.

Additionally, there must be some consideration given to what will be needed to support the BA/PM. Are there other team members who can assist with tasks that would normally be associated with one or the other function? I have been successful in BA/PM hybrid roles where I had an oversight role on the business analysis side and was expected to review and guide the work of other BAs, rather than do everything myself. A successful support structure will also include access to the education, training and mentoring needed to allow those performing the role to sharpen their skills. All of these will increase the odds for success in the BA/PM hybrid role.

Published on: 2017/02/16

Ode to a Picture

Practically everyone has heard the expression “a picture paints a thousand words”.  In the world of art, a picture can be used to express ideas and evoke emotions, or it can also simply be used to capture on canvas something or someone significant. In the professional world, carpenters and architects rely on drawings to build to precise specifications. In the business analysis world, the whole purpose of creating a picture, otherwise known as a diagram, is to clearly communicate information without using words.

There are many different types of diagrams at our disposal, and I will attempt to name a few key ones here: entity, activity, data flow, sequence, use case, flowchart, system context, workflow, object, component, and UML.  However, the focus here is on what you want to convey to your audience through a diagram and the benefits of doing so, rather than how or which diagram you should use to do so. The point is to emphasize the benefits in the use of diagramming in many situations to communicate meaningful information and transform your business analysis efforts!

 

What a Diagram Can do for You

Diagrams can tell a story from numerous perspectives. For example, they can be used to confirm our understanding of processes, or to define system interfaces. They can illustrate system and network connectivity. They can help to explain complex processes. Diagrams can depict workflow, business processes and system interactions. They can help to define in scope and out of scope features.  They can also help establish or confirm understanding between the business analyst and a stakeholder in a way that verbal or written words sometimes cannot.

Diagrams can help confirm requirements by illustrating what needs to happen in a system or workflow. They can also be used to model database structures and to depict data flow. Diagrams can cut across confusing jargon or long-winded verbal or written explanations and get right to the point in the simplest of terms. When you consider all of the benefits, the power of a diagram is undeniable!

 

Diagrams are Blueprints to the Past, Present and Future

Diagrams can be used as blueprints for past, current or future conditions. For instance, diagrams from the past can help explain why outdated processes or procedures might have come into existence. How many times have you come across the question “why do we do this”? The typical answer of “because we’ve always done it this way” never solves the problem.

If only you could time travel back in time to document a process using a diagram so that in the current day you or anyone else could easily answer any questions about the “why’s” of a process or procedure. Prevent this lapse of information for future questions and diagram your process!

 

Take Time to be in the Present

Although your stakeholders (and you) might be very familiar with the tasks and workflow used with a given process, it is still beneficial to take the time to depict current “as-is” diagrams.   These diagrams are helpful to illustrate current interactions between actors and systems as well as point out manual tasks that might be targets for process or system improvements. Current state/as-is diagrams can also serve as a valuable documentation tool. New employees and auditors alike tend to appreciate the information conveyed in a diagram.

Additionally, going through the process of building out diagrams for current business systems and stakeholder processes can help demonstrate the need for better written procedures. Current state diagrams can also help point to key performance indicators when changes are proposed. For instance, when comparing the proposed future state to the current state, time-consuming manual tasks will hopefully be earmarked for potential elimination. Having these diagrams at your fingertips can make these improvement opportunities stand out, which will make the task of quantifying the time saved or cost savings (or whatever differences) that much easier to document.

 

Advertisement

 

Illuminate the Future

Future state or “to-be” diagrams can help to illuminate the roadmap for upcoming changes, whether that might be a business process, a system component, or a new business system altogether. For instance, they can help define system changes and plan improvements to technical interfaces, thereby avoiding future outages. They can help to confirm our understanding of impending changes to processes and to thereby plan accordingly. They can also help identify the business processes that may become obsolete. Future state diagrams can also help the organization stay focused on the planned and specified changes or help to inform decisions to adjust the plan if necessary.

 

Conclusion

As a business analyst, the diagram has to be one of the strongest tools in the arsenal of BA weapons. There are so many uses and applications where a diagram can transform work efforts. It doesn’t have to be fancy or complex. In fact, the simpler the better. The point is to use a diagram to convey the desired information in as clearly a manner as possible. The benefits of a diagram can be felt across all levels of the organization, communicating across different levels of knowledge and understanding. Diagrams can clarify information for stakeholders and business analysts alike.

They can validate or improve existing understanding and inform future changes. They can serve as documentation for auditors, and training tools for staff. Diagrams can highlight the need for improvements and underline performance improvement indicators.

The uses and benefits go on and on, so hopefully this will inspire you to take a little time in each of your project efforts to paint the picture that will prevail in communicating your message and save yourself a thousand words!

Back To Basics: Excellent Elicitation

Elicitation is a core business analysis skill, and one that BAs typically utilize daily. It is easy to fall into the trap of thinking that elicitation is so basic that it doesn’t warrant talking about. Yet, just because it is a core skill doesn’t mean it’s easy, and it certainly doesn’t mean it’s unimportant. Not only this, but elicitation usually involves working with stakeholders, and whenever people are involved there can be inadvertent conflict and contradiction.  Achieving  clarity is rarely easy!  In this article, I’ll address three perspectives of elicitation that you might find useful.

 

Elicitation As A “Trawling” Activity

In their book Mastering the Requirements Process, James and Suzanne Robertson use the metaphor of trawling to describe elicitation. The idea is, much like a fishing boat with a net trawls for fish, an analyst ‘trawls’ a business area for relevant pieces of information.

 

Ever since I first heard this metaphor I’ve liked it. Building on the Robertsons’ work and extending the metaphor, we might also say:

 

  • Where you trawl matters: If you trawl in an area with no fish, you’ll end up with an empty net. The same is true of requirements—ask the ‘wrong’ people and you’ll get very little.
  • The type of net matters: I’d imagine that the type and size of fish you are trying to catch will affect the type of net used. There’s a comparison here with elicitation—the techniques need to vary depending on the context and the types of requirements that you’re looking for. Detailed observation might yield very in-depth requirements, so might be considered a ‘small net’. A high-level conversation with an executive might yield high level outcomes and be considered a ‘big net’. Both are important, but it’s important to know which you are looking for.
  • There will always be stuff to throw back: Sometimes, it’s tempting to plan elicitation activity in a straightforward, linear way. As if you’ll be able to speak to person A, person B, do some observation and then everything is done. Of course, it never works exactly like that, as people will throw in curve-balls, there’ll be discussions which take you in unknown directions and so forth. I suppose this is a bit like trawling for fish: there will always be some fish to throw back if they are too small, too big, or the wrong type. In requirements terms, this shows that elicitation and analysis go hand in hand. As soon as elicitation starts, there will be filtering and prioritization happening.
  • Ethics should be built in to the process: I gather that fishing boats may throw back fish that are endangered, or are below a certain size. In terms of requirements, there is perhaps a lesson for us as analysts: If we come across a requirement that we believe is unethical, we should question it.  This might sound like an odd thing to say, after all, who would raise an unethical requirement? Yet, with proposed technological transformation there might be an underrepresented group that is disproportionately affected, and perhaps this hadn’t been considered. It might be that the requirement owner had never considered the ethical consequences, and is very happy to amend or remove it once they think about the broader unintended consequences.

 

Advertisement

 

Elicitation Relies On Stakeholder Analysis

Much as elicitation and analysis are inextricably connected, there is a clear dependency on stakeholder analysis. Sometimes we might be led to believe that stakeholder analysis is a frivolous activity, after all, who has time to sit down and create stakeholder lists and models?  Yet, the reality is that it’s one of those activities that will likely save time in the future.

 

I can still vividly remember a time, very early in my business analysis career, when I was assured that a particular project I was working on didn’t require compliance sign-off. I took this at face value, didn’t do any further stakeholder analysis and went ahead. Cutting a long story short, we got to testing and found that we absolutely did need compliance sign off. That was a scary revelation, but luckily our compliance colleagues were friendly and pragmatic. With some late nights and minor changes we got the project over the line. But for me, it was a lesson learned: Proper stakeholder analysis could have avoided it entirely.

 

I’m a particular fan of the stakeholder rainbow, and the stakeholder interest intensity index. I discussed a number of stakeholder techniques in a presentation that’s available on YouTube, feel free to check that out if you’d like to know more!

 

Context And Scope Matter

Finally, it’s worth noting that elicitation which doesn’t consider context and scope is really just a Santa’s wishlist. Imagine asking everyone in an organization “what is it you want?” or “what could save you time?”. You’ll get lots of ideas, many of them actionable, but you won’t get a coherent set of ideas.

 

This probably sounds so obvious, but it’s an easy trap to fall into. As analysts, it’s easy to be so familiar with the scope and context of a project that we assume everyone knows it. Yet that’s rarely the case, so spending a few moments to outline the core objectives and outcomes can really help.

 

This also highlights another key point: It’s absolutely crucial to understand the business objectives and outcomes being sought. Trying to elicit and prioritize without knowing the outcomes is virtually impossible. How can anyone say requirement A is in scope (or not), and whether it’s more important than requirement B if there’s no clear agreement over the ultimate outcomes being sought?

 

Conclusion: Shine The Light On Elicitation

It’s easy, particularly as an experienced practitioner, to let elicitation become second nature. That is completely natural. But perhaps it is worth spending time now and again reflecting on how we elicit and whether it is still effective. Although it might not be a headline-grabbing topic, elicitation is absolutely crucial to what we all do!

Your Next Process Model’s Degree of Abstraction

Any process model is so much more than a flowchart. It is an abstraction of current or future real-world operations.

Process modeling is one of the core competencies of any capable business analyst. Both the International Institute of Business Analysis (IIBA) Business Analysis Standard[1], and the Project Management Institute (PMI) Guide to Business Analysis[2] call for certified business analysts to be capable of preparing and using process models.

Business analysts and process improvement analysts may prepare process models at key points of business process management, information technology, and regulatory compliance project methodologies. They may specify current or future functional, organizational, and information systems architectures, functional requirements, workflow designs, and even automated operations. What any process model needs to communicate will vary from one project to the next.  The highest quality process model examples provide clear, accurate process information of direct interest to their readers.

Informed business analysts know that one of the secrets to producing a high-quality process model is to establish a clear mission for each model. To be successful, you should mindfully establish the mission of your next process model within the business process management, information technology, or regulatory compliance project that the model will serve.  You will then tailor your elicitations of the model’s content and configuration to meet project needs. Part of your process model mission-setting elicitation agenda will include asking and answering this important question:

What is this model’s required degree of abstraction?[3]

There are three generally accepted degrees of abstraction to consider: conceptual, logical, and configuration.

 

A Conceptual Process Model  

A conceptual process model graphically presents the defining structure of what a process is.

Business analysts, project sponsors, project managers, domain subject matter experts, regulators, and other process stakeholders use conceptual process models, for the following purposes:

  • To make process governance and scoping decisions;
  • To gain agreement about and communicate the process’s defined scope and structure, unequivocally distinguishing that process from all others in their business;
  • To design enterprise architecture, to define technology solution architectures,
  • To be the sound foundation on which forthcoming detailed problem analysis or detailed process definition is scoped out or planned;
  • To support project management decisions (e.g. budgeting, scoping).
  • To further elicit and fit logical process details upon its sound contextual and structural foundation.

 

Some business analysts and systems analysts might interpret the term conceptual to mean “high level”. That would be an oversimplification and a mistake. To serve its purpose, a conceptual process model should unequivocally define the sound, stable structure of the process. Despite being the highest degree of abstraction, a high-quality conceptual process model is still precise.  It can clearly and graphically communicate all of these process-defining information:

  • The process’s name.
  • The process’s initiating event(s) that causes the process to be performed.
  • The process’s activities and their expected sequence of execution.
  • The process’s expected outcome(s).
  • The process’s customer(s).

 

Advertisement

 

A Logical Process Model

A logical process model elaborates contextually relevant details about how a process is required to operate, is designed to operate, or currently operates.

A high-quality logical process model could graphically, answer any of these types of how-elaborating questions:

  • The decomposition or summary of some of the process’s activities.
  • The rule-driven or decision-driven conditional work that may be performed.
  • The assigned responsibilities for performing the process’s activities.
  • The data or information required to be used and/or produced.
  • The causes of the process to be delayed or interrupted.
  • The processing errors that may occur while the process is executing, and how they will be resolved.
  • The process’s related performance or measurement data, and text-based operating procedures, documents, or other specifications.

There is a spectrum of uses for logical process models. Process owners and analysts use logical process models to determine what and where to measure an existing process’s performance or to design and communicate proposed process improvements. They also define requirements for, or the design of manual or automated procedures, or describe the design of workflows.

Competent business analysts and process analysts can anticipate, elicit and document a range of logical refinement types, using clear agendas and reusable modeling patterns[4]. They also know that no two logical process models need to communicate all of the same types of logical refinements. So they will consider the model’s mission within each project and tailor their modeling efforts to focus on eliciting and documenting the types of logical refinements that suit each model’s intended use within its project’s methodology.

 

A Process Configuration Model

A process configuration model communicates concrete implementation mechanisms such as software operations and user procedures or workflows.

A process configuration model is the lowest degree of abstraction. Business analysts and systems analysts typically prepare process configuration models in low-code and no-code software platforms. The platform consumes the process configuration model along with detailed process-related roles, security, forms, system interface, and data specifications to generate operating software, on top of an already well-rounded software product architecture. There is otherwise no or very little programmer intervention in translating the model into working software. When updates to requirements or defects emerge, the analyst revises the configuration model, and the platform regenerates and redeploys the software.

You must adopt and adhere exactly to a chosen low-code or no-code platform’s process modeling syntax. You can learn that by taking the training offered by the low-code or no-code platform’s vendor. Along with a process configuration model, you would specify, in detail:

  • System users, their assigned roles, and their responsibilities to perform the configured process flow.
  • The sequence of execution of configurable functional components, of an automated end-to-end workflow.
  • The configurable functional components involved in the process flow configuration. These are typically the user interfaces (e.g. forms, reports) system integrations (e.g. APIs), and the data attributes used in an automated process workflow.

Since process configuration models are precisely translated into operating software and business operations, any errors or omissions in the modeling become errors or omissions in the generated software and business operations.  It stands to reason that to be a successful business analyst or systems analyst in a low-code or no-code environment, you must design process configuration models based on sufficiently detailed logical requirements, that you have elicited and understood.

 

How to Choose Your Next Process Model’s Degree of Abstraction

Follow these guidelines to choose what the required degree of abstraction of your next process model will be:

Use conceptual process models to get agreement about and communicate what the process is. What is the scope? What causes it to be performed? What are the activities and their expected sequence? What is or are the expected outcome(s)? Use conceptual process models for planning, scoping, and architecture definition.

Use logical process models to get agreement and communicate how a process works or is required to work. Be prepared to elicit and document the answers to logical details such as: What are the detailed or summary activities? Who is responsible for what? What happens if? What happens when? What decisions will be made? What information is produced or used? Remember to elicit and include the details that are relevant to your model’s intended audience: those who participate in the lifecycle of your business process management or information technology project. Keep your model’s intended audience in mind when eliciting and documenting details. Use appropriately detailed logical process models for detailed functional requirements or design.

Use process configuration models to specify the configuration of concrete software modules, physical devices, and/or manual operating procedures that implement a process.

You typically use process configuration models in no-code or low-code software generation. To gain the benefits, you must specify very precise and accurate process implementation details, and exactly follow the process configuration modeling syntax.

 

Conclusion

A process model is not just a flowchart. It communicates what are, or will be, real-world operations. It may play a crucial role in the success or failure of your next business process management, information technology, or regulatory compliance project.

The most competent business analysts and process analysts clarify what their model’s required degree of abstraction will be, at the start of their analysis. They then focus their own and their project stakeholders’ efforts and time on the types of model content and format that will best suit each project’s unique needs.

You are welcome to learn more or share your comments and experiences about Your Next Process Model’s Degree of Abstraction via the Contact Us page at www.ProcessModelingAdvisor.com.

Copyright 2023, Edmund Metera
[1] The Business Analysis Standard (IIBA, November, 2022)
[2] PMI Guide to Business Analysis (PMI Inc, 2017)
[3] The Universal Process Modeling Procedure: The Practical Guide to High-Quality Business Process Models (Metera, 2018, 2022)
[4] The Universal Process Modeling Procedure: The Practical Guide To High-Quality Business Process Models Using BPMN (Metera, 2022)