Project Initiation and Feasibility

Introduction and Context

A software project begins before requirements are fully specified and before developers write code. At initiation, an organization decides whether a proposed project is worth investigating, whether it supports organizational strategy, and whether the organization can deliver it responsibly. Poor initiation creates unclear expectations, unrealistic commitments, weak governance, and expensive rework. Effective initiation converts an idea into a justified, bounded, and governable project.

This chapter examines the principal initiation instruments used in software project management: the business case, project charter, feasibility study, objectives, scope statement, stakeholder analysis, and measurable acceptance criteria. These instruments are related but serve different purposes. A business case justifies investment; a feasibility study investigates whether the proposal is practical; a charter formally authorizes the project; a scope statement defines boundaries; stakeholder analysis identifies people affected by or able to influence the project; and acceptance criteria define the conditions under which deliverables will be accepted.

The chapter uses a diploma-level professional perspective. The emphasis is on making defensible decisions, documenting assumptions, communicating clearly, and creating a foundation for later planning and control.

Learning Objectives

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

1. Explain the purpose and contents of a software project business case.
2. Distinguish technical, economic, operational, legal, schedule, and organizational feasibility.
3. Develop a concise project charter with objectives, authority, risks, and constraints.
4. Define project scope, exclusions, assumptions, and deliverables.
5. Identify and analyze stakeholders using appropriate engagement strategies.
6. Write objectives and acceptance criteria that are specific, measurable, and testable.
7. Apply initiation techniques to a realistic software project.
8. Recognize ethical, governance, privacy, security, and accessibility issues during initiation.

1. From an Idea to an Authorized Project

A project proposal may arise from a business problem, a regulatory requirement, a customer request, an operational inefficiency, or an opportunity created by new technology. An idea is not yet a project. It becomes a project proposal when its intended outcome, expected value, approximate cost, and major uncertainties can be described sufficiently for an initial decision.

The initiation process commonly follows this sequence:

1. Identify the problem or opportunity.
2. Define the desired business outcome.
3. Investigate alternative solutions.
4. Assess feasibility and major risks.
5. Estimate benefits, costs, resources, and schedule.
6. Identify stakeholders and governance requirements.
7. Prepare the business case and project charter.
8. Obtain a decision to approve, reject, defer, or investigate further.

The sequence is not strictly linear. Discovery may reveal that the original problem has been misunderstood, or that a process change is preferable to new software. Initiation is therefore an evidence-building activity, not merely an administrative formality.

Important terminology

• Project: A temporary endeavor undertaken to create a unique product, service, or result.
• Sponsor: The person or group that provides strategic support, resources, and authorization.
• Business case: A structured argument for investing in a project or selecting among alternatives.
• Feasibility study: An investigation into whether a proposed solution is practical and desirable.
• Project charter: The document that formally authorizes a project and gives the project manager authority to use organizational resources.
• Deliverable: A verifiable product, service, document, or result produced by the project.
• Constraint: A restriction affecting scope, cost, time, quality, resources, technology, or compliance.
• Assumption: A condition treated as true for planning purposes, although it may require confirmation.
• Baseline: An approved reference point against which performance or change is evaluated.
• Acceptance criterion: A condition that a deliverable must satisfy to be accepted by an authorized party.

2. The Business Case

The business case explains why an organization should undertake a project. It should present evidence rather than enthusiasm. A persuasive business case links the current situation to measurable organizational value and compares realistic alternatives.

A typical business case contains:

2.1 Problem definition

A useful problem statement describes the current condition, its consequences, and the evidence supporting it. “The company needs a modern application” is weak because it assumes the solution. A stronger statement is: “Customer-support staff spend an average of 18 minutes locating information across three systems, contributing to delayed responses and duplicated records.” The second statement identifies a measurable condition without prematurely prescribing technology.

The business case should distinguish outputs from outcomes. An output is something produced, such as a mobile application. An outcome is a change resulting from its use, such as reduced processing time. Benefits are the measurable advantages associated with outcomes, while disbenefits are measurable negative effects, such as training disruption or migration effort.

2.2 Alternatives analysis

Alternatives may include:

• maintaining the current process;
• improving the existing system;
• purchasing and configuring a commercial product;
• developing a custom solution;
• outsourcing the service;
• conducting a limited pilot before full implementation.

The “do nothing” option should be explicit. It may appear inexpensive but can carry costs such as lost revenue, security exposure, regulatory penalties, or declining customer satisfaction.

2.3 Economic reasoning

At diploma level, economic analysis should be transparent rather than falsely precise. Costs may include development, licenses, infrastructure, integration, training, support, migration, security testing, and retirement of legacy systems. Benefits may be financial, operational, strategic, regulatory, or social.

A simple net benefit estimate is:

This expression is meaningful only when benefits and costs use comparable monetary units and the same time period. It does not capture every strategic or ethical consideration.

A basic return on investment estimate is:

Here, Benefits and Costs are measured monetary values for a defined evaluation period, and Costs must not be zero. ROI is a simplified ratio; it ignores the timing of cash flows, uncertainty, and non-financial value. It should not be used as the sole approval criterion.

For projects extending over several years, discounted cash flow may be more appropriate. The net present value is:

Where I₀ is the initial investment at time zero, CFₜ is the net cash flow in period t, r is the discount rate per period, and n is the number of periods. The formula assumes cash flows are represented consistently and that the discount rate reflects the organization’s evaluation approach. A positive NPV indicates that the discounted benefits exceed the discounted investment under the stated assumptions; it does not guarantee project success.

Worked example: simple economic comparison

A proposed service portal is expected to produce benefits valued at $96,000 during its first two years. Development, deployment, and support costs are estimated at $72,000. Thus:

Net benefit = $96,000 − $72,000 = $24,000

ROI = ($96,000 − $72,000) ÷ $72,000 × 100% = 33.33% approximately.

The result supports further consideration, but the business case must still examine security, operational readiness, delivery risk, and whether the benefit estimate is credible.

3. Feasibility Study

A feasibility study asks whether an option is workable, not merely whether it is attractive. Feasibility is multidimensional. A technically possible system may be economically unjustifiable, legally unacceptable, or impossible to operate with available staff.

3.1 Technical feasibility

Technical feasibility examines whether the organization can build, integrate, secure, test, deploy, and maintain the proposed solution. Questions include:

• Are required platforms, interfaces, data, and skills available?
• Can the proposed architecture meet performance and availability needs?
• Can legacy systems be integrated without unacceptable complexity?
• Are cybersecurity controls and privacy protections achievable?
• Can the team support the technology after launch?

A proof of concept may reduce uncertainty about a high-risk interface or technical approach. It should answer a specific question and have a defined time and success condition; it should not become uncontrolled development.

3.2 Economic feasibility

Economic feasibility compares expected costs with expected value and affordability. Estimates should identify their basis, range, confidence, and assumptions. Early estimates are often uncertain because requirements and technical choices are not fully known. Presenting a single exact figure can create false confidence. A range, such as $80,000–$110,000, with an explanation of uncertainty is usually more honest.

3.3 Operational feasibility

Operational feasibility considers whether the solution will work in the organization’s real environment. It includes workflow fit, staffing, training, support, service ownership, user acceptance, and business continuity. A technically excellent system may fail if it adds effort to already overloaded staff or lacks a clear support model.

3.4 Schedule feasibility

Schedule feasibility evaluates whether the required outcome can be delivered by the necessary date. It considers dependencies, procurement, approvals, recruitment, data migration, testing, training, and implementation windows. A deadline imposed by a business event is not evidence that the work is feasible. If schedule feasibility is weak, scope may need reduction, resources may need increase, or the date may need renegotiation.

3.5 Legal and regulatory feasibility

The study should identify applicable requirements involving privacy, intellectual property, accessibility, records retention, sector regulation, employment, contracts, and data location. Legal review should occur early where risk is significant. A project must not treat compliance as a final documentation activity.

3.6 Organizational and ethical feasibility

Organizational feasibility examines sponsorship, decision rights, culture, resource availability, and readiness for change. Ethical feasibility asks whether the project could create unfair exclusion, harmful surveillance, unsafe decisions, discriminatory outcomes, or unjustified collection of personal data. These issues are especially important where software affects employment, education, health, finance, or access to public services.

A feasibility conclusion may be:

• feasible as proposed;
• feasible with conditions;
• feasible only after further investigation;
• not feasible under current constraints; or
• feasible alternatives exist and should be preferred.

4. Project Objectives and Success Measures

Objectives translate purpose into results. A useful objective identifies what will change, for whom, by how much, and by when. The commonly used SMART model describes objectives as specific, measurable, achievable, relevant, and time-bound. SMART is a useful quality check, but it does not replace professional judgment.

Weak objective: “Improve the help-desk system.”

Stronger objective: “By 30 September, reduce the median time required for support staff to locate a customer’s active service record from 18 minutes to 8 minutes or less, measured across a representative sample of completed support cases.”

The stronger version specifies a deadline, baseline, target, metric, and population. It also permits later verification.

Objectives should be connected through a hierarchy:

• Strategic goal: broad organizational direction.
• Business outcome: measurable change resulting from the project.
• Project objective: result the project is expected to enable or deliver.
• Deliverable: tangible product or service produced by the project.
• Acceptance criterion: testable condition for approving the deliverable.

Project teams should distinguish project success from product success. A project may deliver on time and within approved cost but produce little business value. Conversely, a delayed project may still produce a valuable product, although governance should record the performance issue.

5. The Project Charter

The project charter is the formal authorization document. It is usually approved by the sponsor or an authorized governance body. It should be concise enough to guide decisions but sufficiently specific to prevent contradictory interpretations.

A practical charter includes:

1. Project title and identification.
2. Business problem or opportunity.
3. Purpose and high-level objectives.
4. Expected benefits and success measures.
5. High-level scope and exclusions.
6. Major deliverables.
7. Assumptions and constraints.
8. Initial milestones or target dates.
9. Initial budget or funding limits.
10. Key stakeholders and governance structure.
11. Major risks and dependencies.
12. Project manager, sponsor, and decision rights.
13. Approval signatures or authorization record.

The charter is not a detailed schedule, requirements specification, or complete risk register. It provides an authorized direction from which detailed planning can proceed. If the charter is silent about decision authority, disputes may be escalated too late. For example, it should state who approves scope changes, who accepts deliverables, and who resolves conflicts between business units.

6. Scope Definition

Scope describes the boundaries of the project. A scope statement normally contains the product scope, project scope, deliverables, exclusions, assumptions, constraints, and acceptance approach.

6.1 In-scope and out-of-scope work

Explicit exclusions are valuable because stakeholders often assume that adjacent needs are included. For a student service portal, in-scope work might include account registration, appointment booking, and email confirmation. Out-of-scope work might include a mobile application, integration with an external payment provider, and historical data cleansing. Exclusions are not rejections of future value; they are controls on the current commitment.

6.2 Scope boundaries and requirements

Scope should be consistent with the problem and objectives. If the objective is reducing appointment-processing time, unrelated features such as social networking may increase cost without improving the outcome. A product breakdown structure or work breakdown structure can later decompose deliverables into manageable components.

6.3 Assumptions and constraints

An assumption might be that the organization will provide a test environment by a stated date. A constraint might be that personal data must remain within a specified jurisdiction. Assumptions should have owners and validation dates where possible. If an assumption becomes false, its effect should be assessed rather than silently absorbed by the team.

7. Stakeholder Analysis and Engagement

A stakeholder is an individual, group, or organization that can affect the project, be affected by it, or perceive itself to be affected by it. Stakeholders may include sponsors, users, customers, operations staff, developers, suppliers, regulators, security personnel, accessibility specialists, and communities.

Stakeholder analysis commonly involves:

1. Identifying stakeholders.
2. Understanding their interests, influence, concerns, and information needs.
3. Assessing their current and desired level of support.
4. Planning communication and involvement.
5. Reviewing the analysis as the project changes.

A power–interest matrix provides a simple planning aid:

The matrix is not a substitute for judgment. A stakeholder with limited formal power may possess critical knowledge, influence users, or identify an ethical risk. Stakeholder analysis should therefore include perspectives that are easily overlooked, including people with disabilities, minority users, temporary staff, and people whose data is processed but who do not select the system.

A stakeholder register may include stakeholder name or group, role, interests, influence, concerns, current attitude, desired engagement, communication method, and owner. Personal information in such registers should be limited to what is necessary and handled appropriately.

8. Measurable Acceptance Criteria

Acceptance criteria state the conditions that must be met before a deliverable is accepted. They differ from general aspirations and from implementation tasks. “The system should be user-friendly” is difficult to test. “A first-time user shall complete appointment booking in no more than five minutes in usability testing, without assistance, in at least 8 of 10 trials” is more measurable, provided the test population and procedure are defined.

Good acceptance criteria are:

• unambiguous;
• observable or testable;
• relevant to the objective;
• feasible within the agreed constraints;
• stated in language understood by business and technical participants;
• associated with an acceptance authority.

Acceptance criteria may address functionality, performance, security, usability, reliability, accessibility, data quality, documentation, and operational readiness.

Examples:

Performance criteria require defined conditions. “95% within two seconds” is meaningful only if the test environment, workload, measurement point, and excluded conditions are specified. Similarly, a security criterion should identify the control or evidence required, not merely state that the system must be secure.

9. Integrated Initiation Workflow

The initiation documents should agree with one another. A practical review asks:

• Does the problem statement explain the objectives?
• Do the objectives justify the proposed deliverables?
• Do the deliverables fit within the scope boundaries?
• Do acceptance criteria measure the objectives and deliverables?
• Do the feasibility findings support the schedule and budget?
• Are affected and influential stakeholders represented?
• Are risks, assumptions, constraints, privacy, accessibility, and security visible?
• Is there an authorized person who can make decisions?

Traceability is useful. For example, a business objective can be linked to a deliverable, acceptance criteria, stakeholder, and evidence source. This reduces the risk that a feature is built without a clear purpose or that an important outcome has no corresponding test.

Illustrative Case: The Campus Appointment Portal

Background

This fictional case illustrates an initiation decision for a college student-services appointment portal. Students currently request appointments by email or telephone. Staff manually enter requests into spreadsheets, and students often receive delayed confirmations.

Problem

A review of three months of records found that staff required an average of 12 minutes to create and confirm an appointment. During peak registration periods, requests were sometimes lost or duplicated. Students with hearing impairments also reported difficulty using telephone-only booking.

Analysis

The initiation team identified three alternatives: retain the existing process, configure an existing institutional service platform, or develop a custom portal. The custom option offered flexibility but required greater integration and support effort. The configured platform appeared less expensive and could provide accessibility and audit features more quickly, but some reporting requirements would need adaptation.

Technical feasibility was rated moderate because a standard identity service and calendar interface were available, but integration with the student information system required a proof of concept. Operational feasibility was favorable if staff workflows were redesigned and training was provided. Legal and ethical review identified privacy, retention, accessibility, and role-based access as mandatory concerns.

Approach and proposed charter direction

The proposed objective was: “Within six months of authorization, provide an accessible appointment-booking service that reduces median staff appointment-entry time from 12 minutes to 5 minutes or less, while maintaining an auditable record of changes.”

Initial scope included student booking, staff calendar management, confirmation messages, role-based access, audit logging, accessibility testing, migration of active appointments, and support documentation. The mobile application, automated triage, and historical spreadsheet cleansing were explicitly excluded.

Sample acceptance criteria were:

1. A student can request, amend, and cancel an appointment through keyboard navigation.
2. A confirmation is generated for at least 98 of 100 valid test bookings under the agreed test conditions.
3. Every change to an appointment records the user, timestamp, and change type.
4. Median staff entry time is 5 minutes or less in a representative post-training trial.
5. The service desk receives approved operating procedures before launch.

Outcome

The sponsor approved a short discovery phase rather than immediate full development. The discovery phase was authorized to validate the calendar integration, confirm privacy requirements, test accessibility with representative users, and refine cost and schedule estimates. This was a controlled decision: the organization accepted limited investigation cost to reduce major uncertainty before committing to implementation.

Learning points

The case demonstrates that initiation is not simply the production of a charter. It is a structured decision process. The team defined the problem without assuming a technology solution, compared alternatives, considered affected users, identified exclusions, and used measurable criteria. It also recognized that a staged approval can be more responsible than approving a large project with unresolved technical and operational questions.

10. Challenges, Governance, and Professional Practice

False precision and optimism bias

Early estimates are uncertain. Teams may underestimate integration, data migration, testing, training, and support because these activities are less visible than coding. Use documented assumptions, ranges, comparable historical information, and independent review. Do not reduce an estimate merely to fit an arbitrary budget without recording the resulting risk.

Scope pressure and premature commitment

Stakeholders may request features before the problem and priorities are understood. Capture requests, but distinguish an idea from an approved commitment. A clear change-control approach protects the project from uncontrolled expansion.

Governance and accountability

Approval should be based on evidence and should identify who is accountable for benefits, delivery, acceptance, security, privacy, and operations. Decision records should preserve the reasons for approval, conditions, and rejected alternatives. Governance is not bureaucracy for its own sake; it provides traceability and protects affected parties.

Privacy, security, and accessibility by design

Initiation should ask what data is needed, why it is needed, who may access it, how long it will be retained, and how it will be protected. Security threat assessment, access control, logging, secure development, and incident responsibilities should be considered early. Accessibility should be a scope and acceptance concern, not a last-minute visual check. Inclusive consultation improves both ethical quality and practical usability.

Use of AI in initiation

AI tools can help summarize interviews, generate alternative scenarios, identify missing questions, or draft preliminary risk categories. However, AI-generated content may contain fabricated facts, biased assumptions, inappropriate disclosure of confidential information, or unjustified certainty. Project professionals must verify sources, protect sensitive data, disclose material use where required, and retain human accountability for business cases, feasibility conclusions, and approval decisions. AI should support analysis, not replace stakeholder consultation or governance judgment.

Best-Practice Checklist

Before requesting authorization, confirm that:

• the problem is evidence-based and not merely a preferred solution;
• alternatives, including doing nothing, have been considered;
• benefits have owners and measurable indicators;
• costs include delivery, operation, support, training, security, and retirement where relevant;
• feasibility findings and uncertainties are explicit;
• objectives are measurable and connected to organizational value;
• scope includes boundaries and exclusions;
• stakeholders and affected groups have been identified;
• acceptance criteria are testable and have an acceptance authority;
• privacy, security, accessibility, legal, and ethical requirements are visible;
• the sponsor, project manager, decision rights, and approval conditions are clear.

Chapter Summary

Project initiation transforms an idea into an informed and authorized commitment. The business case explains the problem, alternatives, expected value, costs, risks, and recommendation. A feasibility study tests technical, economic, operational, schedule, legal, organizational, and ethical practicality. The project charter authorizes the project, identifies its purpose and authority, and provides high-level boundaries for detailed planning.

Effective objectives state measurable results rather than vague intentions. Scope statements define deliverables, exclusions, assumptions, and constraints. Stakeholder analysis identifies those who influence, use, support, regulate, or are affected by the project, while engagement planning turns that knowledge into appropriate involvement. Acceptance criteria convert expectations into observable conditions for approval.

Professional initiation requires consistency among the business case, feasibility findings, charter, scope, stakeholder analysis, and acceptance criteria. It also requires honest treatment of uncertainty, responsible governance, privacy, security, accessibility, and ethical impact. A staged decision or limited proof of concept is often preferable to committing prematurely to a large and uncertain software project.

Key Terms

Business case: A structured justification for investing in a project or selecting an alternative.

Feasibility study: An investigation of whether a proposed solution is practical and desirable.

Project charter: The document that formally authorizes a project.

Sponsor: The person or group that supports and authorizes the project.

Stakeholder: A person, group, or organization that can affect or be affected by a project.

Objective: A defined result that a project intends to achieve.

Outcome: A change produced through use of a project deliverable.

Benefit: A measurable advantage resulting from an outcome.

Deliverable: A verifiable product, service, document, or result.

Scope: The boundaries of the project and its intended product.

Exclusion: Work or capability explicitly outside the approved scope.

Assumption: A condition treated as true for planning purposes.

Constraint: A restriction affecting project decisions or performance.

Acceptance criterion: A testable condition required for deliverable approval.

Baseline: An approved reference used for comparison and control.

Technical feasibility: The extent to which a solution can be built, integrated, secured, and supported.

Operational feasibility: The extent to which a solution can function effectively in its organizational environment.

Stakeholder register: A record of stakeholder interests, influence, concerns, and engagement information.

Return on investment: A simplified ratio comparing net benefit with cost over a defined period.

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

Review Questions

Short Answer Questions

1. What is the primary purpose of a business case?
2. Name four dimensions of feasibility relevant to a software project.
3. Distinguish an assumption from a constraint.
4. What authority does a project charter provide?
5. Why should acceptance criteria be testable?

Long Answer Questions

1. Explain how a business case, feasibility study, and project charter differ and how they support one another.
2. Describe the main contents of a project charter and explain why decision rights should be included.
3. Explain how scope exclusions, assumptions, and constraints help control a software project.
4. Discuss the role of stakeholder analysis in identifying ethical, operational, and adoption risks.
5. Explain why financial measures such as ROI should not be the only basis for project approval.

Analytical / Application Questions

1. A college proposes an online assessment system because “students want modern technology.” Identify the weaknesses in this proposal and formulate a stronger problem statement and two measurable objectives.
2. A project has strong technical feasibility but requires personal data to be stored with a supplier in another jurisdiction. What additional feasibility and governance questions should be answered before authorization?
3. A sponsor demands a fixed launch date while the project has unresolved integration and accessibility risks. Recommend an initiation approach and justify whether to proceed, defer, reduce scope, or authorize a discovery phase.

Multiple Choice Questions with Answers

Question 1

Which document primarily provides the formal authorization to begin a project?

A. Project charter

B. User manual

C. Test script

D. Issue log

Correct Answer: A. Project charter

Question 2

Which statement is the strongest project objective?

A. Improve customer service significantly.

B. Build a modern portal as soon as possible.

C. Reduce median appointment-entry time from 12 minutes to 5 minutes within six months.

D. Use current web technologies for booking.

Correct Answer: C. Reduce median appointment-entry time from 12 minutes to 5 minutes within six months.

Question 3

Which feasibility dimension examines whether staff, workflows, training, and support arrangements can sustain a solution?

A. Technical feasibility

B. Operational feasibility

C. Schedule feasibility

D. Economic feasibility

Correct Answer: B. Operational feasibility

Question 4

A project has benefits of $96,000 and costs of $72,000. Using ROI = (Benefits − Costs) ÷ Costs × 100%, what is the approximate ROI?

A. 24%

B. 25%

C. 33.3%

D. 75%

Correct Answer: C. 33.3%

Question 5

Which item is an example of a scope exclusion?

A. Student booking is included.

B. The project will provide confirmation messages.

C. The mobile application will not be developed in this project.

D. The calendar interface requires testing.

Correct Answer: C. The mobile application will not be developed in this project.

Question 6

What is the most appropriate treatment for a high-power, high-interest stakeholder?

A. Monitor with minimal effort.

B. Keep informed but exclude from decisions.

C. Manage closely and involve in decisions.

D. Communicate only after project closure.

Correct Answer: C. Manage closely and involve in decisions.

Question 7

Which acceptance criterion is most measurable?

A. The system should be user-friendly.

B. The system should be modern.

C. Users should like the interface.

D. At least 8 of 10 representative first-time users shall complete booking within five minutes without assistance.

Correct Answer: D. At least 8 of 10 representative first-time users shall complete booking within five minutes without assistance.

Question 8

Why should the “do nothing” option be considered in a business case?

A. It is always the cheapest option.

B. It provides a comparison that may reveal the cost of inaction.

C. It automatically becomes the approved option.

D. It eliminates the need for feasibility analysis.

Correct Answer: B. It provides a comparison that may reveal the cost of inaction.

Question 9

Which statement best distinguishes an outcome from a deliverable?

A. An outcome is a tangible document, while a deliverable is a business change.

B. An outcome is a business change, while a deliverable is a product or result produced by the project.

C. They are identical terms in project management.

D. An outcome is always technical, while a deliverable is always financial.

Correct Answer: B. An outcome is a business change, while a deliverable is a product or result produced by the project.

Question 10

What is an appropriate use of AI during project initiation?

A. Allowing AI to approve the business case without human review.

B. Using AI to replace consultation with affected stakeholders.

C. Using AI to help identify questions or summarize information, followed by human verification.

D. Uploading confidential stakeholder records to any public AI service.

Correct Answer: C. Using AI to help identify questions or summarize information, followed by human verification.