Solution Assessment and - Memphis TN IIBA Chapter - The IIBA by fdshsdhs

VIEWS: 18 PAGES: 46

									 International Institute of Business Analysis

                      Purpose:
                        - To assess proposed solutions in order to determine how
                        closely they meet stakeholder and solution requirements.
Chapter 7
                      Value:
Solution Assessment     - Ensuring that the process of reviewing, selecting, and
                        designing the solution is done in a way that maximizes value
& Validation
                        delivered to stakeholders. The business analyst knows the
                        business environment and can assess how each proposed
                        solution would affect that environment.




                                                                                   1
Solution Assessment and Validation Relationship to
other Knowledge Areas




                    Greater Memphis
                                                     2
                        Chapter
Solution Assessment and Validation
IIBA Operational Vision
Input/Output Diagram
                                     Typo: ;)
                                     Outputs




                 Greater Memphis
                                                3
                     Chapter
Solution Assessment & Validation Inputs/Outputs


   Q: What are the Tasks necessary for Assessment and
    Validation?
    1.   Assess Proposed Solution
    2.   Prioritize Requirements
    3.   Allocate Requirements
    4.   Assess Organizational Readiness
    5.   Define Transition Requirements
    6.   Validate Solution
    7.   Evaluate Solution Performance


                         Greater Memphis
                                                     4
                             Chapter
7.1 Assess Proposed Solution

 Purpose 7.1.1
    To assess proposed solutions in order to determine how closely they meet
     stakeholder and solution requirements.
 Description 7.1.2
    Solution assessment may be performed on a single solution or to compare
     multiple proposed solutions.
    When assessing a single solution, the business analyst determines whether
     the solution delivers enough business value to justify its implementation. This
     will most often be the case when a custom solution has been created to meet
     a particular business need.
    When assessing multiple alternative solutions, the business analyst has the
     additional goal of attempting to determine which solution delivers the greatest
     business value. This requires understanding the advantages and
     disadvantages of each alternative.


                                Greater Memphis
                                                                                   5
                                    Chapter
7.1 Assess Proposed Solution

   Q. Which of the following are NOT inputs into this
    Task?
    1.   Assumptions and Constraints?
    2.   Solution Scope
    3.   Solution Option(s)
    4.   Requirements [Prioritized and Approved]
    5.   Business Case




                          Greater Memphis
                                                         6
                              Chapter
7.1 Assess Proposed Solution

   Which of the following tasks help the business analyst
    determine which solution delivers the greatest
    business value when assessing solutions?
    1.   Assumptions and Constraints
    2.   Business Need
    3.   Requirements [Prioritized and Approved]
    4.   Solution Options(s)




                               Greater Memphis
                                                         7
                                   Chapter
7.1 Assess Proposed Solution

 Q: When relatively few criteria are involved, it may be
  easier to focus on the criteria where substantive
  differences exist between solution options.
  (True/False?)




                       Greater Memphis
                                                            8
                           Chapter
7.1 Assess Proposed Solution

 Q: Sometimes solution options will offer capabilities that
  are not part of the prioritized and approved
  requirements or the business case. These additional
  capabilities should NOT be used as part of the
  evaluation. This is scope creep. (True/False?)




                       Greater Memphis
                                                          9
                           Chapter
7.1 Assess Proposed Solution

   Q: Which of the following are techniques of Assessing
    a Proposed Solution?
    1.   Acceptance and Evaluation Criteria Definition
    2.   Decision Analysis
    3.   Observation
    4.   Vendor Assessment
    5.   Focus Groups




                          Greater Memphis
                                                         10
                              Chapter
7.1 Assess Proposed Solution

 The output for this task is
    Assessment of Proposed Solution
 What are examples of Supporting Materials?




                       Greater Memphis
                                               11
                           Chapter
  7.1 Assess Proposed Solution
Business
Components
a/k/a Process
Areas
Each
Component will
implement a
subset of
requirements




                   Greater Memphis
                                     12
                       Chapter
7.1 Assess Proposed Solution




                 Greater Memphis
                                   13
                     Chapter
7.1 Assess Proposed Solution




                 Greater Memphis
                                   14
                     Chapter
7.1 Assess Proposed Solution




                 Greater Memphis
                                   15
                     Chapter
7.2 Allocate Requirements

   7.2.1 Purpose
       Allocate stakeholder and solution requirements among solution components and
       releases in order to maximize the possible business value given the options and
       alternatives generated by the design.
   7.2.2 Description
       Requirements allocation is the process of assigning stakeholder and solution
       requirements to solution components and to releases. Allocation is supported by
       assessing the tradeoffs between alternatives in order to maximize benefits and
       minimize costs. The business value of a solution changes depending on how
       requirements are implemented and when the solution becomes available to
       stakeholders, and the objective of allocation is to maximize that value.

       Requirements may be allocated between organizational units, between job functions,
       between people and software, software application components or releases of solution.
       Requirements allocation typically begins early in the project lifecycle (as soon as the
       solution approach can be determined) and will continue to be performed until all valid
       requirements are allocated. Allocation typically continues through design and
       construction of a solution.




                                   Greater Memphis
                                                                                          16
                                       Chapter
7.2 Allocate Requirements

 Q: What Inputs from Task 7.1 are same for 7.2?



 Q: What Inputs are in new for 7.2?




                      Greater Memphis
                                                   17
                          Chapter
7.2 Allocate Requirements

 The allocation of requirements to solution components
  will be a primary driver of the cost to implement the
  solution and the benefits delivered by it.

 Q: What are some examples of solution components?




                      Greater Memphis
                                                          18
                          Chapter
7.2 Allocate Requirements

   Q: When may it be necessary to revisit the initial
    allocation of functionality between components as
    defined in the solution scope?
    1. Solution Design
    2. Organizational Readiness Assessment




                       Greater Memphis
                                                         19
                           Chapter
7.2 Allocate Requirements

   Q: As costs and effort are understood for each
    solution component, which of the following are likely to
    be considered effective tradeoffs between delivery
    options?
    1. Available resources
    2. Constraints on the solution
    3. Dependencies between requirements




                       Greater Memphis
                                                          20
                           Chapter
7.2 Allocate Requirements

   Q: Which of the following techniques are NOT
    essential to Allocate Requirements?
    1.   Acceptance and Evaluation Criteria Definition
    2.   Business Rules Analysis
    3.   Decision Analysis
    4.   Functional Decomposition
    5.   Process Modeling
    6.   Interface Analysis
    7.   Scenarios and Use Cases


                          Greater Memphis
                                                         21
                              Chapter
7.2 Allocate Requirements

   Q: Which stakeholder is NOT listed that will be affected by how
    and when requirements are implemented and may have to be
    consulted about, or agree to, the allocation decisions?
    1.   Domain SME
    2.   End User
    3.   Implementation SME
    4.   Operational Support
    5.   Project Manager
    6.   Tester
    7.   Sponsor




                               Greater Memphis
                                                                      22
                                   Chapter
7.2 Allocate Requirements

 Q: The Output of the Allocate Requirements task is a
  document of the requirements associated with the
  solution components. (True/False?)




                      Greater Memphis
                                                         23
                          Chapter
7.3 Assess Organizational Readiness

 Purpose: Assess whether the organization is ready to make effective use
  of a new solution.

 Description: An organizational readiness assessment describes the
  effect a new solution will have on an organization and whether the
  organization is prepared for the organizational change that the solution
  implementation will cause. Effective communication of solution impacts
  assists in enabling necessary organizational change management
  practices and identifying training requirements for solution
  implementation. In order to identify impacts the business analyst should
  understand what changes will occur in the business area, technical
  infrastructure or processes and how these affect other business units or
  operations.



                             Greater Memphis
                                                                        24
                                 Chapter
7.3 Assess Organizational Readiness

 In order to identify impacts the business analyst should
  understand what in order to communicate the effect a new
  solution will have on an organization?




                       Greater Memphis
                                                             25
                           Chapter
7.3 Assess Organizational Readiness

   Which of the following is an input into this Task?
    1.   Enterprise Architecture
    2.   Solution Designed
    3.   Solution Scope
    4.   Stakeholder concerns
    5.   Assumptions and Constraints




                         Greater Memphis
                                                         26
                             Chapter
7.3 Assess Organizational Readiness

   Key concepts to consider when assessing the
    organizational readiness are:
    1. Cultural Assessment
    2. Operational or Technical Assessment
    3. Stakeholder Impact Analysis

   Q: To understand how change will affect a particular
    Stakeholder group (refer #3) what things may be
    considered in an impact analysis?


                       Greater Memphis
                                                           27
                           Chapter
7.3 Assess Organizational Readiness

   Q: Which of the techniques listed are considered ‘general
    techniques’ for assessing organizational readiness?
    1.   Force Field Analysis
    2.   SWOT Analysis
    3.   Risk Analysis
    4.   Problem Tracking
    5.   Organization Modeling
    6.   Focus Groups, Interviews, Survey/Questionnaire
    7.   Data Flow Diagrams and Process Models
    8.   Acceptance and Evaluation Criteria Definition




                             Greater Memphis
                                                                28
                                 Chapter
7.3 Assess Organizational Readiness

   Q: The output of an Organizational Readiness
    Assessment document describes whether stakeholders
    are prepared to accept the change associated with a
    solution and are able to use it effectively. Which of the
    following may need revisions based on this
    assessment?
    1. Solution Scope
    2. Project Scope
    3. Assessment of proposed solution



                       Greater Memphis
                                                          29
                           Chapter
7.4 Define Transition Requirements

   Purpose: To define requirements for capabilities needed to transition from an existing solution to a new solution.

   Description: In most cases, a solution is implemented within an enterprise in order to enhance or replace an
    existing solution. During the transition period (the time when both the old and new solutions are operational), the
    enterprise may need to operate both solutions in parallel, move information between the new and old solution,
    conduct training to enable stakeholders to effectively operate the new solution, and so forth. In addition to
    developing the solution itself, the implementation team is likely to have to develop additional capabilities to
    support this transition.

    These capabilities are requirements, as stakeholders need to be able to make this transition successfully—but
    they are different in nature from other kinds of requirements, as they cannot be defined until a solution has been
    designed. These requirements also have a different lifespan from other types of requirements, as they remain
    relevant only during the transition period between solutions.

    Transition requirements are elicited, analyzed, managed, and communicated by performing the same tasks as
    for other requirements. The difference is not in the methods for defining them, but in the inputs, the nature of
    transition requirements, and in that they cease to be relevant once the existing solution is eliminated.

    In instances where there is no existing solution, and the new solution is adding a entirely new capability to the
    enterprise rather than extending and improving an existing capability, then transition requirements do not need
    to be analyzed.




                                             Greater Memphis
                                                                                                                   30
                                                 Chapter
7.4 Define Transition Requirements

   Q: When are Transition requirements defined?
    1. After the solution is designed?
    2. Before the solution is designed?




                        Greater Memphis
                                                   31
                            Chapter
7.4 Define Transition Requirements

   Which of the following are NOT inputs to Transition
    Requirements?
    1.   Organizational Readiness Assessment
    2.   Requirements [Stated]
    3.   Solution [Deployed]
    4.   Solution [Designed]
    5.   Solution Scope




                         Greater Memphis
                                                          32
                             Chapter
7.4 Define Transition Requirements

 Likely sources of transition requirements include what?




                      Greater Memphis
                                                        33
                          Chapter
7.4 Define Transition Requirements

   Which of the following are NOT techniques used for
    defining transition requirements?
    1.   Business Rules Analysis
    2.   Data flow Diagrams
    3.   Functional Decomposition
    4.   Scenarios and Use Cases
    5.   Process Modeling
    6.   Organization Modeling
    7.   Data Modeling


                         Greater Memphis
                                                         34
                             Chapter
7.5 Validate Solution

 Purpose: Validate that a solution meets the business need and
  determine the most appropriate response to identified defects.

 Description: Solution validation is required to ensure that a
  delivered solution meets the business needs on an ongoing basis.
  Problems that are identified through solution validation will be
  reported and prioritized for resolution. When a problem is
  identified with the solution (i.e., a failure to meet a stakeholder
  need, whether or not the requirement was correctly specified) the
  business analyst will be able to help the team determine the most
  appropriate action.


                          Greater Memphis
                                                                   35
                              Chapter
7.5 Validate Solution

   Q. Which of the following are NOT inputs into this
    Task?
    1. Solution [Constructed]
    2. Solution [Deployed]
    3. Requirements [Prioritized and Validated]




                        Greater Memphis
                                                         36
                            Chapter
7.5 Validate Solution

 Q: An example of a defective output is a requirement
  that has been changed more than once before it is
  implemented. (True/False?)




                     Greater Memphis
                                                         37
                         Chapter
7.5 Validate Solution

   Which of the following techniques are used to
    determine the if the output is a symptom of a deeper
    underlying problem?
    1. Acceptance and Evaluation Criteria Definition
    2. Root Cause Analysis
    3. Problem Tracking




                        Greater Memphis
                                                           38
                            Chapter
7.5 Validate Solution

   Which stakeholder is missing from this task?
    1.   Domain SME
    2.   End User
    3.   Implementation SME
    4.   Operational Support
    5.   Project Manager
    6.   Regulator
    7.   Sponsor



                         Greater Memphis
                                                   39
                             Chapter
7.5 Validate Solution

   The outputs to the Validate Solution task include:
    1. Identified defects
    2. Mitigating Actions
    3. Solution Validation Assessment

    (True/False?)




                       Greater Memphis
                                                         40
                           Chapter
7.6 Evaluate Solution Performance

 Purpose: Evaluate functioning solutions to understand the value they
  deliver and identify opportunities for improvement:

 Description: Solution evaluation involves investigating how a solution is
  actually used after it is deployed, and assessing the effect it has had,
  both positive and negative. It may also be referred to as post-
  implementation assessment when performed immediately following the
  completion of a project.

 Solutions may be adapted and modified directly by end users, including
  use of manual workarounds, recording of additional information, and
  adoption of informal policies and procedures in order to resolve problems
  that have occurred or to allow new uses of the solution. In order to
  properly evaluate the solution, it is also necessary to understand when,
  where and why this has occurred and asses the benefit that these
  changes have brought to the organization.


                             Greater Memphis
                                                                          41
                                 Chapter
7.6 Evaluate Solution Performance

   There are four inputs to this task, which one is
    missing?
    1.   Business Requirements
    2.   Identified Defects
    3.   Solution Performance Metrics
    4.   ?




                         Greater Memphis
                                                       42
                             Chapter
7.6 Evaluate Solution Performance

   Key concepts to consider when evaluating a solution
    performance can include:
       Understand Value Delivered by Solution
       Validate Solution Metrics
       Solution Replacement or Elimination
           Ongoing Cost versus Initial Investment
           Opportunity Cost
           Necessity
           Sunk Cost




                             Greater Memphis
                                                          43
                                 Chapter
7.6 Evaluate Solution Performance

   Which techniques is NOT used for this task?
    1.   Decision Analysis
    2.   Focus Groups
    3.   Observation
    4.   Survey/Questionnaire
    5.   Lessons Learned Process




                        Greater Memphis
                                                  44
                            Chapter
7.6 Evaluate Solution Performance

 Q: The output of the Evaluate Solution Performance is
  the Solution Performance Design document.
  (True/False?)




                     Greater Memphis
                                                      45
                         Chapter
Solution Assessment & Validation




              Questions?




                 Greater Memphis
                                   46
                     Chapter

								
To top