Tag: Agile

10 Common Problems Business Analysts Help Solve

Written by Esta Lessing on July 27, 2022. Posted in Articles.

Often Business Analysts are swept up by the hustle and bustle of project life and simply do what is needed to get to the end goal. Business Analysts focus on delivering a valuable solution to business stakeholders and they forget just how much value they add by help solving many problems along the way.

This short article outlines 10 of the common problems that Business Analysts help solve in the organization and especially when helping to deliver progressive change initiatives for the organization.

In no specific order of importance, find out more about these common problems that Business Analysts help solve and see if you can recognize some as familiar problems you often help solve too:

#1 Unclear or conflicting stakeholder expectations

Stakeholders may have unclear or conflicting expectations of what a project will deliver which hampers progress and can lead to disappointment.

Business analysts can help mitigate this problem is to ensure that all stakeholders have a shared understanding of what is achievable and what the project will deliver.

A Business Analyst helps to solve this problem by facilitating workshops with stakeholders to reach agreement on project outcomes, and by creating clear documentation of requirements that can be referred to throughout the project.

#2 Inadequate resources

Many projects also suffer from inadequate resources these days, which can lead to delays and frustration. Experienced Business Analysts can help identify which skillsets are needed to help deliver a project during the planning stages of the project to ensure resources are request early during the project set up stages.

Some more ways that a Business Analyst helps to solve this problem is by monitoring project progress and highlighting to the Project Manager where risks of resource shortages may occur. Where possible Business Analysts also help to create mitigating actions to avoid potential project delays due to resource constraints.

#3 Poor communication

Poor communication is often a root cause of many problems that occur during a project. Miscommunication can lead to misunderstandings, errors, and delays.

A Business Analyst can help to improve communication by facilitating communication between stakeholders, creating clear and concise documentation, and holding regular meetings to update everyone on the project status.

#4 Unclear or changing requirements

Unclear or changing requirements are one of the most common problems faced by Business Analysts. This can cause confusion amongst team members, as well as delays in completing the project.

One way that a business analyst can help solve or minimize this problem within a project is to ensure that requirements are well-defined and agreed upon by all stakeholders before work begins, whether they are working in Waterfall projects or Agile based iterations. This can be done through creating a requirements document which outlines all the requirements for the project and getting sign-off from relevant stakeholders.

In an Agile environment, the Business Analyst can help manage this issue by ensuring that user stories are well-defined and understood by all team members before work begins on them.

#5 Lack of engagement from stakeholder

Another common problem faced by Business Analysts is lack of engagement from stakeholders. This can be due to several reasons, such as stakeholders being too busy, or not feeling invested in the project or even mistrust of the business analyst.

The Business Analyst can solve this by ensuring a clear stakeholder engagement plan is a key activity within the project. The Business Analyst can also work to build relationships with stakeholders and ensure that they are kept updated on the project status and progress.

#6 Ineffective or missing processes

Ineffective or missing processes can lead to a number of problems within a project, such as errors, delays and duplication of work. This is often due to a lack of understanding of current processes being followed within the area the project is trying to solve for.

A way that the Business Analyst can help to solve this problem is by conducting a business process analysis to understand the current processes in place and identify areas for improvement. The Business Analyst can also work with the relevant stakeholders to develop new or improved processes where needed.

#7 Lack of understanding of user needs

A very common problem that a Business Analyst face is a lack of understanding of user needs. This is not because the Business Analyst is ineffective when engaging stakeholders necessarily, it can be due to several reasons including unavailability of key stakeholders and time or resource constraints that exist within the organization.

If there is a lack of understanding of user needs, it can lead to the development of a solution that does not meet the needs of the users, and ultimately will not be successful.

The Business Analyst can help to solve this problem by conducting user research and requirements elicitation to understand the needs of the users that will be using the solution. This can be done through a few methods such as interviews, focus groups, workshops or surveys.

#8 Lack of understanding of business goals

Many business analysts also find that there is a lack of understanding of business goals within an organization. This can make it difficult to align projects with organizational objectives and ensure that the right solutions are delivered. Often a Business Analyst will be assigned the task of developing a business case for a potential solution without having clear alignment of business objectives.

A way the Business Analyst can help to establish a clear understanding of the business goals is to work with stakeholders to document the business goals and objectives for the project. This can be done through workshops or interviews to understand the pain points that the organization is experiencing, and what they are looking to achieve by undertaking the project.

#9 Change fatigue

Another common yet less tangible problem faced in organizations is change fatigue. This is when staff members become resistant to change because change happens so frequently within the organizational area. This situation can make it difficult for Business Analysts who has to introduce new changes to business stakeholders and it becomes hard for Business Analysts to achieve their requirement outcomes.

One strategy a Business Analyst can follow to help manage the change fatigue of their stakeholders is to ensure that they keep them updated and engaged at the appropriate level throughout the project. They should at the same time aim to champion the benefits of the change to stakeholders and try to avoid asking stakeholders to repeat requirements or information that may have been articulated in the recent past by other Business Analysts. This is where it is very useful if Business Analysts can research similar project information to avoid rehashing the same content with fatigued stakeholders.

#10 Lack of governance

Finally, another common problem faced by Business Analysts is a lack of governance around requirements management. This can lead to several issues such as scope creep, requirements changes being made without consent or approval, and a general lack of control over the requirements. This can be a particular problem on larger projects where there are many stakeholders involved and the Business Analyst is not the only person working on gathering and documenting requirements.

A way to help solve this problem is for the Business Analyst to put in place a requirements management governance framework. This should include processes and procedures for how requirements will be managed, approved, and changed throughout the project. It is also important to ensure that all stakeholders are aware of and agree to the governance framework prior to the start of the project.

Conclusion

These are some of the top problems I could think of that Business Analysts often face and help solve. Some projects have multiple of these challenges happening at the same time which makes the role of the Business analyst very valuable as problem solver.

10 Principles for Working with Processes

Written by Jamie Toyne on July 14, 2022. Posted in Articles.

Process: “a series of actions or events performed to make something or achieve a particular result, or a series of changes that happen naturally” Source: Cambridge Dictionary

When used correctly, process modelling is an invaluable activity, and along with process maps can be a powerful way of communicating of what is happening or should happen. At its simplest it helps us to decompose a process into a sequence of steps, with a defined start and end, and understand the various events that trigger specific actions. They can also help us to identify the users (‘actors’) and what their involvement is.

This provides the basis for analysis and optimization.

However, it can be easy to fall down the path of over-complication, especially when it comes to drawing up a process. Meaning that instead of being helpful, they can be time consuming and not fit for purpose.

Therefore, here are my set of 10 principles for working with processes, whether that be through a discovery activity to define an ‘as-is’ or through a design phase to build up a set of potential ‘to-be’ processes.

Understand the purpose and why, before anything else — what are the models going to be used for? Is it to share with others to seek a consenus view on how something works? Is it to enable you to perform analysis activities off the back of? Is it to identify to a list of users (‘actors’) in an existing process?
Consider your audience, and use notation frameworks sparingly. Notation frameworks such as UML and BPMN, can be helpful in the right circumstances. Especially as a ‘behind the scenes’ analytical aid. But, bear in mind, they often confuse many who haven’t had the same training.
Focus on ‘just enough’, don’t let perfection be the enemy of good. Low-fi is generally fine, share early. Iterative process modelling is often the best form.
Think about accessibility, when sharing process maps—not everyone may have a Visio or Lucid license. Consider the best tool so that everyone who needs to access it, can access it. If in doubt, export it as a PDF before sharing.
Levels, know when you need them and when you don’t — you don’t need to model every level every time. However, you may need to understand something at a higher level first, before you can break it down further. All goes back to the purpose!
Beware relying on previously documented processes — Beware of re-using or relying on the information in a previously modelled processes unless you have a robust process library, that is regularly maintained and with stringent change control. Processes have a shelf life!
Consider sample size, like you would with any other type of research — there are documented processes, and then there are workarounds that users and customer actually do. Not everyone may approach or engage with it in the same way, so consider how many people you should speak to, in the same way you would with any other type of research activity.
Talk to users who ‘do’ the process, not just the person who ‘owns’ the process. Expectations vs reality are often very different.
Obsess over the events that trigger a process. They might be automated, such as triggered at a set time or upon a specific action being completed. They could be manual, triggered by an interaction from a user. Whatever, they are — invest time in understanding what they are, how they work and assess whether they’re helpful.
Reference your contributors — its theirs, not yours — whether they’ve helped you to to understand how a current process works, or if they’ve been involved in designing an improved or new process. Not only is it polite, to reference those who you’ve collaborated with along the way, it‘s a helpful record when looking back. It may also prompt others, to suggest additional people who should be involved.

Lastly, remember processes are different to customer journey maps, service maps, business capabilities. Don’t be fooled into thinking that you don’t need to understand processes, if you have a good grasp on the customer journey or business capabilities. They provide different thinking and perspectives, and will uncover different information. Especially in discovery settings, processes are the closest you can get to understanding what is actually happening for all users involved. They also consider both visible and invisible triggers and events.

Why Good Business Analysis Involves More Than Gathering and Managing Requirements

Written by Indu Koul on July 13, 2022. Posted in Articles.

While the basic function of a Business Analyst (BA) may be broadly understood as gathering, developing and managing business requirements, so many more activities contribute to effective and authentic business analysis practice.

Good business analysis ultimately results in wide-scale improvements and value creation as well as a deeper and clearer understanding of technology and its purpose across an entire organization.

Outside of requirements management, here are just a few of the important elements of effective business analysis.

Budgeting, financial forecasting, modelling and reporting

Generally, BAs are engaged with a project after the project is approved with defined budget and timelines. However, this practice can produce many challenges and limited project success. Challenges include not fit-for-purpose solutions, scope creep, budget variations, limited usage of existing enterprise platforms, multiplying applications of similar functionality … and an end result of insignificant business value.

To address this, BAs at VU conduct a minor but critical analysis prior to projects commencing in order to approve and assign budget to the project. We call this a short mandatory analysis to check the viability of the project, focus on identifying the value of the project and aligning it with VU’s IGNITE framework Value Identification Phase.

Running for 3-4 weeks, this process is led by BAs to understand the business problems and various solution options (internal/external) with a priority of assessing internal enterprise platforms first. The short analysis consists of:

Understanding the business problems through user journey maps.
Building a blueprint of high-level AS IS process.
Identifying gaps in AS IS process.
Building blueprint of TO BE process.
Identifying Minimal Viable Product (MVP) deliverable within a few sprints.
Devising context solution overview that shows the overall system with user interaction and dependency on other systems (this identifies the impact on existing systems and their integration points, and the impact on other business areas).
Providing solution options keeping future in mind.

The outcome of the analysis is shared with vendors for quotation. The MVP option becomes vital in establishing realistic budget and timelines for the project. Post analysis, BA inputs become critical to submission of New Initiative Funds Request (NIFR) to justify the existence of a project through its value and benefits.

A pilot of the short analysis was conducted in 2021 with VU’s introduction of a new Academic Integrity Register. The Academic Integrity Register is an online system developed to record, report and support academic decision-making in relation to academic integrity concerns and breaches of students studying in the higher education and vocational education sector.

Identifying stakeholders and managing expectations

Identifying relevant stakeholders at the commencement of the project is as important as assigning stable budget to the project. At VU, BAs identify stakeholders and map them through a tool known as a Stakeholder Power Interest Map. The mapping is conducted collaboratively by the business team, communications team and the BA. This helps stakeholders visualize the importance and relevance of the project. Stakeholders can vary from business sponsors to business owners and end users to operational support teams. Mapping demonstrates the stakeholder’s power and interest in the project which tells us how we have to manage their involvement and expectations.

To return to our Academic Integrity Register Project as an example, there were business owners, business sponsors, and roughly 2000 academics as end users of the system. At the commencement of a project, BAs should work closely with business owners to develop a communication plan which includes who needs to be involved at which stage of the project. For example, with our Academic Integrity Register project, business teams led by business owners were involved at all design related workshops and system testing phases. However, it was not possible to involve thousands of end users in User Acceptance testing (UAT), so we asked for senior representatives from each stakeholder group to participate and ensure transition to the new system was successful. These senior representatives became champions of VU’s Academic Integrity Register digital transformation.

Another critical aspect of stakeholder engagement is formulating a Project Control Board. The project owner (business sponsor) assembles a Project Control Board (PCB) and its members to assist in oversight and decision making needed to drive delivery of the project outcomes. BAs identify risks and issues and provide recommendations on approach which are presented at PCB for approval. The PCB also helps in maintaining buy-in and interest of senior leadership.

Seeking opportunities for greater value creation/realization beyond the immediate solutions required

A system implementation is successful only when the system is used and exploited by end users to a level that value is generated, and business benefits are realized during a defined period of time. For a system to continuously generate value, it has to be designed with future needs in mind. In all projects, though we focus on resolving immediate business needs through delivering MVPs, the entire system architecture should be designed based on future needs and solution expansions.

It goes without saying that implementing a system, deploying it to end users, and asking them to use it without bringing them on a project journey is a big risk to value generation. That’s why it’s essential to ensure representation of each user group at all stages of the project. Taking users along the journey with you keeps them invested and interested. This practice becomes a critical part of value realization. Users must not only accept the system but use it to a level that more opportunities are identified to improve the system, processes and solution itself.

A successful project with high acceptance from end users automatically opens doors for further opportunities in terms of engagement with other strategic prospects, process improvement, building branding through enhancing reputations. For instance, our Academic Integrity Register project enabled many across the business to learn more about CRM products which helped in product selection for other business areas. Project teams, including BAs, became recognized for their expertise and engaged in other strategic initiatives where learnings from this project could be applied.

Building beneficial relationships – not only with stakeholders but with developers, architects and partners

BAs lead the analysis of business needs, articulate the needs, perform market analysis and internal platform analysis, Request for Information (RFI), Request for proposals (RFP), product selection and vendor on-boarding. Though the BA leads these initial activities, they require Subject Matter Experts (SMEs) from other areas to ensure all the ends meet. For example, BAs collaborate with architects for establishing architecture vision and solution design, and with cybersecurity teams to ensure cyber risk assessment is conducted prior to vendor and product selection. If a decision is made to leverage a third-party provider for implementation to achieve cost saving or shift special functions to more experienced providers, BAs collaborate with partners to ensure the product is built per the business requirements and is fit for purpose. Partnering with external providers comes with its own risks and BAs have to manage these risks and ensure the project continues to be managed effectively.

Historically third-party partners have worked in a more siloed way, creating systems based simply on what was presented to them in the business’ technical specifications document. However, today there is a set of expectations on partners and their developers to add further value to the system implementation and its processes by providing their expert views and leveraging past experiences. This requires a great deal of collaboration, trust and strong partnership between BAs and implementation partners.

Our Academic Integrity Register solution was developed by a third-party partner. Over the duration of the project, a great relationship was built between BAs and the third-party partner. Post success of the project, the third party became VU’s strategic partner in managing the services through a managed service agreement. Win-win.

In summary, experienced and effective Business Analysts observe the pattern of business operations. Findings through these patterns become essential in driving solution recommendation, direction in investments, and alignment in the strategic roadmap.

Why Business Agility Starts with Strong Data Governance

Written by Chethan Laxman on June 9, 2022. Posted in Articles.

Data is now one of the most valuable assets corporations own, yet, it is still often treated as a waste product.

As data increasingly guides decision-making and digital advances automate business processes, so the integrity of data assets becomes more important. All organizations, regardless of size or sector, need to shift from viewing data as an inconvenient cost center to an asset that is reliable, accessible, secure and usable. To ensure organizations can proactively manage their data in all its disparate guises and locations, they need a structured approach with defined rules and policies governing how it is handled and stored.

The Case for Data Governance

Bad governance is costly. Poor data management impairs an organization’s ability to conduct business, whether that involves managing customers, delivering timely products, spotting market opportunities or operating as efficiently as possible.

Gartner predicts that through 2025, 80 percent of organizations looking to advance their digital business will fail because of their outdated approach to data and analytics governance. If that estimate is correct, businesses are actively missing opportunities and putting themselves at risk.

What Barriers Do Businesses Face?

Faced with increased internal demand for answer to complex questions combined with external pressures to demonstrate value and ROI, organizations are turning to data for the answers. However, harnessing data to deliver actionable insights starts with improved data stewardship. Furthermore, amid a rapidly changing regulatory climate, data management and governance are also critical to ensure businesses don’t fall foul of their regulatory obligations.

Establishing Good Data Governance

Good data governance is about creating a system of data management that addresses all these challenges. Few data and analytics leaders would disagree with the push factors for data governance, but market unpredictability and the sheer pace of innovation has made it harder to benchmark data governance efforts and establish best practice. Having invested in data and analytics, business and IT leaders now urgently need to ensure good governance in order to meet their goals of operational efficiency, increased growth or improved CX.

Establishing a data governance framework is a multidisciplinary exercise. It requires strategic input, data engineering, cloud management, data privacy and compliance expertise. Whether a business is setting up data governance systems from scratch or amending existing processes, there are four guiding principles that can help them wherever they are on their digital maturity journey.

Align Data Governance to Business Goals

The most common pitfall for data governance projects is the failure to match the mission statement to business goals. It may sound obvious but quantifying the business value of the any information transformation required is essential to success. Too often data governance has been perceived as something carried out by the data people, far removed from the rest of the business. However, when business and IT leaders fail to align their thinking at the strategy and goal-setting stage, they risk ending up with tactics and metrics that do not reflect business goals.

Example: metrics that measure data transformation (“X data points de-duped, Y data points corrected”) rather than linking data quality or data management to customer experience.

Establish a Data Governance Blueprint

Does the business have a holistic view of the information requirements by each business process and stakeholder? Amid shifting regulatory requirements and growing data volumes, it is easy for a data governance framework to get outdated. Focus on establishing clear stewardship of data, information, business and security risk. Once data requirements are understood, identify a data management roadmap to organize, maintain and sustain the underlying data so it can deliver the capabilities identified in your blueprint.

Leverage Technology and Automation

Improving data integrity at speed is achievable through smart tool selection. In the burgeoning RegTech sector, for example, there are many examples of solutions that address the need to comply with regulations such as GDPR, KYC and anti-money laundering (AML); bolster security using biometrics, 2FA, blockchain and AI; and automate unnecessary, expensive manual interventions in the data management lifecycle.

Embrace a Cross-functional Approach

Formalizing cross-functional teams for data governance is an important first step to strong data stewardship. Balanced decision-making, which involves weighing up (IT, security, compliance) risks against business opportunities, is the hallmark of true multidisciplinary collaboration, but it only happens if everyone’s committed to the same goals. Training and education are good for raising awareness of issues around data integrity, but don’t go far enough. The next step should be to involve teams in data accountability, transparency and ethics discussions and foster a more data-centric, collaborative culture as a result.

Compliance and Competitiveness Drive Governance

In industries such as healthcare and BFSI, strong data governance has become an imperative in order for these organizations to adapt to changing regulatory environment. Regulatory volatility has made it much harder for these organizations to improve data integrity in a timely manner across business functions. Pioneering organizations in these sectors have led the way with strategies that prioritize an active data governance approach, leveraging cross-functional decision-making and the latest automation technologies to adapt to changing environments fast.

Compliance has been a key driver for data governance until recently but now companies are beginning to understand the importance of data stewardship for value generation as much as risk mitigation. Any business that is committed to its digital transformation goals around improving data-driven decision-making – indeed any business that has invested or is planning to invest in data and analytics – should make data governance a major focus for 2022.

Business Analysis | Role or Capability?

Written by Tiffany Wiley on March 31, 2022. Posted in Articles.

I love this question! It opens the door for so many different perspectives (which is key in our line of work). Before we answer this, let’s start with a story.

A recent employer pulled me aside after about 2 weeks on the job (as a contractor) and said “We’ve been told that we don’t need business analysts on this project. I’m curious what your thoughts are on this?” Despite my obvious hesitations with wanting to keep my job and income, I said “That’s probably right. However,…” and I went on to explain that while a person sitting in that role/title isn’t necessary, the function is. It is critical to have someone performing the business analysis activities to ensure a successful solution delivery – digging into and understanding the business and user needs, the problems they are facing, understanding the value that they are seeking, etc. Generally speaking, developers are busy developing, QA engineers are typically busy testing, etc., so someone needs to do it.

I do believe this open and honest discussion is a big reason why I was converted from contractor to permanent employee. They trusted me enough to ask the question and I trusted them enough with a thoughtful answer.

What is a Business Analyst and what do they do?

This is sort of a loaded question in my opinion. There are so many variations out there in the job world. Some people have the title of Business Analyst but don’t really perform typical “BA” activities (as outlined in IIBA knowledge areas). While some have different titles but are neck-deep in the strategy analysis, solution assessments, etc.

The IIBA Defines it as:

The Business Analyst is an agent of change. Business Analysis is a disciplined approach to introducing and managing change in organizations, whether they are for-profit businesses, governments, or non-profits.

The global community on Wikipedia defines it as:

A business analyst (BA) is a person who analyzes and documents the market environment, processes, or systems of businesses.

When talking to family and friends, I usually describe it as “I work with people and teams to understand what they need, want, and why. What problems they have and how they currently go about solving those problems. So that I can help define possible solutions. The solution could be new technology, a new process, new data reporting, organizational structure, etc.” While most of us know that there is a LOT more to it than this, that’s a decent elevator pitch to those who truly have a minimal-to-no understanding of the function.

Why is there so much confusion about BA’s? Let’s take a closer look:

Can you have the BA title but do something else?

Yes, you can. While there are market standards, companies are free to title jobs in any way that fits their organization. At times, these titles may not match with the wider job market. Because of this, there are situations where people do get the title of Business Analyst but aren’t performing the typical “business analysis” activities. This can create a lot of confusion and headache at time of job searching for both candidate and employer.

Can you perform BA duties and not have the BA title?

Also, yes. In many cases, people are performing Business Analysis activities while having other job titles – and some have no idea that what they’re doing is considered business analysis. For example:

Have you ever investigated potential tools to use for a project or need?
Have you ever helped your team/a team define problems they have with a current process?
Have you yourself identified problems with a current process and defined a new one that would address issues/gaps?
Have you help identify individuals that may be impacted by an upcoming change?
Have you helped to facilitate a brainstorming session?
Have you done a current-to-future state analysis?
Have you made a process flow to articulate how something is done?

Guess what…each of these are business analysis activities. And frankly speaking, most of us in a professional setting has performed these activities before. And in most cases, regularly!

So even if you don’t have a title of Business Analyst, you probably still have the experience!

Circling back to the original question: Role or Capability?

The answer is both – it can be a role and a capability.

While I believe having the business analysis capability is far more critical than a title, sometimes if feels good to be able to call yourself a business analyst as well.

Set your project up for success and make sure you have someone performing business analysis activities (even if you must call them something different)!