Learner Guide

Learner guide
ICTSAD506 - Produce a
feasibility report
TABLE OF CONTENTS
Contents
Introduction ..................................................................................................................... 2
Chapter 1: Confirm client requirement ........................................................................... 3
1.1 Confirm client requirements to determine project scope and the problem
context or opportunity faced by the business ............................................................. 3
1.2 Review documented client requirements, project scope, related problems and
sources of information ................................................................................................. 3
1.3 Confirm requirements and scope with the client .............................................. 3
CHAPTER 2. Examine and review alternatives ............................................................... 12
2.1 Ensure that future client requirements are considered ...................................... 12
2.2 Research and document feasible solutions for client requirements ................... 12
2.3 Ensure that the feasibility of each solution has been assessed, including
constraints .................................................................................................................. 12
Chapter 3. Prepare and publish feasibility report ......................................................... 20
3.1 Prepare a feasibility report................................................................................... 20
3.2 Ensure that the completed feasibility report covers client requirements, project
scope and analysis of alternative scenarios ............................................................... 20
3.3 Confirm the recommendation of the preferred scenario .................................... 20
3.4 Present feasibility report to the appropriate person for project approval ......... 20
Learner Guide -ICTSAD506 - Produce a feasibility report V1.0 Dec 2019 Review: Dec 2020 Page 1 of 33
INTRODUCTION
This learner guide is about the knowledge and skills required for:
• Investigating client requirements, determining project

scope, problems and opportunities
• Confirming client requirements and scope with the client.
• Documentation of the business problem and
identification of the developed objectives and expected
results.
• Identification of the information gathering mechanisms
from the clients and their relevant issues and recording
the client responses.
• Examining and reviewing the new alternatives
• Researching and documenting the feasible solutions for client requirements.
• Ensuring the feasibility of each solution has been assessed, including constraints.
• Implementation of the new systems after the analysis of the physical requirements.
• Classification of the documents as per the business requirements, its submission and
verification of its accuracy.
• Checking of the feasibility report according to the client’s requirements and submitting of the
document for final approval and sign off.
What will I learn
The learning materials provide opportunities for collecting client’s requirements and analysis of these
requirements. Different techniques for acquisition of the information from the clients are to be discussed.
Also, the information gathering techniques used are to be according to the business requirements. This guide
also helps to learn the documentation of the required information along with the response of the client.
Analysis of the information and handling the requirements and identifying the changes to the new system
are done. Preparing a feasibility report and relevant documentation. Documentation is always of immense
importance, so all the verifications and clarifications of the documents as per the organization’s policy and
client’s requirements are ensured. Also, it provides the learner with the opportunity to learn how to submit
the documents and sign off for final approval.
CHAPTER 1: CONFIRM CLIENT REQUIREMENT
This chapter will help you learn about the following:
• Confirm client requirements to determine project scope and the problem context or
opportunity faced by the business
• Review documented client requirements, project scope, related problems and sources of
information
• Confirm requirements and scope with the client
1.1 Confirm client requirements to determine project scope and the problem context
or opportunity faced by the business
1.2 Review documented client requirements, project scope, related problems and
sources of information
1.3 Confirm requirements and scope with the client
Albert Einstein once said, “If I were given one hour to save the planet, I would spend 59 minutes defining the
problem and one minute resolving it.” While that may sound extreme, it does highlight the importance of
defining problems. It also hints at some interesting facts: A well-defined problem often contains its own
solution within it, and that solution is usually quite obvious and straightforward. By defining problems
properly, you make them easier to solve, which means saving time, money and resources.
Every business person needs to master the ability to understand client requirements, define problems, or
challenges.
Understanding client requirements
Client requirements are things that a client wants, needs or expects in a product or service. The following
are common types of client needs.
Functionality and features
Clients need products and services to accomplish objectives. For example, a client needs a refrigerator that
makes small ice cubes.
Price
A client needs a product or service that meets their budget objectives or constraints. For example, a student
needs a reliable bicycle for under $100.
Time & Convenience
Requirements for products and services that save time and are easy to use. For example, a hotel that is close
to major attractions.
Terms
A client requires certain terms of service. For example, a mobile network client requires privacy such that
their location and data isn't sold to third parties.
Experience
Expectations regarding end-to-end client experience. For example, a client may require a hotel that feels
elegant and tranquil.
Look
A client requires a product in a particular style and colour.
Design
Design related requirements such as usability. For example, a client requires a baby stroller that is easy to
fold.
Status & Identity
Clients may view certain types of products and service as an extension of their identity and element of their
social status. For example, a client may require clothing that doesn't have a visible brand logo.
Reliability & Durability
Clients often have requirements that products and services be reliable, available and durable. For example,
an airline requires aircraft that can be operated safely for many hours each month.
Performance
Performance requirements such as speed or accuracy. For example, a client requires a software service that
can process a million transactions an hour.
Efficiency
Client requirements for efficient resource utilization. For example, a customer requires solar panels with a
high conversion efficiency.
Safety
A client may have safety-related requirements. For example, a client may strongly prefer vehicles that do
well in crash tests.
Quality of Life
Requirements related to the quality of life such as a client that expects healthy menu items from a restaurant.
Risk
Needs related to risk such as a client that requires delivery insurance.
Formulations
A client needs a product with specific ingredients such as a moisturizer made with shea butter.
Sustainability
Requirements related to community impact, ethics and the environment.
Packaging
A client needs a product that is easy to open and reseal.
Integration & Compatibility
Requirements for products and services to work with other products and services. For example, a mobile
device that accepts memory cards.
Standards & Compliance
A client may require that a product or service adhere to a particular set of standards or rules. For example,
a restaurant may require organic certifications for its ingredients.
Project scope
A challenge we encounter quite often when first working with new clients is defining, at a fairly granular
level, a project’s scope. Often organisations know what they want in terms of high-level project deliverables
but have not gotten down to the nitty gritty stuff – but that’s what we’re here for!
Project scope is the part of project planning that involves determining and documenting a list of specific
project goals, deliverables, features, functions, tasks, deadlines, and ultimately costs.
In other words, it is what needs to be achieved and the work that must be done to deliver a project.
It is important to pin down the scope early in a project’s life cycle as it can greatly impact the schedule or
cost (or both) of the project down the track.
Below is an overview of some of the key processes to follow in order to define scope correctly.
Project scope management
Project scope management includes the processes required to ensure that the project includes all the work
required, and only the work required, to complete the project successfully. The Project Manager defines and
controls what is, and what is not, included in the project, and manages any change to the scope. Scope
management occurs throughout the project life cycle and is actively reviewed at regular intervals and as new
or more detailed information becomes available.
Clearly defining the scope of a project is vital to ensure that all stakeholders understand:
• Where we are
• Where we want to go
• How we will get there
Define the Product Requirements
Before we determine what will be in the project’s scope, you must be very clear about what are the product
requirements, otherwise known as product scope. In other words, what are the functions and features
required for the website, application and/or software solution being developed? Is there anything
specifically that must be built into the design? Must it follow a specific set of branding guidelines? The list
goes on.
Define the Process Requirements
Process requirements describe how people interact with a product and how a product interacts with other
(often existing) business processes. When you discuss how data gets moved and how business transactions
flow from one point to another, you are describing process requirements. For example, the requirements
for billing transactions within a website, how such transactions link to invoicing and accounts, and at what
point can staff view and alter the status of orders need to be detailed.
Involve the correct stakeholders
It, of course, goes without saying that for a project to be delivered successfully, the correct stakeholders
from the organisation commissioning the project must be involved very intimately at various stages of the
project scope. When this does not occur, assumptions begin to be made (which are generally subjective) and
stakeholder confusion can occur as the project goes on.
Identify the limitations
Perhaps even more important than what is in-scope for a project is what is out-of-scope for a project. Often
it is crucial to document what will not be done – otherwise, people will assume that certain things are to be
executed that were not budgeted for or included in the project timeline.
Change Management
It is natural for parts of any large project to change along the way. While it is always best to avoid scope
creep (a situation in which one or more parts of a project ends up requiring more work), sometimes it is
unavoidable due to the changing nature of any business. In order to avoid disagreements and changes to a
project’s scope by all stakeholders, both client-side and agency-side, it is best to have strict change
management processes in place.
Once the scope is defined, it must not be

changed without the appropriate change
management functions taking place, at
which point appropriate action can be
taken to address the shifting project
requirements.
So there you have it! A simple guide to

getting your project off to the right start
by correctly defining your project scope.
At its very basis, effective scope
management requires good
communication to ensure that everyone
understands the requirements of the
project and agrees upon exactly how the
project’s goals will be met. Once you
have this bedded down, you have the
foundation to commence and hopefully
successfully complete your project.
System scope and boundaries
There are two places that scope is defined on your project. The high-level scope is defined in your project
charter. The low-level scope is defined in your business requirements document.
The high-level scope consists of two main components.
Deliverables. If you can't remember anything else about scope, list your deliverables. Defining your
deliverables goes a long way toward defining the overall scope of the project.
Boundaries. You should also try to define the boundaries of your project. Boundary statements help to
separate the things that are applicable to your project from those areas that are out of scope. Examples of
boundary statements include:
This project will affect AUS operations only. All other locations are out of scope.
We will deliver our solution to the Finance and Legal departments. All other departments are out of scope.
Investigate and identify problems, opportunities and objectives
Analysing your business systems for potential improvement begins with gaining an understanding of what
you do and what methods you currently utilise to deliver your product(s) or service(s). In addition, clearly
stated objectives help to refine the desired outcome of an analysis of your business systems. The analysis
will focus on identified issues or processes, based on the experience and recommendations of employees
and managers and the approval of executives.
We look at the ‘who’ (people involved); ‘what’ (business activity); ‘where’ (work environment); ‘when’
(timing/sequence); and ‘how ‘(current procedures) of the selected areas of your business. In addition to this,
we want to understand why business is currently conducted in this manner.
Interviews with managers, executives and employees may be conducted and their comments, issues, and
desires for improvements documented. Questionnaires may be developed and distributed, and their results
collated. Important processes may be documented, step-by-step, with flow-charts and/or in writing. Current
reports may be reviewed; new reports may be detailed. Paper forms may be gathered and examined. Staff
interactions with clients and/or processes may be observed.
Present findings and alternatives
The result of the above effort is usually a feasibility report, which is a summary of the information gathered,
an estimate of the scope of the project, and presentation of alternative solutions for consideration. Review
and discussion of the document should lead to a commitment to the issues to be addressed and the chosen
alternative for responding to those issues. Decision makers within the organisation should be able to plan
and commit to improvements in the system based on their response to this document.
The feasibility report can be responded to in many ways. The scope of the project could be expanded or
contracted. Management could conclude that no changes are desired now, or that only a select number of
items will respond to. This is the point at which organisational decisions and commitments must be made
regarding how to proceed.
Designing the improved system
Once decisions have been made about what issues will be addressed and alternative solutions have been
selected, these are consolidated into a description of the proposed new system.
The proposed new system might require the development of custom software like a database. It may only
require that new forms or procedures be created, or some combination of possible solutions. The goal is to
meet business objectives and to address the issues identified.
If the System Proposal calls for new procedures, forms, etc. then any specific details not previously identified
must be fleshed out, and documentation created, reviewed and approved.
The scope of the project will dictate how to proceed from this point. If the System Proposal identifies an off-
the-shelf software product then the design will be relatively fixed and we can move on to the implementation
phase. It should be noted that for most established fields, off-the-shelf software could meet 80 – 95% of the
needs of an organization, and this option should be considered before committing to a custom application
development project.
Implementing, evaluating and maintaining the new system
Implementing the new system involves user training, the successful conversion of data from the old system
to the new, upgrading and/or installing any needed equipment to support the system, and bringing the new
system online.
Although evaluation should be taking place in every phase of analysis and design, users often cannot predict
what issues will arise until the new system has been implemented. This is often the first opportunity users
have to experience the application as a whole, and thus to critique what and how the application performs
in relation to their expectations and experience. Implementing should include ongoing user evaluation of
the system after installation.
Maintaining the new system involves an ongoing cycle in response to the need for bug fixes,
hardware/software updates, business system process changes and implementing additional features
requested by users or management.
What is a problem context?
A set of considerations constituting a problem situation including the goal, constraints, as well as
environmental conditions. Your goal in looking through the data is to try to understand several aspects of
the data you have:
• What patterns do you see in the way people describe their problem?
• What do you know about what's causing the problem?
• What are the various consequences of the problem?
• Which aspects of the problem seem changeable?
Self-check assessment
Question 1: What are the most common client requirements?
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
Question 2: How can you design the process requirements?
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
Question 3: How can you present your findings and recommendations to the stakeholders?
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
______________________________________________________________________________________
CHAPTER 2. EXAMINE AND REVIEW ALTERNATIVES
This chapter helps to understand the following:
• Ensure that future client requirements are considered

• Research and document feasible solutions for client requirements
• Ensure that the feasibility of each solution has been assessed, including constraints
2.1 Ensure that future client requirements are considered

2.2 Research and document feasible solutions for client requirements
2.3 Ensure that the feasibility of each solution has been assessed, including
constraints
Feasibility study
The purpose of the feasibility study is to find out if a project can be possible and justified. It also suggests
possible alternative solutions to meet future client requirements. It provides management with critical
information about:
• Whether the project can be done

• Whether the final product will benefit its intended users
• What the alternatives are (so that a selection can be made in subsequent phases)
• Whether there is a preferred alternative
The feasibility study is a management-oriented activity where management and its key people, ultimately,
decideds a “go or no-go” decision. It starts by examining the problem in the context of a broader business
strategy.
How to analyse the future client requirements
Things you must consider analysing the future client requirements are:
• The present organisation system (Stakeholders, users, policies, functions, objectives,...)

• Problems with the present system (inconsistencies, inadequacies in functionality,
performance,…)
• Goals and other requirements for the new system
o Which problem(s) need to be solved?
o What would the stakeholders like to achieve?
• Constraints (including nonfunctional requirements on the system (preliminary pass))
• Possible alternatives
o “Sticking with the current system” is always an alternative
o Different business processes for solving the problems
o Different levels/types of computerization for the solutions
• Advantages and disadvantages of the alternatives
The PIECES Framework
A checklist for identifying problems with an existing information system.
• Performance
o Throughput
o Response Time
o Is current throughput and response time adequate?
• Information (and Data)
o Outputs
▪ Lack of any information
▪ Lack of necessary information
▪ Lack of relevant information
▪ Too much information – information overload
▪ Information that is not in a useful format
▪ Information that is not accurate
▪ Information that is difficult to produce
▪ Information that is not timely to its subsequent use
o Inputs
▪ Data is not captured
▪ Data is not captured in time to be useful
▪ Data is not accurately captured – contains errors
▪ Data is difficult to capture
▪ Data us captured redundantly – same data is captured more than once
▪ Too much data is captured
▪ Illegal data is captured
o Stored Data
▪ Data is stored redundantly in multiple files and/or databases
▪ Stored data is not accurate
▪ Data is not secure from accident or vandalism
▪ Data is not well organized
▪ Data is not flexible – not easy to meet new information needs from stored
data
▪ Data is not accessible
o Do end users and managers get timely, pertinent, accurate and usefully formatted
information?
• Economics/ Economy
o Costs
▪ Costs are unknown
▪ Costs are untraceable
▪ Costs are too high
o Profits
▪ New markets can be explored
▪ Current marketing can be improved
o Are services provided by the current system cost-effective?
o Could there be a reduction in costs and/or an increase in benefits?
• Control (and Security)
o Too little security or control
▪ Input data is not adequately edited
▪ Crimes (e.g. fraud, embezzlement) are (or can be) committed against the
data
▪ Ethics are breached on data or information – refers to data or information
getting to unauthorized people
▪ Redundantly stored data is inconsistent in different files or databases
▪ Data privacy regulations or guidelines are being (or can be) violated
▪ Processing errors are occurring (either by people, machines, or software)
▪ Decision- making errors are occurring
o Too much control or security
▪ Bureaucratic red tape slows the system
▪ Controls inconvenience customers or employees
▪ Excessive controls cause processing delays
o Are there effective controls to protect against fraud and to guarantee information
accuracy and security?
• Efficiency
o People, machines, or computers waste time
▪ Data is redundantly input or copied
▪ Data is redundantly processed
▪ Information is redundantly generated
o People, machines, or computers waste materials and suppliers
▪ The effort required for tasks is excessive
▪ Materials required for tasks is excessive
o Does the current system make good use of resources: people, time, the flow of
forms,?
• Services
o The system produces inaccurate results
o The system produces inconsistent results
o The system produces unreliable results
o The system is not easy to learn
o The system is not easy to use
o The system is awkward to use
o The system is inflexible to new or exceptional situations
o The system is inflexible to change
o The system is incompatible with other systems
o The system is not coordinated with other systems
o Are current services reliable? Are they flexible and expandable?
Explaining the Different Types of Feasibility Studies
The feasibility study is one of the phases in project development, it is the analysis of the problem to
determine whether the problem can be solved more effectively. It is an evaluation of the proposed project.
It is used to document relevant information regarding the project and determines whether the project can
be implemented. The result of feasibility study also determines whether the solution for the problem should
be implemented.
There are four types of feasibility.
Operational feasibility.
If the system is developed, will it be used?
• Human and social issues…

• Potential labour objections?
• Manager resistance?
• Organizational conflicts and policies?
• Social acceptability?
• legal aspects and government regulations?
It used to identify the importance of certain problem project and how it is to be solved.
It also measures how the solution of the problems will work for any project or in any organization.
Its analysis the behaviour of the proposed system and whether the proposed system is easier than the
existing system for the users of the system.
Technical feasibility.
Is the project possible with current technology?
What technical risk is there?
Availability of the technology:

• Is it available locally?
• Can it be obtained?
• Will it be compatible with other systems?
It used to identify whether the technical resources are available to form the project or system. It suggests
efficient input and output devices manage a large amount of data.
It measures whether the hardware and software of existing system to which extent it can support the
proposed system.
It checks the available technology is within the given constraints such as the budget.
For example: if the current computer is operating at the speed of capacity, when it needs to run one or more
applications at the same time The system may get overloaded. This includes financial consideration to
accommodate technical resources such as the addition of hardware, the proposed system must those
enhancements.
Economic feasibility.
Is the project possible, given resource constraints?
What are the benefits?
Both tangible and intangible
Quantify them!
What are the development and operational costs?
Are the benefits worth the costs?
It used to determine the financial resources of the project.
It measures all costs the development of the new system.
It called cost-benefit analysis because it determines the total cost for development of the new system and
benefits derived from the new system
Benefits of a new system should be more than the cost incurred to achieve profit from new system or for
any organisation.
Schedule feasibility:
Is it possible to build a solution in time to be useful?
What are the consequences of delay?
Any constraints on the schedule?
Can these constraints be met?
Scheduling is based on time; it measures whether there is available time to do the project.
Some projects are needed to be completed in the given deadlines; feasibility determines whether the project
can be completed within that deadline.
This feasibility used to allocate time for separate module development in the proposed system.
Comparing alternatives
How do we compare alternatives?
• When there are multiple selection criteria?

• When none of the alternatives is superior across the board?
Use a Feasibility Analysis Matrix!
• The columns correspond to the candidate solutions;

• The rows correspond to the feasibility criteria;
• The cells contain the feasibility assessment notes for each candidate;
• Each row can be assigned a rank or score for each criterion
o e.g., for operational feasibility, candidates can be ranked 1, 2, 3, etc.
• A final ranking or score is recorded in the last row.
Other evaluation criteria to include in the matrix
• quality of output
• ease of use
• vendor support
• cost of maintenance
• load on system
Question 1: Explain “The PIECES Framework”.
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
______________________________________________________________________
Question 2: Explain the different types of feasibility studies.
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_________________________________________________________________________
Question 3: How can you use a Feasibility Analysis Matrix?
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_________________________________________________________________________
CHAPTER 3. PREPARE AND PUBLISH FEASIBILITY
REPORT
This chapter focuses on the following:
• Prepare a feasibility report

• Ensure that the completed feasibility report covers client requirements, project scope and analysis
of alternative scenarios
• Confirm the recommendation of the preferred scenario
• Present feasibility report to the appropriate person for project approval
3.1 Prepare a feasibility report

3.2 Ensure that the completed feasibility report covers client requirements, project
scope and analysis of alternative scenarios
3.3 Confirm the recommendation of the preferred scenario
3.4 Present feasibility report to the appropriate person for project approval
Feasibility report
A feasibility report is the results of a feasibility study. This report details whether or not a project should be
undertaken and the reasons for that decision.
A feasibility report is a document that details the study of the profitability, feasibility, effectiveness of a
proposed investment, and to evaluate the imminent business problem or opportunity.
The purpose of this report is to determine project parameters and define solutions to the problem that
Further needs analysis.
Below is a common format of a feasibility report:
• Introduction
• Business Description
• Preliminary Evaluation of Market consideration
• Management Team
• Technical specifications and Project plan
• Marketing plans
• Critical Risk Analysis and Problem Analysis
• Financial and Economic plans
• Evaluation and conclusion
How to Write a Technical Feasibility Study Report
Unlike feasibility report, a technical feasibility report only assesses the details of how your company will
deliver a particular product or service. You don’t have to include financial statement information on your
technical feasibility report, but the component must support your financial data. These are the basic things
included in a business feasibility technical report:
• Materials – The materials you need to create a product or provide service

• Labor – Number of employees needed to run your business.
• Transportation and Shipping – The local or international carriers to ship your items.
• Location – The location on where you run your business.
• Technology – Technologies used to operate your business.
What about Project Feasibility Reports?
A feasibility report of projects defines the problem and opportunities of the project that is studied. The main
objective of a project feasibility report executive summary is to ensure that the project is legally and
technically feasible, economically justifiable and to determine the viability of an idea to a project. Some
reasons why most organizations conduct a feasibility report to a project are as follows.
• There are some projects that are not achievable and operable.
• Not every project should be taken up.
• The results of a project may not be used effectively in an organisation.
Elements of a Good Feasibility Report
A good feasibility report must have these six essential elements:
• The Project Scope – Description or the definition of the business problems and opportunities
• The Current Analysis – The implementation plan and the methods of a new product or how
the service is being provided.
• The Requirement – The requirements need depending on the objective of the project.
• The Approach – Action plan and effective solutions to meet the desired requirements.
• Evaluation – The evaluation and assessment of the cost-effectiveness of the chosen
approach.
• Review – This will verify the accuracy of the feasibility report and make better decision
making.
Feasibility Report - Template
1. Desirability Analysis of the Available Options:
a. The following table delineates the available options for solving the software system problem.
Option Description
b. The following table delineates the target solution characteristics that are desired and were
used as criteria in the analysis process.
Characteristic Description
c. The following table delineates the options in their order of desirability.
Option Option Desirability Value
2. Feasibility Analysis of Options by Order of Desirability:
a. The following table delineates the driving requirements for the software system that is needed.
Driving Requirement Description
b. The following table delineates the known constraints for the software system that is needed.
Constraint Description
3. Conclusion of the feasibility study.
Best option:
Best option feasible?
b. The following table gives an overview of ranking results along with how the ranking was
determined.
Option Desirability Ranking Reason
b. The following table verifies that the best option is feasible by indicating whether or not it
satisfies the known project constraints.
Constraint Satisfied by Best Option?
c. The following table verifies that the best option is feasible by indicating whether or not it
provides positive responses to key go/no-go questions.
Key Question Response
Completed feasibility report covers client requirements, project scope and analysis of alternative
scenarios
You must conduct ongoing checks to ensure the feasibility on the project scope and analysis of alternative
scenarios that best meet the needs of the client. Project scope statement must be followed throughout the
project lifecycle.
Project scope statement
The scope statement is an agreement among the project team, the project sponsor and key stakeholders. It
represents a common understanding of the project for the purpose of facilitating communication among the
stakeholders and for setting authorities and limits for the project manager and team. The scope statement
includes relating the project to business objectives and defining the boundaries of the project in multiple
dimensions including approach, deliverables, milestones, and budget.
Timely reporting to the stakeholders
It is critical to report in a timely manner to all the stakeholders. You can use a daily, weekly or monthly
reporting.
A reporting template has been provided below:
Feasibility Report - Monthly reporting to the stakeholders
Monthly Report
Project Information:
Project Name:
Project Handler:
Employee Employee ID Date Project Price Qty Total
0
Name Signature Date
Confirm the recommendation of the preferred scenario
After conducting all of the feasibility study needed, all of the analysis, surveys, computations, and interviews,
the people conducting the study come up with the findings and recommendations that help the organisation
in deciding whether to deploy the project or retain the current processes and systems or go for any other
preferred choices. This information is usually provided through a recommendation report.
Recommendation report
This type starts from a stated need, a selection of choices, or both and then recommends one, some, or
none.
For example, a company might be looking at grammar-checking software and want a recommendation on
which product is the best. As the report writer on this project, you could study the market for this type of
application and recommend one particular product, a couple of products (differing perhaps in their strengths
and their weaknesses), or none (maybe none of them are any good).
The recommendation report answers the question "Which option should we choose?" (or in some cases
"Which are the best options?) by recommending Product B, or maybe both Products B and C, or none of the
products.
Typical Contents of the Recommendation Report
Whatever shade of feasibility or recommendation report you write, whatever name people call it--most of
the sections and the organisation of those sections are roughly the same. Now remember! Your specific
writing project may not require all of these sections, nor in the order shown here--plus you may need other
sections not mentioned here.
The structural principle fundamental to this type of report is this: you provide not only your
recommendation, choice, or judgment, but also the data and the conclusions leading up to it. That way,
readers can check your findings, your logic, and your conclusions and come up with a completely different
view. But, more likely, they will be convinced by all your careful research and documentation.
Introduction. In the introduction, indicate that the document that follows is a feasibility report (or whatever
it is called). Instead of calling the report by name (which might not mean anything to most readers), you can
indicate its purpose. Also, provide an overview of the contents of the report.
For some feasibility reports, you'll also be able to discuss the situation and the requirements in the
introductions. If there is little to say about them, you can merge them with the introduction, or make the
introduction two paragraphs long.
Technical Background. Some feasibility reports may require some technical discussion in order to make the
rest of the report meaningful to readers. The dilemma with this kind of information is whether to put it in a
section of its own or to fit it into the comparison sections where it is relevant. For example, a discussion of
power and speed of laptop computers is going to necessitate some discussion of RAM, megahertz, and
processors. Should you put that in a section that compares the laptops according to power and speed?
Should you keep the comparison neat and clean, limited strictly to the comparison and the conclusion?
Maybe all the technical background can be pitched in its own section--either toward the front of the report
or in an appendix.
Background on the Situation. For many feasibility reports, you'll need to discuss the problem, need, or
opportunity that has brought about this report. If there is little that needs to be said about it, this information
can go in the introduction.
Requirements and Criteria. A critical part of feasibility and recommendation reports is the discussion of the
requirements you'll use to reach the final decision or recommendation. If you're trying to recommend a
laptop computer for use by employees, there are likely to be requirements concerning size, cost, hard-disk
storage, display quality, durability, and battery function. If you're looking into the feasibility of providing
every ACC student with an ID on the ACC computer network, you'd need define the basic requirements of
such a program--what it would be expected to accomplish, problems that it would have to avoid, and so on.
If you're evaluating the recent program of free bus transportation in Austin, you'd need to know what was
expected of the program and then compare its actual results to those requirements.
Requirements can be defined in several basic ways:
Numerical values: Many requirements are stated as maximum or minimum numerical values. For example,
there may be a cost requirement--the laptop should cost no more than $900.
Yes/no values: Some requirements are simply a yes-no question. Does the laptop come equipped with a
modem? Is the car equipped with air conditioning?
Ratings values: In some cases, key considerations cannot be handled either with numerical values or yes/no
values. For example, we might want a laptop that has an ease-of-use rating of at least "good" by some
nationally accepted ratings group. Or we may have to assign a rating ourselves.
The term "requirements" is used here instead of "criteria." A certain amount of ambiguity hangs around this
word; plus most people are not sure whether it is singular or plural. (Technically, it is plural; "criterion" is
singular, although "criteria" is commonly used for both the singular and plural. Try using "criterion" in public-
-you'll get weird looks. "Criterias" is not a word and should never be used.)
The requirements section should also discuss how important the individual requirements are in relation to
each other. Picture the typical situation where no one option is best in all categories of comparison. One
option is cheaper; another has more functions; one has better ease-of-use ratings; another is known to be
more durable. Devise a method by which you can pick a "winner" from situation where there is no clear
winner.
Discussion of the Options. In certain kinds of feasibility or recommendation reports, you'll need to explain
how you narrowed the field of choices down to the ones your report focuses on. Often, this follows right
after the discussion of the requirements. Your basic requirements may well narrow the field down for you.
But there may be other considerations that disqualify other options--explain these as well.
Additionally, you may need to provide brief descriptions of the options themselves. Don't get this mixed up
with the comparison that comes up in the next section. In this description section, you provide a general
discussion of the options so that readers will know something about them. The discussion at this stage is not
comparative. It's just a general orientation to the options. In the laptops example, you might want to give
some brief, general specifications on each model about to be compared.
Category-by-Category Comparisons. One of the most important parts of a feasibility or recommendation

report is the comparison of the options. Remember that you include this section so that readers can check
your thinking and come up with different conclusions if they desire. This should be handled category by
category, rather than option by option. If you were comparing laptops, you'd have a section that compared
them on cost, another section that compared them on battery function, and so on. You wouldn't have a
section that discussed everything about option A, another that discussed everything about option B, and so
on. That would not be effective at all, because the comparisons must still be made somewhere.
Each of these comparative sections should end with a conclusion that states which option is the best choice
in that particular category of comparison. Of course, it won't always be easy to state a clear winner--you may
have to qualify the conclusions in various ways, providing multiple conclusions for different conditions.
If you were doing an evaluation report, you obviously wouldn't be comparing options. Instead, you'd be
comparing the thing being evaluated against the requirements placed upon it, the expectations people had
of it. For example, Capital Metro had a program of more than a year of free bus transportation--what was
expected of that program? did the program meet those expectations?
Conclusions. The conclusions section of a feasibility or recommendation report is in part a summary or

restatement of the conclusions you have already reached in the comparison sections. In this section, you
restate the individual conclusions, for example, which model had the best price, which had the best battery
function, and so on.
But this section has to go further. It must untangle all the conflicting conclusions and somehow reach the
final conclusion, which is the one that states which is the best choice. Thus, the conclusion section first lists
the primary conclusions--the simple, single-category ones. But then it must state secondary conclusions--the
ones that balance conflicting primary conclusions. For example, if one laptop is very inexpensive and has
poor battery function, but another is rather expensive but has good or even excellent battery function, which
do you choose, and why? The secondary conclusion would state the answer to this dilemma.
And of course as already mentioned, the conclusions section ends with the final conclusion--the one that
states which option is the best choice.
Recommendation or Final Opinion. The final section of feasibility and recommendation reports states the
recommendation. You'd think that that ought to be obvious by now. Ordinarily it is, but remember that some
readers may skip right to the recommendation section and bypass all your hard work! Also, there will be
some cases where there may be a best choice, but you wouldn't want to recommend it. Early in their history,
laptops were heavy and unreliable--there may have been one model that was better than the rest, but even
it was not worth having.
The recommendation section should echo the most important conclusions leading to the recommendation
and then state the recommendation emphatically. Ordinarily, you may need to recommend several options
based on different possibilities. This can be handled, as shown in the examples, with bulleted lists.
In an evaluation report, this final section would state a final opinion or judgement. Yes, the free-bus-
transportation program was successful, or at least it was, based on its initial expectations. No, it was a
miserable flop--it lived up to none of its minimal requirements. Or, it was both a success and a flop--it did
live up to some of its requirements but did not do so in others. But in this case, you're still on the hook--
what's your overall evaluation? Once again, the basis for that judgment has to be stated somewhere in the
requirements section.
Feasibility report for project approval
Before you take your feasibility report for project approval from your managers or supervisors, please make
sure:
• Write a good introduction in which you indicate the situation and the audience and provide
an overview of the contents.
• State requirements--those factors that influence the decision or the choice of options. (And
remember to state how important requirements are in relation to each other.)
• Indicate how the field of options was narrowed to the ones being compared.
• Organise the comparison of the options using the point-by-point approach. Don't use the
whole-to-whole approach.
• At the end of each comparative section, state the best choice in terms that point of
comparison.
• Include a summary table, if possible, in which you summarize all the key data in table form.
• Provide technical background, if necessary for understanding the comparative discussion.
• Discuss the background on the problem or opportunity--what brought about the need for the
report.
• Include a conclusions section where you restate all the key conclusions from the comparison
section.
• State secondary conclusions in the conclusions section--and based them on requirements
that you state in the requirements section of the report.
• State a final conclusion in the conclusions section--one that states which is the best choice.
• Include a recommendation section where you make the recommendation. Briefly mention
the key factors influencing the recommendation.
Approval should always be collected in writing using approval sheet or any other relevant document.
Approval sheet template
APPROVAL PAGE
This the name of the feasibility study prepared and submitted by name of the people conducted the
study for the purpose of list down the reasons and purposes to conduct the study.
The recommendations and outcome of the feasibility study is mentioned below:
list down the recommendations and outcome of conducting feasibility study.
Approval (Manager/supervisor to complete)
Select the correct option:
Option one:
This feasibility study is approved with the following changes:
List down the changes recommended.
Option two:
Without any changes and all recommendations will be implemented.
Question 1: How should you write a Technical Feasibility Study Report?
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_____________________________________________________________________________
Question 2: What are project feasibility reports?
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
____________________________________________________________________________
Question 3. Explain the typical contents of the Recommendation Report.
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
_______________________________________________________________________________________
____________________________________________________________________________

Learner Guide - ICTSAD506 Produce A Feasibility Report

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Learner Guide - ICTSAD506 Produce A Feasibility Report

Uploaded by

Copyright:

Available Formats

• Investigating client requirements, determining project

What will I learn

Functionality and features

Time & Convenience

A client requires a product in a particular style and colour.

Status & Identity

Reliability & Durability

Needs related to risk such as a client that requires delivery insurance.

Requirements related to community impact, ethics and the environment.

A client needs a product that is easy to open and reseal.

Integration & Compatibility

Standards & Compliance

Project scope management

• How we will get there

Define the Product Requirements

Define the Process Requirements

Involve the correct stakeholders

Identify the limitations

Once the scope is defined, it must not be

So there you have it! A simple guide to

System scope and boundaries

The high-level scope consists of two main components.

Investigate and identify problems, opportunities and objectives

Present findings and alternatives

Designing the improved system

Implementing, evaluating and maintaining the new system

What is a problem context?

Question 1: What are the most common client requirements?

Question 2: How can you design the process requirements?

• Ensure that future client requirements are considered

2.1 Ensure that future client requirements are considered

• Whether the project can be done

How to analyse the future client requirements

• The present organisation system (Stakeholders, users, policies, functions, objectives,...)

The PIECES Framework

A checklist for identifying problems with an existing information system.

Explaining the Different Types of Feasibility Studies

There are four types of feasibility.

If the system is developed, will it be used?

• Human and social issues…

Is the project possible with current technology?

What technical risk is there?

Availability of the technology:

Is the project possible, given resource constraints?

What are the benefits?

Both tangible and intangible

What are the development and operational costs?

Are the benefits worth the costs?

It used to determine the financial resources of the project.

It measures all costs the development of the new system.

Is it possible to build a solution in time to be useful?

What are the consequences of delay?

Any constraints on the schedule?

Can these constraints be met?

How do we compare alternatives?

• When there are multiple selection criteria?

Use a Feasibility Analysis Matrix!

• The columns correspond to the candidate solutions;

Other evaluation criteria to include in the matrix

Question 1: Explain “The PIECES Framework”.

Question 2: Explain the different types of feasibility studies.

Question 3: How can you use a Feasibility Analysis Matrix?