Tag: Communication

Best of BATimes: Business Analyst Role in COTS Projects

Written by Maksym Lysikov on September 13, 2023. Posted in Articles.

Many tech companies offer commercial off-the-shelf (COTS) products.

Such products allow to meet their clients’ business needs relatively fast, comparing to the development of the new IT solutions from scratch. However, a COTS product for a complex solution such as ERP, CRM, laboratory or hospital information systems requires considerable time and effort to be invested into the configuration. Hence organizations usually involve a separate implementation team of professionals familiar with the COTS product to adapt it for the company’s needs.

COTS vendors normally provide the implementation service to their clients. This can vary from company to company, but oftentimes it includes discovery phase, configuration or customization of the system according to the business needs, user training and making sure the project goes live.

This article describes the BA role in the implementation of the COTS projects and cooperation between a COTS product team and BA from an implementation team.

BA in Implementation Project

One might say that COTS projects do not require business analysis since there seem to be no significant development activities. However, COTS projects could vary from completely out-of-the-box to complex solutions with lots of configuration and additional customization (codding) involved. In the latter case we can and shall involve the standard business analysis activities:

Plan your business analysis work. Ask yourself what is your business analysis approach (adaptive vs predictive)? Who are your stakeholders? Do you have a requirements governance process in place?
Requirements elicitation and analysis. This covers discovering the current and desirable states, conducting workshops and interviews, document analysis, etc. Don’t forget to elicit and document any gaps if a COTS solution is not capable to meet some of the business needs.
Requirements modeling. COTS projects normally do not require the complete functional specification since the solution is predefined already. However, there are many other requirement views which can be useful for the configuration project. We will discuss that in the section that follows.
Solution evaluation. Define your KPI and measure if they improved compared to the legacy solution.
Configuration. System configuration is normally out of business analysis scope, but some companies tend to involve business analysts in such activities. In any case, the BA should know how the system works and understand the solution limitations.

Requirements Modeling

As mentioned before, it might not be required to document all the functional requirements for the already predefined solution like COTS product. However, not documenting requirements at all could result in certain drawbacks:

Apparently, external stakeholders, like end users, and internal stakeholders, like testing or support teams, will need at least some documentation that describes how the system behaves.
Without modeled requirements, there is no way to validate the requirements before they are actually implemented and the system is demoed for users. What if you only validate your assumptions by demoing already configured piece of functionality? That is right, you will most likely need to reconfigure the system again once you receive the feedback, and then again and again. Nevertheless, you still can present out-of-the-box functionality which doesn’t require any configuration efforts and use it as a starting point to collect the initial feedback from your users.
The change management process can suffer. Imagine that you documented the requirements for the billing module in the bunch of meeting notes, and now 4 weeks after the requirements were implemented the clients insists that some of the billing transactions are not calculated correctly. Would it be easier to refer to the SRS part where all business rules are documented, or try to find the relevant emails?

To address the above issues, the BA can use a variety of the business analysis techniques which will be applicable for the project and audience. For example:

Roles and Permission Matrix: most of the COTS solutions allow roles configuration and assigning permissions. Start with defining and documenting user roles and their permissions. The organization chart can come in handy to define the roles.
Process Modeling: you can elicit and model the current processes using either the standard notations such as BPMN, UML or come up with a simple drawing which doesn’t follow any notation standard but clear for the audience. The next step will be to review the models with stakeholders, define if anything should be changed in the process and update the model. Once done, you can supplement the model with the additional requirements view, e.g. use cases.
Gap Analysis: as the BA on the implementation project you need to identify the areas in your client’s business which are not covered by the COTS package and address it to the product team. Bear in mind that it is always a good idea to think about the potential workarounds you can offer to the client, before escalating the gap to the product team. That way the client can access the desired functionality earlier, the product backlog will not be overloaded and there will be no need to overengineer the product with the functionality potentially used by only 1 client. So at first always assess if it is possible to configure the system in an alternative way or if the client can agree to do certain steps manually.
User Stories: this is a simple and popular way of specifying the requirements, especially if you follow the agile approach and need to deploy the COTS solution incrementally. It is also quite convenient to prioritize the requirements using the user story form.
Use Case and Scenarios: you can document each separate business flow in the use case. Use cases can easily be converted into the test scripts and serve for validation purposes.
Business Rules Analysis: it is always a good idea to elicit and document business rules. Make sure you have a process in place to update business rules due to external or internal changes.
Interface Analysis: your COTS product will most likely not be used as a standalone solution and will communicate with other components. Define and document interfaces specific to your client.
Data requirements: usually a COTS solution replaces an outdated legacy solution and you need to take care of the historical data. And it is better to define data requirements upfront before you realize you cannot import 256 characters long text into the address column for one of the top customer’s client. Ask yourself the following questions: do you need to import the historical data into your brand new COTS solution? will the legacy data fit the new system? how will you handle the cases when the data doesn’t fit the new COTS product?

Provide Feedback to your Product Team

A good way to improve the product is to listen to your user’s feedback. And when it comes to COTS project who is the best candidate to elicit, analyze and document all the client’s concerns and frustrations? Yes, you’ve got it right! It is the implementation BA or anyone else who fulfills this role in an organization. And thus the BA is the one who should establish a process to communicate all business concerns and client gaps to COTS product team.

For example, the BA can create a separate Wiki page per a client where they can list all gaps discovered during the project and communicate them to the product team. The product team can then collect the feedback from all clients, prioritize the gaps for the future releases and share the roadmap with the implementation team.

Conclusion

COTS implementation projects can be a challenge for the BA as they differ from the traditional IT development projects. However, with the right attitude and a bit of creative thinking, we can adopt the BA techniques and establish the process which will bring value to the implementation projects and help improve the COTS product.

Published: 2019/08/08

Don’t Deliver a Donkey instead of a Horse

Written by Nurani Easwaran on August 30, 2023. Posted in Articles.

All of us at some point in our life have heard of the children’s game called Telephone Game or Broken Telephone. In this game, Players form a line or circle, and the first player comes up with a message and whispers it to the ear of the second person in the line. The second player repeats the message to the third player, and so on. When the last player is reached, they announce the message they just heard, to the entire group. Very often, the message that comes out at the end is quite different from what the first player had whispered, and this creates a lot of amusement.

Now imagine that same game being played when a project is initiated. In this case, the project sponsor or sponsors may request for a given deliverables at the onset of the project based on business needs. However, after the message gets filtered through many teams, the outcome may not match what was asked for in this first place resulting in a number of unhappy customers or stakeholders. This can be considered as delivering a Donkey when asked for a Horse. The moral of this story is that if there was proper end to end communication, the result would have been much closer to what the sponsor asked for in the first place. Effective Communication is considered as one of the most important aspects of both personal and work life.

Business analysts need to effectively gather and convey information between stakeholders, team members, and other parties involved in a project. Clear and concise communication ensures that requirements are accurately understood, objectives are aligned, and expectations are managed. Effective communication fosters collaboration helps in resolving conflicts and ensures that the project stays on track. Some of the key techniques or aspects of communication within the business analysis domain are discussed below. All of them are equally important and need to be considered during any engagement and can be improved through training and constant practise.

Active Listening.

Active listening plays a crucial role in business analysis. It involves fully engaging with stakeholders, understanding their needs, concerns, and requirements. This helps the BA to gather accurate and detailed requirement related information, which is essential for making informed decisions and developing effective solutions. Active listening improves collaboration, builds rapport, and ensures that project goals align with stakeholders’ expectations.

Interpersonal Communication

Interpersonal communication skills are vital in business analysis because they involve interactions with various stakeholders, each with their own perspectives and needs. Along with the Active Listening mentioned above, building rapport, and empathising with the viewpoint of the stakeholders are crucial for establishing trust and understanding. These skills help business analysts navigate conversations, gather requirements, and address concerns effectively. Related techniques such as Collaborative problem-solving, negotiation, and conflict resolution also rely heavily on strong interpersonal communication. By fostering positive relationships and adapting their communication style, business analysts can facilitate smoother interactions and achieve better outcomes throughout the project lifecycle.

Stakeholder Management

Stakeholder management is a critical aspect of business analysis that involves identifying, engaging, and effectively communicating with all parties impacted by a project. Business analysts need to understand stakeholders’ interests, expectations, and concerns. By building relationships and maintaining a clearly defined two-way lines of communication, the Business Analyst can ensure that stakeholder needs are considered throughout the project lifecycle. Effective stakeholder management involves involving the right people, keeping them informed, addressing their feedback, and managing conflicts when they arise. Successful stakeholder management contributes to project success by aligning goals, managing expectations, and fostering collaboration

Within stakeholder management, a crucial element to consider is Communication strategy. This has a number of components of its own including identifying the audience for each message, understanding the environment or business situation under which the given project has been initiated, getting a clear understanding of the sponsor vision or objectives , being able to define what needs to be said to whom and when, and knowing what are the various ways in which the message can be delivered and feedback received.

Facilitation

Facilitation is an important technique in business analysis that involves guiding discussions and workshops to achieve productive outcomes. By facilitating meetings, workshops, and brainstorming sessions as per the needs of the project, business analysts can encourage participation, manage conflicts, and ensure viewpoints from all the stakeholders or impacted parties are heard. Facilitation helps in eliciting requirements, prioritizing features and functionality, and fostering collaboration among stakeholders. It also aids in reaching a collective understanding and agreement of the objectives and making informed decisions, leading to more successful project outcomes

Business Writing

Strong writing skills are crucial for business analysts as they are responsible for documenting and communicating various aspects of their work. Clear and concise writing is essential for creating requirements documents, project plans, reports, and other forms of documentation. Effective writing ensures that complex deliverables or impacts are accurately and clearly represented to stakeholders, team members, and decision-makers. It also helps in avoiding misunderstandings and serves as a reference for project progress and decisions. Well-written documentation contributes to effective communication, reduces ambiguity, and supports the overall success of business analysis efforts.

Presentation Skills

Visual and presentation skills are essential for effective communication in business analysis. They help convey complex ideas, data, and information to stakeholders in a clear and understandable manner. Business analysts often use visual aids like diagrams, charts, and models to represent processes, workflows, and requirements visually. Strong presentation skills enable them to deliver findings, recommendations, and project updates to diverse audiences, ensuring engagement and comprehension. These skills enhance collaboration, facilitate decision-making, and contribute to the overall success of projects.

Nonverbal communication

It is often mentioned that over 70 percent of face-to-face communication is Non-Verbal. Nonverbal behavior, such as body language, facial expressions, and gestures, plays a significant role in business analysis. It helps convey emotions, attitudes, and intentions that words alone might not capture. Observing nonverbal cues during meetings and interactions with stakeholders can provide valuable insights into their reactions, level of engagement, and concerns. Being attuned to nonverbal behavior allows business analysts to adapt their communication style, build rapport, and ensure effective collaboration. It also helps in detecting potential misunderstandings and addressing them promptly.

By considering and effectively executing all the above techniques, the Business Analyst is certain to have a much higher success rate in delivering and meeting the needs of the stakeholders

Communication Strategy

This can be considered as the overarching technique or approach that is used and includes elements or all the above techniques.

Best of BATimes: How to Facilitate Successful Process Mapping Sessions

Written by Chelsea Gaillard on August 23, 2023. Posted in Articles.

Process mapping is often the first step in business process improvement. It is a necessary activity that provides a baseline from which improvements can be measured and is the key to identifying and localizing opportunities for improvement. Therefore, it is important that facilitators capture the right information to help steer process improvement initiatives in the right direction.

To have successful mapping sessions, facilitators must possess the ability to lead (steer the direction of meetings), manage people (deal with conflicts and diversions), and persuade participants to open up and share the knowledge they possess.

This can be challenging when dealing with large groups and complicated processes. To help to ensure that you have a successful process mapping session, follow the guidelines outlined below.

Be Aware of Scope Creep

Off-topic or side conversations can lead to the kind of scope creep that takes time away from the original goals set for the meeting. It can also lead to the capture of irrelevant data. It is easy to get off topic in any meeting. When conducting process mapping sessions, additional challenges exist.

Mapping sessions are designed to bring SMEs and various groups together to document how tasks are performed. However, these sessions often serve as a learning experience revealing for the first time details about a process and its challenges. Because each participant may have a different level of understanding about the process, this can contribute to extended discussions about issues. These discussions can be enlightening and sometimes necessary, but can also get the meeting off-topic. For example, let’s say group A is using a manual process to calculate input for a step and it is revealed that group B is utilizing a tool that could be implemented by group A. This tool could eliminate the need for the manual process. This, of course, sparks an interest for group A and leads to a discussion about the tool rather than the overall purpose for the meeting. These types of side or off-topic conversations often happen as process issues are revealed. The facilitator must have the ability to put a time limit on these discussions and be able to determine the difference between relevant and irrelevant conversation to protect the goals of the meeting. Remember, process mapping sessions are not for solving problems – they are for the purpose of identifying and documenting potential problems.

Mapping sessions can also get off topic by the compulsion of participants to document processes as they “should be” and not how they exist in its current state. Mapping sessions typically begin by documenting the “As Is” or “Current State” process to identify opportunities for improvement and then end in the design of the “To Be” or “Future State” process after teams solve problems. Although it is a great sign when participants recognize during meetings better ways to do things, it is counterproductive to prematurely document the “Future State” before establishing a baseline for the improvement effort. It is the job of the facilitator to identify when this shift occurs and get back on course.

Capture the Right Amount of Information

As a facilitator you must be able to determine the right level of information to capture. Whether you are capturing too much or too little information – both extremes can be a waste of time and not address the overall purpose of the project.

Process mapping standards identify Level 0 or the steps identified in a SIPOC as the starting point for most mapping efforts. SIPOCs (Supplier, Input, Process, Outputs, Customers) are used to identify roles, inputs and outputs and high-level steps of a process. (To learn more about SIPOCs see the article “The Four Agreements You Need to Have a Successful Process Mapping Session”)

It is best to start with a high-level map (Level 0) and identify what topics need to be fleshed out from there. Additional levels can be mapped accordingly (see Figure 1). The various levels can be described as follows:

Level 0 – high-level core steps of a process listed in six steps or less.
Level 1 – drills down from the core steps and describes the steps involved in a process at the next level.
Level 2 – describes the step-by-step details of a process.

You may need to drill-down further to uncover bottlenecks and inefficiencies of a process, but it is important to get input from SMEs about relevancy of the data being captured and regularly compare project goals against your process mapping efforts to help make sure that you are steering the meetings in the right direction.

Figure 1 – Levels of Process Maps

Make Sure the Right People Are In the Room and/or Available For Participation

There is nothing like being in the middle of a successful mapping session that suddenly stalls because no one in the room knows exactly what happens in the next step! If this situation occurs, you simply do not have all the right people in the room. The SIPOC reveals your suppliers and customers or those representative groups that should be in the meeting. However, sometimes the right individuals are not chosen to participate. Instead, managers and/or process owners are chosen to represent departments when actual processors should be in the room or available for contact during the meetings. Often sponsors are reluctant to release critical resources from core work, but it is well worth it to lobby with sponsors to provide the proper representation for the mapping session to capture information correctly.

Proactively Address Conflict

Business professionals who attend meetings regularly have first-hand knowledge of how unproductive meetings can be when attendees are disruptive. Conflict that exists between individuals, departments and/or organizations can make its way into your process mapping session and prevent you from capturing critical details of a process or impede progress.

It’s important to uncover potential problems that may arise during a mapping session and proactively respond prior to the meeting. How can you prepare for these types of challenges before the meeting? Implement tools from change management principles and conduct a simple/modified risk or change readiness assessment prior to the session. Knowing beforehand the challenges groups face with their processes and/or between groups will help you prepare a response and manage behaviors in the meetings.

Here are five important things you should know prior to a meeting. Ask these questions of each sponsor and/or process owner:

Do you support this initiative?
What concerns, if any exist about this effort?
Do your SMEs have the time and energy to participate in this effort?
Are SMEs motivated to participate in the mapping activities?
Do you have good relationships/rapport with external groups that will enable your team to work efficiently during the mapping sessions?

If conflict exists, it is best to deal with it openly and honestly. Start with the sponsors. Reiterate the overall project goals, restate the purpose and stay passionately neutral during the process. Taking a side will cause other sides to shut down and you will lose engagement immediately preventing the accurate capture of data. Transparency about the process and having courage to address problems will allow facilitators to meet the goals of the mapping session.

Structure Meetings to Have the Least Impact on SMEs and Groups

Process mapping sessions that are lengthy and continuous can lead to waning support. There are a few ways to construct meetings to keep participants engaged. Facilitators can hold “Cross-functional Meetings” or “Functional Meetings”. Each type has its pros and cons, but each can address issues surrounding participant engagement.

Cross-functional Meetings – this type of meeting gathers all teams from across functions to participate in the same full or half day workshops to map out processes.
Functional Meetings – allows functional groups to gather independently to map processes related to the functions they perform. If there are six groups involved in a process, six separate meetings will be held to capture the processes of each function. The individual functional maps are consolidated to create one overall map of the process and then presented at a review meeting where all SMEs and groups will gather to review and approve the final process map.

See Figure 2 for the pros and cons of each meeting type.

In summary, strong facilitation is the key to holding successful process mapping sessions. But the real measure of success is how effectively the data captured is utilized in the overall process improvement initiative. If the identification of problems using process maps leads to lasting change that reduces costs and increases profits – you held a successful mapping session. And in that case, congratulations!

Published: 2015/07/15

The Tyranny of the Algorithm

Written by Adrian Reed on August 16, 2023. Posted in Articles.

A while ago, I noticed that some people changed the way that they were writing LinkedIn posts. Rather than writing in sentences and paragraphs, everything would be written in this weird separated way with everything spaced out in a really unnatural way. Then certain other common patterns appeared (e.g. using PDFs documents with multiple pages, or ‘carousels’ as some people call them). Video was huge, then not huge, and so the trends fluctuated. Some of the formats seemed really good and useful… others… not so much (we’ve probably all clicked on the occasional ‘click bait’ LinkedIn post…).

I gather one of the reasons that people post in particular ways is to get maximum exposure, and to do this you have to pander to the algorithm. It is, after all, the algorithm that will decide how many people see your post… and not all posts are created equal. Those that get more ‘engagement’ will be seen by more people (and, very likely, get even more engagement). Yet the algorithm decides what counts as ‘engagement’.

There’s nothing inherently wrong with this. LinkedIn is a private enterprise, it can (I suppose) run its operations however it chooses. But take a step back for a moment, and let’s make a hypothesis here:

The algorithm has changed the way people write content and interact with others on LinkedIn

I’m making no moral judgment here, and the way that people write and engage with each other has adapted over the years. But let’s follow this to its logical conclusion: social media algorithms have the ability to influence the style and formats in which people communicate. It decides what content gets seen (and doesn’t get seen). Again, as users we might be OK with that. But I hope that there is someone within those companies asking a whole set of ethical questions…

Avoiding Biases and Unintended Consequences

In particular, it’s important to consider whether algorithms might lead to bias, and might inadvertently disadvantage or affect particular groups or stakeholders, or whether they might have other types of unintended consequences. For example, I’d imagine that the LinkedIn algorithm probably aims to keep people on the site for as long as possible, and serve them up relevant adverts. But when people learn its nuances, they start to ‘game’ the algorithm, meaning that some folks are more likely to get their content seen than others. Presumably, LinkedIn eventually learns about this too, and adapts the algorithm, and the process repeats.

Yet unintended consequences like this aren’t limited to IT or algorithms. Nor are biases (there are plenty of well-documented cognitive biases that affect people too). Crucially this is an area where BAs can help ask some of the difficult questions, and get beyond (or at least highlight) potential issues.

I have often thought it interesting that within most organizations, if you ask the question “who is responsible for regulatory compliance” you will get a clear cut answer. There is usually a legal or compliance team, and often a named individual who is responsible and accountable. Ask “who is responsible for the ethics of this product or project?” and (outside of some very specific domains) you’ll likely get a blank stare. Or, you’ll get a word-soup answer that boils down to “we’re all responsible”. And when everyone is responsible, too often nobody steps up to ask the hard questions.

The Ethical Imperative

This is a space where BAs can add significant value. As BAs we’ll be used to conducting stakeholder analysis, thinking in terms of the different stakeholders or personas who will be impacted by a particular proposal. We can extend this thinking by asking “who isn’t here around the table, who is missing from these conversations, and how can we ensure they are represented?”.

We can ask the difficult, but important ethical questions, and ensure that the projects and products that are progressed by the organization are in line not only with its strategy but also its values. If there’s a strategy-execution divide in many organizations, that’s nothing compared to the values-execution divide! (We’ve probably all had experiences with organizations that say they ‘put the customer at the heart of what they do’ that… definitely don’t actually do that!).

Often, as BAs, we are able to take a step and ask “what is the impact of this”, and “what does success look like for X stakeholder group?” and “how does that vary from what the Y stakeholder group thinks?”. By taking a holistic view, balancing different viewpoints and putting an ethical lens on things, we can hopefully reduce the risk of inadvertently introducing bias or unintended consequences.

This involves us having the courage to ask bold questions and keep ethics firmly in mind. If we don’t, there’s a real danger that the ethical dimension will get missed. A situation that I’m sure we’re all keen to avoid!

Avoid The “Saying/Doing” Gap

Written by Adrian Reed on August 10, 2023. Posted in Articles.

Elicitation is a core part of business analysis, and there are a vast array of elicitation techniques at a BA’s disposal. However, if you’re like me (and most BAs) you probably have a few favorite techniques that you gravitate towards. For me, I’ll often start with interviews and workshops, using document analysis to gain context and perhaps some observation to see how things really work.

While it’s completely natural to have frequently-used techniques, it’s important not to forget that other elicitation techniques exist. It is very easy to fall into a rhythm of reverting to a particular set of techniques irrespective of the context, project or situation being examined. This could lead to a situation where other techniques might have proved more efficient or effective. In particular, it’s important to use an appropriately varied set of techniques to avoid the ‘saying/doing’ gap…

People Often Do Things Differently In Reality

As any experienced BA will tell you, asking someone to describe how they do their work will often give you a very different result to going and seeing them do their work. There are often parts of the process that are so obvious to the people undertaking the work that they don’t even think about mentioning them. Imagine if someone asked you to describe the act of driving a car… you might explain the steps of opening the car door, putting the key in the ignition, checking mirrors and accelerating away. You probably wouldn’t mention putting on a seatbelt, or closing the door… but these are things that are very important! If we are wanting to understand an as-is process, we’ll often want to understand those ‘seatbelt’ moments too.

There’s also the tricky subject of exceptions and unofficial workarounds. Sometimes there will be exceptions that the designed process never really catered for, so workarounds have emerged. These workarounds might not be documented anywhere, or if they are documented they might be documented in an informal way. Knowing about these workarounds (and the exceptions that cause them) is important too—any new process really ought to cater for these situations without a workaround being necessary.

All of this points towards the need for a mixture of elicitation techniques.

Use a Mixture of Elicitation Techniques

Interviews and workshops are excellent techniques for understanding stakeholders’ perspectives on a situation and asking probing questions. Yet if we are going to gain a broader understanding of the situation, it’s important to mix and match our techniques. There are also some techniques that might not traditionally be thought of as elicitation techniques that can be brought into the mix too.

Here are just a few examples for consideration:

Analysis of Reports, Data & MI: What does the data show you about the process? When are the peaks? How many queries go unanswered? What are the most common queries from customers? Why are those the most common queries? What are the uncommon situations that might be causing exceptions or problems?
Observation, Sampling & Surveys: Observing colleagues undertaking their work can help us understand how the work really works, but requires a good level of rapport (else people might revert to the ‘official’ process rather than what they actually do). It isn’t always possible to do this, so sampling can be useful. In a call center where calls are recorded, if (with the relevant legal permissions) you can gain access to call recordings, you can potentially sample elements of a process and see how things are done. Or, you might issue a survey to the relevant customers or internal stakeholders. Sometimes giving people some time to reflect (rather than asking for an instant response in a one-on-one interview) can be useful.
Document analysis: A very broad technique, but looking at things like process models, procedures, exception reports and so on can prove useful. Of course, there is often a gap between how a process is written and how it is actually executed, but documentation is a good starting point.
Correspondence or sentiment analysis: This is really a particular type of document analysis, but if you are looking to improve a customer-facing process, why not look at some of the correspondence that customers have written about it? What do they like and dislike? Look at complaint logs, which elements are they complaining about? After all, complaints are a potential source of innovation, when they are filtered and used as input to process improvement. If your company has a social media team, perhaps they are capturing suggestions that have been submitted via these channels also.

Of course there are many other elicitation techniques too, these are just a few examples. But crucially, initiatives usually benefit from a mixture of elicitation techniques, some of which require synchronous stakeholder input, some of which require asynchronous stakeholder input (and therefore gives reflection time), and some of which initially don’t require stakeholder input at all (e.g. document analysis).

With a breadth of elicitation techniques, we gain a broad understanding of the current situation (and future needs). This helps ensure we deliver a valuable solution to our stakeholders.