Defining a Solution


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 Opportunity

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.

Creating a Shared Vision

Lead 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:

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

Clarity Point

Instead of calling it a "vision statement," teams sometimes call it a "mission statement." The difference is semantics. A "mission statement" often is more constrained and more focused than a vision statement is. A vision statement seems less bounded and leaves constraining to a project scope.


Lesson Learned

Sometimes it is good to have two vision statementsa brief one (couple of sentences) that people are able to memorize easily and an expanded one that more richly describes the vision.


Defining High-Level Requirements

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 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" Requirements

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, "Understanding Solution Delivery Environments," and sources of risk referenced in Chapter 5, "Managing Project Risks." 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, "MSF Plan Track: Planning a Solution)," high-priority fixes

  • Risk Degree(s) of tolerance and avoidance

  • Data Sources, targets, structures, rules, retention, auditing

  • Usability Performance and usability enhancements

  • Technology Hardware, software, networks, communications, infrastructure, security

Writing Requirements

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).

[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.

Creating User Profiles

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.

Forming Solution Design Strategies

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).

Architectural Design Strategy

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.

Figure 7-9. Example of a conceptual architecture


Technical Design Strategy

The 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 Solution

Lead 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.

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


Defining Acceptance Criteria

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:

  • User acceptance criteria

  • Operations acceptance criteria

  • Customer 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 qualitysometimes 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.

User Acceptance Criteria

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.

Operations Acceptance Criteria

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.

Customer Acceptance Criteria

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).




MicrosoftR Solutions Framework Essentials. Building Successful Technology Solutions
Microsoft Solutions Framework Essentials: Building Successful Technology Solutions
ISBN: 0735623538
EAN: 2147483647
Year: 2006
Pages: 137

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net