Project Smart ~ Exploring trends and developments in project management today

Calendar iconNot recorded
Adobe PDF icon

The Elements of a Good Feasibility Study

~ By Tim Bryce

Spiral bound document

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 and 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.

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 labour 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 that 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 car 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 analyses what was delivered versus what was proposed in the Feasibility Study.

Feasibility Studies represent a common sense approach to planning. Frankly, it is just plain good business to conduct them. However, I have read where some people in the IT 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.


Tim Bryce is the Managing Director of M. Bryce & Associates (MBA) of Palm Harbour, Florida, a management consulting firm specialising in Information Resource Management (IRM). Mr. Bryce has over 30 years of experience in the field. He is available for training and consulting on an international basis. His corporate web page is at: http://www.phmainstreet.com/mba/


Comments (1)

5/5 (1)
Gravatar
Full StarFull StarFull StarFull StarFull Star
Clock icon 22nd April 2015 11:02am
Ben (Manchester) says...
I have used the elements highlighted within this article in order to justify new projects, proposals and programmes on several occasions.

All these elements are short, sharp and to the point which gives the decision maker or body a quick analysis in order for you to gauge the right or intended decision.

All six points enable you to justify your thought chain and come to a logical outcome.

I now form this as a basis in order to justify changes or new ideas that could be implemented within my business development plans.

Very useful, thank you.
Ben

Add a comment



(never displayed)



 
1000
Enter the word hand backwards.
Notify me of new comments via email.
Remember my form inputs on this computer.

Writing the Project Statement of Work

White note reading Statement of Work

The Statement of Work, or SOW, is the bible for the work your project must produce. So how do you go about writing one for your project?

Requirements Gathering 101

Manager passing a document to a colleague

Requirements gathering is an essential part of any project and a key project management skill. Read 10 rules for successful requirements gathering.

Reduce Project Risk in the Requirements Process

Business people gathered around a table for a brainstorming meeting

Gathering and managing requirements are important challenges in project management. Projects succeed or fail due to poor requirements at any time throughout the project lifecycle.

The Role of a Business Analyst

A young businessman is sitting at a polished table attentively reading a document

This article examines the multifaceted role of the Business Analyst and gives a depiction of the duties and skills required to embark on such a career.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates on what's happening in the world of project management.


Latest Comments

Tomislav commented on…
How to Avoid Project Burnout
- Sun 2 August 5:11pm

Bradley Jackson commented on…
17 "Must Ask" Questions for Planning Successful Projects
- Fri 31 July 9:32pm

Bradley Jackson commented on…
A Tale of Two Projects
- Fri 31 July 7:58pm

Latest tweets

General Project Management • Re: APMP for PRINCE2 Practitioners http://t.co/cWwoy7HB7C #pmot #projectsmart about 1 day ago

Seven of the most important areas to consider when auditing a construction site http://t.co/OXlKGatc4m #pmot #pm #projectsmart about 4 days ago

General Project Management • Wanting to become a PM from a developer role http://t.co/J7KZj8KpJ1 #pmot #projectsmart about 5 days ago