Tag: Project Management

Back To Basics: Excellent Elicitation

Written by Adrian Reed on May 11, 2023. Posted in Articles.

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.

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

Written by Edmund Metera on March 15, 2023. Posted in Articles.

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).

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)

Best of BATimes: 4 Business Analyst Interview Questions And Answers To Kickstart Your Career

Written by Jimmy Rodela on November 9, 2022. Posted in Articles.

Published on November 7, 2019

If you’re just starting your career as a Business Analyst (BA),

knowing the usual types of interview questions can help you prepare to impress your potential employers.

After all, knowing the possible interview questions will help you prepare the right answers that will make you stand out from other candidates who are vying for the same position.

Although the requirements for Business Analyst positions vary depending on the company, there are a set of common questions that you’re most likely to hear in every interview.

These questions could range from a simple “Why a career in Business Analysis?” to more in-depth queries, like the kind of tools you use, so the more familiar you are with these questions, the better equipped you’ll be to ace your interviews.

To aid you on how to do just that, here are four Business Analyst interview questions and possible answers to help you prepare to leave a positive impression on your prospective companies.

Question 1. What Is The Role Of A Business Analyst In A Company?

As a business analyst, you play a crucial role in guiding businesses to improve their products, services, software, and processes through data analysis.

Plus, you can bridge the gap between IT and your employers to help boost efficiency and translate data into useful and actionable insights.

As such, you’ll need to emphasize the specific roles of business analysts. If you have experience in the field, discuss some of your previous functions with your interviewers.

Here are some of the things you can consider to help you discuss the roles of a BA.

Business analysts can take on specific roles within a company project such as System Analyst, Application Designer, Business Planner, Technical Architect, Data Analyst, etc.

If you’ve played these specific roles in the past, expound on what you did and the solutions you came up with.

The job of a BA will vary based on the requirements of your potential employer – some BA roles may be limited to IT projects, with a few extending to marketing, accounting, finance, and more.

Your primary role as a BA is to help determine the needs of your company, uncover the problems – including using predictive technology to predict future issues (to some extent) – and come up with business solutions.

Aside from technical skills, your role as a BA will require you to have a good grasp on engineering concepts, possess leadership qualities, and excellent communication skills.

Question 2. What Are The Crucial Tools For Business Analysis?

There is a wide array of tools and software that business analysts use to perform several functions required of the role.

With that said, interviewers will ask you what the crucial tools are for business analysis so they’ll know which ones you’re proficient in and what you can bring to their company.

If you are proficient with tools like MS Office, Structured Query Language (SQL), Blueprint, programming languages such as Python and R, Tableau, and more, bring them up during the interview.

Most interviewers will also ask you outrightly about the tools and the training you are certified in, but instead of going through the whole list, bring to focus a few of your most recent ones.

For instance, if you have undergone a CBAP certification training course, then discuss how it has enhanced your skills and how you can apply it to your prospective company.

Doing so helps give your potential employers an idea about your skills and proficiency, and whether or not you already have what they need or if they need to train you for specific tools.

Question 3. How Do You Handle Difficult Stakeholders?

Remember that being a Business Analyst means coming up with solutions, but you’ll also need to prepare for the possibility when your proposed solutions are met with resistance.

Many factors can contribute to this, but among the rest, human factors like – difficult stakeholders – might be one of the most challenging to handle.

Your potential employers will want to know how you can manage this type of situation since it is bound to happen in every company.

You won’t need to provide an entire outline of your answers during your actual interview, but keep these few points in mind when formulating your possible responses.

Spot your “difficult” stakeholders from the group, listen to what they have to say, and exercise a significant amount of patience.

If you cut them off or be impolite towards them, it will only lead to misunderstandings, and that will not help you resolve any of your issues.

Some stakeholders are difficult because they are not comfortable with some of the things in your project. So take the time to dig deeper into their issues by listening to what they say and answering any questions they might have.

As much as possible, meet and discuss with your difficult stakeholders personally as a way of showing them that you are committed to working towards the same goal with them.

Continuously engaging your difficult stakeholders helps them understand that their contribution is valuable to your project. Their resistance could also stem from valid points of view, so it’s crucial that you don’t just dismiss their opinions.

Keep in mind that there are no perfect answers, but being prepared for possible questions like this will always help you have concrete responses.

Question 4. Do You Have Any Questions For Me?

Asking tons of questions comes with the job of being a Business Analyst, and one of the best places to demonstrate your ability to ask relevant and insightful questions is during your interview.

This part of the interview that you can turn into a conversation by asking questions about the company, its processes, and more.

Aside from demonstrating your abilities, asking relevant questions also shows your potential employers your interest in their company, which can only help increase your chances of getting the job.

Here are a few questions that you can ask your interviewers.

“How does your company handle systems analysis, and do you have a dedicated systems analyst?”

There are companies with job postings for BAs when what they really want is a Systems Analyst/BA, so it’s best to clarify this ahead if this is not the type of role you would like to fulfill.

“Which project phases are your BAs involved with?”

If your interviewer says that business analysts are only involved in requirements, then the company might be looking for a Requirement Analyst specialist.

This might not suit you if you want to perform a deeper and wider BA role, so you should get this out of the way during the interview.

“Does your company have a central BA team, or does each function have its own BA team?”

Asking this question will help you determine whether or not there is a central team that will allow the pooling of knowledge.

Bottomline

There might not be perfect answers to your business analyst interview questions, but being prepared by learning the possible responses will help equip you for the big day.

Remember that being a business analyst means solving problems, and your interview Q&A is the first obstacle you need to overcome in a long list of challenges coming your way in a BA career.

Also Read: Business Analyst Manager Interview Questions

Did you learn something from this post? Please share this with your network if you agree. Cheers!

Best of BATimes: 4 Common Mistakes Made When Looking For Your First Business Analyst Job

Written by Paul Benn on September 22, 2022. Posted in Articles.

Published on: May 12, 2021

Often when I coach Business Analysts to land their first Business Analysis Job, I find that either they have no strategy and just throw darts and hope one of them hits the bullseye, or that they make some serious errors in how they approach it.

Darts does sometimes work, but not always (read my e-book on 13 strategies for your first Business Analysis Job) and if you do the following errors then it takes just as much wasted effort.

Let’s look at some of the common errors I see:

1. Don’t Have A Plan Or Strategy

Many prospective candidates who want to break into Business Analysis don’t have a strategy or plan. They send their CVs out to every job ad that mentions Business Analysis.

The first thing I look for when I get CVs for job ads is if the person takes the time to match his/her skills and CV to the position they are applying for.

A successful business strategy comes down to the following. First, what are your goals? Getting a job as a Business Analyst isn’t a SMART goal.

If we think of SMART then it comes to the A – achievable ask yourself is this achievable i.e. are you accountable for it.

I think it is important to have a goal you are accountable to achieve, no one else. Getting a job isn’t entirely in your control, is it? Someone else has to agree to it, and you don’t have that authority.

An appropriate goal would be something like:

“I will engage at least x recruiters per week with my CV”, or

“I will spend at least x hours a week looking for Business Analysis jobs that match my skill set”.

So let’s test those two through SMART:

S (Specific) – Yes, I am specific about what I wish to achieve.

M (Measurable) – Yes, I can measure how many

A (Achievable) – Yes, because I am responsible for them.

R(Realistic) – Yes, I can do either one.

T (Timeous) – They follow a schedule.

2. Your Resume Or CV Makes You Sound Like You Know You Know What A Business Does – Not That You Can Do The Job

When receiving a CV, I also look at it to determine if it seems like the person has a good understanding of what a Business Analyst does and if their experiences on the CV reflect that.

You don’t have to actually work as a Business Analyst to have real Business Analysis experience. You can have it regardless of what you do.

So I am looking at the title. Even the BABOK 3.0 says it is not about the title but the tasks when defining what a Business Analyst is.

It is the skills, the experiences, and the tasks and related activities that a candidate performed in that role that speak to their understanding of a Business Analyst, and that even the candidate can recognize the tasks they have performed that are applicable to a Business Analyst.

A few weeks ago, I was talking to an employer and they told me about how many CVs they are rejecting just because the CV does not position a candidate with relevant Business Analysis task experience.

3. Your CV Must Speak The Language Of The Job You’re Applying For

You putting job before experience and not experience before job

A few days ago I was coaching a client who wanted to become a Business Analyst. They are in a non-Business Analyst role. I was trying to find out how much experience they have in tasks related to Business Analysis.

I asked what I could do to fill the gaps of experience. He said there are none and I will wait until I have a Business Analysis job to acquire the experience.

Here is the problem. Employers value experience. It is no different in any job application. Even doctors have to go through a community service program before they are allowed as practicing doctors.

You must embrace it, so think about how you can gain relevant experience at your current location.

I love the saying “We grow into opportunity”. Apply the skills now and learn, gain experience, and reflect that on your CV. Then the opportunity will come.

4. Focus On Certification

As a member of the IIBA, and CBAP certified individual, you are probably raising your eyebrows. Let me explain.

Certifying yourself is one good way to learn about Business Analysis, gain accreditation with peers, and boost your confidence. Yes, it does play a role in getting a job.

However, for an entrant in Business Analysis you must understand that employers want experience foremost. A certification doesn’t give you that. Just like a degree doesn’t give experience, it gives knowledge.

Do the certification to gain knowledge that you can apply to gain experience. Back to having the right goals again.

You need to put in the time and have SMART goals that you can achieve. Then, your strategy flows from there. It’s not an overnight thing either. Work at it, and adjust your strategy as you go.

When you have worked hard for your first opportunity, it will come.

For more strategies download my free e-book “13 strategies to getting your first Business Analysis job” – https://www.altitudejourney.com/ba-career-starter

A Picture Is Worth A Thousand Words

Written by Timothy Figueroa on September 15, 2022. Posted in Articles.

Many customer requests are complicated, involving complete end-to-end solutions. In many cases adding to the complexity is that these solutions must be integrated into an existing system. This article focuses on complex requests and the value of use of experience design tools to support the BA in meeting customer goals.

For the BA to demonstrate understanding of a request, work at speed, and gain consensus, the BA approach to elicitation matters.

The BA approach should support continuous communications, speedy responses, common understanding, risk mitigation and collaboration across distance and time. In the case of complex requests where the analyst writes detailed requirements up front, this may in fact result in miscommunications, reduced speed, and restrained collaboration. Most customers are business managers where an approach that generates upfront details may overwhelm the customer and obscure the view of the end-to-end solution putting the customer and BA in a “can’t see the forest from the tree’s” scenario.

Approach selection typically determines how efficiently and effectively the BA meets the customers’ need which in most cases is to demonstrate to the customer “you heard me”, “show me what I requested”, and “prove progress toward a solution, a road map”. IIBA’s BABOK defines knowledge areas containing strategies, guidelines, and techniques that provide an array of approaches to elicitation.

One efficient technique is the use of a prototype. It is said, “A picture is worth a thousand words”. Prototyping is a proven method for product design and helps a great deal in providing an early model of the final result.

Prototyping, in this case, will highlight the use of experience design tools for web and mobile apps in support of elicitation activities for complex requests. Complex requests are an indicator for the use of prototypes.

The use of an experience design tool is typically cloud-based supporting collaboration and communications. These types of tools as well support a big picture view giving the customer the ability to experience what the solution might be without the time and development expense.

Users do not experience database, integrations, or technical details. They are impacted by them, however, the user experiences UI’s, workflows, processes, features, and functions. Prototypes encourage common understanding by supporting the ability of the customer to walk through the solution model that incorporates UI’s, processes, workflows and features and functions.

There are several industry leading experience design tools that support solution prototyping. This article will not detail specific tools, rather it is to focus on the value of the use of these tools in satisfying complex business requests. Experience Design tools provide the ability for the business analyst to document requirements in the form of a prototype as described by the customer. The value of an experience design tool is that it supports the BA’s ability to create a simulated solution that,

The customers may walk through, make comments, suggest changes, discover the unexpected, use for demonstration purposes and more…
The technical team as well may walk through the proposed solution asking questions, making suggestions, prioritizing work, planning technical details, and coming to a common agreement using the additional documented requirements.
The BA can plan and write the requirements from the customer-approved prototype without leaving out any details. The prototype assets (i.e., UI’s, processes etc.) can be reused in the documented requirements to provide the needed details.

In conclusion, experience design tools can reduce misunderstanding, encourage communications and collaboration, support progress, and more. Consider adding experience design tool skills to your BA toolbox. A picture is undoubtedly worth a thousand words!