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 scenariobased 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. Defining the Problem or OpportunityLead 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. Creating a Shared VisionLead Advocacy Group: Product Management As discussed in Chapter 2, "Understanding Solution Delivery Environments," 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. Figure 7-8. A shared vision gives a team direction
Project vision is best expressed in the form of a vision statement. Although conciseno more than a paragraphthe 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:
Defining High-Level RequirementsLead 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 itthose 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.). "Finding" RequirementsHigh-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, "Understanding Solution Delivery Environments," and sources of risk referenced in Chapter 5, "Managing Project Risks." These include the following:
Writing RequirementsHigh-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).
Creating User ProfilesLead 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. Forming Solution Design StrategiesLead 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). Architectural Design StrategyAn 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. Figure 7-9. Example of a conceptual architectureTechnical Design StrategyThe technical design strategy maps out alternate technologies to implement the architectural design strategy. It is a high-level description of the key products and technologies to be considered for use in building a solution. Developing a Conceptual Understanding of a SolutionLead Advocacy Group: Product Management It is very hard to conjure up a well-structured solution without detailed requirementsusually 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.
Defining Acceptance CriteriaAcceptance 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:
Note that people and priorities can change over the course of a project, so all acceptance criteria should be periodically reviewed and refined accordingly. User Acceptance CriteriaLead 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. Operations Acceptance CriteriaLead 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. Customer Acceptance CriteriaLead 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). |