Four Imperatives for Service Organizations Looking for a Competitive Advantage
“In this Age of the Customer, the only sustainable competitive advantage is knowledge of and engagement with customers.” – David M. Cooperstein, “Competitive Strategy In The Age Of The Customer,” October 10, 2013.
According to Forrester Research, the Age of Information is over and we are now firmly in the Age of the Customer, a time when a strategic focus on the customer matters more than any other imperative. In two insightful reports, The CIO and CMO’s Blueprint For Strategy In The Age Of The Customer, Forrester Research lists the four key strategic imperatives that are necessary to establish a competitive advantage in today’s customer-driven marketplace.
Every service organization should be following these four imperatives:
- Focus on the customer experience.
In the Age of the Customer, if we’re not strategically focused on designing and continuously improving a valuable customer experience, it is impossible to compete with the top companies in the industry. With all of the digital technologies and disruptions, today’s customer is more empowered than ever. The only way we can anticipate the needs of today’s customer and develop valuable service experiences that excite and delight is to become “customer-obsessed.” The definition of being “customer-obsessed,” according to Forrester Research:
“A customer-obsessed enterprise focuses its strategy, its energy, and its budget on processes that enhance knowledge of and engagement with customers and prioritizes these over maintaining traditional competitive barriers.” – Kyle McNabb and Josh Bernoff, “The CMO’s Blueprint For Strategy In The Age Of The Customer,” September 12, 2014.
To become customer-obsessed and successfully create excellent customer experiences, we need to improve the way we design all aspects of the experience. We have to spend all of our energy on improving our approach to designing, implementing, and managing the touchpoints in our customer’s journey so that we can provide an experience that exceeds the expectations of today’s empowered customer. This requires an overall change to the organization’s culture, capabilities, and competencies. Implementing a paradigm shift such as this one will require significant process change, a lot of collaboration and communication between the people in the organization and stakeholders, and a complete overhaul of the business techniques used to create valuable customer experiences.
- Make your business digital to create more value.
The key to keeping up with the empowered customers of today is to be more digital in every aspect of our business. While we continue to improve the way we use digital technologies to increase operational excellence, we also need to be thinking of ways to digitally create new sources of value for our customers.
Unfortunately, most organizations still lack a clear digital business vision. If there isn’t one existing yet, we need to craft a comprehensive digital business strategy, including all necessary technology, people, and processes. Furthermore, embracing digital technology should be part of every person’s responsibilities. Whether we succeed as a digital organization is not solely determined by the IT department or executives—we need everyone to start embracing digital business techniques.
- Accept and adopt the “Mobile Mind Shift.”
Mobile adoption is predicted to grow considerably by 2017, according to a report by Forrester Research. The global market can expect 651 million tablet users and 2.4 billion smartphone users by 2017. Mobile devices are used more and more every day by customers to instantly get answers and information in their moments of need.
This “Mobile Mind Shift,” as Forrester refers to it, needs to be embraced before it’s too late. To do that, we need to identify our customers’ mobile moments on the customer journey and design mobile moments in ways that engage our customers and provide value. On top of that, we need to be constantly analyzing and optimizing performance to continuously improve mobile interactions, thus improving the overall customer experience.
- Leverage big data to continue improving.
One upside to today’s empowered customer is that the more customers use our mobile apps, websites, etc., the more information we can get from them and these interactions. In the Age of the Customer, our customers leave behind “digital breadcrumbs” that need to be leveraged to continuously improve our services and create new sources of value.
For a competitive advantage, companies need to be using real-time, two-way, insight-driven data to anticipate and respond to customer needs. Exploiting all available data helps drive new, massive business insights that we weren’t capable of obtaining before. Once our organization has made the shift to the necessary culture, competencies, and capabilities to leverage all of the data shared by our customers, we see major benefits, such as improved customer engagement, increased revenue, and enhanced customer experiences.
[cta id=”8569″]
Our Favorite New Tool for Continuously Creating Value—The Value Proposition Canvas
When we’re designing new solutions for our customers, it can be easy to get caught up in the products and features we create and neglect to ensure that what we are building actually ends up delivering value to our customers. It can be challenging to acquire the necessary deep understanding of what our customers consider valuable. Value Proposition Design, described in the book of the same name written by Alexander Osterwalder, et. al., is great for organizations who are overwhelmed by the task of creating value for customers, a task which can be incredibly difficult without the proper guidance.
According to the authors of this useful method, value proposition design helps people “successfully understand the patterns of value creation” by making them easily visible. Following this method, we don’t just end up designing products, but rather entire value propositions that directly effectively target our customers’ jobs, pains, and gains.
In the book, the authors describe tools that can be used to continuously create and improve value propositions that meet customer expectations. One of the most useful tools that can be applied to discover value propositions is the Value Proposition Canvas.
The Value Proposition Canvas is made up of two sides:
- Customer Profile—This part clarifies our customer understanding
- Value Map—This part describes how we intend to create value for our customer
The goal is to achieve “Fit” between the two sides of the canvas by ensuring one agrees with the other.
The Customer Profile, or Customer Segment Profile, describes a specific customer segment by breaking it down into customer jobs, pains, and gains. Identify these three items to create a value proposition that our customers want:
- Gains—The outcomes and benefits customers seek to achieve. Once we identify customer gains, we determine the relevance of each gain, meaning whether the customer gain feels essential or just nice to have.
- Pains—The bad outcomes, risks, and obstacles related to customer jobs. We must understand how our customers measure pain severity, and determine whether each pain is extreme or moderate.
- Customer Jobs—The things customers are trying to get done in their work, expressed in their own words.
The Value Map, or Value Proposition Map, helps to describe the features of a specific value proposition by breaking it down into three parts:
- Products and Services—a list of all products and services that the value proposition is built around
- Gain Creators—How our products and services create customer gains
- Pain Relievers—How our products and services alleviate customer pains
Fit is achieved by making the Value Map meet our identified Customer Profile. The pain relievers and gain creators of the Value Map must match one or more of the jobs, pains, and gains that are important to our customer.
We suggest using an automated tool to document information that can be used in the Value Proposition Canvas. Enfocus Solutions provides software and services that help organizations identify and design value propositions to meet customer needs and solve customer problems.
[cta id=”8569″]
Are You Focusing on Service Design in 2015?
As organizations search for new ways to deliver solutions and increase customer satisfaction, many have turned to the discipline of IT service design. But still, many organizations haven’t made the transformation yet—big mistake! Don’t take our word for it; hear what the experts have to say about what exactly service design is, and why it is so important to the success of the company:
What is service design?
“The objective of ITIL Service Design is to design new IT services. The scope of Service Design includes the design of new services, as well as changes and improvements to existing ones… Service Design identifies service requirements and devises new service offerings as well as changes and improvements to existing ones.” – IT Infrastructure Library
“Service design is sometimes easiest to grasp when contrasted with product design. Product designers create tangible things such as bikes, cars, coffee machines, MP3 players, and laptops. Service designers create intangible experiences, such as the series of interactions that you have as you book a flight, pay a bill, get a driver’s license, or visit a doctor. Service designers also design the behind-the-scenes activities that enable those experiences to be delivered as planned.” – Kristina Dervojeda, et. al., Design for Innovation: Service design as a means to advance business models
“Service design applies design methods and craft to the definition and orchestration of service experiences.
Service design examines the operations, culture, and structure of an organization for impact on service experience.” – Jamin Hegeman, 5 Things I Wish I Knew: A Service Design Journey
“Service design is a relatively new discipline that asks some fundamental questions: What should the customer experience be like? What should the employee experience be like? How does a company remain true to its brand, to its core business assets and stay relevant to customers? It has grown as our economies have moved from being primarily manufacturing based to service based, and as our world becomes increasingly complex, networked, and interconnected via technology. It uses design methodologies, but applies new, heuristic design tools to develop service models that delight both users and employees who deliver services.” – James Rock, managing director and chief business designer for Cultivar Consulting Limited
Why is service design so important?
“A positive customer experience doesn’t happen by chance. It must be designed.” – Jin Zwicky, VP Group Customer Experience, OCBC Bank
“No consumers ever buys a product. Consumers buy what products provide.” – Peter Drucker, business and management specialist
“There’s been a lot of focus on product innovation over the years, but very little discussion or thought on innovation in the service sector – despite the vast growth of that part of our economy.” – John Byrne, editor-in-chief Fast Company magazine
“Mobile behaviors and user expectations for an engaging digital experience are changing. People now desire a more intuitive and meaningful interaction from both brands and their services. That’s why we put them at the center of what we do.” – Kristina Dervojeda, et. al., Design for Innovation: Service design as a means to advance business models
“Service design is underused by many of the companies all around the world. Services are a growth area but service design is often poorly planned. A perfect statistic that illustrates this reality, is that 80% of companies think they offer a superior service, yet only 8% of their customers agree.” – Nelly Trakidou, Service Designer and blogger
“Customers are… becoming more demanding so it is… very important that… service organizations develop highly responsive service recovery processes. In the rapidly growing world of social media, customers are becoming more vocal and very quick to complain about poor service to thousands of friends and followers on Facebook and Twitter. This “word of mouth” effect is playing a bigger and bigger role in brand marketing campaigns. So I think it’s only natural that organizations recognize they need to constantly improve and reinvent the way [services are] delivered to make sure they delight rather than disappoint customers. – James Rock, managing director and chief business designer for Cultivar Consulting Limited
[cta id=”7662″]
Service Portfolio Vs. Service Catalog: What’s the Difference?
Maintaining the service portfolio is a great way to identify service enhancements, document service definitions, and determine which services need to be retired or replaced.
But, we have a service catalog, you say. So we’re gonna move along.
Wait a minute. Sorry to break the news, but you need to go back and do some work on an actual service portfolio. The service portfolio is not the same as the service catalog. An IT Service Portfolio describes services in terms of business value, specifying what the services are, how they’re bundled or packaged, and what business benefits they provide. It’s articulated from the customer’s perspective and answers the following questions, according to ITIL: Service Strategy:
- Why should customers buy our service?
- Why should they buy this service from us?
- What features and components do customers want and are willing to pay for?
- What is the demand for the service?
- What are customers willing to pay for our service?
- What resources are needed to provide the service?
On the other hand, an IT Service Catalog is a service order and demand-channeling mechanism, which is a fancy term for a website. It takes services that are already defined in the service portfolio and describes them as offerings that a customer can buy through an online service catalog. You need the foundation of the service portfolio before creating a useful service catalog.
Too many IT organizations rush to define the catalog without starting with the portfolio, causing services to be poorly understood and insufficiently defined. Those organizations are probably currently in the process of overhauling their service catalog, if they haven’t already.
Those new to service portfolio management should consider the strategies below, taken from ITIL:
- Define business services, which are IT services designed to directly support strategic capabilities
- Define technical services, which are the IT services needed to support business services
- Implement service portfolio management best practices for:
- Launching a new service
- Retiring a service
- Enhancing services
- Rationalize the application portfolio, or alter the strategy for particular products, to identify opportunities for savings and free up funds to support transformation
[cta id=”8434″]
How Do You Know if a Software Feature is Done?
A clearly-defined Definition of Done is absolutely essential to agile software development.
At the end of every sprint or increment, software is demonstrated to the product owner and relevant stakeholders to make sure that the increment is done. But too often, we end up accepting the work completed during the increment even though it isn’t truly done yet – “DONE-done,” as we call it at Enfocus Solutions.
A Definition of Done creates a shared understanding of what it means to be finished. According to AgileAlliance.org, the Definition of Done is a list of criteria that must be met before a product increment is considered “Done.” The Definition of Done is also an expression of the team’s quality standards. A more precise Definition of Done is often associated with the delivery of higher quality solutions. Generally, the team will increase their velocity as their Definition of Done gets refined, because they will improve release planning and spend less time fixing old problems.
The most important function of the Definition of Done is that it provides a clear description of what it means for an increment to be done and ready to be implemented. It helps us avoid misunderstandings and miscommunications, and makes sure that there’s transparency around what the team is doing during the sprint.
It is difficult to pin down a Definition of Done that suits all circumstances. Each organization needs to define their own definition; the checklist found in this pocket guide is meant to serve as a guideline for building your own Definition of Done for an iteration.
Here’s a couple tips for dealing with the Definition of Done:
Tie the Definition of Done into Inspect and Adapt (I&A) activities
The solution should be continuously inspected during development by people on all levels (i.e., portfolio, program, and team) to ensure the solution increment is completed. During I&A, everyone should refer to the agreed-upon Definition of Done to make sure everyone is still operating on the same scale of “done.”
Document the Definition of Done using Verifications in Enfocus Solutions’ software
By documenting the Definition of Done in a collaborative software tool like the one provided by Enfocus Solutions, we provide transparency to what’s going on and make sure everyone is on the same page. There’s no need to constantly ask, “Is it done yet?” because you can check on the progress yourself.
[cta id=”8404″]
Inspect and Adapt Activities Should Be Happening All the Time
At Enfocus Solutions, we’ve adopted much of the Scaled Agile Framework®, the premiere scaling framework for scaling agile developed by Dean Leffingwell and Scaled Agile, Inc. One of the many aspects of the framework that makes it such a useful tool is Leffingwell’s concept of Inspect and Adapt Workshops.
Building on one of the principles taken from the Agile Manifesto that, “at regular intervals, the team reflects on how to become more effective,” SAFe® incorporates the Inspect and Adapt (I&A) workshop at the end of a release or Program Increment (PI). According to SAFe®, “I&A is to a Release Train what the sprint demo and retrospective are to a team—a regular, programmatic, time to reflect, problem solve, and take on improvement actions [to] identify actions needed to increase the velocity, quality and reliability of the next increment.”
When discussing the Inspect and Adapt workshop, the Scaled Agile Framework® describes I&A activities occurring only on the program level. However, at Enfocus Solutions, we like to take it a step further and carry out Inspect and Adapt activities at every level: portfolio, program, and team. This way, we review the solution constantly, making it more likely that we catch problems and issues as they happen, instead of during a demo with a stakeholder.
At each level in the organization, there are activities that can be performed that will help ensure your teams are continuously inspecting and adapting, not just during program level events:
- Portfolio—A formal Performance Evaluation (or, inspection) should take place to ensure the Program Portfolio achieves the desired performance by measuring business outcomes against predetermined KPIs. There may be some required course corrections (or, adaptations) based on the evaluation.
- Program—I&A workshops are still a valid event for inspect and adapt activities; the program level is just not the only level at which I&A events should occur.
- Team—The individual development team (usually a Scrum team) should inspect what went well and what needs to change, adapting to any changes as necessary. While at the program level we focus I&A activities on finding solution changes, at the team level we’re focused on what needs to change to help the team collaborate and communicate better and increase team velocity.
Using Enfocus Requirements Suite™, Enfocus Solutions’ premiere solution for scaling agile to the enterprise, issues that would normally be found during an I&A workshop are identified at any point in the project and documented as individual issues to be assigned to specific team members, speeding up project velocity and increasing solution quality.
For more information on what should be going on at the portfolio, program, and team levels, download the Enterprise Agile Project Management Pocket Guide below.
[cta id=”8404″]
Agile Project Management Q&A
You guys did it again! Our last webinar, Enterprise Agile Project Management, was an incredible success. There were many thoughtful questions asked that I unfortunately didn’t have the time to answer. The Webinar Q&A can now be downloaded alongside the rest of the webinar resources, including the recording and slide deck. Here are a few of the questions asked during the webinar:
Q: Today, the role of scrum master is the same as Project Manager in traditional projects, they just use different terminology and PDM process. Is this correct?
A: A Scrum Master and a Project Manager are not the same. Organizations that have made this assumption have seen disastrous results. The traditional Project Manager is a leader, a decision maker, and a planner who manages the project and his team, and is the person accountable to the business for accomplishing the project objectives. The role of the Scrum Master is more of a coaching and facilitation role, a role that sits between the project and the customer.
Q: Is Project Manager role the same as Product Manager role in this presentation? I’ve just submitted for a position that states the role as a PO and went on to state tasks as a PM. I personally don’t think this is a successful set up. Please advise.
A: No, the project manager and the product manager are not the same role. The project manager is responsible for managing releases and associated business change. The project manager also manages assignments among multiple teams when multiple teams are involved. The product manager is responsible for determining what new features are needed in the product. I also agree with you that what you described is not a successful setup.
Q: In reality, the self-managing and self-organized team is a very rare case. In addition, ramp-up and growing a team up to this level of cooperation and collaboration is expensive and toward to project end. So, how do you handle this ‘assumption’ that the team shall be ‘self-ready’?
A: Your point is accurate—you don’t make the switch to agile overnight. It requires a cultural change and training for teams.
Q: Can agile documentation have templates? For example in waterfall, we have templates for Scope Analysis, Business Requirements etc.
A: In agile, you can have templates, if it saves time and money. Generally the goal is to reduce the amount of documentation and this means eliminating many of the so-called templates that have been in place. If you do use templates, start from scratch—do not try to apply waterfall templates to an agile environment.
Q: What would you say are some cons of agile?
A: Agile has been proven to deliver higher quality products faster than traditional waterfall. Standish Group research shows that agile projects are three times more likely to be successful than traditional projects. The cons are dealing with organizational change and cultural issues to get there. For example, completely restructuring the role for BAs and PMs has not been easy for many organizations.
For more questions and answers, download the Enterprise Agile Project Management Webinar Q&A along with all of the other free webinar resources.
[cta id=”7436″]
The Business Analyst as Explorer (Part 6 of 6): User Requirements and Use Cases
The business requirements will help the business analyst identify potential user classes for the product. The objective of exploring user requirements is to understand what members of these user classes expect to be able to do with the product and how the product will let them achieve specific goals. The user requirements must align with the higher-level business goals captured in the business requirements.
Some user goals might pertain to tasks the users must perform; use cases often are an effective way to record these tasks. Other user goals, though, might indicate the importance of specific nonfunctional requirements. Examples include the ability to complete a task within a certain length of time, and the ability to access a system remotely from a smart phone. Therefore, user requirements also encompass the users’ expectations about performance, availability, usability, reliability, and other quality attributes.
It’s also important to surface pertinent business rules, design and implementation constraints, and assumptions the various stakeholders might be making. The objective is for the BA to understand what customers are envisioning so he can record both functional and nonfunctional requirements that will guide the development team’s work. Furthermore, documented requirements and user acceptance criteria will help testers determine whether the delivered product satisfies its requirements.
When eliciting user requirements, the BA typically works with a number of key users who represent specific user classes. The BA needs to ask questions that will help those users describe the goals they want to accomplish with the help of the system. For most types of software projects, this is far more valuable than the traditional focus of requirements discussions on system features and functions. The emphasis on user tasks or goals is the essence of the use case approach to requirements elicitation. Scenarios and stories also emphasize a usage-centric perspective to requirements elicitation.
Instead of asking, “What do you want?” or even “What do you want the system to do?” an approach based on usage and user goals asks, “What do you need to do with the product?” Your users might not be accustomed to a dialogue of this nature. It can be difficult to shift their thinking from the traditional focus on the system itself, so some education of your user representatives is in order. It’s not realistic to think you can simply ask the users what their use cases are and get a meaningful response. Even if you explain what use cases are, don’t expect users to hand you a tidy, precise, and complete list of their use cases. The BA must work with the input that users provide to determine the real goals they have in mind.
I sometimes use the example of an airline flight reservation kiosk when describing use cases in my training seminars. Instead of just asking the class what their use cases would be for such a product, I ask, “What are some things you would imagine doing with an airline flight reservation kiosk?” A variant question is, “What are some reasons you would want to use an airline flight reservation kiosk?” During the class discussion, some of the responses are indeed candidates for use cases, although they still need to pass through a filter that asks “Is this in scope?” before we determine that they belong in the system we’re exploring. These use cases include:
- Find Available Flights for an Itinerary
- Make a Flight Reservation
- Select Seats
- Print an Itinerary
- Change a Reservation
- Cancel a Reservation
- Check on Flight Status (This one might not be in scope because it requires real-time access to current flight information from the airlines. The business requirements should indicate whether this sort of capability will help us achieve our business objectives.)
Notice that all these use cases begin with a verb. This is a standard convention for naming use cases. The BAs should listen for responses from customers that do not begin with a verb and discuss the intent behind each such response. Once when I held this discussion in a class and asked, “What are some things you would imagine doing with an airline flight reservation kiosk?” one student simply said, “Weather.” This one-word response prompted me to explore exactly what aspect of weather the student had in mind, to find an appropriate verb. Did she want to create the weather, change the weather, or what? I learned that she wanted to check the weather forecast at the originating, destination, and connection cities for a specific flight itinerary. Hunting for the verb the customer has in mind is a way to discover the task or goal behind the initially presented input.
Just because a user provides a response that begins with a verb doesn’t mean that it’s actually a use case. Someone might suggest as a possible use case, “Enter my frequent-flier number.” A use case should describe a standalone task: A user has a specific goal in mind, walks up to the system, interacts with it in some way, and—if all goes well—achieves the goal and walks away happy. However, no one would ever walk up to this kiosk, enter his frequent-flier number, and feel fulfilled. I needed a follow-up discussion to determine what the user was really trying to accomplish by entering a frequent-flier number. Some possibilities are:
- See how many miles he has accrued.
- Purchase a ticket using frequent-flier miles.
- Purchase a seat upgrade using frequent-flier miles.
- See if he has received mileage credit from a previous flight, car rental, or hotel stay.
- Recall his stored profile so that he doesn’t have to reenter a lot of information when making a reservation.
The first four of these items are use cases, something a user might do as a standalone task. The last one, though, doesn’t represent a discrete task. It’s likely part of some other use case, such as Make a Flight Reservation. The main point here is that the BA must expect to work with users to determine whether a piece of presented input is a user task, a bit of system functionality, a quality attribute, a constraint, a business rule, extraneous information, or something else.
Author Bio:
Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is Software Requirements, 3rd Edition, co-authored with Joy Beatty (Microsoft Press, 2013).
The Business Analyst as Explorer (Part 5 of 6): Why Ask Why?
“Why?” is an excellent question to put in the business analyst’s bag of tricks. During a reengineering project, a BA named Dawn asked one of the developers why a utility company fee calculation was being performed a certain way in the existing system. “There’s a government statute that dictates how we have to calculate these fees,” was the reply. Upon investigation, Dawn discovered that in fact the current system had not implemented the computation correctly according to that statute. The system had calculated these utility fees incorrectly for an embarrassingly long time. This discrepancy never would have come to light had Dawn simply accepted the stated need for the current formula. Asking “why” revealed a major error that the replacement system corrected.
The shrewd BA asks why a lot. It’s important that “why” explorations be expressed in a way that doesn’t sound confrontational, accusatory, or challenging. I often ask questions that begin this way: “Can you please help me understand…” This phrase is longer than why and means essentially the same thing, but it has a more collaborative feel to it.
When a user representative presents a requirement that contains an embedded solution idea, asking why can let you know whether the solution idea is a true design constraint or just an idea or suggestion. Asking why several times in succession is a way to drill down from a superficially proposed customer “want” to the real underlying need. This helps the software team address the real issue, not just a superficially presented issue. Gently probing with why can reveal other sorts of useful information:
- The answer to why might point out a business rule that affects the project. Then you can check to see whether the business rule is still pertinent and whether the information you have available for it is complete and accurate. You can discover whether and where the business rule is documented, who’s responsible for maintaining the information, and whether there are related rules you need to know about.
- Asking why sometimes surfaces assumptions held by the person you’re questioning. An assumption is a statement that you regard as being true in the absence of definitive knowledge that it is It’s important to try to identify assumptions that various stakeholders might be making. Those assumptions could be incorrect or obsolete. They could be at odds with assumptions other people are making. Such conflicts make it harder for the stakeholders to have shared project expectations.
- Asking why can reveal implicit requirements that no one thought to casino online mention yet.
- The answer to “Why is this requirement included?” supplies the rationale behind the requirement. It’s always a good idea to know where each requirement came from and why it needs to be included in the project. This can help the BA learn about requests that lie outside the project scope. This question sometimes also exposes that the “requirement” is really a design idea for an unstated higher-level requirement.
- Suppose you encounter a requirement that a user representative presented as being high priority. It doesn’t look that important or urgent to you. If you ask why it’s high priority, perhaps you’ll learn that it’s logically connected to other requirements that also are high priority. Without this knowledge, someone might unwittingly defer the requirement that doesn’t seem so important, thereby crippling the related requirements that are scheduled for early implementation.
- Sometimes the BA thinks she understands a requirement, only to discover upon further investigation that she really doesn’t. Asking why a requirement is necessary a few times could provide additional details that solidify the BA’s understanding of that requirement.
- Asking why or similar questions can help the BA distinguish essential requirements knowledge from extraneous information.
Asking why might save you a lot of work. One project was replacing an existing customer relationship management (CRM) system with a package solution. Senior management directed the team to use out-of-the-box features from the package as much as possible and to limit the extent of configuration or changes to the package. One user representative asked that a specific function be added, a counter that indicated how many times a customer had used a certain product feature. It would have cost a significant amount to modify the core package to accommodate this requirement.
When the BA asked why that function was needed, the user said that the function was present in the current CRM application. The BA probed further: “What exactly does this counter show?” “Why do you check it?” “What action do you take depending on what it tells you?” This discussion eventually revealed that several stakeholders all thought that someone else was using the data. In reality, no one used it at all! By asking “why” a few times, the BA and user representative agreed that the function wasn’t needed, thereby saving a significant amount of money.
A BA needs to be a bit of a skeptic. Don’t believe everything you hear, and don’t accept it all at face value. Ask “why” enough times to give you confidence that you’ve got the real requirements in hand.
Author Bio:
Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is Software Requirements, 3rd Edition, co-authored with Joy Beatty (Microsoft Press, 2013).
[cta id=”8310″]
The Business Analyst as Explorer (Part 4 of 6): Questions for Eliciting User Requirements
This article (adapted from my book More About Software Requirements) presents several sets of questions the business analyst might consider asking customer representatives during a discussion about user requirements. Don’t use these questions as a script to be followed by rote in an elicitation workshop. Instead, look for ways to build these sorts of questions into the natural flow of a requirements exploration.
What are some reasons why you or your colleagues would use the new product? These “reasons to use” could become candidates for use cases. They might identify business tasks or objectives that members of a particular user class might need to achieve from time to time.
What goals might you have in mind that this product could help you accomplish? Use cases normally are directed toward helping the user achieve a specific goal. The name of the use case indicates the goal the user has in mind: Print a Boarding Pass, Withdraw Cash, Submit an Employment Application, and so on.
What problems do you expect this product to solve for you? Understanding the problems and limitations the users perceive in their current environment helps the business analyst determine appropriate capabilities for the new system. This question also helps determine whether the end users’ objectives for the system align well with senior management’s objectives, as captured in the business requirements. If not, you need to iterate between the business requirements and user requirements to align expectations.
What external events are associated with the product? BAs sometimes use the term business event to describe the triggering condition that launches execution of a use case. Perhaps a help desk receives a phone call from a user who needs assistance. This external event triggers the help desk staffer to create a problem report ticket. In products such as real-time control systems, use cases aren’t a valuable technique for understanding user requirements. An alternative approach is to identify the external events the system must detect. Then describe the appropriate system response, which depends on the state the system is in at the time each event is detected.
Most requirements discussions focus on functionality. However, a product’s nonfunctional characteristics also have a great impact on how users feel about the product. Questions such as the ones that follow help the BA understand the user’s expectations about aspects of the product’s quality.
What words would you use to describe the product? Consider asking users to close their eyes and describe their vision of the future system. Listen to the words they use to describe the product. Nouns suggest objects the system must be able to manipulate (such as order, reservation, chemical, account balance, sensor). Verbs can indicate actions the user expects to be able to take or expects the system to take (such as place, create, revise, submit, receive, detect, measure, display). Adverbs convey the user’s thoughts about the product’s characteristics (for example, quickly, reliably, efficiently, flexibly, easily).
Are specific portions of the product more critical than others for performance, reliability, security, safety, availability, or other characteristics? You can never create a product that combines the maximum levels of all quality characteristics. Tradeoffs are necessary between properties such as usability and efficiency, integrity and usability, and integrity and interoperability. (See Chapter 14 of my book with Joy Beatty, Software Requirements, 3rd Edition, for more about such quality attribute tradeoffs.) Therefore, it’s important to understand which specific portions or aspects of the product have critical quality demands so that developers can optimize their designs to achieve those objectives.
Are there any constraints or rules to which the product must conform? Most products are subject to corporate policies, industry standards, government regulations, and computational algorithms. It’s essential to know about such business rules so the BA can specify functional requirements to enforce or comply with those rules. Look for subject matter experts within the organization who have current knowledge about the business rules.
How is the product you envision similar to the way you do business now? How should it be different? When automating current business processes or replacing an existing information system with a new one, it’s easy to inadvertently re-implement all the shortcomings of the current approaches. This is known as “repaving the cow paths.” It’s difficult for people to break from the mindset of their current ways of working and to envision something that’s really different and better. The BA should stimulate the thinking of the user representatives to rethink business rules and business processes to see what has changed—or what could change.
What aspects of the current product or business process do you want to retain? To replace? Customer acceptance of a new product depends partly on how familiar it feels to them. Similarity to previous products and processes reduces the learning curve, making it easier for users to master a new system and workflow.
The following questions help the BA gain a richer understanding of how potential users view the product. Asking these questions of people who represent different stakeholder groups can reveal conflicts that you’ll need to reconcile.
Which aspects of the product are most critical to creating business value? A user’s view of business value might be different from a manager’s view or an acquiring customer’s view. A user might value a more efficient way to perform a specific task that will save considerable time over many executions. A manager could be more impressed if the product has lower acquisition and support costs than the one it’s replacing.
What aspect of the product will be most valuable to you? Least valuable? No project can deliver everything to everybody on day one. Someone needs to determine the implementation sequence for various capabilities. Ask this question of different user representatives, and look for patterns that indicate certain product capabilities are more important and more urgent than others. Those capabilities should have top priority.
What is most important to you about the product? This deliberately vague question could generate responses dealing either with the product itself or with other aspects of the project. One user might say, “It’s most important that this system be available before the beginning of the next fiscal year.” Another might respond, “It’s most important that this system will let me import all my data from these older systems we’ve been using.” A manager might say, “It’s most important that the people in my department can get up to speed on this new system without training.” These responses have implications for how the project is planned, the functionality to include, and usability, respectively.
How would you judge whether the product is a success? A business manager might judge the success of the product quite differently from how members of various user classes determine success. Surface these different perspectives early so that they can be reconciled to keep all stakeholders working toward a common objective.
Can you describe the environment in which the product will be used? The operating environment has a big impact on both requirements and design decisions. The user interface is also highly sensitive to the operating environment. Touch screen displays are superior to keyboards in some settings, for example, and speech recognition is becoming increasingly effective for certain applications.
The more the BA can learn about how users intend to employ the product, the better she can do at determining and specifying the functionality that developers need to implement. When you get right down to it, users don’t really care about product features; they care about getting their job done efficiently and maybe even enjoyably.
Author Bio:
Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is Software Requirements, 3rd Edition, co-authored with Joy Beatty (Microsoft Press, 2013).
[cta id=”8310″]