Feasibility studies

Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of an existing business or proposed venture, opportunities and threats as presented by the environment, the resources required to carry through, and ultimately the prospects for success. In its simplest terms, the two criteria to judge feasibility are cost required and value to be attained. As such, a well-designed feasibility study should provide a historical background of the business or project, description of the product or service, accounting statements, details of the operations and management, marketing research and policies, financial data, legal requirements and tax obligations. Generally, feasibility studies precede technical development and project implementation.

Technical feasibility

The assessment is based on an outline design of system requirements in terms of Input, Processes, Output, Fields, Programs, and Procedures. This can be quantified in terms of volumes of data, trends, frequency of updating, etc. in order to estimate whether the new system will perform adequately or not. Technological feasibility is carried out to determine whether the company has the capability, in terms of software, hardware, personnel and expertise, to handle the completion of the project. When writing a feasibility report the following should be taken to consideration:

  • A brief description of the business to assess more possible factor/s which could affect the study 

  •  The part of the business being examined 

  •  The human and economic factor 

  •  The possible solutions to the problems 

At this level, the concern is whether the proposal is both technically and legally feasible (assuming moderate cost).



Economic feasibility

Economic analysis is the most frequently used method for evaluating the effectiveness of a new system. More commonly known as cost/benefit analysis, the procedure is to determine the benefits and savings that are expected from a candidate system and compare them with costs. If benefits outweigh costs, then the decision is made to design and implement the system. An entrepreneur must accurately weigh the cost versus benefits before taking an action.

Cost-based study: It is important to identify cost and benefit factors, which can be categorized as follows: 1. Development costs; and 2. Operating costs. This is an analysis of the costs to be incurred in the system and the benefits derivable out of the system.

Time-based study: This is an analysis of the time required to achieve a return on investments. The future value of a project is also a factor.

Operational feasibility

Operational feasibility is a measure of how well a proposed system solves the problems, and takes advantage of the opportunities identified during scope definition and how it satisfies the requirements identified in the requirements analysis phase of system development.




How to Talk to Users [for analyst members of a JAD team]


      Encourage users to speak up. Don't assume they understand that they carry equal authority on the team.
      Ask probing questions about how users do their work, even about points that seem obvious. Ask why they so something as well as "what" and "how."
      Do state the obvious (once, at least). Don't assume that something is "common knowledge."
      Ask for clarification. Don't assume you are the only one confused. If users start talking office-lingo, bring them gently back down to Earth.
      Restate the user's points in your own words to make sure you understand each other.
      Avoid technical explanations and computer jargon. if you must use technical terminology, provide a list of terms and definitions.
      Mention problems that you see when you see them. Don't assume that users are not mentioning something because it's okay.
      Be clear about your schedule for implementing features. Provide frequent opportunities to reevaluate and discuss the "to do " list.
      Make a distinction between features which will not be implemented because they are technically impossible and those for which there simply isn't time. Be gentle when dealing with ideas which are impractical.
      Be open to ideas and maintain a non-judgmental stance.

 

How to Talk to Analysts [for user members of a JAD team]


      Don't be bashful. Analysts on the team are counting on you to tell what you know and to correct their misconceptions and oversights.
      Help the analyst to understand how your work is done. Provide a context for your remarks. Give examples.
      Ask for the features you need to do your work. Don't assume that your needs are unimportant or impossible to meet.
      Ask for the features that make your work easier, even in small ways.
      Make a distinction between features you must have and those that would be nice for you. Set priorities and make them clear to the analyst
      Do state the obvious (once, at least). Don't assume that something you know is "common knowledge."
      Ask for clarification. Don't assume that you are the only one confused. If an analyst starts talking " computerate," bring them gently back down to Earth.
      Restate the analyst's points in your own words to make sure you understand each other.
      Mention problems that you see when you see them. Don't assume problems will " get worked out later."
      Discuss needs you will have after the system is finished. Plan ahead for working independently once the analyst has gone on to other projects. 

●   Be open to ideas and maintain a non-judgmental stance.



How do you know if your JAD is successful?


After creating Joint Application Development (JAD) team and managing it for any project to complete, you have to know if your JAD is successful or not. Here are some methods from which you will able to know about your JAD success. 

By applying the positive answers for the following questions.

● Are your meetings well attended?

● Are all affected parties involved/aware of decisions being made?

● Did you solve the true underlying problem?

● Is your solution accepted and used by your clients?

● Is the solution available on time?

By applying the following Success Factors

● A clear purpose shared by all team members - the project charter

● A diverse team, representative of all areas effected by this project.

● Every person in the group has equal responsibility and decision making power.

● Every idea is valuable. Throughout the JAD, listen and acknowledge each idea and concern. Evaluating ideas during a brainstorming session will shut down the creative process. The best idea may never get said out of fear of being shot down.

● Participation by everyone is very important. Encourage quieter members to speak, they often have the best ideas. Don't allow 1 or 2 members to dominate. This is the facilitators responsibility as well as the whole teams' responsibility.

● Listen when others speak, don't interrupt or talk while others are talking (side conversations may have great ideas...we don't want to miss them).

● Maintain a parking lot to record important issues that are not within the scope of this project.

● Don't hold meetings, just to hold meetings. Only meet when there is something substantial to talk about.

● Don't let more than 3 or 4 weeks pass between meetings, you will loose momentum. Remember, each meeting is a motivation for the team to complete tasks assigned. It is no fun to come to a meeting and admit you didn't finish your task.

● Decisions are reached by consensus. We are here to create a win/win solution...win/lose solutions aren't good enough. You can reach consensus by giving everyone three options:

○ Thumbs up - I agree

○ Thumbs down - I disagree

○ Thumbs sideways - I can support this idea


You Might also view the following Related Posts

Roles of JAD Group Members


The roles of JAD group members as a project sponsor, project leader, timekeeper and clients are described below.

Project Sponsor - remember, this is the person who owns the business process. Their support and participation is crucial to the success of the JAD. In addition to the project responsibilities listed below, the project sponsor and the lead analyst can share the role of Project Leader, being equally responsible for the successful completion of the JAD. 

Project Sponsor Responsibilities 

● ensure the right clients are part of the group 

● ensure there is enough technical staff support for the project 

● ensure that software/hardware is purchased as needed for the project 

● ensure that the clients are given time off from their regular work to attend the JAD meetings and to perform the tasks they are assigned by the JAD (policy research, gathering information / opinions from other client groups, documentation, testing) 

● assign and work on policy research 

● delegate tasks to clients who are in the group 

● ensure that the client tasks are done 

● assist in the selection of test cases 

● assist in the definition of the scope and functionality 

● assist in benchmarking against current systems and external systems 

● help set up quality measures 

● evaluate whether the system is effective and efficient 

Project Leader - the project leader can make or break the project. They need to be committed wholeheartedly to the project, and to have a background knowledge of the business area and current or related information systems. They also need to be committed to The University, and to understand the implications of the project within the context of University goals. They need to be enthusiastic and objective. They need to be sensitive to political issues and able to draw out the opinions of the quiet members of the group, and to not allow any single individual to dominate the group. 

Project Leader Responsibilities 

● work with project sponsor to ensure the right people are in the group 

● ensure all roles for the group are filled 

● ensure that meetings are scheduled and publicized with agendas 

● ensure that agendas are planned and followed 

● ensure that meeting notes are taken, and published by the record keeper 

● edit the notes and make sure they are not a transcript but a concise accurate summary of decisions made (both pro and con) and issues discussed and actions to do (make sure they are available historically if a new member has to join in the middle of a project) 

● ensure that tasks are assigned and done, and that a task list is planned and executed in the sequence that it needs to be, with appropriate timelines 

● coordinate the technical efforts of the analysts on the team 

● do research prior to the meetings to make sure background information is gathered on the appropriate agenda topics 

● facilitate the meetings effectively 

Record Keeper - The record keeper takes comprehensive notes during a session, and then edits them into a concise summary of discussions and decisions. It is important that the resulting notes NOT be transcription of who said what. The role can be shared by various members of the team as needed. Often a well-facilitated meeting will have a note taking record keeper, and also someone who records points on an easel pad. The easel pad serves as a ready reference to the group when summarizing discussions, and for return reference on complex points. And it also is a means for the record keeper to evaluate the accuracy and thoroughness of their notes. 

Record Keeper Responsibilities 

● take accurate and thorough notes during the meeting 

● ask for clarification on points if anything is not clear 

● summarize and condense the notes after the session 

● ensure that the JAD leader and project sponsor or other relevant people proof and edit the notes prior to publishing 

● publish the notes for all current members of the team and for any other interested parties 

● keep a history of the notes for the benefit of any members who join the team in mid-project 

● remind the group if they contradict earlier decisions and make sure they know they are in contradiction. 

Timekeeper - The Timekeeper is responsible for keeping the meeting running on time and helping the group use time wisely. 

Timekeeper Responsibilities 

● makes sure the meeting begins and ends on time 

● help the meeting stay on time for each topic on the agenda 

● reminds the group that they need to end a discussion in order to have time to summarize and create an action plan in the final minutes of the meeting 

Clients - Clients are here because this is a system they use. They understand how this system is used in the real world. They will help the group understand all the tasks handled by the system, correct any misperceptions, search for oversights and supply details. Remember, no detail is too small to mention. Sometimes minor details make a major difference in the way the system should work. 

Typical Client Responsibilities 

● describe the sequence of events in a business process as it affects their office 

● describe the decisions that have to be made in a business process 

● define the information that the process has to deal with 

● define what is critical vs. what would be nice for the first version of the system 

● bring up any problems that exist in the current process or any opportunities for making it more efficient 

● research policy questions when a new business procedure is being proposed 

● analyze if there are any obstacles to success in the current environment of their office for implementing the new system 

● create test cases for testing 

● run test scripts on the cases 

● give the developers feedback on the usability and accuracy and effectiveness of the system in an organized, documented way 

● help prepare documentation on how the system works from a client's point of view 

● help prepare and implement training for other clients 

All Team Members - have the following responsibilities: 

● Commitment to the team 

● Regular attendance 

● Actively listen 

● Actively participate 

● Identify concerns 

● Brainstorm ideas 

● Recommend solutions 

● Agree upon a design by consensus 

● Assist with project duties