Tag: Planning

Process Redesign: Problem Prevention or Detection

Written by Adrian Reed on July 12, 2023. Posted in Articles.

I recently changed phone networks, and wanted to keep the same phone number. I’ve done this before in the past, and it’s always been a relatively simple process. Usually, a changeover date is agreed, and on that date there’s an hour or so where the phone number is inactive, and then everything works again as usual.

Unfortunately, this time was different. Something went wrong with the ‘porting’ of my number, and days later I was left in a situation where I couldn’t reliably receive calls or texts. Pretty annoying for someone who relies on a phone for work. It was doubly annoying that I kept getting told “wait another 24 hours to see if it magically corrects itself” and it was only when I made a formal complaint that things got resolved…

Now I’ve no idea how number porting works on UK mobile (cell) phones, but from what I read online it’s more complex than a consumer might imagine, involving lots of interfaces and interactions between the old and new companies, and sometimes problems occur. This got me thinking about how some processes preempt problems, and others leave the customer high-and-dry…

Predictable Problems: Prevent or Detect

When designing processes, there will be some potential problems that can be predicted. If you were designing the payment processes for an online shop, you can predict that at some point in the future someone will try and use a stolen card to make a transaction. You can try to prevent that by restricting the shipping address to be the same as the cardholder address, and by processing the card transaction prior to shipping the goods.

Prevention involves use of sensible validation and “guard rails” to ensure that things go as smoothly as possible. Yet there will be some predictable problems that you can’t prevent, but you can still detect as soon as they occur. Once detected, the process can notify relevant people or systems, so that action is taken to rectify the situation.

An example: “Your bags didn’t make the flight”

A few years ago, I was flying from the USA to the UK, with a flight connection at Dallas Fort Worth. Unfortunately, my initial flight was delayed and I landed at the airport really late. So late that even though I ran as fast as I could, the gate for my transatlantic flight had closed. However, luckily the plane hadn’t left and the gate staff explained they were holding the flight for passengers like me who were transferring. Phew! I boarded the plane, relaxed, and tried to sleep for the flight.

When I landed in London and turned on my phone, I got a notification. It read:

“We’re sorry, but your baggage (1 of 1) for record locator <<Reference number>> is arriving on a later flight. For help, go to the <<Airline Company Name’s>> baggage office”

It also had contact details, and a link to track my bags. Now, the fact my bags didn’t make it onto the flight wasn’t really a surprise to me… I nearly didn’t make it onto the flight! But this preemptive message meant I didn’t have to waste time at the baggage carousel. I went straight to the baggage counter, they explained it was on a flight about 12 hours later and they’d courier it to my home address.

A Process Design Pattern: Detect, Inform and Solve

A key point here is the process the airline had set up meant that the problem (a delayed bag) was detected by them, they provided relevant information to me and provided a practical solution. I suspect most customers accept that problems will occur. But when the customer notices the problem first, surely that indicates an opportunity to improve the process?

This highlights the importance of building in problem detection into manual and automated processes. Going back to my earlier example of a phone number transfer that went wrong, surely there must be some way for the phone company to detect that the process failed? Wouldn’t it be far better for them to ‘notice’ this before the customer does, and either fix it straight away or at least inform the customer so the customer doesn’t have to raise a query?

This might sound like it will add processing cost. Yet, it might actually be cost saving or cost-neutral. When things go wrong, customers often spend an inordinate amount of time navigating helpdesks and eventually making complaints. This is really a type of ‘failure demand’—work that is best avoided. By creating a situation where customers don’t have to raise the query in the first place, it reduces these incoming queries and will also likely increase customer satisfaction. In many cases, this will be a clear win/win!

This pattern of prevent or detect, inform and solve is one well worth remembering for us as BAs. I hope that you find it useful in your process analysis and definition!

Beware Proxy Measures

Written by Adrian Reed on June 22, 2023. Posted in Articles.

Organizations are usually pretty good at measuring and counting things. Whether it’s positive customer reviews, staff engagement, average call handling time or something else… chances are that someone in the organization is tracking it. They might even be creating reports or dashboards so that executives can see how different elements of the organization are performing.

From time-to-time a metric will drift and there will be a desire to get it back on track. Perhaps the staff engagement survey shows that people aren’t happy. Or perhaps there’s a contact center where the average call handling time has drifted from 3 minutes to 5 minutes. Either way, it’s easy to imagine that a concerned manager would want to investigate and initiate changes.

Yet here a danger awaits the unprepared. It would be very easy to make knee-jerk reactions when referring to the data alone, without considering its context. It would be even more dangerous to make decisions based on ‘proxy measures’. By ‘proxy measure’ I mean some kind of indicator or metric which approximates how well something is going, but doesn’t directly measure it.

That might sound abstract, so here’s an example. Like many people, I wear a smartwatch that counts my steps. Doing this has definitely changed my behavior, and I strive to get 10,000 steps each day. Yet if my overall goal is to “stay healthy by staying active” then the step counter is at best a proxy measure. Sure, it’ll indicate if I’ve suddenly slumped into a sedentary lifestyle… but it would be very easy to ‘cheat’ the system. Ten thousand slow steps around the house are probably not anywhere near as beneficial as fast-paced walking (or jogging)… and that’s before we even consider the fact that it’s possible to wave your arms around to get a few extra steps. I’m sure I’m not the only one who has done that to get an extra few ‘steps’ in before midnight…

The Danger Of Unfair Comparisons

The point here is that it would be easy to equate ‘number of steps’ with ‘how active and healthy’ a person is. But that would be a dangerous equivalence to make. Ultimately, the smart watch is (I guess) “measuring the number of arm movements which are likely to indicate steps”. That is the real metric… it can be used to approximate many other things, but that is just an approximation. You certainly wouldn’t want to rely on it for decision making.

A similar pattern exists within organizations where unfair comparisons are made. Let’s imagine a call center manager is measuring the ‘average length of call’, and wants each agent to achieve an average of 3 minutes or less. The manager is probably equating “effectiveness of operator” with “length of call”. But is this truly the case?

Extending this example, perhaps there are two different agents: One (Agent A) has an average call handling length of 5 minutes, the other (Agent B) of 2.5 minutes. Agent A is put on a performance management program, while Agent B is given a bonus. Is this fair? Or could it be that Agent A is thoroughly investigating the customers’ needs, solving root causes so they don’t have to call back again, whereas Agent B is just doing the quickest thing. Perhaps Agent B even cuts an occasional customer off to hit their target…The point here is that without further investigation it would be impossible to know.

A Key Question: “Why?”

As with so many situations, a key question to ask is “why?”. In this case it’s important to ask why particular measurements are being taken. It can be a difficult question for stakeholders to answer, and different stakeholders might have different perspectives on the rationale for measuring and reporting on a particular metric. That’s useful to know too.

Asking this question can help us to determine potential gaps in the way that situations are being assessed. For example, imagine we asked two stakeholders why call handling time was measured. Perhaps they say:

“To measure efficiency of the call center agents”

“To ensure good customer service”

Arguably, the measure on its own doesn’t achieve either of these. It might be that other metrics are necessary alongside this to give a better picture. Customer feedback, customer satisfaction scores and so on might also need to be considered to give a better picture. In some cases it might be useful to stop measuring or reporting on something entirely, as the very act of reporting just acts as a distraction. All of this depends entirely on the context, so further investigation of the situation is likely to be needed.

Questioning The Norm

As with any situation, this is an area where BAs can add value by acting with curiosity. Working backwards to understand why things are measured will help ensure that possible options for improvement are generated. It will often involve questioning the norm, but most BAs are used to that!

User Stories: A Vital Step to Craft Successful Software

Written by Suchita Panchal on June 21, 2023. Posted in Articles.

Simple and easy-to-understand user stories are the key to designing and developing successful software applications (products). Mastering the art of writing user stories is crucial for product owners and business analysts. Want to explore more about user stories? Here you go!

User Story 101

The foremost step in developing a project is to have a clear view of what needs to be created. Clarity is the most crucial element in software application design and development to end up with the most efficient solution.

User stories are the step-by-step documentation of a process, which describes the actions and results. It is an agile software development tool that mentions the features from the users’ perspective. The well-documented user stories are the foremost step in the agile development process to design and develop a software application that users love to use.

The primary purpose of writing a user story is to define project deliverables and how they will bring value to the user. No matter how complex a product or project can be, user stories are always written in simple terms. It needs to be as simple as possible so that a non-technical person can understand the document. There are some key considerations that make the creation of user stories even easier.

Key elements of a user story

Simple, straightforward content
Keeps users at the focal point
Collaborate with team members to gather details
Emphasis value deliverables

Apart from this, Business Analysts should also focus on making the entire teams’ and stakeholders’ participation by adding an INVEST element to the user story.

I – Independent (Self-contained without overlapping actions)

N – Negotiable (Keep the scope for negotiation to design a user-centric product)

V – Valuable (Must deliver values to the end users)

E – Estimable (Estimate, prioritize, and fit into sprints)

S – Small (In the form of small stories to complete in a couple of days)

T – Testable (Confirmation via pre-written acceptance criteria)

These elements are crucial in writing well-documented, to-the-point user stories to initiate the product development process. Once you understand the basics of user stories and how they should approach, it becomes easier to create those accurately.

Now that we have understood what user stories are and their key elements, let’s explore why Business Analysts need to master the skill to write definitive user stories.

Why a BA needs to master the skill to write user stories

User stories are the foundational documentation that works as a blueprint while working on a project. The simple and easy-to-understand documents help the entire team to adhere to the project requirements and develop user-friendly features and functionality.

Moreover, it offers a contextual overview before the initiation of a project so that the team can understand what they need to work on. Also, they can think creatively and employ their best efforts to craft a user-centric product.

The most important benefits of user stories include.

Higher clarity on business values and project deliverables
Improved collaboration and visibility across the team
Prioritize features and functionality of the product
Efficient use of the end-users’ feedback
Minimize potential risks like communication gaps, technical flaws

As the user story conveys information about potential users and their actual needs, well-written user stories are essential to developing function-rich software applications. Business Analysts should understand the concept of user stories and focus on crafting user stories that drive value for the businesses via developing user-centric products.

When user stories are created

Generally, user stories are written at all software development stages BEFORE the development is initiated. Especially, while shaping product ideas, prioritizing features, and functionality, and during the development phase.

Who is involved in creating the stories

Business analyst, product owner or project manager, development, and design team, and sometimes stakeholders. Primarily, a business analyst or product owner writes the user stories; however, the entire team’s involvement is essential to create well-versed user stories that contribute to developing a user-centric, feature-rich software application.

How to create user stories

User stories are generalized documentation of why the product (software app) will be created and how it will take action. Here’s a simple way to create user stories that lead to a successful project development process. As mentioned earlier, keep users at the focal point along with what and why.

Who is the user story for?
What action is required?
Why is the action important?

The most commonly used format to create a user story:

As a <user>, I want to <complete this action> so that . Business analysts and the other team members can add other details to make the user stories to-the-point document.

Examples:

As a <user>, I want <to have to sign up feature> so that
As a <customer>, I want <to receive text notification when the item arrives> so that.
As a <customer>, I want <to have online payment terminal> so that
As a <manager>, I want <to generate multiple reports on dashboard> so that

In short, user stories need to be created before product development initiates. The understanding of users and what actions they need to take and why the action is necessary must be reflected in the user story. A well-documented user story will aid in creating a blueprint for project development that will lead to a successful software application. Usually, a product owner is assigned to form user stories; however, a business analyst must know how to create user stories that drive the design and successfully develop a product or software.

Do Your Organization’s Transformation Initiatives Align?

Written by Nicola Myers on May 4, 2023. Posted in Articles.

Organizations are increasingly looking to improve their processes and additionally embrace digital transformation to leverage their capabilities. Two frameworks that have gained traction in this regard are the Business Process Maturity Model (BPMM) by the Object Management Group (OMG) and the Digital Transformation Framework (DTF) used by Laserfiche. While both frameworks aim to enhance efficiency and effectiveness, they differ in their approach. In this blog post, we will explore what these frameworks are and how they align (or not) so that you will be able to be wiser when choosing transformation frameworks.

The Business Process Maturity Model (BPMM) is a framework that assists organizations in assessing their business processes against five levels of maturity. It assists in identifying areas for improvement and developing a roadmap for process improvement. It also provides a common language for process redesign and some government organizations require a certain level to consider an organization’s tender submission.

The BPMM consists of five levels of process maturity, which are as follows:

Initial: This level represents an ad hoc approach to process management, where processes are informal. The success of the work depends on the employee who just gets the job done and this results in inconsistent outcomes.

Managed: At this level, basic processes are documented, and some level of standardization and consistency is achieved but this is sporadic and will depend on the management of that unit. The benefits of process improvement begin to seep in, for example reducing rework.

Standardized: This level represents a structured approach to process management, where end-to-end processes are well-defined and documented, thus removing the silo effect. This includes process measures and using best practices to define processes.

Predictable: At this level, process performance is measured and monitored. The processes are automated and stable with predictable results. Knowledge is gained when quantitatively managing processes, for example, optimally achieving capacity.

Innovating: This level represents a proactive organization with a strong culture of process change while implementing and planning continuous improvement. This results in finding new and better ways to provide value to the client.

The other focus organizations have, is to achieve their digital transformation goals and drive innovation in the digital age. This has a larger scope than just processes. “Laserfiche is the leading global provider of intelligent content management and business process automation. The Laserfiche® platform enables organizations in more than 80 countries to transform into digital businesses”. Their Digital Transformation Model (DTM) provides a structured framework for content digitization and process automation through to data-driven innovation.

The Digital Transformation Model consists of five levels, which are as follows:

Digitize Documents: Converting paper documents to electronic documents. This leads to cost savings and less chance of lost data, but there is no central repository and so the information is fragmented, especially between silos.

Organize Content: Categorizing and organizing documents into a central repository to increase accessibility and improve security. For example, invoices are filed under the accounts payable folder. This organizing of documents assists in streamlining the work being done and supports compliance. It should be noted that at this point the document storage is standardized but the work being done is not yet standardized.

Automate Processes: Eliminating inefficient processes such as paper forms and replacing them with standardized electronic forms. Automation leads to improved productivity, accountability, and capacity but still lacks visibility because the automation is sporadic, and the end-to-end processes have limited visibility.

Streamline Processes: Automating common processes (not just forms) to increase visibility and gain business insights, for example, to optimize staffing levels. At the end of this phase, the company will be able to implement streamlined processes easily, have access to complete and consistent data, measure progress using tools like dashboards and visualizations, and involve customers in the process.

Transform Processes: Align processes with business needs, make plans for the future, and become more proactive. Data-driven innovation can be done by leveraging analytics and the organization will be more agile in changing markets.

The frameworks align by focusing on enhancing process efficiency and effectiveness. There is a strong emphasis on the role of technology (such as a central repository) as well as process management concepts (such as end-to-end processes and standardized processes). They both have five levels to compare.

However, there is a major concern with implementing these transformation frameworks and that is when to automate processes and when to standardize them. In the process maturity model framework above, the standardization starts at level 2 and is completed at level 3, while process automation takes place at level 4. In Laserfiche’s digital transformation framework, automation takes place at level 3 and processes are only improved and standardized at level 4. This means by following both transformation initiatives at the same time, the organization is working at cross-purposes, and it is likely that both projects will fail, resulting in a very costly mistake for the organization.

It should also be noted that with the digital transformation framework, there is no initial level where the company is purely paper based. It would make sense that before the digitalization level, there would be a level where the organization is haphazard about its use of technology. This may result in a six-level model and so not aligned with the levels of the process maturity model again.

In conclusion, there are many other business process maturity model frameworks (Robledo, Gartner, CMMI, and Rosemann) and other digital transformation frameworks (for example McKinsey, Forrester’s Playbook, and Capgemini). Whichever you choose, make sure your transformation frameworks align before sinking billions into organizational transformation projects that are heading in opposite directions.

Factors Impacting Analysis

Written by Virginie Terry on May 3, 2023. Posted in Articles.

As Business Analysts, we are experts at defining good quality requirements and processes that enable the implementation of solutions which are fit for purpose and deliver the benefits from the business case. We may have several Business Analysis qualifications and many years’ experience working on all types of projects, from simple process changes to complex technical overhauls with multiple integrations, data migration and significant business change elements, and everything in between.

Yet our skills are just one of the many components that enable us to do our job well. There are some other factors which we don’t have much control over but which are also hugely important. We need to be aware of them and should consider them upfront and throughout the delivery of our projects to set ourselves up for success. Unsurprisingly, they can all be grouped under communication within project teams and organizations’ delivery standards and processes.

Consider the delivery model

Are the delivery frameworks from your organization and any third party you are working with aligned? Organizations tend to have slightly different definitions of the same terms, for example “delivery phase”. Does the delivery phase consist purely of coding and configuring what has been defined in great detail in previous, distinct analysis and design phases? Or will the delivery phase also include collaborative sessions at the start where technical teams, BAs and users flesh out these details together?

Consider roles and responsibilities

This is particularly important in organizations which have a high staff turnover, use many contractors or employ staff on short, fixed term contracts. The execution of testing can be a grey area for example, particularly User Acceptance Testing (UAT). Who is expected to write the test scripts? Is it the Tester(s) on your project, the business Subject Matter Experts (SMEs), or even yourself?

Consider the experience from other key roles within the project team

Do the Project Manager and other key roles within the project team have a good understanding of the role BAs play, what we do and don’t do? For example, do they know that BAs need to be present in all meetings with the users and technical team(s) where the scope is discussed? Or that we cannot make an on-the-spot decision about the validity of a change request, such as descoping an area of functionality because of new budget constraints, without assessing the impact on the processes and the integrity of the solution overall?

Consider the project plan

How will the project plan be produced? Do you need to do some “right to left” planning, because the go-live date can’t be moved, which is common on a lot of commercial or regulatory projects, or can you estimate the duration of each phase before agreeing on a go live date?

In the first scenario, you will need to timebox each activity and almost certainly compromise on some elements of your analysis. In both cases you need to really think through any assumptions which are being made around the effort required to produce each deliverable and any dependencies. You should also document any risks you foresee as a result of the approach being undertaken.

One common oversight is the business users’ availability to support the project, which can really hinder progress if not managed effectively. This can range from planned absence, such as annual leave, to having to perform Business As Usual (BAU) activities no one else can backfill, or supporting other projects which have a higher priority.

Consider the project governance

Does your organization have well defined processes to govern the decisions required around the different project milestones and the challenges you will meet in the course of the delivery? For example, are you clear on the documentation that you need to produce, or contribute to, at each stage gate? What is the change control process you need to follow when a new requirement emerges after the requirements catalogue has been baselined?

Consider the Sponsor’s role

Sponsor engagement, and the BA’s access to the Sponsor, are critical to the success of the project. Are you able to have one-on-one meetings where you can speak openly to update them or seek guidance when you are uncertain about the direction you should follow? Does your Sponsor know the level of involvement they need to have so that they support you, the Project Manager, and the delivery of the project, without interfering with the methodology or the due diligence required, for example?

Conclusion

There are no simple answers to these issues. Every organization has its own culture, and each project team has specific dynamics.

However, identifying them as early as possible means that you can prepare for them and address them effectively within the constraints that you operate in, even if it means you’re not able to follow best practice. When dealing with these challenges, regardless of your level of experience, you will achieve something much bigger than the delivery of your project.

This may be learning something new about the way that you communicate, educating your colleagues about the role of the Business Analyst, or even instigating an improvement in the way in which your organization delivers change.