Feasibility & Cost-Benefit Analysis

Schedule & Legal Feasibility

18 min Lesson 6 of 10

Schedule & Legal Feasibility

A project that cannot be delivered on time is not feasible — even if the technology is proven and the budget approved. Equally, a system that violates a regulation, breaches a contract, or ignores data-protection law will be shut down no matter how brilliantly it is built. Schedule feasibility and legal feasibility are the two gatekeepers that analysts check before a project is allowed to proceed. This lesson shows you how to assess both, with the concrete tools and language you will use in real feasibility reports.

Schedule Feasibility: Can We Deliver in Time?

Schedule feasibility asks one core question: given the available people, resources, and dependencies, is there a realistic path from today to a working system before the deadline expires? Deadlines are rarely arbitrary. They are tied to business events — a clinic must go live before its legacy system contract expires, an online store must launch before the peak shopping season, a logistics firm must comply with a new customs-reporting mandate by the statutory date.

The assessment has three steps:

Enumerate the deliverables. Break the project into phases — requirements, design, build, test, training, go-live — and estimate the calendar time each phase needs. Use historical data from similar projects where possible.
Identify constraints and dependencies. External constraints include regulatory deadlines, partner integration windows, and vendor lead times. Internal constraints include holidays, competing projects for the same team, and approval cycles.
Apply a buffer and compare. Real schedules include contingency (typically 15–25 % of net effort). Compare the buffered timeline against the hard deadline. If the gap is negative, the project is not schedule-feasible as scoped — you must either reduce scope, add resources, or negotiate the deadline.

The "optimism trap": most project failures stem from teams that underestimate by removing the buffer to make the schedule look acceptable. Document the buffer explicitly so that stakeholders understand the true risk if contingency is consumed early.

A Worked Example — Clinic Booking System

A private clinic chain wants a new online booking system. The deadline is fixed: the current paper-based system's support contract ends in 5 months. The analyst estimates:

Requirements & design — 3 weeks
Development — 10 weeks
Integration with existing patient records — 3 weeks
User acceptance testing — 2 weeks
Staff training & data migration — 2 weeks
Go-live & stabilisation — 1 week

That totals 21 weeks (approx 5.25 months) of net effort — and it ignores contingency. Adding a 20 % buffer raises the realistic estimate to 25 weeks (6.25 months). Against a 5-month (approximately 21.7-week) hard deadline, the project is not schedule-feasible at full scope. The analyst's recommendation: descope the patient-records integration to Phase 2, which cuts the timeline to 18 weeks net / 21.6 weeks with buffer — just inside the window.

Phase 1 descoped timeline fits inside the 5-month hard deadline; records integration deferred to Phase 2.

Legal Feasibility: Are We Allowed to Build This?

Legal feasibility examines whether the proposed system can operate within the applicable legal, regulatory, and contractual framework. Analysts who skip this step create ticking legal time-bombs. The main categories to check are:

Data protection & privacy law. Systems that store personal data must comply with the relevant jurisdiction's legislation — the EU's GDPR, the UK's Data Protection Act, Saudi Arabia's PDPL, or similar. Key questions: what data will the system collect, where will it be stored, who will access it, and what consent mechanism is required?
Industry-specific regulations. A clinic booking system must comply with health-data regulations (for example, HIPAA in the USA, regional health authority mandates in the GCC). An e-commerce platform must implement consumer-protection rules (right of withdrawal, invoice obligations). A logistics system may need to generate customs declarations in a mandated format.
Intellectual property & licensing. Does the planned technical stack include open-source libraries with copyleft licenses? Will the system store or reproduce third-party content? Does the project reuse code from a previous employer?
Contractual constraints. Existing vendor contracts, SLAs, and partnership agreements can restrict technology choices, data-residency locations, or integration methods. An analyst must read — or commission a legal review of — any contract that the new system may touch.
Employment & accessibility law. Internal HR systems may be subject to labor law data requirements. Customer-facing systems in many jurisdictions must meet accessibility standards (WCAG 2.1 AA).

Do not assume compliance is easy to retrofit. Discovering a GDPR gap during user acceptance testing — rather than during design — typically costs 3–10× more to fix and may delay go-live by months. Legal feasibility must be assessed at the beginning of the project, not the end.

The Legal Feasibility Checklist

A practical analyst maintains a living checklist. For each item, the feasibility report records the applicable law or contract, the specific obligation it creates, whether the current design satisfies that obligation, and any action required. The following excerpt illustrates the pattern for our logistics firm scenario:

LEGAL FEASIBILITY CHECKLIST — Logistics Customs System

Regulation / Contract     Obligation                   Status       Action
---------------------------------------------------------------------------
EU Customs Code           Electronic customs declaration RISK        Integrate with approved
                          in UCC-MX format                          government gateway API
GDPR Art. 13              Inform shippers on data collection PASS   Privacy notice drafted
Data residency clause     EU customer data on EU servers  RISK      Cloud region selection
                          (partner SLA §4.2)                        must be restricted
eIDAS Regulation          Electronic signature on          OPEN     Legal sign-off pending
                          commercial invoices
WCAG 2.1 AA               Accessible shipper portal       PASS      Tested with screen reader

Any item marked RISK or OPEN must be resolved before the project is approved. If resolution is impossible, the project is not legally feasible in its current form.

Five legal dimensions that every new system must be assessed against before approval.

Connecting Schedule and Legal: The Compliance Deadline

In practice, schedule and legal feasibility are tightly coupled because many legal obligations carry their own hard deadlines. A new payments regulation might mandate PCI-DSS certification by a specific date. A government e-invoicing mandate might require all companies above a revenue threshold to comply from a published go-live date. When this is the case, the compliance deadline becomes the project deadline — it is non-negotiable and carries financial penalties or forced shutdown if missed.

The analyst's task is to work backwards from the compliance date, subtract the implementation timeline (with buffer), and identify whether development can begin in time. If the start date has already passed, the project must either fast-track (parallel workstreams, additional resource, deferred scope) or escalate immediately to the steering committee — not six weeks before the deadline when options have run out.

Practical tip — maintain a regulatory calendar. In regulated industries (finance, health, logistics), analysts should maintain a rolling 18-month calendar of known upcoming regulatory changes. New system proposals can then be checked immediately against this calendar to surface compliance-deadline conflicts early.

Documenting the Findings

Both assessments must be captured in the feasibility report with enough precision to support a decision. A weak entry reads: "The project should be finished on time and there are no legal issues." A strong entry provides the deadline, the estimated completion date with buffer, the identified risk, and the recommended mitigation. Similarly for legal: cite the specific regulation by name and article, state the obligation it creates, and confirm or deny that the current design satisfies it.

When the schedule is tight or a legal obligation is unresolved, the recommendation section must say so clearly — with options. Stakeholders who receive a sanitised, optimistic report and then discover problems in production will rightly question the quality of the analysis. The analyst's professional value lies in surfacing difficult truths early, when they are still actionable.