Operational Feasibility and the Feasibility Report
Chapter Eight
Syllabus topic Module 1, "Problem Identification & Feasibility Study: ... Feasibility analysis (technical, economic, operational)", the third of the three; and Course Outcome OC 1, "prepare structured project documentation including SRS and feasibility reports".
Pages 43 to 49 of 499
In one line
Operational feasibility asks whether the system will actually be used, and will work, in the way the people and the organisation really operate; this chapter also asks the two questions the three names leave out, whether it is lawful and whether it can be finished in time, and then puts every answer into a feasibility report.
In the wording to use when asked: operational feasibility is the assessment of whether a proposed system fits the organisation's processes, will be accepted and used by its users, can be operated and supported after installation, and will solve the problem in practice; a feasibility report presents the technical, economic, operational, legal and schedule findings with a recommendation.
Why a system that works can still fail
Many systems that were technically sound and economically sensible were never used. They asked people to change how they worked in ways nobody had agreed to, or made someone's job harder at the busiest moment of their day, or were left with nobody to look after them once their builders left.
Operational feasibility is the study of exactly those failures, before they happen. It is about people and process, not about code. That is why it cannot be answered from a desk: it needs the stakeholders you listed in Chapter 5, and it needs you to watch the place at its busiest again, this time imagining your system in it.
The questions operational feasibility asks
1. Does it fit the way the work is done? Write the process as it is now, step by step, and then as it will be with the system. Every step that changes is a step someone must be willing and able to change.
2. Can the users use it? Their skills, their devices, their time, and the conditions they will be working in: noise, crowds, one free hand.
3. Will they want to? Who gains from the change, and who loses something: a habit, a skill that stops mattering, control over their own work, the chance to blame the system. People who lose something resist, often quietly.
4. What happens when things go wrong? The network fails, a student orders and never comes, the kitchen runs out of something the system says is in stock. A system that only works when everything goes right is not operationally feasible.
5. Who will run and support it? Somebody enters the daily data, somebody resets a forgotten password, somebody restarts the server. Name them.
6. Do the people in charge support it? Without the owner's and the institution's support, a system is not adopted, however good it is.
7. How will people learn it? Training, a one-page guide, a trial period.
Operational Feasibility and the Feasibility Report
Before and after: the most useful table in the study
The clearest way to answer question 1 is a table of the process before and after.
For the worked project:
| Step | Now | With Canteen Pre-order |
|---|---|---|
| Deciding what to eat | at the counter, while the queue waits | on the phone, before the break |
| Ordering and paying | in the queue at the counter, both at once | ordering on the phone; paying at the counter on collection |
| The kitchen knows what to make | guessed in the morning | a list of what has been ordered for each slot, by 12:20 |
| Waiting for food | at the counter, in a crowd | only until the chosen slot |
| Collecting | shout the order across the counter | give the order number |
| Students without a phone, or on mobile data only | queue as now | queue as now: walk-in sales continue |
| The day's sales | counted from slips at closing | the owner's daily report, for pre-orders |
Two decisions are visible in the table, and both came from studying operations rather than technology.
Walk-in sales continue. Four of the 180 students surveyed had no smartphone with internet, and some students will not be on the college Wi-Fi. The system does not replace the counter; it takes pre-ordered lunches out of the queue, which shortens the queue for everyone else too.
The stock in the system is the owner's allocation for pre-orders. The kitchen cooks for walk-in customers as well. So each morning the owner decides how many portions of each dish to offer for pre-order, and enters that number as the day's stock. When it is gone, the dish shows as sold out in the app and is still sold at the counter while it lasts.
The worked project: operational feasibility
Users' ability. Students use phones all day (Chapter 5's user classes). The counter staff member, Ganesh More, uses a phone but little else; so every counter action is a single large button, and nothing needs typing during the break. The owner uses the system in the morning and evening, at quiet times.
Willingness, and the concerns the team heard:
| Who | Concern | What the design does about it |
|---|---|---|
| Ganesh, at the counter | "Now I have to watch a screen as well as the queue" | the counter screen shows one slot at a time, oldest first, one button per order |
| Ganesh | "Students will say they ordered when they did not" | every order has a number, and the counter's list is the truth |
| The owner | "Students will order and not come, and I will waste food" | no-shows are recorded on the counter screen; the daily report shows how many; a penalty rule is left for the college to decide later |
| The head cook | "We still have to cook for the counter" | the kitchen list shows pre-orders only, and walk-in cooking continues as before |
| Students | "What if I am late for my slot?" | the order waits at the counter until the end of the break; it is marked not collected only then |
Operational Feasibility and the Feasibility Report
When things go wrong:
| Failure | What happens |
|---|---|
| The college Wi-Fi fails at lunchtime | nobody can order; the counter works from walk-ins as today, and pre-orders already placed are on the counter screen of the lab machine's network |
| The server is off | the same fallback; the service is set to start by itself when the machine boots (Chapter 60) |
| A dish runs out in the kitchen while pre-orders exist for it | the counter tells those students and offers another dish; the owner reduces the next day's allocation |
| A student forgets their password | the owner can create a new account for them after checking their college identity card; a self-service reset is a later release |
Support after the semester. The IT lab in-charge agreed to keep the machine on during college hours and to restart it if needed. The team writes a server guide for him (Chapter 60) and a user manual for the owner and the counter (Chapter 67).
Management support. The owner agreed to a two-week trial. The principal's office agreed after a letter and a short demonstration, on condition that only college email addresses may register.
Training. One half-hour session at the canteen with the owner and the counter staff, and a one-page guide taped beside the counter.
Verdict: operationally feasible, with walk-in sales continuing beside it, the owner allocating stock for pre-orders each morning, and the IT in-charge supporting the machine.
Two more questions: is it lawful, and is there time?
MU names three kinds of feasibility. Two more are often added, and a careful study answers both, because either can stop a project on its own.
Legal feasibility
Ask what the system collects about people, and what the law requires of whoever runs it. For most student projects the relevant law is about personal data.
India's Digital Personal Data Protection Act, 2023 (No. 22 of 2023) defines personal data as "any data about an individual who is identifiable by or in relation to such data", and calls the person who "determines the purpose and means of processing of personal data" the Data Fiduciary. For the worked project that is whoever runs the system: the canteen owner.
The Act is coming into force in stages. By a notification of 13 November 2025 (G.S.R. 843(E)), its main obligations, in sections 3 to 17, including notice, consent and the general obligations of a Data Fiduciary, come into force eighteen months after that date, which is 13 May 2027; one sub-section of section 6, about consent managers, comes in a year after the notification. A system built now should nevertheless be designed to meet them, because it will still be running then. Two of those obligations shape the worked project directly. Section 8(5) requires a Data Fiduciary to "protect personal data in its possession or under its control ... by taking reasonable security safeguards to prevent personal data breach", and section 8(7) requires personal data to be erased once "the specified purpose is no longer being served".
Operational Feasibility and the Feasibility Report
Until then, the Information Technology Act, 2000 already applies. Its section 43A makes a "body corporate", which its Explanation defines to include a "sole proprietorship or other association of individuals engaged in commercial or professional activities", liable to pay compensation if it is negligent in "implementing and maintaining reasonable security practices and procedures" for sensitive personal data. The rules made under it in 2011 list the first kind of sensitive personal data as a password.
So the law, as it stands and as it is coming, points the same way for a system like this:
- collect only what the purpose needs: the worked project stores a name, a college email address, a password hash and the orders, and nothing else, no phone number and no payment details;
- tell users what it is for: the registration page says what is stored and why;
- protect it with reasonable security: passwords are stored only as salted hashes (Chapter 46), access is by role, and the server is reached over the college network only;
- do not keep it longer than needed: orders older than the current term can be deleted by the owner, and accounts of students who leave can be removed.
The team also needed permission to use the college's machine and its email domain, which is a matter of the college's rules rather than the law, and they had it in writing.
This book explains what the texts say so that you can design responsibly; it is not legal advice, and a system handling personal data for real should have its legal position checked by someone qualified.
Schedule feasibility
Can the project be finished in the time available? Chapter 17 computes the worked team's schedule: 65 working days of work on the longest chain of tasks, against a semester of 15 weeks, which is 74 working days once the Gandhi Jayanti holiday on 2 October is taken out. That leaves 9 working days of slack for college events, examinations in other papers, and the things that go wrong. Feasible, with a margin, though not a large one.
The feasibility report
MU's first Course Outcome for this paper asks you to "prepare structured project documentation including SRS and feasibility reports". The feasibility report is where the findings of Chapters 6, 7 and 8 come together. It is short, because it summarises; the working stays in your notes.
Operational Feasibility and the Feasibility Report
A dependable structure:
- The problem: the problem statement from Chapter 4.
- The proposed solution, in a paragraph, and the alternatives considered.
- Technical feasibility: the verdict, the stack, the key conditions.
- Economic feasibility: costs, benefits, payback, sensitivity.
- Operational feasibility: the process before and after, concerns and answers, support.
- Legal and schedule feasibility.
- Risks: the most serious ones, with mitigations.
- Recommendation: go ahead, go ahead with conditions, or do not go ahead.
Three to five pages is plenty. Much of it will be reused in the project proposal (Chapter 33), which is why it is worth writing well.
The worked project: the feasibility report
Feasibility Report: Canteen Pre-order. Version 1.0, 19 August 2026. Prepared by Aditi Kulkarni, Farhan Shaikh, Sneha Nair and Rohan D'Souza. Guide: Prof. S. Iyer.
1. The problem. Students have a 40-minute lunch break and one canteen counter at which they both order and wait. Over five days we counted an average of 212 students served and 31.2 leaving the queue without buying each day, and timed waits averaging 16 minutes and reaching 27. In a survey, 131 of 180 students said the queue makes them late for the 13:10 lecture at least once a week. The owner estimates that about Rs 600 of food is thrown away each day because the kitchen cannot know demand in advance.
2. Proposed solution and alternatives. A web application, with an Android app, through which students order before the break for a ten-minute pickup slot and pay at the counter on collection; a counter screen for the day's orders; a kitchen list; and the owner's menu, stock and daily report. Alternatives considered and rejected: a second counter (cost of staff), paper tokens (ordering still queues), a shared online form (no stock control or status), a general delivery platform (built for delivery, not collection).
3. Technical feasibility. Feasible with Node.js, Express and MySQL, which all four members have used, on a lab desktop running Ubuntu 24.04, reached over the college Wi-Fi, whose signal we confirmed throughout the canteen. Estimated peak about 7 orders a minute; we will test at 100 in a minute. Conditions: the Linux deployment is practised by week 8, and ordering is made safe when many students order the last portions at once.
4. Economic feasibility. One-time cost Rs 9,500, for a tablet at the counter; no running cost. Estimated benefit Rs 465.20 a day: Rs 265.20 of profit on half the lost sales at the owner's 25 per cent margin, and Rs 200.00 of food not wasted. Payback about 20 days of college; about 29 days if only a quarter of lost sales return. About 36 hours of students' time returned daily, unpriced.
Operational Feasibility and the Feasibility Report
5. Operational feasibility. Fits the canteen with two decisions: walk-in sales continue, and the owner allocates each dish's pre-order stock every morning. Concerns of the counter, the kitchen and the owner are answered in the design. The IT lab in-charge supports the machine; one training session and a one-page guide for the counter.
6. Legal and schedule feasibility. We store only a name, a college email address, a password hash and orders, with no payment data. Passwords are sensitive personal data under the Information Technology rules of 2011, and are stored only as salted hashes; the design follows the obligations of the Digital Personal Data Protection Act, 2023 that come into force on 13 May 2027. The college has permitted the use of its machine and email domain. The schedule needs 65 working days of the 74 available.
7. Main risks. Linux deployment inexperience (practise early); simultaneous orders for the last portions (safe stock updates, tested); Wi-Fi failure at lunchtime (walk-in fallback); students who order and do not come (recorded; policy for the college).
8. Recommendation. Proceed, on the conditions in sections 3 and 5, with a two-week trial agreed with the owner.
Do this for your project
- Write the process before and after, step by step, with the people who do each step.
- Take the table to the users and ask what worries them. Record each concern and what your design does about it.
- List what can go wrong in operation, and what happens then.
- Name who will run and support the system after the semester.
- List the personal data you will store, and cut anything the purpose does not need.
- Check the schedule against the weeks you have.
- Write the feasibility report in eight short sections, and end with a recommendation.
Mistakes that cost marks
Operational feasibility answered in one line. "Users will find it easy to use" is an assumption. The before-and-after table and the list of concerns are evidence.
A system that replaces a process everyone relies on, with no fallback when it fails.
Personal data collected because a form had room for it. Every field you store is a field you must protect.
Treating a law as in force when it is not, or as irrelevant because it is not yet in force. Say what applies now and what is coming, and design for both.
A report with no recommendation. A feasibility study exists to reach a decision.
Operational Feasibility and the Feasibility Report
Quick revision
- Operational feasibility: fit with the process; users' ability; users' willingness; what happens when things go wrong; who runs and supports it; management support; training.
- The before-and-after process table is the core evidence.
- Resistance comes from people who lose something; record their concerns and answer each in the design.
- Legal feasibility: the personal data held and the law on it. DPDP Act 2023: sections 3 to 17 in force from 13 May 2027 (G.S.R. 843(E)); until then IT Act s.43A and the 2011 rules, which count a password as sensitive personal data.
- Schedule feasibility: the longest chain of work against the weeks available.
- The feasibility report: problem, solution and alternatives, technical, economic, operational, legal and schedule, risks, recommendation.
Questions you must be able to answer
1. What does operational feasibility assess, and why can a technically sound system fail it? Whether the system fits the organisation's processes and will be accepted, used and supported by its people. A technically sound system fails it when it disrupts how people work, makes someone's busiest moment harder, has no fallback when something fails, or has nobody to look after it.
2. How does a before-and-after process table help? It shows every step that the system changes, and therefore every place where someone must change their work. Each changed step is a point to check with the people who perform it, and the table reveals decisions such as keeping walk-in sales beside pre-orders.
3. Why does the worked project let walk-in sales continue? Because some students have no smartphone with internet, some will not be on the college Wi-Fi, and the system must not fail the canteen when the network fails. Pre-ordering takes orders out of the queue; it does not replace the counter.
4. Which law applies today to the passwords the worked project stores, and which is coming? Today, section 43A of the Information Technology Act, 2000, which requires reasonable security practices for sensitive personal data, and the 2011 rules under it, which list passwords as sensitive personal data. Coming, the Digital Personal Data Protection Act, 2023, whose sections 3 to 17, including the Data Fiduciary's duty to take reasonable security safeguards, come into force on 13 May 2027.
5. List the sections of a feasibility report. The problem; the proposed solution and the alternatives considered; technical, economic and operational feasibility; legal and schedule feasibility; the main risks with their mitigations; and a recommendation.
The rest of this subject
These notes are cut from the University's printed syllabus. Open the syllabus itself for the same subject.