Feasibility Analysis for a Software

Project
 Feasibility Analysis

“A measure of how beneficial or practical the

development of a software system will be to an
organization. This analysis recurs throughout
the life cycle.”

•2
 Feasibility Checkpoints
“creeping commitment approach”

Existing System Planned Project

Planning

Support Analysis

Production Business
System Requirements

Implementation Design
Technical
Design

•3
 Existing System Planned Project
Planning

Support Analysis

Production
System

Implementation
Technical
Design
Design
Business
Requirements

Feasibility Checkpoints

• systems analysis -- study

– urgency? rough cost estimate
• systems analysis -- definition
– clearer scope, refined cost estimate
• systems design -- selection
– adjust scope, schedule, costs
• systems design -- procurement
– option check before letting contracts
• systems design -- detail design
– one last chance to cancel or downsize
•4
 Existing System Planned Project
Planning

Support Analysis

Production
System

Implementation
Technical
Design
Design
Business
Requirements

Feasibility Analysis

• Technical
– can system be developed?
• Operational
– can organization absorb the change?
• Economic
– what is business justification?
• Schedule
– can system be implemented in time available?

•5
 People

Technology Technical Feasibility

• Is the technology or solution practical?

• Do we currently possess the necessary
technology?
• Do we possess the necessary technical
expertise?

•6
People

Operational Feasibility

• Is the problem worth solving?

• Will the solution to the problem work?
• How do the end-users and managers feel
about the problem (or solution)?

•7
People

Schedule Feasibility

• Can the project deadlines be met?

• What will it cost to accelerate development?

•8
 Economic Analysis

• Cost estimates
– acquisition or development costs
– operation and maintenance costs
• Benefit estimates
– tangible benefits
– intangible benefits

•9
 Estimating Costs

• acquisition or development (one time)

• operation and support (ongoing)

• in these expense categories

– personnel hours
– computer usage
– media and supplies
– equipment and software

•10
 Estimating Acquisition Cost

• Shop the Vendors (informal)

• Request for Proposal (RFP)
• Request for Quote (RFQ)

•11
 Estimating Development Cost
• break project up into tasks
– estimate SDLC tasks independently
• use life cycle cost model
– e.g., 1-3-3-3 model
• take advantage of analogy/experience
– how much have similar projects cost?
• calculate function point metric
– estimate “size” of project from inputs, outputs, etc.
– apply productivity rate

•12
 Estimating Operation and Support

• client/user personnel
• technical personnel
• media and supplies
• equipment and software support
– repair
– enhancement

•13
 Estimating Tangible Benefits
• reduced costs
– manual operations
– computer operations
– programmed decisions
• increased revenue
– new services
– differentiated product
– faster delivery
– better quality
– larger market share

•14
 Estimating Intangible Benefits
• information quality
– precision
– timeliness
– integration
– presentation
• job satisfaction
– participative design
– job enrichment
– improved tools
• external standing
– responsiveness
– corporate image •15
 Economic Analysis (continued)

• traditional capital planning techniques apply

– payback analysis
– return on investment
– net present value

•16
 January 1996

Payback Analysis

• determines how long it will take for accrued

benefits to overtake accrued and continuing
costs
– most companies want quick payback
– 3-5 years is typical

•17
 % Return on Investment (ROI)

• determines the lifetime profitability of different

investments
– ROI = (benefits - costs) / costs)
– Annual ROI is common measure

•18
 Net Present Value (NPV)

• determines the lifetime profitability of different

investments
– NPV = discounted benefits - discounted costs
– Preferred technique in many organizations

•19
 Feasibility Matrix

Characteristics Option 1 Option 2 Option 3

(mainframe) (distributed) (client server)
Technical Low risk, Moderate risk, High risk,
No problems Some IS staff IS staff needs
are ready more training
Operational Strong user High user High user
resistence acceptance acceptance

Economic (NPV) $220,000 $180,000 $320,000

(Payback) 2.5 years 3.2 years 3 years

Schedule Jun 2013 Dec 2016 Oct 2016

 Benefit Profile Chart
(for documenting intangibles)
Some Significant New Benefit
Improvement Improvement
Better x
Communication
Current Market x
Information
Better x
Teamwork
Higher User x
Satisfaction

•21
 Things to remember

• IT’S ALWAYS POLITICS

• Find the political agendas

• You cannot get new system approved unless

you understand the environment
– Ownership
– Authority
– Reduced responsibilities or workers
•22
 Things to remember

• You will have to SELL the new system

• Possibly use a CONOPS (Concept of

Operations)

•23
Developing and Using a Concept of
Operations In Transportation
Management Systems

The Foundation for Effective System

Development and Operations
 Purpose and Project Sponsor

• Introduce the Concept of Operations and its

role in transportation management systems
• Provide an overview of guidance document
 Presentation Outline

• What is a Concept of Operations?

• Lessons Learned in Developing and Using a
Concept of Operations In Transportation
Management Systems
• Available Resources to Support Concept of
Operations Development and Use
What is a Concept of Operations?
 Concept of Operations

• The Concept of Operations should be a

document available, and relevant, to all
stakeholders in the system, no matter what
their background or role within the system. It
should be as readable and relevant to high-
level decision makers as it is to the manager
as it is to the operator. The Concept of
Operations answers the who, what, when,
where, why, and how for the new or existing
system.
Role Within
Systems
Engineering

•Graphic provided by ASE Consulting LLC

 Mature Process for System
Development
Designers Developers
Users View View View

Functional System Spec System Design Module Design

Analysis

User's System System Module

Views Reqts Spec Design Design
User
Trial Accept Integ Unit module
Test Test Test
Plan Plan Plan Plan coding

Delivered Integ Modules Coded

System System Units

Ould and Unwin 1986

“Testing in Software Development”
Acceptance System & int. Unit
testing testing testing
Concept of Operations

CONOPS

“The Big Picture”

 Common Problems
• Typical Requirements Issues
– Unable to identify “owners”
– Security/Access Responsibility
– Ownership of Process/Data/IT
– Lack of formal Requirements Process
– User Interface (too many “users”)
– Responsiveness - Status tracking
• What other Issues can you come up with?
 CONOPS1 Philosophy
• Users Perspective
• Holistic (operational) view of system
– vs. individual pieces or functions or interfaces
• First step of a development
– identify user types and primary modes
• Focus is on prioritizing user requirements at a
VERY high level
• Iterative
• Results of Conceptual
Analysis
•1 The Concept of Operations: The
Bridge from Operational Requirements
to Technical Specifications, Fairley &
Thayer, 1996.
 Goals of a Concept of Operations

• Stakeholder Identification and

Communication
• High-level System Definition
• Foundation for Lower-level System
Description
• Definition of Major User Classes and User
Activities
Elements of a Concept of Operations
 Essential Elements
• Description of current system or situation
• Description of needs that motivate new
system
• Modes of operation
• User classes / characteristics
• Operational features of the new system
 Essential Elements

• Priorities among proposed operational

features
• Operations scenarios for each operational
mode and class of user
• Limitations of proposed (new) system
• Impact analysis
 What Questions Will the Concept of
Operations Answer?
• What – What are the known elements and the high-
level capabilities of the system?
• Where – What are the geographical and physical
extents of the system?
• When – What is the time-sequence of activities that
will be performed?
• How – What resources do we need to design, build,
or retrofit the system?
• Who – Who are the stakeholders involved with the
system?
• Why – What does your organization lack that the
system will provide?
 How to write a CONOPS

• From users’ perspective

• Narrative prose (natural language) using
users’ language
• Should be organized to “tell a story”
• Should place emphasis on user need, and
maintaining tracability to those needs
 Roles for CONOPS
• To communicate user and buyer needs to
developers
• To communicate developer understanding to
user and buyer
• To show different user viewpoints
• To document consensus
• Show system vs. software
• To show common understanding between
multiple system/software developers
 Additional roles

• Verification mechanism for users

• Stating desires and expectations, without
making them quantifiable and testable
• Show thoughts and concerns of possible
solution strategies
 When do you build a CONOPS?
• Before the decision is made to develop a
system (to support decision)
• Before RFP
• After the award of contract, to help developer
better understand user needs
 CONOPS Outline
• Scope
• References
• Current system
• Justification / nature of proposed changes
• Concept of operations
• Operational scenarios
• Summary of impacts
• Analysis of proposed system
 CONOPS Process
1. Determine objectives, roles, and team
members
2. Tailor CONOPS document
3. Describe objectives and shortcomings of
current system
4. Describe scope/boundary of current /new
system
5. Describe current/new operational policies
6. Develop and validate operational scenarios
7. Prioritization
8. Analyze Operational Impacts
 CONOPTS
9. Overview of benefits, limitations,
advantages, disadvantages
10. Develop scenarios, and walk-through them
11. Walk though scenarios with users
12. Obtain consensus on scenarios
13. Describe impacts (operational and
organizational and political) of new system
14. Describe benefits, limitations, advantages
and disadvantages of new vs. old system
 Living Document

• CONOPS should be updated and maintained

during the entire lifecycle.
• Update to reflect new users, system design,
operational policies, user needs.
• Must be under configuration management
 Recommended Format
1. Scope
1.1 Identification
1.2 System overview
1.3 Document overview

2. Other referenced documents

 Scope

• The Scope section will provide an overview of

the entire Concept of Operations, including
the following elements
– Outline the Contents of the Document
– Purpose for Implementing the System
– Highlight Major Objectives and Goals
– Identify the Intended Audience
– Set Boundaries on the Scope of the System
– Describe an Overarching Vision for the System
 Referenced Documents

• Referenced Documents – this section

identifies resources used when developing
the document. Types of reference documents
that are typically listed include:
– Business Planning Documents
– Concept of Operations for Related Systems
– Requirements for Related Systems
– Studies to Identify Operational Needs
– System Development Meeting Minutes
 Recommended Format
3. Current system or situation
3.1 Background, objectives, scope
3.2 Operational policies and constraints
3.3 Description of current system
3.4 Modes of use of current system
3.5 User classes for current system
3.5.1 Organizational structure
3.5.2 Profiles of user classes
3.5.3 Interactions among user classes
3.6 Other involved personnel
3.7 Support Environment for current system
 Operational and Supporting
Environments
• This section describes the environment or “world” in
which the system will operate, including information
about the system’s environment in terms of the
following categories:
– Facilities
– Equipment
– Hardware
– Software
– Personnel
– Operational Procedures
– Support Necessary to Operate the Deployed System
 Recommended Format
4. Justification and nature of proposed new system
4.1 Justification for changes and new features
4.2 Description of changes and new system
4.3 Priorities among new features
4.4 Changes considered but not included
4.5 Assumptions and constraints
 Recommended Format
5. Concepts of operations for new system
5.1 Background, objectives and scope
5.2 Operational policies and constraints
5.3 Description of proposed system
5.4 Modes of operations
5.5 User classes for proposed system
5.5.1 Organizational structure
5.5.2 Profiles of user classes
5.5.3 Interactions among user classes
5.6 Other involved personnel
5.7 Support Environment for proposed system
 Recommended Format

6. Operational scenarios for proposed system

7. Summary of impacts
7.1 Operational impacts
7.2 Organizational Impacts
7.3 Impacts during development
 Operational Scenarios

• In this element, the authors place themselves

in the users’ position, and detail how the new
system would impact their activities under
differing conditions including:
– Stress/Failure Scenarios
– Multiple Circumstances
• Effective scenarios include a variety of user
classes
 User-Oriented Operational
Description
• This section describes the system from a user
vantage point. Typical information in this
section includes:
– User Activities
– Order of User Operations
– Operational Process Procedures
– Organizational/Personnel Structures
 Operational Needs

• This section details agency- and region-

specific goals and objectives that will drive
the requirements for the system.

• The element is attempting to answer the

question of what is necessary for the agency
or region that would complement and improve
the existing system.
 Recommended Format
8. Analysis of the proposed system
8.1 Summary of improvements
8.2 Disadvantages and limitations
8.3 Alternatives and tradeoffs considered

9. Notes

Appendices

Glossary
 System Overview

• This section provides a high-level description

of the interrelationships of key system
components, focusing on the
interrelationships among the elements. The
areas this section should address include:
– Scope
– Interfaces
– System Capabilities (Functions)
– Goals and Objectives
How to Develop a Concept of Operations
 Benefits of Developing and Using a
Concept of Operations
• Stakeholder Consensus
– Create consensus on the priority of needs for an
organization
– Bridge the gap between the technical and
operational sides of an organization
– Provide continuity over the ebbs and flows of the
economy and politics
• Reduction of Risk for the System
– Reduce the risk of schedule and cost overruns
• Improvement in the quality of operations
– Matching the agreed upon vision with the
implemented, operational system
 For more info…

• IEEE Std 1362 – 1998 is a reprint of the

Thayer and Fairley paper (jazzed up to be an
IEEE standard)
 Best Practices Identified

• Active Use of Concept of Operations

– A living document for the life-cycle of the system
– The document should be used and updated
• Use of Graphics
– Complex systems need diagrams to convey
multiple types of information at once
– Graphics can communicate the vision, goals, and
functionality of the system in a clear, non-technical
manner
 Best Practices Identified

• Scenario Development
– A broad range of user classes and operational settings
will enhance the reader’s understanding of the operations
of the system FOR ALL CLASSES OF USERS!!
• Technical Writing
– Keep the level of technical jargon as low as possible
• Stakeholder Identification
– It is important to identify all those groups and individuals
with a stake in the system, both within the scope and
those that interact externally with the system