Skip to main content

Tag: BPM

The Incredible Expanding Requirement

The Incredible Expanding Requirement

A simple requirement statement might conceal much detail that eventually must be discovered and addressed.

Image by kjpargeter on Freepik

Some requirements are like icebergs: The portion that you see initially is only a small fraction of the whole thing. Whether it’s represented as text—such as a single functional or nonfunctional requirement statement, a feature summary description, or a user story—or visually in the form of an analysis model, there could be far more to it than first appears. Requirements analysis involves digging below the surface of a presented requirement to understand its full scope, complexity, and implications.

Let’s consider a simple, common nonfunctional requirement: “Only authorized users may access system services.” That security requirement could have originated from a company policy, government regulation, or other business rule. Can you just hand that requirement to a developer, or maybe write it in the form of a user story and add it to the product backlog? I don’t think so. Peeling away the layers shows that that one requirement statement can expand enormously, raising many questions and spawning many child requirements along the way.

This raises the question of how much detail to document for an unrefined requirement versus leaving it in the hands of the developer to process as they see fit. In other words, who do you want to make all the decisions associated with a complex requirement, and when? Considering that question will help you manage the transition from requirements to design.

If you want an initial high-level requirement implemented in a specific way, the business analyst should elaborate it into the appropriate level of detail and precision. That elaboration could impose design constraints on the developer, albeit for good and thoughtful reasons. On the other hand, if you’re okay with the developer having the final say on the functionality and user experience details (preferably with feedback from others on design documentation, prototypes, or screen sketches), then just pass the higher-level requirement along for implementation.

Looking Below the Surface

Consider some of the questions you’d have to answer if you were the developer asked to implement our one-sentence security requirement. It’s unlikely that you’d have all the answers yourself. As you study the requirement, you’d have to make up those answers, research policy standards, or consult with others to agree on how to resolve each issue. That’s what business analysis is all about. Let’s see how quickly an exploration of this single requirement statement expands into many detailed requirements.

First, we’ll need a clear definition of exactly what an “authorized user” is and just what system services cannot be accessed unless a user is authorized. Do different parts of the system require different privilege levels or access credentials?

How should each user be uniquely identified? With a login name, an email address, using a third-party account (like Google, Apple, Facebook, or X), or something else? Will the user ID be assigned by a sys admin or user-selected? What are the rules for the user ID: minimum and maximum length, allowed characters, and case sensitivity? What happens if the user selects a user ID that’s already in use?

Next, what is the primary user authentication mechanism? We have numerous choices, including password, passkey, PIN, and biometrics of various kinds. Let’s just think about the venerable password for now. Here are some questions that come to mind regarding passwords:

  • What are the rules for the password: minimum and maximum number of characters; allowed, prohibited, and required; characters, case sensitivity; pattern restrictions (such as no more than two instances of the same character in sequence); required patterns (such as at least one each of upper- and lowercase letters, numbers, and symbols)?
  • Must the user re-enter the same password in a separate field during creation to verify it? If so, what happens if the two entered passwords don’t match?
  • Can the user toggle the visibility of the entered password on and off, either during creation or during logins?
  • How is the password masked in the entry field? With asterisks or dots? One symbol per entered character or a random number of symbols to conceal the password length from an onlooker?
  • What feedback will the system provide if a login attempt fails?
  • Is the user blocked after too many unsuccessful login attempts? If so, how many tries do they get?
  • If the user’s account is locked after too many failed login attempts, how long does the account remain locked? How can the user unlock it?
  • What happens if the user forgets their login ID or password? What recovery method is used? I can’t get into my original YouTube account because I’ve long since forgotten the password, and the phone number on the account cannot receive texts. Google offers me no other identity verification options.
  • Must the user change their password periodically? If so, how often? Are there restrictions on what the new password can be, such as not reusing any of the previous N passwords?
  • Can the user define a personal identification number (PIN) as a shortcut for the password, as on a Windows PC? If so, what are the allowable characters and the minimum and maximum length of the PIN?

These are some of the issues associated with specifying a security requirement for just a simple password mechanism. You can see how the answers to those questions lead to more and more functional requirements to satisfy the nonfunctional security requirement. But the expansion can get much worse.

The Many Modes of MFA

If your project’s decision makers want better security than a password provides, you’ll explore multifactor authentication (MFA) options. You’ll need to choose from numerous options for both MFA techniques and their implementation details. Start by deciding what types of MFA the system should enable to provide the desired security level. Options include:

  • Sending a one-time code that the user must enter to verify their identity
  • Sending an email containing a one-time login link
  • Biometrics, such as fingerprint, facial recognition, voice ID, and iris or retinal scan
  • A physical security token
  • Using an authenticator app, perhaps on a second device

Here are a few more general questions:

  • How many of these MFA options should you make available to the user?
  • If more than one, can the user select their default preference to use initially for each login attempt? Can they change that default?
  • How will the user enable and disable MFA on their account?
  • If for some reason the user can’t employ their initial method (such as not having access to the device with the authenticator app), can they select another method for that session?
  • Will there be some other backup action, such as contacting customer support, in case none of these MFA methods work for the user?

Let’s take a closer look at just the technique of sending the user a one-time code. Contemplate these questions:

  • What options will you provide for sending the code: text message, e-mail, or phone call? Will the user have more than one option available?
  • If text message or phone call, can the user save more than one phone number in their application’s profile? Can they specify the default and select the number to use for each session? Can they change or delete a saved number or change which is the default?
  • How many characters are in the one-time code and what are the valid characters?
  • How long is the one-time code good for? If it’s limited, should the application display a countdown timer? Can the user request to have the code re-sent? If so, is the same code sent again or a new code? What happens if the user enters the one-time code after the time-out period?
  • What happens if this secondary authentication attempt fails? Is the entire login session terminated, or can they try the MFA again? How many tries does the user get at the MFA action? If it’s limited, do attempts using different methods all count toward the limit?
  • Can the user opt to have their authenticated device and login recognized for some period of time so they won’t have to re-authenticate for each session? If so, how long is that period? Where should that information be stored? I use some apps that recognize my device even if I restart my browser, while others lose my remember-me setting whenever I clear the browser cookies.

I’m sure there’s even more to it than this, but you get the picture. Drilling into the particulars of an initial, concise requirement statement often opens a sizeable can of worms. The answers to the resultant questions lead to an explosion into more and more requirements. This fact is true whether the exploration is performed by a business analyst during requirements specification or by a developer who’s been tasked to write the user authentication code. The original requirement isn’t actually growing, so this process isn’t changing the project’s scope. It’s merely revealing the true scope.

The good news is that if you can craft a well-thought-out set of requirements for a complex function like user authentication, you can likely reuse them in multiple applications. At the least, they should provide an excellent starting point.

Beware the Blast

I’ve used a common nonfunctional requirement to illustrate how much complexity can hide beneath the tip of that requirement iceberg. The same can apply to functional requirements and product features, of course.

One of my consulting clients held a large workshop to gather requirement ideas for a new flagship product. One of the requirements stated, “The product shall respond to editing directives entered by voice.” This was at a time before speech recognition capabilities were built into all of our devices. That one simple requirement statement looked to be no bigger or smaller than all of the many others in the set. However, you can guess how large the requirements explosion would be when someone looked into everything involved with the details of that speech recognition feature.

Understanding the true scope of a requirement so your team can estimate and plan for its design and implementation often requires a fair amount of exploration. During that exploration, you can set the priorities of the various child requirements, perhaps deferring some functionality to later development iterations and maybe never implementing others. That thinking process is less painful than encountering one additional, unexpected need after another and continually revising the product.

======

Karl Wiegers is the author of Software Requirements Essentials (with Candase Hokanson), Software Requirements (with Joy Beatty), Software Development Pearls, The Thoughtless Design of Everyday Things, Successful Business Analysis Consulting, and numerous other books.

 

BATimes_Sep11_2024

The Mirage of AI as a Cure-All: How to Ground Executive Enthusiasm in Realistic Outcomes

In today’s fast-paced business environment, artificial intelligence (AI) is often heralded as a panacea for a wide range of organizational challenges. Whether it’s optimizing supply chains, improving customer service, or enhancing decision-making processes, AI promises to revolutionize how businesses operate. However, as any seasoned project manager or business analyst knows, the reality is far more nuanced.

Many executives, driven by the latest headlines or industry trends—often referred to as “managing-by-magazine”—may come to you with the next “big idea” for an AI project. While their enthusiasm is commendable, it can also lead to unrealistic expectations and poorly defined projects that fail to deliver the promised results.

 

The Problem with AI Hype

The marketing surrounding AI often paints it as a silver bullet capable of solving any business problem. This can create a disconnect between what executives expect and what AI can realistically achieve. Without a clear understanding of AI’s limitations and the specific problems it can solve, organizations risk investing in projects that deliver little to no return on investment (ROI).

As a project manager or business analyst, your role is to bridge the gap between executive enthusiasm and practical outcomes. This involves not only understanding AI technology but also being able to communicate its potential and limitations in a way that resonates with decision-makers.

 

Start with the Use Case

The first step in any AI project should be to thoroughly discuss the potential use cases. What specific problem is the AI solution intended to solve? How will success be measured? By framing the conversation around use cases, you can help executives focus on the practical applications of AI rather than getting swept up in the hype.

For example, if an executive is excited about using AI to improve customer service, you might start by discussing how AI could be used to automate routine inquiries, allowing human agents to focus on more complex issues. From there, you can explore the potential ROI, such as reduced call times or improved customer satisfaction scores.

 

Identify Specific Deliverables

Once the use case is clear, the next step is to identify specific deliverables. What tangible outcomes will the project produce? These could be anything from a working prototype of an AI-powered chatbot to a detailed report on how AI can be integrated into existing workflows.

By focusing on specific deliverables, you can help manage executive expectations and ensure that the project remains grounded in reality. This also makes it easier to track progress and measure success, as you will have clear milestones to work towards.

 

ROI: The Bottom Line

One of the most critical aspects of any AI project is identifying the potential ROI. This involves not only estimating the financial return but also considering the broader impact on the organization. Will the AI solution improve efficiency? Reduce costs? Enhance the customer experience?

ROI calculations should be revisited regularly throughout the project lifecycle. As new information becomes available, it’s important to reassess the potential benefits and adjust the project scope as needed. This iterative approach ensures that the project remains aligned with organizational goals and delivers real value.

 

Refine Through Requirements Gathering

Even with a clear use case, specific deliverables, and a well-defined ROI, it’s essential to continually refine the project scope through requirements gathering sessions. These sessions allow you to gather input from various stakeholders, identify potential challenges, and ensure that the project remains on track.

During these sessions, it’s important to ask probing questions to get to the heart of the matter. What are the underlying business needs? How will the AI solution integrate with existing systems? What data will be required, and how will it be managed? By addressing these questions early on, you can prevent scope creep and ensure that the project stays focused on its core objectives.

 

Advertisement

 

The Power of Business Process Mapping (BPM)

One highly effective tool for refining project scope and ensuring alignment with business objectives is Business Process Mapping (BPM). BPM is a visual representation of an organization’s workflows and processes, and it can be instrumental in highlighting inefficiencies, redundancies, and gaps within current operations.

Before diving into an AI implementation, BPM can help you and your stakeholders gain a clear understanding of how work is currently being done. By mapping out existing processes, you can identify where AI might be most beneficial, as well as areas that may need improvement before AI can be effectively integrated.

For instance, if a process map reveals that a significant amount of time is spent on manual data entry, this could be a prime area for AI automation. Conversely, if a process is already highly optimized, it might not be the best candidate for AI enhancement, helping you avoid misallocation of resources.

BPM also serves as a communication tool, providing a common language for discussing process improvements. It enables all stakeholders to visualize where changes will occur, what the expected outcomes are, and how the AI solution will fit into the broader organizational landscape. This transparency can help prevent misunderstandings and ensure that everyone is on the same page regarding the project’s goals and expectations.

 

Conclusion: Turning AI Hype into Real Results

AI has the potential to transform businesses, but it’s not a one-size-fits-all solution. By taking a thoughtful, measured approach to AI projects, you can help your organization avoid the pitfalls of “managing-by-magazine” and achieve real, tangible results.

The key to success lies in grounding executive enthusiasm in practical outcomes. This involves thoroughly discussing use cases, identifying specific deliverables, calculating potential ROI, and continually refining the project scope through requirements gathering sessions. Additionally, leveraging tools like Business Process Mapping can provide valuable insights into existing workflows, highlighting areas where AI can be most effective and ensuring that the project delivers real value.

By following this process, you can ensure that your AI projects are not only aligned with organizational goals but also contribute to the long-term success of your organization.

BATimes_Aug29_2024

Three Keys to Building a Strong Process Management Foundation

Effective process management is not something that can be built overnight but is critical to the success of process management programs. Recent research by APQC indicates that only 52% of organizations feel their process management programs are somewhat effective, and only 11% feel they are very effective. However, the survey findings also point out three opportunities for growth:

 

  1. Align process programs with organizational strategy
  2. Measure process performance
  3. Ensure a strong focus on process governance

 

Organizations looking to leverage opportunities for growth and to build their process program on a strong foundation should consider the points outlined in this article.

First, the structure.

Organizations can structure their process team in a variety of ways; and most often, the same way won’t work best for every organization. According to APQC’s research, most organizations (44%) have centralized process teams, 29% have federated teams, 14% have decentralized teams, and 13% follow an ad hoc approach.

 

While organizations will favor the structure that works best with their organization’s overall structure; there are pros and cons to consider with each structure.

 

Next, align to strategy.

Process work has traditionally involved teams driving efficiencies in cost, cycle time, and throughput. However, over the last few years, process teams are shifting these tactical objectives under broader organizational drivers. ​

While some organizations are not aligning to strategy as well as they should, 49% of organizations do align their process efforts to organizational strategy.

 

Strategy and process management activities should intertwine and inform each other. The following best practices lead to greater alignment of strategy with the work of the rest of the organization:

  1. Planning – Do not limit strategic planning processes to the corporate level, and make sure that the planning process is constantly evolving with business needs and forecasts. Continuous improvement is a best-practice mantra.
  2. Measurement – Use qualitative data in addition to carefully selected quantitative data points to set strategic plans but remember that financial numbers only tell part of the story. Qualitative information can provide the context needed to make valid decisions.
  3. Organizational structure, communication, and culture – Strategic plans should include processes for communicating strategy. The organization will never be aligned if strategy is not clearly and consistently communicated and discussed. Embed strategic planning into people’s roles, driving employees to feel motivated to contribute and feel that their time is valued.
  4. Process design – Integrate the strategic planning process with quality processes. Be sure that quality and strategy inform each other and enable enterprise success.

 

Advertisement

 

Lastly, measure process performance.

Once organizations have selected their team structure and defined their strategy, it’s time to consider how they will measure the performance of their process efforts. When organizations were asked how they use measures in managing process performance, 30% of organizations only use ad hoc measures, and 16% have no process measures at all.

 

Measurement enables decision making at all levels in the organization. Without measuring, leaders manage and make changes in the dark, without a clear view of which changes need to be made and where.

Determining which measures align with strategic goals is the first step. Once the organization selects the initial sets of measures for the different audiences (e.g., executives, business units, departments, managers, frontline workers), those measures can be tracked over time and tweaked as necessary. When an organization can look at its performance on a granular level and see how those pieces roll up into high-level metrics, it can begin to adjust in the places where they will make the biggest difference.

Don’t forget about process governance.

Organizations can have the best process program strategies, linked to organizational objectives and with smart measures in place; however, if the right governance is not in place, those plans can fail.

Governance encompasses all the structural elements that help process management function and often dictates the efficiency and speed at which an organization implements and embeds process management into its practices. Appropriate governance ensures that the right changes are made to processes and that policies surrounding process design and management are clear and relevant to the entire enterprise.

 

According to APQC’s survey, 75% of organizations have process owners present in their organization and 57% have process improvement specialists. Only 38% of organizations have champions or steering committees, which vitally provide oversight and governance for process work, help to prioritize opportunities, and align processes and process work with organizational strategy and objectives. Thankfully, the number of process sponsors and champions at organizations has improved since the last time this survey was conducted in 2020, showing the increased importance organizations have placed on these more strategic process roles.

Process management programs are not built overnight, and they all follow a different path. Starting with the key topics outlined in this article can help organizations get off on the right foot.

 

BATimes_Nov15_2023

Introduction to the 4 Pillars of Digital Transformation

In the wake of World War I, French Premier Georges Clemenceau advised the French people that “War is too important to be left to the generals”. Paraphrasing his words I would say that “Digital Transformation is too important to be left to the marketing and sales departments”- Why? Because they are infatuated with the client and it is right because it is their main objective and priorities.

While the customer is very important, I will say paramount, I believe the causes of so many pitfalls and failures in the implementation of DT (Digital Transformation) are the obsession of marketing and salespeople on the customer the hyper concentration in the customers disregarding what I believe are the foundation of DT: The Four Pillars of Digital Transformation.

Even before any consideration of the digital part (Software and Hardware) of the DT equation we need to take care of what I call the 4 pillars of Digital Transformation.

  1. Culture
  2. Process and Policies
  3. Data
  4. Security

They exist in a hierarchical cycle so while some overlapping is possible, the same that when you wear your shoes, you first need to put your socks on. In the four pillars, Culture comes first, then Processes, Data and Security.

Following the diagram of The Four Pillars of Digital Transformation:

 

Advertisement

 

For marketing and sales, a customer is an external agent, a person that buys the company’s goods (products and services) for the DT practitioner. The concepts should be broader, instead of customer we should think about USERS.

Please, do not read me wrong. The Sales and Marketing people are paramount for the success of your DT but are not the only ones, in my humble opinion. DT is a matter of life and death for your company and if the CEO and all the C-Level are not deeply involved in the DT projects the probability of success is null, zero, nada.

I am using data as a general term because what we call data is often confused with Information and Knowledge, other two important blocks of the ILC, as I explained in my article “Do we know what are Data, Information and Knowledge?” on this website.

In my other model, “The Intelligence Life Cycle” which I used to discover the AI limitations, I explained what Data, Information and Knowledge really are and created a model of the intelligence Life Cycle based on 4 axioms or postulates in the style of the ancient Greek mathematician Euclid’s. I am going to present the ILC and the Limitations of AI at the PMBA Conference in Orlando next year.

Data is not the New Oil as the hyper propaganda instigated by the media and some data scientists in search of fame, support and money claim, and as you can see from the above diagram, occupied a 3rd position in importance.

You can get more details by watching my 4 Pillars of the Digital Transformation at the Virtual BA and PM conference in Dec this year.

BATimes_Sep21_2023

Building a Business Analysis Center of Excellence: A Blueprint for Success

A Business Analysis Center of Excellence (BACoE) is a dynamic and strategic organizational asset that can significantly enhance the effectiveness and efficiency of business analysis processes. Often referred to as a Competency Development Center, a BACoE serves as a hub for collaboration, best practice management, and competency development in a specific functional area. This article explores the key elements of establishing a BACoE and its pivotal role in increasing business success.

Defining a Business Analysis Center of Excellence

A BACoE is more than just a department; it’s an organization that promotes collaboration, manages best practices, and elevates the competency level within a specific domain. Whether established as a virtual entity integrated into the broader organizational structure or a distinct group with a dedicated budget and authority, a BACoE can be staffed with either full-time or part-time members.

Creating a BACoE signifies an organization’s move toward higher organizational maturity, and as maturity increases, the risk of project failures tends to decrease.

 

Responsibilities of the BACoE

One of the primary responsibilities of a BACoE is to ensure consistent quality in business analysis artifacts throughout the organization. Variations in the quality and format of these artifacts can lead to project risks. The BACoE takes the lead in standardizing the expected quality, format, and presentation of artifacts, initially through training and artifact templates. Additionally, it promotes the use of standardized tools among business analysts and provides support for projects to maintain consistent professionalism.

 

Functions of a Business Analysis Center of Excellence

A well-established BACoE should provide support and oversight in several critical areas:

 

  • Tactical Project Assistance: The BACoE offers assistance to projects through project coaches, mentors, and staff. This includes planning business analysis activities at the project’s initiation phase, ensuring appropriate resources and approaches are in place, and providing resources as needed.

 

  • Methodology: The BACoE defines standard approaches for business analysis planning, monitoring, and execution. A methodology aligned with industry best practices, such as the IIBA®’s Business Analysis Body of Knowledge® (BABOK®), serves as a foundation for training and practice within the organization.

 

  • Best Practices: The BACoE curates a collection of company and industry-best practices for business analysis and artifact creation. This includes standards for use cases, data models, process models, and other documentation types.

 

  • Learning and Professional Development: It manages a competency model, training curricula, certifications, assessments, and practices for knowledge sharing. This includes the maintenance of knowledge repositories, discussion forums, and collaborative tools like “wikis.”

 

  • Tool Standards: The BACoE provides guidance on tools essential for preparing high-quality, standardized business analysis artifacts, including requirements management and visual modeling tools. It also maintains a repository of templates and guides for artifact preparation.

 

Advertisement

 

Forming a Business Analysis Center of Excellence

The establishment of a BACoE involves a series of steps:

 

  • Assessment of Current State: Evaluate the organization’s current business analysis maturity by assessing the skills of business analysts and gathering feedback from project managers.

 

  • Determination of Desired Future State: Define the level of maturity needed to support projects effectively.

 

  • Analysis of Gaps: Identify gaps between the current and desired states.

 

  • Specification of Desired Level of Maturity: Clearly outline the competency model and practices required to bridge the gaps.

 

  • Development of Competency Model: Create a competency model that aligns with the organization’s needs and industry best practices.

 

  • Dissemination of Improvements: Implement strategies to disseminate competency improvements through training, mentoring, and internal resources.

 

  • Maintenance and Continuous Enhancement: Regularly assess and enhance competencies through retrospectives, surveys, and ongoing training.