1.       What is a Commercial-Off-The Shelf (COTS) Solution?

Organizations are relying more and more on commercial applications to enhance, supplement or replace existing systems.  These commercial applications also provide a means to exploit new opportunities that might not have been feasible if custom build had been required.  There is a broad spectrum to approaching COTS implementations from plain vanilla (out of the box) to highly customization of the COTS solution.  The business analysis deliverables will vary from a custom build, however still required for a successful solution in the eyes of the stakeholders.

·       Buying solutions versus custom build solutions

·       Spectrum of COTS Solution implementations

·       Terminology around COTS Solutions

·       Review of Types of Requirements

·       Roles of the Business Analyst on a COTS Solution project

Practice Sessions:

·       Terminology Exercise

·       Requirement Type Exercise

·       COTS Business Analyst Role Brainstorm

 

2.       The Business Case for Business Analysis on COTS Projects

COTS solutions can open new possibilities for organizations but are many times advertised as deceptively simple.  Hence, the business analysis effort is many times rushed to just start building the software.  Failure to successfully select, control, and implement critical components continues to result in projects that are delivered late and over-budget or that fail entirely.  Then, if we consider the price of meeting only the short-term goal/problem; business analysis becomes increasingly important to look further into the future.  The COTS solution may solve the problem today, however if it cannot be easily modified or designed to meet future needs, it is not the right solution.

·       Increased Value 

·       Risk Mitigation

·       Understanding the organization’s expected value for “buying” – does business analysis play a part?

o   Reduced cost of ownership

o   Mitigate the lack of capability to develop and maintain proprietary information technology applications

o   Improved functionality

o   Profound Benefits to IT organization

​

Practice Sessions:

·       Factors to Improve Success

·       Traceability to organization’s capability model

 

3.       Understand the Problem and WHO is impacted

The golden rule is that the software solution must solve the business problem; otherwise it is not the right solution.  The ideal situation when working on a COTS project is one in which you elicit and analyze business requirements from the stakeholders before selecting a solution.  Too often you are faced with a pre-determined purchase of software packages and then your team is asked to implement the software after the fact.  In any case it is never too late to ensure we understand what problem we are trying to solve and who is expected to be impacted.

·       Problem statement discovery

·       Business Requirements

​

Practice Sessions:

·       Develop stakeholder analysis using a stakeholder map

·       Develop problem statement using situation statement

·       Develop a vision board to serve as an abbreviated business case

 

4.       Scoping the Solution

After we have a clear understanding of the problem to be solved with the expected benefits, we can scope the solution.  With the decision of a COTS solution approach, the stakeholders’ expectations must be set of trade-offs that are likely down the road and how much time and money the organization is willing to invest for a user-centric approach.  Developing just enough documentation to provide scope in the form of Stakeholder Requirements will be practiced in this section.

·       Setting Stakeholder Expectations  

·       Stakeholder Requirements

o   What functionality must be supported

o   What conceptual data is supported and in what manner

o   What chunks of business rules should we be aware of

o   What conditions must be supported

·       Scope Definition

​

Practice Sessions:

·       Facilitate consensus on approach

·       Develop functional decomposition to depict expected functionality to fulfill

·       Develop context diagram to understand expected actors

·       Prioritize functional "chunks"

·       Develop high-level conceptual data model and state diagram for important object

·       Brainstorm collections of business rules

·       Identify non-functional aspects to be supported

·       Develop scope definition to guide vendor engagement

 

5.       Business Analysis in the Vendor Selection Process

In this section, you will be introduced to mechanics of developing requirements for seeking vendor feedback and Vendor Analysis and then practice.

·       Types of requests for vendor feedback

·       Who is involved in developing requests for vendor feedback

·       Vendor analysis boilerplate

·       Understanding gap analysis components

·       Building the business case for vendor selection

 

Practice Sessions:

·       Develop an vendor evaluation criteria

·       Analyze potential offerings developing a list of vendors to request a response

·       Develop business analysis portion of Request for Proposal (RFP)

·       Perform vendor gap analysis

·       Make vendor recommendation

​

6.       Solution Requirements (COTS-Style)

In this section, you will be introduced to mechanics of developing solution requirements to inform the development team COTS-style and then practice.

·       Solution Requirement Types – COTS-Style

·       End User Process Impact Analysis

 

Practice Sessions:

·       Develop solution requirements – COTS-Style 

o  Develop user story map

o   Elaborate user stories with acceptance criteria, interface/integration requirements, data definition, and  business rules

·       Estimate the cost of user impact

​

7.       Working with the Development Team

There are multiple opportunities during the requirements engineering activities to interface with the development team.  It is likely that there will be both in-house and vendor team members with varying degrees of involvement through the lifecycle.  You will ensure there is clear understanding of the problem to be solved, stakeholder requirements and finally work together to ensure solution requirements (COTS-style) are feasible.  It is likely that negotiations will arise, and the liaison role is filled by the business analyst. 

·      Transition Requirements

·      Getting Real with Examples

·      Trade-offs

​

Practice Sessions:

·      Develop process models to support process change required

·      Discover configuration and extension requirements

·      Specify examples using Gherkin Syntax 

·      Development of mutually acceptable resolutions

​

8.       Evaluating the Solution

Based on COTS implementation studies, many delivered solutions fail to meet the business needs and end-user expectations.  This leads to inefficiencies and practices that negate the anticipated benefits.  In this section, you will develop an understanding of seeking out continuous improvement in solutions at play in your organization.

·       Success measurements

·       Continuous improvement strategies

 

Practice Sessions:

·       Refine business case success measurements

·       Perform root cause analysis using causal tree

 

Wrap-up