Tag: Tools

The Wide World of Stakeholder Approvals

Written by Tom McIntire on August 17, 2017. Posted in Articles. 1 Comment on The Wide World of Stakeholder Approvals

I have found that the simplest tasks or gates within an SDLC (System Development Life Cycle) can often be the most stressful.

One of these tasks in particular has left me frustrated beyond belief at times. I’m speaking about, of course, Stakeholder Approvals on Requirements. Let’s look at the following scenario:

As a project team, we have completed the requirements gathering process, we have answered any outstanding questions, we have documented the requirements thoroughly, we have had a walkthrough of the requirements, and the approval session and timelines has been established. Approvals should be obtained well within the time frame.

WRONG! Only in a perfect storm would this occur.

Often times as BA’s we have to battle different personalities that can hinder the approval process and cause delays.

The Part Timers

These are stakeholders that glance over the requirements and approves without reading in full detail. This can create more work later in the project life cycle as requirement may have been overlooked or stated incorrectly and will need to be corrected and reapproved.

Try to express to these stakeholders during the kickoff and reiterate during the requirements process how important it is to fully review everything. If you feel that they are not fully committed ask if they would rather be a reviewer and delegate their approval to another stakeholder.

The Bewildered

Initially, these stakeholders understand the requirements during the elicitation process, but when review and approval time comes around they do not understand the requirements as they are presented during the review and approval process.

It is important for all stakeholders to understand the requirements, so it is your job as a BA to confirm this. If they are unprepared for a review meeting and they are challenging every question, try cancelling the meeting until they are prepared; this can really only be achieved if it is a one-on-one review or just a couple of people. If there is a larger group attending the review, ask the person to hold their questions and have a side meeting with them to cover the requirements so they fully understand. Don’t ignore the situation. There may be a viable reason the person doesn’t understand. Perhaps someone else doesn’t understand either, so you may have to clarify your requirements.

The Late to the Party Stakeholders

These types of stakeholders wait until the absolute last minute to provide feedback and/or approval on requirements. I particularly find it extremely difficult to work with this personality type the most. However, I have developed a few ways to overcome the problems BA’s face .

Be in frequent contact with them. It may seem like you are bombarding them with phone calls, emails, or personal interactions, but it is important for them to know how important this process is to you and the company.

Another technique is to set the review deadline date ahead of the stakeholder approval date. This way the stakeholder will review the material by the deadline and there will be time available to answer questions and make updates prior to the “actual” approval date.

Lastly, if push comes to shove, ask yourself: Does this stakeholder need to approve the requirements?

Is there someone else that can step in and approve for them? Often times In these situations I find myself asking these questions. If there are multiple people from the same department on the review and the one with the approval role is not timely I will notify he or she along with their manager that I will remove their approval role by a certain date and move forward with the approval from a reviewer role member from the same department. The initial response may be negative, but if the stakeholder in question is constantly missing deadlines there are few options.

The Flip-floppers

Flip-flopper is a phrase that has been coined in recently Presidential elections. A flip-flopper is stakeholder that keeps changing their minds on requirements and often at the last minute. Try reviewing the requirements in a power workshop that leads up to the final review session. In this setting the stakeholder feels more involved in the process and if questions arise then they will be brought up sooner and can be handled properly. No more last-minute change controls for additional time on the project. A side meeting may be needed to go over requirements and questions in detail.

The Grammar Police

We all know this stakeholder. Don’t misunderstand me. Grammar is important. We should not provide documented requirements that are full of grammatical errors and misspellings. However, should the approval on requirements be delayed due to a couple misspellings? No. Small grammatical errors can be resolved after the approval and be noted as such if ever questioned on what changed. Express your concerns for the timeliness and deadlines of the project. Examine with the stakeholder if the concept of the context is correct and how perhaps all the wordsmithing isn’t always necessary.

The Noobs

These stakeholders are new to the project by either replacing a current stakeholder or a new resource was needed over an area of the requirements. Initially, you may not have complete buy in to the project and if they have to approve requirements this stakeholder will have lots of questions that will slow down the approval process. To remedy this situation, cover in great detail the benefits of the project. This way they will see value in what the core group is doing and the solution in general. It is important to work alongside with the project manager during this process in order to provide a solid front line against any speculation.

Where do we go from here?

Communication is the key aspect of dealing with these various personality types. If communication breaks down, then the project is going down in flames. The advancement in technology has often made us “lazy” in the sense that we no longer speak to stakeholders face-to-face or over the phone. We rely on email, text messages, or software applications that provide automatic updates to stakeholders which can often get over looked or ignored. Pick up a phone or set up a quick meeting to discuss. If we, as BA’s, can effectively communicate the goals and expectations then every stakeholder should be held accountable for their actions or lack thereof.

Business Analysis Canvas, Roadmap to Effective BA excellence.

Written by Jason Kelly on August 10, 2017. Posted in Articles. 92 Comments on Business Analysis Canvas, Roadmap to Effective BA excellence.

Business Analysis and the role it plays has evolved over time as organizations strive towards refinement, improvement, and optimization.

A Business Analyst is someone whose role and function is ever changing with organizational evolution. The pace of change has increased over the last few years as more and more organizations shift towards a technology enabled future. Technology does provide the opportunity to harness efficiencies in process automation/removal as well as improved speed to change.

To allow for the change it is important for the organization to understand the pivotal role the Business Analyst plays within the realization of organizational development.

The Business Analyst role has developed into a mix of an internal consultant to a financial expert. When I consider the Business Analyst it is with the mindset of an internal consultant supporting the organization throughout the project life cycle.

With this said, I propose the following definition of Business Analyst:

“A business analyst is someone who analyzes and documents business, processes or systems. Assesses and recommending the business model or its integration with technology.”

There were a number of key questions posed whilst conducting research:

What are the key questions Business Analysts need to ask?
How can a Business Analysis plan be effectively communicated?
What supporting documentation would assist all Business Analysts?
How can a book become a playbook to support current and future needs of Business Analysts?

Extensive research, personal experience, group work, and collaboration have answered these questions. Each section of this book seeks out to provide insight to the Business Analysis activities to support the Business Analyst complete their duties more efficiently.

CANVAS

The CANVAS is not a magic pill that will resolve all your Business Analysis concerns/issues. It is a flexible approach to complex matters.

That sounds rather grand, what is meant by this statement is the fact that the CANVAS is a robust or troubleshooting tool that can be applied to the most complex of Business Analysis activities in a simple, yet refined manner. The CANVAS is repeatable and easy to share with subject matter experts (SME’s) and other stakeholders.

There are some suggested questions in the sections to follow that will help you build our your Canvas for sharing and communicating with project stakeholders.

Section – Project Objectives

What are the high-level expectations of the project?
What is the project trying to change/improve/remove?
Is this project part of a larger program, if yes, what is the expectation of the program?
Has there been a project plan development for all project activity (beyond Business Analysis activity)?
Is the business edging towards a specific outcome (try to identify embedded bias within the organization)?
What systems/processes are affected by this project engagement?

Section – Stakeholders

Who are the Stakeholder groups affected by this project?
Where are these Stakeholder groups located?
How complex is each Stakeholder group?
What is the Attitude / Influence of each Stakeholder?
What is the impact of the project on each Stakeholder?
What is the Decision-making Authority of each Stakeholder?

Section – Deliverables

What is the Deliverable key area(s)?
How detailed is the Deliverable required to be?
Is there an opportunity to review previous Deliverables?
What is the approval/sign off expectations for each Deliverable?
What is the sequence of the Deliverables (if more than one)?
What are project dependencies aligned to each Deliverable?

Section – Communication Approach

Who needs to be communicated?
What does each group need to understand in the communication?
What form does each group require?
Who is the owner of this communication transmission?
How often does each communication need to be sent?
Is this communication part of the larger project communication approach?

Section – Key Dates

What is the overall project completion date?
What is the sequence of the project (key tasks/phases)?
When do we expect each key task/phase to be completed?
What are the elements of the key tasks/phases relating to Business Analysis activity?
When is the Business Analysis resource expected to be off boarded from the project?
What is the expected Business Analysis resource availability/allocation on the overall project?

Section – Responsibilities

Who is the project sponsor and steering committee (if available)?
Who are the SME identified for each key Business Analysis Activity?
What are business units in which the Business Analysis activities will take place?
Who are the Talent allocated to the Business Analysis project (who is doing work and producing deliverables)?
Who is accountable for the overall deliverables / Business Analysis Activity and does this person(s) change depending upon the deliverable?

Section – Target Operating Model (TOM)

PEOPLE QUESTIONS –

Will the project affect staffing hours of operating?
Will labor structure change (number of people required to complete the role(s))?
Does the skills/capabilities of the resource base change?

PROCESS QUESTIONS

What processes are effected within the future state?
How do these processes change the overall organization value stream?
What are the process dependencies?
What is the customer journey impacts of the change to process?

TECHNOLOGY QUESTIONS –

Which Legacy systems will be impacted by the change?
How is the enterprise architecture impacted by the project activity?
What are the process touch points impacted with technology changes?

Section – Scheduling

How long is the Business Analysis project activity (i.e. when is it starting and expected completed date)
What resources are available to support the Business Analysis activity?
What percentage of the time are these resources allocated to the Business Analysis specific activity (be mindful the resource may be working on other elements of the project beyond the Business Analyst activity)?
What are the deliverables or their sequence?

Explore more of the Business Analysis Canvas:

The Business Analysis Canvas has been designed to quickly be adapted to meet your project needs. The questions help guide the Business Analysis through the steps of gathering and completing the information required to effectively kick off the Business Analysis project.

You can explore more of the CANVAS by downloading CANVAS templates, tools, PowerPoint side decks and additional information from www.BusinessAnalysisCanvas.com

Surviving as a Business Analyst in a Product-Centric world

Written by Faisal Jumriani on July 27, 2017. Posted in Articles.

According to the IIBA, “a Business Analyst (BA) enables change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.”

However, Business Analysts (BA) are often viewed as simply requirement recording machines. Agile methodologies have allowed the BA role to evolve, by limiting the focus on documentation. However, the next step in the evolution of Business Analysts is to don a product management hat to develop stable, scalable and innovative solutions. Here I outline a guide to help analysts create more elegant, effective, creative and expansive solutions using a product-centric approach by keeping the user and business as the core focus.

What If

As usual, you want to start with identifying the needs of your users by articulating and framing the need statements. If you are working on a new product, outline “what if” statements, which test the status quo, such as for e.g. “what if our customers can access their medical records on the go.” These questions enable you to think outside of your constraints and leave you open to all possibilities. Put together multiple statements with your team and consider these your hypotheses. Make sure you involve your stakeholders from the beginning, so you don’t have to convince them for approvals later. With each statement, ask yourself:

Does this help you maximize the impact?
Does the situation work in multiple contexts?

You can use this worksheet to complete your “What If” statements.

Make First, Document Second

Make first, document second may sound counter-intuitive, especially if you are a seasoned BA who is coming from waterfall background; but you don’t have to document anything at the moment. Once you are done with your “what if” statements, create prototypes that will validate your hypotheses. Prototyping is a great way to make your idea tangible. You can get quick feedback from your end-users to help you with capturing acceptance criteria and use-cases. It can also help you get buy-in from stakeholders, who would be convinced by working software. Your prototype doesn’t have to be a finished product. It can range from an image, wire frame, digital mock-up or storyboard that would help you communicate your idea to the end-user.

Just make sure you observe how your end-users are getting engaged with it and what questions it generates. You can use this worksheet to guide you with capturing the necessary data. Capturing this data will help you immensely with your requirements documentation as well since it will be insight driven and you can determine possible use cases as you observe their interactions with the prototype. You can capture your learning on Typeform, Google Forms or Murals. Some of the tools that can come handy for prototyping are POP, Proto.io, or Sketch.

Go Out of the Building

We usually are sitting in front of our screens, playing around with the current systems, creating diagrams and defining processes. This may be effective when we know what we need. Going out of the building is a metaphor used to test your hypothesis with actual users to understand their pain points and get a perspective of the environment your solution will be used in. Connect with your users and ask them, if they would use your product/service and give them your prototype to play around with. Keep a close eye on them while they are playing with your product. Remember you are just validating your hypothesis, so don’t be biased towards it.

Refine and Prioritize

Once you know you have the pain points and solution defined, take a step back and assess the merits of your solutions by questioning the impact of it and what resources would it require to be implemented. This would allow you to get a sense of direction and have a product roadmap by the end. You can connect each concept and feature with a specific set of goals that the solution would achieve for your organization by answering the following three questions:

Viability: If it addresses the long-term strategic goal of the business.
Desirability: If it provides value to the end user.
Feasibility: If it will be viable to develop and what resources would be required.

This worksheet will help you prioritize, refine and put solutions in perspective.

Once you have these questions answered, you will be able to start from the top and implement these features one by one. Our job as business analysts doesn’t end in the solution phase. We need to be engaged continuously in the process to assess the usage of the solution and how it is impacting the business.

The Use Case and I – My 10-Year Journey

Written by Michelle Green on July 5, 2017. Posted in Articles.

I’ve been a BA for nineteen years, and it wasn’t until about ten years ago that I met my first Use Case.

Since then I’ve used use cases in different ways for different types of project efforts. I’ve used them for:

As stand-alone requirements
As a supplement to stakeholder requirements
As a vision and scope communication tool
As functional requirements

In this article, I’ll be taking you through my journey with Use Cases in the hope that you might gain a better understanding of what use cases can do for you. I’m not saying that any of these approaches is right for everyone or even work all the time, but learning is an evolution. I live by the Brian Tracy quote, “You can only grow if you’re willing to feel awkward and uncomfortable when you try something new.”

Stand Alone Requirements

Ten years ago, we were picking up a new automated workflow system to replace an outdated product. An independent consultant was brought in to help our newly formed Business Process Office (BPO) determine some standards and processes they wanted to use within their organization. The objective was to learn how to identify, document, and select business processes that were good candidates for automation. I was brought in to learn the new processes and help identify ways that the company’s Business Analysts and the new BPO Subject Matter Experts (SME) could work together with the system developers as one team. One of the tools the consultant recommended to capture workflow automation requirements was a Use Case Specification Document, including, among other things the Use Case Diagram and Use Case Narrative.

It was an “Ah-Ha” Moment. I had never used use cases before, but I could tell right away that it was going to be the start of a beautiful friendship! I had finally found something that the business and the technical team could both relate to while representing the voice of the customer.

During the next couple years, we used a Use Case Specification Document as our sole requirements document for all things “automated workflow.” In hindsight, this approach only worked well because we were developing workflow automation. Business SMEs were the workflow designers, business analysts were working with them during use case development, and the technical resources were active team members for the entirety of the project. We weren’t working within an agile framework, but the co-located team principal and light documentation concept applied.

Supplement to Stakeholder Requirements

Flash forward a couple of years. The BPO had grown and was now engaged in most business projects that involved workflow enhancements. They were comfortable with use cases, but we had a project where use cases alone weren’t enough. We agreed to attach the use cases to the Business Requirements Document (BRD) and trace to them in the stakeholder requirements. Functional requirements were then written and traced back to the Stakeholder requirements.

During System Integration Testing we noticed some inconsistencies in expectations. What we found was that although many of the stakeholder requirements traced back to the use cases, the programmers were concentrating on delivering on the functional requirements, ignoring the higher-level detail. They had only looked at the use cases the first time they reviewed the Business Requirements Document (BRD) and didn’t follow the traceability all the way through. They considered them as a guide rather than an expectation. There was not cohesive understanding of the purpose of the use case.

Here’s the lesson we learned: If I could do that project over again, I would have included the use cases in the functional requirements and highlighted the purpose they provide.

Vision and Scope Communication Tool

I was paired with a Project Manager (PM) and Solutions Architect (SA) to work with a business unit to determine a high-level scope of a project for making a buy versus build decision. The goal was to replace an existing user interface system with one that could handle more complex business rules. We were on a tight deadline and every day counted.

In the first Joint Application Development (JAD) session it became obvious the business had a very clear vision for the system capabilities. It was also evident that the architect did not fully understand the scope of the request to determine what technology should be considered. We only had days to present options and t-shirt sizes to our sponsor. I needed to quickly achieve a joint understanding of the vision and scope and communicate it effectively to both the business team and the solutions architect.

Then it hit me. I could create a vision use case. Writing the use case at a high-level, I was able to insert existing system interfaces (which could potentially be re-used), show exceptions, and get a business agreement that the use case met their expectations for the new system. I took the use case to the architect, and we walked through it. With his previous architecture experience, he leveraged the use cases to draft different context diagrams highlighting interfaces for each of the build/buy solutions. The two items together allowed the business to make a quick decision, and the documents became our scope and outline to fund our detailed requirements.

Moral of this story was that in the right landscape, you could utilize use cases to communicate vision, define scope, and by the time you’re done have a great high-level requirements document,

Functional Requirements

With use cases there tends to be two different schools of thought: 1) Functional requirements are written to support use cases, and 2) Use cases are functional requirements. For this last project, and most of my projects after that, I have been leveraging use cases as functional requirements.

I was assigned the task of eliciting requirements for implementing custom packages for a Commercial Off-The-Shelf (COTS) system. In the BRD there were plenty of standard functional “The system shall…” requirements for pieces of functionality, but where a workflow was involved, use cases were embedded with the functional requirements.

Example:

In later projects, I have been known to add another section in the functional requirements for Use Cases as stand-alone components.

Conclusion

I have read different articles where experts recommend placement of use cases in requirements documents, but I like to go with the principal that the best direction to take is whatever gets you to a place of joint understanding before your audience. Learn all you can about how to use the tools in your BA Toolbox, then experiment with how to use them for your audience, as I did with my friend the Use Case.

Top 5 Techniques in Business Analysis

Written by Bola Adesope, B.Sc, MCITP, CCNA, MCTS, PMP, ITIL, PRINCE2, BAP, SSYB, SFC, CSSBB, CBAP, MBA on May 10, 2017. Posted in Articles.

Having been involved in several Business Analysis engagements and assignments, I have discovered top 5 techniques that I find most useful for Business Analysis, and they are highlighted below.

One Caveat: I am more tilted towards Strategic Business Analysis.

1. SWOT Analysis

The SWOT Analysis, which stands for Strength, Weakness, Opportunities, and Threat is a very simple, yet powerful technique used by Business Analysts to analyze both internal and external organizations under analysis.

When using SWOT Analysis, the Business Analyst conducts, and thorough analysis of the internal (Strength and Weakness) and external (Threats and Opportunities) actors and factors at play in the space the organization operates in.

In using SWOT Analysis, the Business Analysis answers the following questions under each of the quadrants

Strengths: characteristics of the business or project that give it an advantage over others
Weaknesses: characteristics of the business that place the business or project at a disadvantage in relation to competitors or other projects
Opportunities: elements in the environment that the business or project could exploit to its advantage
Threats: elements in the environment that could cause trouble for the business or project

Use: The SWOT Analysis is useful in understanding the position of the organization and helps to recommend the capabilities the organization needs to build or the feasibility of any initiative based on the result of the analysis.

2. MOST ANALYSIS

The MOST Analysis is a very simple and extremely powerful framework tool used by Business Analysts for analyzing and planning the details of what an organization does and initiatives the organization should be looking at doing and helps maintain strategic alignment. It can also be used to give the business or organization a fresh sense of purpose and capability.

The M.O.S.T. Analysis is a highly-structured method for providing targets to team members at every level of an organization. Working from the top down, it ensures that you retain focus on the goals which matter most to your organization

The MOST Analysis comprises of four elements:

Mission: Mission is the top-level, overall reason for being in business and defines outcomes the organization wants to accomplish. The more specific the business is when defining the mission, then the more success the business will have later on trying to define the remaining points within the tool.

Objective: The objectives are one step down from the mission. Think of these as a collection of individual goals that will add up to reaching the overall mission. Just like with the mission, objectives should be specific enough to guide decision making and planning for the future. With the mission in place, it should be relatively easy to develop a list of a few objectives. Objectives should be Specific, Measurable, Achievable, Realistic, and Timely (S.M.A.R.T.). Otherwise, goal-creep will set in, and objectives will become fuzzy and difficult to implement.

Strategy: These are the things the organization or business will do to reach the objectives. What actions should be taken to accomplish the objectives, and in turn, the mission? Strategies offer a way to quickly review and group the tactics implemented on the ground floor, so they make sense as methods to achieve your objectives

Tactics: Tactics are the methods you will use to carry out your strategies. They should be simple and relatively discrete processes that can easily be understood and carried out even by people who do not have a high-level overview of the M.O.S.T. analysis.

Use: The MOST Analysis is used to ensure the BA recommends the solutions that the organization needs to meet its objectives and mission. It is also used for alignment.

3. PESTLE ANALYSIS

The awareness of the influence the environment has on the organization the Business Analyst is working with is a very important factor in any Business Analysis engagement. The PESTLE Analysis, which is also called PEST Analysis is a tool used to identify and analyze the key drivers of change in the strategic or business environment. The analysis looks at the drivers and factors in the following and how the happening in those areas influence the decisions and the type of recommendation the Business Analysts gives the organization

Political: What are the current happenings and factors in the political landscape of the environment the business operates and how can it affect or change our business.

Economic: What are the important economic factors such as inflation or meltdown is happening, has happened, or will happen in our business environment and what do they mean to our business

Social (or Socio-cultural): What cultural aspects are most important that we need to pay attention to

Technological: What are the trends and innovation in the technology space. What is the direction technology is going, and what impact will they have in our organization or business?

Legal: What are the regulations or legislations that directly impact our industry or environment and how do they affect our business

Environmental: What are the environmental considerations we need to make in our business and organization.

Use: The PESTLE Analysis is used to understand the factors and drivers within the environment the organization operates and how those factors will influence the narratives of the organization

4. BRAINSTORMING

Brainstorming in a group creativity technique that is used extensively by Business Analysts to generate ideas, identify root causes of problems, and solve complex business problems. Most of the other techniques such as Mind Mapping, Root Cause Analysis, SWOT, and PESTLE Analysis use Brainstorming and an underlying technique.

I particularly find this technique very useful in generating diverse ideas.

Use: This is used in problem-solving, fact finding and idea generation

5. MINDMAPPING

You want to be sure you have all the areas within the analysis covered, you want to certainly confirm you have considered the different and diverse components and elements under analysis, you do not want to miss anything out? Then you would need the MINDMAP technique.

The Business Analysis function has over the years been greatly helped by this special and often unrecognized technique, but I find it extremely helpful during my business analysis engagement

What are the techniques you find useful in Business Analysis engagement? Share in the comment sections