The Elements of a Good Feasibility Study

Personal Business Skills Articles
Submit Articles Back to Articles
"Those who do not do their homework do not graduate."
- Bryce's Law
In its simplest form, a Feasibility Study represents a definition of a
problem or opportunity to be studied, an analysis of the current mode of
operation, a definition of requirements, an evaluation of alternatives, and an
agreed upon course of action. As such, the activities for preparing a
Feasibility Study are generic in nature and can be applied to any type of
project, be it for systems and software development making an acquisition, or
any other project.
There are basically six parts to any effective Feasibility Study:
1. The PROJECT SCOPE which is used to define the business problem
and/or opportunity to be addressed. The old adage, "The problem well stated
is half solved," is very apropos. The Scope should be definitive and to the
point; rambling narrative serves no purpose and can actually confuse project
participants. It is also necessary to define the parts of the business affected
either directly or indirectly, including project participants and end-user areas
affected by the project. The project sponsor should be identified, particularly
if he/she is footing the bill.
I have seen too many projects in the corporate world started without a well
defined Project Scope. Consequently, projects have wandered in and out of their
boundaries causing them to produce either far too much or far too little than
what is truly needed.
2. The CURRENT ANALYSIS is used to define and understand the current
method of implementation, such as a system, a product, etc. From this analysis,
it is not uncommon to discover there is actually nothing wrong with the current
system or product other than some misunderstandings regarding it or perhaps it
needs some simple modifications as opposed to a major overhaul. Also, the
strengths and weaknesses of the current approach are identified (pros and cons).
In addition, there may very well be elements of the current system or product
that may be used in its successor thus saving time and money later on. Without
such analysis, this may never be discovered.
Analysts are cautioned to avoid the temptation to stop and correct any
problems encountered in the current system at this time. Simply document your
findings instead, otherwise you will spend more time unnecessarily in this stage
(aka "Analysis Paralysis").
3. REQUIREMENTS - how requirements are defined depends on the object
of the project's attention. For example, how requirements are specified for a
product are substantially different than requirements for an edifice, a bridge,
or an information system. Each exhibits totally different properties and, as
such, are defined differently. How you define requirements for software is also
substantially different than how you define them for systems. (See,
"Understanding the Specifications Puzzle")
4. The APPROACH represents the recommended solution or course of
action to satisfy the requirements. Here, various alternatives are considered
along with an explanation as to why the preferred solution was selected. In
terms of design related projects, it is here where whole rough designs (e.g.,
"renderings") are developed in order to determine viability. It is also at this
point where the use of existing structures and commercial alternatives are
considered (e.g., "build versus buy" decisions). The overriding considerations
though are:
- Does the recommended approach satisfy the requirements?
- Is it also a practical and viable solution? (Will it "Play in
Poughkeepsie?")
A thorough analysis here is needed in order to perform the next step...
5. EVALUATION - examines the cost effectiveness of the Approach
selected. This begins with an analysis of the estimated total cost of the
project. In addition to the recommended solution, other alternatives are
estimated in order to offer an economic comparison. For development projects, an
estimate of labor and out-of-pocket expenses is assembled along with a project
schedule showing the project path and start-and-end dates.
After the total cost of the project has been calculated, a cost and
evaluation summary is prepared which includes such things as a cost/benefit
analysis, return on investment, etc.
6. REVIEW - all of the preceding elements are then assembled into a
Feasibility Study and a formal review is conducted with all parties involved.
The review serves two purposes: to substantiate the thoroughness and accuracy of
the Feasibility Study, and to make a project decision; either approve it, reject
it, or ask that it be revised before making a final decision. If approved, it is
very important that all parties sign the document which expresses their
acceptance and commitment to it; it may be a seemingly small gesture, but
signatures carry a lot of weight later on as the project progresses. If the
Feasibility Study is rejected, the reasons for its rejection should be explained
and attached to the document.
CONCLUSION
It should be remembered that a Feasibility Study is more of a way of thinking
as opposed to a bureaucratic process. For example, what I have just described is
essentially the same process we all follow when purchasing an automobile or a
home. As the scope of the project grows, it becomes more important to document
the Feasibility Study particularly if large amounts of money are involved and/or
the criticality of delivery. Not only should the Feasibility Study contain
sufficient detail to carry on to the next succeeding phase in the project, but
it should also be used for comparative analysis when preparing the final Project
Audit which analyzes what was delivered versus what was proposed in the
Feasibility Study.
Feasibility Studies represent a commonsense approach to planning. Frankly, it
is just plain good business to conduct them. However, I have read where some
people in the I.T. field, such as the "Agile" methodology proponents, consider
Feasibility Studies to be a colossal waste of time. If this is true, I've got a
good used car I want to sell them.
If you would like to discuss this with me in more depth, please do not
hesitate to send me an e-mail.
Keep the faith.
About the Author
Tim Bryce is a writer and management consultant with
M. Bryce & Associates
of Palm Harbor, Florida and has over 30 years of experience in the field. He is
available for lecturing, training and consulting on an international basis. He
can be reached at
timb001@phmainstreet.com
Comments and questions are welcome.
Copyright © 2008 by Tim Bryce. All rights reserved.
Follow us @Scopulus_News
Article Published/Sorted/Amended on Scopulus 2008-04-02 15:58:08 in Personal Articles