Project Initiation and Feasibility

Introduction

Project initiation is the first formal stage of the software development life cycle. It transforms a perceived organizational need into a sufficiently clear, justified, and governable project. At this point, an organization should not yet be designing screens or writing production code. It should be deciding whether a problem is worth addressing, what outcome is required, whether the proposed solution is feasible, and who has authority to proceed.

Poor initiation creates downstream problems: unclear requirements, uncontrolled scope, unrealistic deadlines, wasted expenditure, weak stakeholder support, and systems that technically work but do not solve the original business problem. Effective initiation establishes a shared foundation for planning, requirements analysis, procurement, design, development, testing, deployment, and evaluation.

A typical initiation sequence is:

1. Identify an organizational need or opportunity.
2. Investigate the current situation and affected stakeholders.
3. Formulate a problem statement.
4. Define the desired outcomes and preliminary scope.
5. Prepare a project charter.
6. Develop a business case.
7. Assess feasibility and major risks.
8. Obtain an approval, rejection, or request for further investigation.

The result is not a guarantee of project success. It is a disciplined decision based on available evidence and explicitly stated assumptions.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish an organizational need, problem, solution, project, and product;
• write a precise problem statement;
• translate business needs into measurable objectives;
• define project scope, exclusions, assumptions, constraints, and stakeholders;
• explain the contents and purpose of a project charter;
• construct a basic software business case;
• evaluate technical, operational, economic, legal, and schedule feasibility;
• use costs, benefits, payback period, and return on investment appropriately;
• identify initiation risks, ethical concerns, and governance requirements; and
• make a defensible recommendation about whether a project should proceed.

From Organizational Need to Project Definition

An organizational need is a gap between a current condition and a desired condition. The gap may involve excessive cost, slow service, inaccurate information, regulatory exposure, poor customer experience, security weakness, or an opportunity to create new value. A need is not automatically a software problem. Some needs are better addressed through training, policy, process redesign, additional staffing, or organizational change.

A problem statement describes the undesirable current condition, its consequences, affected parties, and evidence of significance. It should avoid prematurely prescribing a particular technology. For example:

The college’s placement office records employer opportunities in separate spreadsheets and email accounts. Staff spend excessive time reconciling records, students receive inconsistent information, and management cannot reliably report placement activity. During the last academic year, 18% of published opportunities contained outdated contact or deadline information.

This statement is stronger than “The college needs a mobile placement application.” The latter is a proposed solution, not an analysis of the problem.

A useful problem statement normally answers four questions:

The business need explains why action is desirable. The project is a temporary endeavor undertaken to produce a defined result. The product is the software or service created by the project. These concepts must not be confused. For example, “reduce appointment waiting time” is a business need; “develop and deploy an online booking system” is a project; and “the booking platform and its supporting procedures” is the resulting product or service.

Objectives and Success Criteria

Objectives translate a problem into intended results. High-quality objectives are specific, measurable, achievable, relevant, and time-bound. This is often called the SMART approach, although professional judgment remains necessary: an objective can be measurable yet strategically unimportant, or relevant yet impossible within available resources.

Weak objective: “Improve the library system.”

Stronger objective: “Within three months of deployment, enable students to renew eligible loans online and reduce routine renewal enquiries handled by library staff by 30%, while maintaining the existing authentication and privacy controls.”

An objective should identify a result rather than merely an activity. “Install a database” is an activity or deliverable. “Reduce duplicate student records to below 1%” is an outcome objective.

Success criteria are the observable conditions used to judge whether objectives have been achieved. They may include:

• functional performance, such as successful completion of specified transactions;
• quality performance, such as availability, response time, accessibility, and defect levels;
• business performance, such as reduced processing time or increased revenue;
• user adoption and satisfaction;
• compliance with legal, policy, and security requirements; and
• delivery performance, including cost and schedule tolerance.

Baseline data is important. A percentage improvement cannot be assessed responsibly without knowing the starting value, measurement method, period, and population. Measures should also identify who will collect them and when.

Scope, Boundaries, and Stakeholders

Scope defines the work and product boundaries. Product scope describes the capabilities and characteristics of the proposed system. Project scope describes the work required to create and implement it. These are related but not identical.

A preliminary scope statement should include:

• purpose and intended outcomes;
• major deliverables;
• included processes, users, locations, and interfaces;
• explicit exclusions;
• assumptions;
• constraints;
• dependencies; and
• acceptance conditions.

For example, a first release might include student registration, employer vacancy submission, staff approval, and notification by email. It might explicitly exclude automated candidate ranking, integration with external recruitment platforms, and a native mobile application. Exclusions are valuable because they protect the project from ambiguous expectations.

An assumption is treated as true for planning but requires confirmation, such as “the identity service will provide an integration interface.” A constraint is a limiting condition, such as a fixed regulatory deadline, approved budget ceiling, or requirement to use an existing database platform. A dependency is an external condition or deliverable on which the project relies.

Stakeholders are individuals, groups, or organizations that can affect the project, are affected by it, or have an interest in its results. They may include sponsors, customers, end users, operational staff, information-security personnel, suppliers, regulators, and communities. Stakeholder analysis considers influence, interest, expectations, possible resistance, and required engagement.

A simple influence-interest classification can guide communication:

This classification is not permanent. A regulator may become highly influential during a compliance review, and frontline staff may become critical when operational procedures are redesigned.

The Project Charter

The project charter is an initiating document that formally authorizes a project and gives the project manager authority to use organizational resources. Its precise format varies by organization, but a sound charter commonly contains:

• project title, sponsor, project manager, and date;
• business problem and rationale;
• objectives and high-level success criteria;
• major deliverables and preliminary scope;
• important exclusions;
• key stakeholders and governance arrangements;
• high-level milestones;
• estimated budget range and resource requirements;
• assumptions, constraints, dependencies, and major risks;
• decision rights and escalation routes; and
• approval signatures or equivalent authorization.

The charter is not a complete requirements specification or detailed project plan. It should provide enough clarity to authorize investigation and planning without pretending that unknown details have already been resolved.

A useful charter separates three levels of commitment:

1. Confirmed: supported by evidence or formal agreement.
2. Estimated: based on preliminary analysis and subject to refinement.
3. Assumed: used temporarily until validated.

This distinction prevents estimates from being mistaken for guarantees. In adaptive approaches, the charter may be a concise product vision and outcome agreement, while detailed scope is progressively elaborated through a prioritized backlog. In predictive approaches, the charter normally precedes a more detailed baseline plan. In either approach, governance and accountability remain necessary.

Building the Business Case

A business case explains why an investment should or should not be made. It compares alternatives, expected value, costs, risks, and strategic fit. The alternatives should include more than one technical solution. Common alternatives are:

• do nothing or continue the current process;
• improve the current process without new software;
• buy or subscribe to a commercial product;
• configure an existing organizational platform;
• develop a bespoke system internally; or
• outsource development or operation.

A business case should state its time horizon, currency, assumptions, and treatment of uncertainty. Typical content includes an executive recommendation, problem evidence, options analysis, benefits, costs, risks, feasibility findings, implementation approach, and evaluation plan.

Benefits can be tangible, such as reduced labour hours, fewer errors, lower infrastructure expenditure, or increased sales. Intangible benefits include improved trust, employee morale, service quality, accessibility, and organizational learning. Intangible benefits should not be ignored merely because they are difficult to express in money; they should instead be described with suitable indicators.

Basic Economic Measures

For a simple project, net benefit over a selected period can be expressed as:

The result has the same monetary unit as the inputs and is meaningful only when the period, cost categories, and benefit assumptions are clear.

A simple return on investment is:

Here, benefits and costs must be measured over the same period and in the same currency. This undiscounted measure is useful for preliminary comparison but ignores the timing of cash flows, risk, taxation, and possible residual value.

Payback period is the time required for cumulative net cash inflows to recover the initial investment. If annual net cash inflow is constant and positive, the simplified formula is:

This formula is applicable only when cash inflows are reasonably uniform and the calculation deliberately ignores discounting. If inflows vary, cumulative cash flow should be calculated period by period.

For example, suppose a system requires an initial investment of $60,000. It is expected to produce net savings of $20,000 in year 1, $30,000 in year 2, and $25,000 in year 3. Cumulative net cash flow is −$40,000 after year 1, −$10,000 after year 2, and $15,000 after year 3. The payback occurs during year 3. Assuming savings arrive evenly during that year, the fraction is $10,000 ÷ $25,000 = 0.4, so the approximate payback period is 2.4 years. This is an estimate, not proof that the project is financially attractive.

For larger or longer-lived investments, discounted cash flow is more appropriate. Net present value is:

Here, C₀ is the initial cash outflow at time zero, Cₜ is the net cash flow in period t, r is the discount rate per period, and n is the number of periods. NPV assumes cash flows and the discount rate are defined for the same period, such as annual values. A positive NPV indicates value above the chosen discount-rate benchmark under the stated assumptions; it does not eliminate implementation risk. Benefits that cannot be credibly monetized should be presented separately rather than assigned arbitrary monetary values.

Feasibility Assessment

Feasibility asks whether a proposal can realistically be delivered and operated. The familiar TELOS framework considers technical, economic, legal, operational, and schedule dimensions. Some organizations add organizational, security, ethical, or resource feasibility as separate categories.

Technical Feasibility

Technical feasibility examines whether the organization can create, integrate, secure, operate, and maintain the proposed solution. Questions include:

• Are the required skills, platforms, data, and infrastructure available?
• Can the system integrate with legacy applications and external services?
• Can performance, availability, accessibility, privacy, and security requirements be met?
• Is the technology mature enough for the required context?
• Can the proposed architecture scale and be supported after delivery?

A proof of concept or technical spike may test the highest-risk assumption, such as integration latency, data migration quality, or identity federation. A demonstration is not a production system; it may omit security, resilience, monitoring, and maintainability.

Operational Feasibility

Operational feasibility concerns whether the solution will work in the organization’s real environment. It includes process fit, user capability, training, support, maintenance, change readiness, and continuity of service. A technically correct system may fail if staff lack time to use it, managers do not reinforce the new process, or the new workflow conflicts with accountability arrangements.

Operational assessment should describe the future process, roles, support model, deployment transition, and measures of adoption. It should also consider accessibility and the effect on people who have limited connectivity, disabilities, language barriers, or low digital confidence.

Economic Feasibility

Economic feasibility compares lifecycle costs and expected value. Costs include discovery, procurement, licenses, development, data cleansing, migration, training, security assessment, infrastructure, support, upgrades, and decommissioning. Omitting ongoing operational costs makes a business case misleading.

Benefits should identify their owner, measurement method, timing, and confidence level. Sensitivity analysis can test what happens if costs increase, adoption is lower than expected, or benefits arrive late. A project that is attractive only under optimistic assumptions deserves careful reconsideration.

Legal and Regulatory Feasibility

Legal feasibility examines applicable law, regulation, contracts, intellectual-property rights, records obligations, accessibility duties, employment requirements, and data-protection rules. The precise obligations depend on jurisdiction and sector; therefore, legal review should not be replaced by generic technical advice.

Important questions include:

• What personal or sensitive data will be collected and why?
• Is processing authorized, transparent, proportionate, and limited to the stated purpose?
• Where will data be stored and transferred?
• Who owns software, content, models, and generated outputs?
• Do licenses permit the intended use and redistribution?
• Are retention, deletion, audit, disclosure, and breach procedures defined?
• Do supplier contracts specify security, service levels, exit, and incident obligations?

Legal feasibility is not simply a final approval step. Privacy, accessibility, security, and intellectual-property requirements can alter scope, architecture, cost, and schedule from the beginning.

Schedule Feasibility

Schedule feasibility asks whether the work can be completed by the required date with available resources and dependencies. It considers the volume and complexity of work, procurement lead times, decision latency, testing, training, migration, approvals, and contingency.

A fixed date does not make an uncertain estimate accurate. Teams should identify assumptions and use ranges where appropriate. A schedule that excludes testing, user acceptance, security review, data preparation, or operational readiness is incomplete. When the date is immovable, scope may need to become flexible, or additional resources and parallel work may be required.

Organizational, Security, and Ethical Feasibility

Organizational feasibility considers strategic alignment, governance capacity, leadership support, and compatibility with organizational culture. Security feasibility examines confidentiality, integrity, availability, identity, access control, monitoring, resilience, and incident response. Ethical feasibility asks whether the project respects autonomy, fairness, safety, dignity, and non-discrimination.

These dimensions are especially important when software makes recommendations, ranks people, processes sensitive data, or uses artificial intelligence. An AI component should not be justified merely because it is technically available. The organization should establish the intended purpose, data provenance, human oversight, explainability needs, performance evaluation, bias testing, security controls, and a process for contesting harmful decisions. If a simpler and more transparent rule-based process meets the need, it may be the more responsible option.

A Structured Initiation Decision

The final initiation recommendation should state one of several possible decisions:

• proceed to detailed planning or delivery;
• proceed conditionally after specified actions;
• conduct a limited pilot or proof of concept;
• defer until assumptions or dependencies are resolved; or
• reject the proposal because value, feasibility, or risk is unacceptable.

A decision log should record the evidence considered, unresolved issues, decision owner, date, conditions, and review point. This supports accountability and prevents the organization from repeatedly reopening settled questions without new evidence.

A feasibility assessment is not a one-time claim that a project is “feasible.” Feasibility changes as requirements, technology, suppliers, regulations, costs, and organizational conditions change. Significant changes should trigger reassessment.

Illustrative Case: College Placement Information System

Background

This fictional case illustrates initiation, not a recommendation for any particular real institution. A college placement office supports 4,000 students and approximately 300 employers. Opportunities are submitted through email, recorded in spreadsheets, and circulated through separate mailing lists.

Problem

The office cannot maintain a dependable single record. Staff duplicate data entry, employers receive delayed responses, and students sometimes view expired opportunities. Management lacks timely evidence about placement demand and outcomes. Interviews and a four-week record review provide the following baseline: 18% of published listings contain outdated information, staff spend approximately 240 hours per month on reconciliation, and the average time from employer submission to publication is three working days.

Analysis and Options

The team considers four options: continue current practice, redesign the process using existing office tools, subscribe to a commercial placement platform, or develop a bespoke platform. The “do nothing” option has no immediate development cost but does not address data quality or reporting. A process redesign may produce rapid improvement but could leave integration and audit limitations. A commercial platform offers established functionality but introduces subscription, migration, and vendor-dependency costs. Bespoke development offers control but has greater delivery and maintenance risk.

Preliminary Approach

The proposed first release includes authenticated employer submission, staff approval, a central opportunity record, expiry notifications, student search, and management reports. It excludes automated candidate ranking, native mobile applications, and integration with external recruitment systems. A technical feasibility activity will test identity integration and migration of existing records. A privacy review will determine retention and access rules before data migration.

Economic Illustration

Assume the commercial option has first-year costs of $75,000 and expected first-year measurable benefits of $110,000. Its simple first-year ROI is:

ROI = (110,000 − 75,000) ÷ 75,000 × 100% = 46.7%

This figure is only a preliminary indicator. It excludes uncertainty, later subscription costs, intangible benefits, and the possibility that staff adoption is lower than expected. The business case should compare lifecycle costs and alternatives rather than select the option with the highest apparent first-year percentage.

Outcome and Learning Points

The sponsor authorizes a short discovery and proof-of-concept stage, conditional on confirming identity integration, privacy requirements, staff capacity, and an agreed success baseline. The case demonstrates that initiation can authorize learning rather than prematurely authorize full construction. It also shows why a problem statement, scope boundary, feasibility evidence, and alternative analysis must be developed together.

Challenges and Limitations

Initiation is affected by uncertainty and organizational politics. Sponsors may overstate benefits to secure funding; users may describe symptoms rather than root causes; technical teams may promote familiar technologies; and estimates may create false precision. Feasibility studies can also be biased when the team evaluates only its preferred solution.

Several practices reduce these weaknesses:

• obtain evidence from multiple stakeholder groups;
• distinguish facts, estimates, assumptions, and opinions;
• compare a realistic range of alternatives;
• document confidence and uncertainty;
• test the riskiest assumptions early;
• include lifecycle and change-management costs;
• involve security, legal, accessibility, operations, and users early;
• use independent review for high-value or high-risk proposals; and
• revisit the case when material conditions change.

The aim is not perfect prediction. It is a transparent, proportionate, evidence-informed decision.

Best Practices for Professional Initiation

A competent software professional should:

1. begin with the organizational outcome rather than a fashionable technology;
2. write the problem in observable, evidence-based terms;
3. identify who owns the problem and who owns the expected benefits;
4. define measurable objectives and a baseline;
5. state exclusions as carefully as inclusions;
6. separate product scope from project work;
7. identify assumptions, constraints, dependencies, and decision rights;
8. compare “do nothing,” process, purchase, configuration, and development options;
9. include recurring costs, migration, training, security, support, and retirement;
10. assess technical, operational, economic, legal, schedule, security, and ethical feasibility;
11. use pilots or proofs of concept to test high-risk assumptions; and
12. record the decision and conditions for proceeding.

Chapter Summary

Project initiation converts an organizational need into an authorized and governable proposal. It begins with evidence-based understanding of the current problem, not with an assumed software solution. A clear problem statement identifies the condition, affected stakeholders, consequences, and evidence. Objectives express desired outcomes, while success criteria define how achievement will be judged.

Scope establishes boundaries through inclusions, exclusions, assumptions, constraints, dependencies, and acceptance conditions. Stakeholder analysis supports appropriate involvement and communication. The project charter authorizes the project at a high level and records its rationale, objectives, governance, risks, and preliminary resources.

A business case compares alternatives and examines lifecycle costs, benefits, risks, strategic fit, and uncertainty. ROI, payback period, and NPV can support economic analysis when their assumptions and limitations are stated. Feasibility assessment covers technical, operational, economic, legal, schedule, organizational, security, and ethical dimensions. The proper initiation decision may be to proceed, proceed conditionally, pilot, defer, or reject. Because circumstances change, feasibility should be revisited at significant decision points.

Key Terms

Organizational need: A gap between a current condition and a desired condition.

Problem statement: An evidence-based description of an undesirable condition, its effects, and affected stakeholders.

Business need: The organizational reason for taking action.

Project: A temporary endeavor undertaken to produce a defined result.

Product scope: The capabilities and characteristics of the resulting product.

Project scope: The work required to create and implement the product.

Objective: A stated result that the project intends to achieve.

Success criterion: An observable measure used to judge achievement.

Stakeholder: A person, group, or organization affected by or able to affect a project.

Assumption: A condition accepted as true for planning but requiring validation.

Constraint: A limiting condition imposed on the project.

Dependency: An external condition or deliverable on which work relies.

Project charter: A document that formally authorizes a project.

Business case: A structured justification for investing in a proposal.

Feasibility: The realistic possibility of delivering and operating a proposal.

Proof of concept: A limited investigation used to test a significant technical or business assumption.

Baseline: A documented starting measurement used for comparison.

Return on investment: An undiscounted comparison of net benefit with cost.

Net present value: The present value of future cash flows less the initial investment.

Governance: The structures and processes used to direct, control, and oversee a project.

Review Questions

Short Answer Questions

1. What is the difference between a business need, a project, and a product?
2. Identify four elements that should appear in a problem statement.
3. Distinguish an assumption from a constraint.
4. What is the purpose of a project charter?
5. Name five dimensions commonly examined in a feasibility assessment.

Long Answer Questions

1. Explain how a problem statement can prevent premature commitment to a software solution.
2. Discuss the relationship between project scope, product scope, exclusions, and acceptance conditions.
3. Explain how a business case should compare alternative courses of action.
4. Describe technical, operational, economic, legal, and schedule feasibility, giving one question for each.
5. Explain the limitations of using ROI and payback period as the sole basis for a software investment decision.

Analytical / Application Questions

1. An organization proposes an automated employee-ranking system because managers report that recruitment is slow. Formulate a problem statement, identify missing evidence, and list ethical and legal feasibility questions.
2. A project has a fixed launch date, incomplete requirements, and a limited team. Recommend how scope, risk, feasibility, and governance should be handled before authorization.
3. Compare a commercial subscription with bespoke development for a small college system. Identify the technical, operational, economic, legal, and schedule evidence required before recommending an option.

Multiple Choice Questions with Answers

Question 1

Which statement best represents a problem statement?

A. The organization should purchase a cloud application.

B. Staff reconcile duplicate records manually, causing delays and inaccurate reports.

C. The project will use an agile methodology.

D. The system will contain three database tables.

Correct Answer: B. Staff reconcile duplicate records manually, causing delays and inaccurate reports.

Question 2

Which item is normally an exclusion in a preliminary scope statement?

A. A capability explicitly outside the first release

B. The project sponsor’s name

C. A confirmed business objective

D. A stakeholder interview record

Correct Answer: A. A capability explicitly outside the first release

Question 3

What is the primary purpose of a project charter?

A. To provide source code standards

B. To authorize the project and establish high-level direction

C. To replace all detailed requirements

D. To report final product defects

Correct Answer: B. To authorize the project and establish high-level direction

Question 4

Which feasibility dimension examines whether users, processes, training, and support can accommodate a proposed system?

A. Technical feasibility

B. Schedule feasibility

C. Operational feasibility

D. Legal feasibility

Correct Answer: C. Operational feasibility

Question 5

A project costs $50,000 and produces measurable benefits of $70,000 over the selected period. What is its simple ROI?

A. 20%

B. 28.6%

C. 40%

D. 70%

Correct Answer: C. 40%

Question 6

Which statement about an assumption is correct?

A. It is always a legal requirement.

B. It is a condition treated as true but requiring validation.

C. It is work that has already been completed.

D. It is an explicit project exclusion.

Correct Answer: B. It is a condition treated as true but requiring validation.

Question 7

Why should a business case include the ‘do nothing’ option?

A. It guarantees project approval.

B. It provides a baseline against which other options can be compared.

C. It eliminates the need for feasibility analysis.

D. It converts intangible benefits into cash.

Correct Answer: B. It provides a baseline against which other options can be compared.

Question 8

A system requires an initial investment of $30,000 and generates constant annual net savings of $10,000. Using the simplified payback formula, what is the payback period?

A. 0.3 years

B. 2 years

C. 3 years

D. 4 years

Correct Answer: C. 3 years

Question 9

Which issue is most directly associated with legal feasibility?

A. Whether the interface uses familiar colours

B. Whether data processing and software licenses comply with applicable obligations

C. Whether the team uses daily meetings

D. Whether the project has a product backlog

Correct Answer: B. Whether data processing and software licenses comply with applicable obligations

Question 10

What is the most appropriate reason to conduct a proof of concept during initiation?

A. To test a high-risk assumption before committing to full delivery

B. To avoid identifying stakeholders

C. To guarantee that the final system will be defect-free

D. To replace user acceptance testing

Correct Answer: A. To test a high-risk assumption before committing to full delivery