Defining a solution is an evolutionary and coordinated effort between team members and key stakeholders. Typically, a team consists of just a few core members and a few key stakeholders such as sponsors and subject matter experts (often users). They work together to identify, analyze, and define the problem or opportunity. Their wrestling with defining the problem or opportunity usually generates many competing ideas on how to address the problem or opportunity. These ideas are vetted and refined into a shared vision of a solution and a few approaches to deliver the solution. Continuing to refine and define their understanding of what is needed, a team defines high-level requirements for a solution as well as develops an understanding of who and what will use a solution through a set of user scenario–based techniques (e.g., personas, use cases, usage scenarios, user stories). All of this is rolled into a conceptual definition of a solution.
The following sections expand upon these activities.
Lead Advocacy Group: Product Management
How does a team quickly get to a workable definition of the problem or opportunity? It might be challenging with a high potential of getting sidetracked discussing noncritical aspects of a solution. This activity is best served if a team establishes some guidelines as to how much and what level of detail to provide while trying to define the problem or opportunity.
Establishing these guidelines is essential because much of the information comes from interviewing existing users and stakeholders, and they do not take too kindly to repeated "clarification" or "oops, we need a little bit more" interviews. When talking with these people about addressing existing problems, it is important to get to the root cause of their pain and not solicit the deficiencies of the features and functions of the current system. Also, try to stay away from technology-based discussions and focus on business-oriented discussions (e.g., strategic capabilities, business processes, customer experience). Before talking with anyone, a team should consider the type of information and how it will be represented, consolidated, and stored for future analysis.
Lead Advocacy Group: Product Management
As discussed in Chapter 2, a vision is a concise description, in business terms, of the overall mission. A shared vision orients a team in a common direction, reinforces solution goals, simplifies and ensures consistency in decision making, motivates the team, and maintains focus on solution quality. Not reaching consensus on a shared vision leads to loss of time and effort, as whimsically shown in Figure 7-8.
Project vision is best expressed in the form of a vision statement. Although concise—no more than a paragraph—the vision statement describes where the business is going and how the proposed solution will help to achieve business value. A good example of a vision statement is this:
I believe this nation should commit itself to achieving the goal...of landing a man on the Moon and returning him safely to the Earth. No single space project...will be more impressive to mankind, or more important for the long-range exploration of space... | ||
--President John F. Kennedy, Speech to U.S. Congress, May 25, 1961 |
Lead Advocacy Group: Product Management
High-level requirements are a descriptive way to bound the vision into something deliverable. They are brief statements of what a solution needs to do, not how a solution needs to do it—those are implementation details left for later. Requirements statements are gathered using techniques such as interviewing, surveys, prototyping, measuring, observing, and examining existing documentation. As discussed later, high-level requirements are decomposed into actionable detailed requirements. But first, high-level requirements need to be defined and reflected in a medium to be shared with the team and stakeholders (e.g., documented in specifications, represented within modeling and design tool(s), explained through user stories, etc.).
High-level requirements should holistically describe the totality of a solution (i.e., cover every aspect of a solution and its interactions with the outside world) and the environment and constraints under which a solution must operate. They reflect the way users and administrators need to interact with a solution (e.g., a field inspector needs a portable data entry device). As such, high-level requirements can come from many sources. Common sources of high-level requirements are consistent with environmental challenges referenced in Chapter 2, and sources of risk referenced in Chapter 5. These include the following:
Environmental. Legal, regulatory, facilities, business governance, site topology, legacy solutions
People. User needs, reflection of skills and abilities of user and administrator, support, training, customer enhancement requests
Organizational. Processes, procedures, roles, structure
Schedule. Time to market
Quality features and functions. Competitive, differentiating
Operational. Qualities of service (discussed in Chapter 8, high-priority fixes
Data. Sources, targets, structures, rules, retention, auditing
Usability. Performance and usability enhancements
Technology. Hardware, software, networks, communications, infrastructure, security
High-level requirements can be expressed in terms of functionality (e.g., new policy data entry form for an insurance solution) as well as rules or parameters that apply to that functionality (e.g., policyholders are limited to one policy per specific property). Like any requirement, high-level requirements need to be "SMART" (i.e., specific, measurable, achievable, results-oriented, and time-bound).[2] Statements like "a solution needs to work as fast as possible" are not requirements. How would a team write the acceptance criteria for that "requirement"? It is not measurable. When writing requirements, it is handy to keep in mind how someone would "test" the requirement. One construct to consider is thinking that all requirements must be evaluated by either inspection (observing behavior; e.g., the light blinks as expected), analysis (mathematically verified; e.g., mean time between failure), demonstration (show that it works; e.g., submitted data is properly formatted in a report), or test (measured behavior; e.g., system responds in less than 1.25 seconds).
Lead Advocacy Group: Product Management
Many different approaches and methodologies have their own name for representing a relevant and respectful description of typical users (e.g., user profiles, personas, actors). To avoid confusion, herein, they are referred to as user profiles and are defined as descriptions of the eventual users of a solution in terms of geography, organizational and communication structures, user functions, resource availability, knowledge, skills, abilities, goals, motives, concerns, usage patterns, and other relevant information.
To develop user profiles, a team needs to identify categories of users (e.g., remote user) by segmenting and differentiating user activities and interactions with a solution. It might be necessary to segment the categories further by user skill level (e.g., senior account manager). If possible, it is helpful to add user expectations of a solution.
Lead Advocacy Group: Architecture
Solution design strategies represent notional approaches to implement the conceptual solution. Typically as part of the conceptual solution, a team develops a conceptual architecture and sometimes adds envisioned vendor products and solutions that might be used (i.e., to support "buy" vs. "build" decision approaches).
An architectural design strategy describes how the different aspects of a solution will operate together. As exemplified in Figure 7-9, a diagram is an excellent means of illustrating these components and relationships. It enables customers, who often understand more when provided images, to visualize a solution in its environment.
Lead Advocacy Group: Product Management
It is very hard to conjure up a well-structured solution without detailed requirements—usually not sufficiently known until midway through a Plan Track. However, a team can start to form a conceptual understanding of how to solve the problem or realize the opportunity. This involves describing features and requirements in high-level terms. It likely includes a series of high-level "approaches" with matching conceptual architectures.
The conceptual solution should contain as much as is known about a solution, its operations, success criteria, and expectations associated with it, including any assumptions and constraints. A solution should be described in terms of business and design goals with matching objectives that enable achievement of the goals.
The conceptual solution should address all functional areas of the various advocacy groups. Table 7-3 provides a sample of the typical approaches covered in a conceptual solution for each advocacy group.
Table 7-3. Typical Approaches in a Solution Concept by Advocacy Group
Approach | Advocacy Group |
---|---|
Design and architecture approach | Architecture |
Communications and marketing approach | Product Management |
Project/quality assurance approach | Program Management |
Development approach | Development |
Deployment and operations approach | Release/Operations |
Usability | User Experience |
Testing approach | Test |
Acceptance criteria define the terms, conditions, and/or metrics that must be satisfied for the reviewer(s) to sign-off on a solution. They represent that a solution has met the agreed-to requirements and conditions. Within MSF, there are three types of acceptance criteria:
Although not called acceptance criteria, MSF also has the following gating criteria, discussed later, that must be satisfied before proceeding in their respective areas:
Success criteria. What are necessary to declare an event, process, or activity a success
Quality criteria. Define required quality—sometimes collectively defining a quality bar
Release criteria. What are necessary to release to a selected environment (e.g., no active issues, satisfy all solution quality criteria, meet stakeholder needs and expectations, satisfy user acceptance criteria, satisfy operations acceptance criteria)
Pilot completion criteria. What are necessary to conclude a pilot successfully
Note that people and priorities can change over the course of a project, so all acceptance criteria should be periodically reviewed and refined accordingly.
Lead Advocacy Group: User Experience
Although some users are likely to work with a project team throughout a project, key user champions that are empowered to "accept" a solution on behalf of all users should work with a project team during an Envision Track to define a set of acceptance criteria. Typically, user acceptance criteria focus on usability and capability from an end user’s perspective. In a Stabilize Track, a team will present a solution to these user champions for their review and comment. A team will work with these users to refine a solution until it meets user criteria, and then it is expected that they sign off on a solution.
Lead Advocacy Group: Release/Operations
An operations team establishes operations-specific acceptance criteria with a project team as to the operations team’s criteria for deploying a solution into the production environment. Typical operations acceptance criteria focus on operational readiness (e.g., operation and support team training), deployment, and qualities of service. Satisfying these criteria signifies that an operations team is willing to assume responsibility for a solution and proceed with solution deployment.
Lead Advocacy Group: Product Management
Customer acceptance is part of project closure and sign-off, which happens at the end of a project. Typical customer acceptance criteria establish the terms and conditions for the customer to take receipt of a solution (e.g., upon successful deployment, the customer takes ownership of a solution) and collateral expected at the end of a project (e.g., lessons learned).
[2] There are a few variants of the definition of SMART. The A is also referenced as attainable; the R is also referenced as realistic, and the T is also is referenced as time-oriented and time-constrained. Because they all roughly imply the same, which variant you use does not really make a difference as long as the point comes across.
18.118.163.250