Tag: Elicitation

The importance of understanding value

Written by Annabel Russell on September 29, 2021. Posted in Articles.

Every company has many competing ideas on projects which need to be fulfilled in order to run successfully. Departments will usually get a budget and at times try to deliver as many items as possible, in order to say they have been completed. But are the correct items/functions/projects being delivered to really drive value to the customer and/or business?

In working in multiple companies over the years, I have seen many ways of deciding on priorities from who screams loudest to very formal detailed business plans being put forward explaining the rational behind the ask.

When prioritizing one key element we must understand is what value we are adding to the customer or the business by delivering the item.

Value statements are a great tool to clearly define the outcome of the item being delivered. One useful technique to really get stakeholders to think about value is writing SMART (Specific, Measurable, Achievable, Realistic and Timebound) objectives. Instead of writing “We will increase revenue” the new value statement will read “We will increase revenue of the whitening toothpaste product by 2% over the 12 months following implementation of a rotation pane on the toothpaste description page”.

While this seems like a relatively straightforward and logical tool, the fact is, some companies still do not follow this practice of clearly defining value and there are many reasons for this, which can include:

Stakeholders or product owners may not be comfortable to stand over quantified data
Stakeholders not believing in the idea but have been asked to progress the idea
The data may not be available in the company easily enough for stakeholders to quantify
A culture of blame, funding cuts or sidelining careers if the targets are not met

When value is not fully outlined and decisions are made based on feeling, this can lead to:

Items being delivered which are not adding value
Items being creating which are not required and could be culled causing waste
Potentially higher support and maintenance costs for items not required
Implementation costs of items not required
Loss of customers/revenue by not implementing needed functionality

Furthermore, value needs to be defined from the outset in order to measure success/failure of the implementation after the time period stated in the objective. Without this measure there is no way to gauge if the item really added value.

Is There Such A Thing as a “Dumb Question”?

Written by Jake Thompson on August 26, 2021. Posted in Articles.

“This may sound like a dumb question…but…,” insert question here.

What prompts us to preamble a question with such a statement? We tend to dwell on the fear that asking questions, even the simplest or for clarification can be the inception of negative thought and appearing uneducated to our peers. One of my colleagues when I first began the role of business analysis reassured me that there is “no such thing as a dumb question.” However, I write this piece to dissuade the notion.

Working with myriad stakeholders and colleagues, as business analysts, remaining consistently curious is a fundamental competency to our field. How must we satiate our endless curiosity? Ask questions! As part of the lexicon to being a business analyst, questions are the lifeblood to the capacity of the work we perform. Executing a swift Google search on “how many questions do we ask a day?” the quantitative results for adults are estimated to be averaged at twenty questions per day, whereas children are in the hundreds a day. Hundreds! Notwithstanding those children may have an ulterior agenda to ask numerous questions, whether it be to annoy their parents out of humor or they’re truly curious, the comparison of frequency in questions is staggering. Yet, we focus less on the quantitative nature and more on the qualitative aspects to feeding our inquisitive intellects.

Is there really such a thing as a dumb question? Drum roll, please. The answer is: yes. You may or may not already know the answer, others may not. Questions that are asked for clarification, for understanding, to ask why to ask how? Those are not dumb questions. In fact, I would quantify those in a simple self-designed model of asking questions as baseline questions. Breaking down the model, for business analysis, or even real-world application, questions can be categorized into four different sections, dependent on the question objective. The question objective is the “why” of your question; what you are seeking to accomplish by asking. The dumb questions, in short, are the ones you do not ask. Silence may be golden in some realms, but if you are remaining silent to avoid asking questions to clarify, to gain a deeper understanding, or even to consider another outcome, that is the underlying “dumb question.”

If you refer to Exhibit 1 provided in this article, it pictorially represents my personal model of how one may categorize questions in four different quantifications. These are: great questions, good questions, baseline questions, and dumb questions.

Exhibit 1:

Great questions are the ones we ask to discover new possibilities or outcomes. The trademark piece to being a business analyst via elicitation. These ones may be framed in ways of detailed, technical questions but the objective remains to discover what may be unseen or overlooked. They also require an incredible amount of effort in terms of research and critical thinking. You may be surprised at the sheer volume of information that can be elicited from asking a great question versus some of the others. Great questions are the cornerstone questions for a business analyst.

Good questions are the step below the great questions. These are critical, nonetheless, but have an objective to challenge assumptions, restrictions, or dependencies within projects or the task at hand. These may require an intermediate level of research or critical thinking and forward consideration to come up with. These may be your “why” questions. Much like great questions, the voluminous amount of data by asking good questions can sow benefits to be reaped in business analysis. Good questions can be the framework between the baseline questions and great questions, where the details are in between the lines.

Baseline questions are as the name implies: intended to set the baseline. These are questions that can be asked for clarification or understanding. These are just as important as any of the others and contain significance in the realm of business analysis. Baseline questions give you that foundation that opens the realm to the categories to inquiring more questions. Rest assured, there is absolutely nothing incorrect about asking baseline questions. It may open the door to good or even great questions by asking the most basic baseline question.

The next time you find yourself in a position, as a business analyst, or elsewhere, determining if you should ask the question, follow these steps. First, remember the only dumb question is the one you do not ask. Two, ask the question! Do not let fear or negative emotion impede your learning as a business analyst and the potential to open doors that may have been left untouched. It is not something that can be learned overnight but over time. Even I, myself, am still working to ask questions in my role, baseline, good, or great, and mitigating the dumb question.

In case of emergency of not knowing…just ask!

Where To Start with an Entity Relationship Diagram

Written by Colin Savage on June 30, 2021. Posted in Articles.

In my previous article An Entity Relationship Diagram Isn’t Just For Database Design I talked about the usefulness of Entity Relationship Diagrams.

Richard Larson did an excellent overview of some of the more technical considerations when putting together an ERD For The Love Of Data

But one of my colleagues recently asked me for help, as they hadn’t done one before and weren’t even sure where to start. If you’ve no experience of putting together an entity relationship diagram, it can be quite daunting to take that first step.

As a consequence, I’ve put this together for the benefit of those who fall more into that “where do I start?” category, and to explain how you might start to document your ERD.

A Checklist for Business Analysis Planning

Written by Edmund Metera on February 18, 2021. Posted in Articles.

Use the Universal Business Analysis Planning Checklist as You Plan Your Business Analysis Approach.

Every project is a unique, temporary endeavor.

The business process management, regulatory compliance and digital transformation projects that business analysts may play a role in all come with different goals, scopes, teams, timelines, budgets dependencies and risks. Though many projects follow similar methodologies they are all tailored for project scope constraints and to take advantage of available resources, opportunities and lessons learned from prior work.

Each business analyst also comes with a unique set of skills and experiences. Almost all business analysts have great communications skills and at least some experience-based business domain knowledge. That’s why they became business analysts in the first place. Every business analyst has uniquely acquired knowledge of business analysis techniques and business domains through personal study, practice and experience. Many have also been trained in elicitation, requirements management, modeling, measurement, analysis and documentation techniques. An ever-growing number have received professional certifications, such as the IIBA Certified Business Analysis Professional (CBAP) or the PMI Professional in Business Analysis (PMI-PBA).

What is Business Analysis Planning?

The most skilled business analysts are not only competent in many business analysis techniques but also consciously tailor their business analysis approach for each project that they engage in. They have learned to consider key project dynamics along with their own competencies and to tailor their planned business activities and deliverables to suit each project’s unique dynamics. Regardless of your own level of business analysis experience, maturity, and whether you are formally trained, certified or not, you can still consciously assess each project’s dynamics and tailor your forthcoming business analysis work to get the most productivity and value out of your business analysis efforts in each project.

The most significant project dynamics include:

The methodology, or sequence of stages or major milestones, and the business analysis products or outcomes that are expected by the end of each stage/milestone (and before starting the next).
The budget and schedule, not only to meet them, but to take advantage of contingency or schedule slack opportunities, to increase the value, quality or to learn.
The key project stakeholders and relationships that are new and changed and forming, to take a proactive role in fostering and building relationships with and among that team.
The types and combinations of elicitation techniques that will be best suited for producing or validating business analysis deliverables.
The business domain knowledge and experiences of the diverse key project stakeholders, including your own unique set of business analysis competencies.

The Universal Business Analysis Planning Checklist

You can be more effective in planning your business analysis approach if you follow a consistent, clear agenda that considers the common project dynamics.

The Universal Business Analysis Approach Planning Checklist covers the most common project dynamics. You can use this as an agenda to elicit and discover a comprehensive view of a project’s key dynamics, its opportunities and use what you discover to adapt/tailor your business analysis approach.

As an exercise, think of a project that you have recently worked on, you are currently working on, or will soon be working on. Answer questions in the following checklist for yourself.

Project Life Cycle

What are the planned stages of this project?
What stage are we currently in?
What is the business analysis deliverable (or set of deliverables) that I am responsible for producing in this stage?
What is the intended use of my business analysis deliverable(s) and who will use it?

Schedule and Effort Budget

How much effort can I spend and by what target date am I expected to produce my business analysis deliverable(s)?
Is that about what I also estimate it will take?
Is either my effort or date estimate higher than the effort budget or target date? If so, how might I adapt my effort, scope, activities or configuration of my deliverable(s)?

Project Stakeholders and Relationships

What are the key roles is on the project team and who is in them?
- Does this project have an executive sponsor, project owner or product owner, project manager, specialists and business subject matter experts?
- What are the names and titles the persons in these project roles?
Are significantly new relationships being are created in this project?
- Who’s new to each other on this team?
- Are there local and who’s remote team members?
What are peoples’ responsibilities?
- Who is responsible for producing, accepting or needs to be consulted or informed of each of the project’s key deliverables, particularly the business analysis deliverable(s)?

Elicitation Techniques

Which elicitation techniques are available to me use?
- Documentation Reviews – What documentation or prior work products are available to review?
- Interviews and Workshops – Who can I interview or include in a workshop, and what questions would I need to ask?
- Observations – Where and what kinds of observations may be needed and how could I arrange for them?
- System reviews – What system(s) are available to review and for what information?
- Surveys – Who could I engage in a survey and using what types of questions?
What are my own business analysis competencies?
- Considering this project’s stakeholders and relationships, the elicitation techniques available to me, and my own core competencies, which elicitation techniques are best suited gather and validate my business analysis information?

Organizational Assets

What specialized tools for elicitation, documentation and modeling are available to me?
- Collaboration tools, facilities, survey tools?
- Diagramming or modeling software?
What prior business analysis work (e.g., documents, models) that I can draw from?
Does my organization offer training in the subject business domain?

Competencies and Knowledge

Who on the project team has what expert business domain knowledge?
What is my own business domain knowledge?
What are my strongest core business analysis competencies?
Where can you take advantage the team’s diversity of knowledge and competencies?
Who are the best stakeholders in this project to engage in elicitation of content or validation of business analysis deliverables and what is or are the best elicitation techniques to use?

On reflection, are you able to answer these questions for yourself? When you go into your project workplace, who will you include in this conversation?

Conclusion:

Business analysis planning is a recognized business analysis activity. The IIBA Body of Knowledge (BoK) includes the Plan Business Analysis Approach activity within its Business Analysis Planning and Management process. The BoK also lays out the scope of what should be covered by a Business Analysis Approach as “The set of processes, templates, and activities that will be used to perform business analysis in a specific context.”

The time and formality that you apply to business analysis planning is up to you. At the financial institution where I work as a project and program manager, our business analysts typically tailor and document a business analysis plan for each new project to which they are assigned.

I think of business analysis planning as a form of insurance. Spend a little time upfront to assure that the bulk of the rest of your business analysis efforts will be as well spent and effective as possible. Expect the benefits of tailoring a business analysis plan for every project to be that:

It will help you to align your own core business analysis competencies to each project, and
You and the project will gain the most value from your business analysis efforts.

That’s a value-adding proposition.
You are welcome to contribute comments about project dynamics that impact business analysis plans or about the checklist presented through the Contact Us page at www.ProcessModelingAdvisor.com.

How to Figure the Detail of Process Models

Written by Jamie Champagne on July 24, 2020. Posted in Articles. 2 Comments on How to Figure the Detail of Process Models

I love that a fellow analyst asked me a question as they were having trouble being asked about putting “narrative on their process model.”

We started with the first question – WHY? Simple, yet seriously, we’re so good at OVER analyzing and getting into analysis paralysis that sometimes just trying to figure out what is going on can save others (but especially us!) LOTS of valuable time!

With the first question, the answer was easy – they want more information. Okay, so then the next questions is then about what the PURPOSE of the model is? What are you trying to accomplish with your process model?

Good foundational, IIBA® BABOK® Guide v3 (2015) states that the purpose of process modeling is to provide a “standardized graphical model…to show how work is carried out…as foundation for process analysis.” So are we showing ONLY how work is carried out? Or are your stakeholders asking for much more?

We have data models and stakeholder RACI matrices and other valuable tools because they’re great at what they’re used for! They each have their own purpose! So ask yourself if you’re ever having difficulty with your process model because you’re trying to do WAY more than model a process?

This is the analysis skill – identify what questions are being asked or needing to be answered and facilitate getting that information to the needed decision makers. If people ask lots of questions about who is doing what on your process, then maybe we do need greater detail on the stakeholder ownership. Perhaps there is no ownership? Or don’t overanalyze and just add a new swim lane if it makes the users happy (and of course understand better!). If people ask lots of questions that revolve around data, do we need a data dictionary and some data modeling or data flow diagrams? This is common when you meet with stakeholders of different levels of focus. Too often process steps, decision points, data elements, stakeholders and end products are thrown at the analyst. Do not feel compelled to write everything on the process model. Write PROCESS on the process model and make notes on the side. Then look at your notes. Are all the notes about data? Then your own notes tell you that you need some data definition. And don’t be afraid to acknowledge that there’s a mix of high-level overview requests mixed in with the “give me the technical details down to the line of code” demands. Just then make your model flow so that each view or screen or page is only showing ONE level. Then with technology today just link it to the page with the lower level of detail. Don’t over complicate it trying to take a full course on modeling software or anything. Simply list high level functions with overall business areas on your main page. Then for each one of those functions, create a “clean page” with just that function’s information. And then you can work WITH your stakeholders to define as much information as they at that deeper level, while keeping everyone on the same page at that higher level. Even better, with this approach, you just created a strategic, overview perspective as well as tactical or operational details. Now you’ve helped multiple groups from starting with a single model!

See what information comes up from the stakeholders on what is missing or needs to be added to make the process model USABLE. You are creating a process model for OTHERS to use. If the level of detail is high and you’re not sure it’ll work – ask! Share it out and see if people have questions. If they have none, then you’ve done what is needed to help others get things done! Analysts process model to facilitate, not own. The model is the stakeholders’, teams’ or client’s. It’s for them to get their work done, complete projects and create great new products. If they ask lots of questions, then help them get the answers. And as you do, always think what is the most efficient and effective way I can get them the answers. Just because they want all the information on the same visual, does not mean that it will help them answer their questions. But to know what to capture appropriately on process models, means you need to know what everyone is trying to accomplish by using your process model. Make it an actionable document. Anything you produce should be reusable over and over again – from decision making to operations and troubleshooting – and by people other than you! That’s the true value!

So next time someone tells you that your process model is lacking lots of information or needs other data and elements added, ask why and get clarity on the stakeholder’s need and what they hope to accomplish WITH your model. Then work with them to help develop a model that answers their questions and supports their decision making.