UNIT 1: PROJECT SELECTION

---

1. Sources of Project Request

1.1 What is a Project Request?

A project request is a formal or informal proposal to create, modify, or replace an information system. It can be a simple email, a completed form (like a Request for System Services – RSS), a verbal request during a meeting, or a strategic directive from the board.

1.2 Why Identify the Source?

Knowing the source helps:

• Determine the priority (e.g., CEO’s request vs. one user’s wish).
• Assign responsibility for further investigation.
• Understand the context and urgency.
• Predict resistance or support during implementation.

1.3 Detailed Classification of Sources

A. Internal Sources (within the organization)

B. External Sources (outside the organization)

1.4 Formal Documentation: Request for System Services (RSS)

Most organizations use a standard RSS form to capture project requests. It typically includes:

• Requester name, department, date
• Problem or opportunity description (what, where, when, how often)
• Expected benefits (tangible and intangible)
• Urgency / priority (high/medium/low)
• Known constraints (budget, timeline, regulatory)
• Approval signature of department head

Example RSS excerpt

Problem: “Accounts payable currently matches purchase orders and invoices manually. Average processing time is 12 days. Last month we missed 2 early payment discounts.”
Expected benefit: “Reduce processing to 3 days; capture 95% of discounts; estimated annual saving $150,000.”
Urgency: High – competition is automating.

1.5 Key Takeaway for Sources

A systematic process for capturing and logging requests from all sources ensures no valuable idea is lost. The source influences the evaluation criteria: a top-management request might skip some cost-benefit rigor if it’s a strategic necessity, while an end-user request must prove its value.

---

2. Managing Project Review and Selection

2.1 Purpose of Review and Selection

Not all project requests can be approved due to limited budget, staff, and time. The review and selection process ensures that:

• Only viable, valuable projects proceed.
• Projects align with business strategy.
• Risks are understood and acceptable.
• Resource conflicts are avoided.
• Stakeholders agree on priorities.

2.2 The Review and Selection Process – Step by Step

Step 1: Logging and Acknowledgment

• Enter each request into a project portfolio database (e.g., SharePoint, Jira, or a simple Excel sheet).
• Assign a unique ID and date received.
• Send an acknowledgment to the requester (e.g., “We have received your request #PR-2025-012 and will review it within 10 business days.”).

Step 2: Initial Screening (Triaging)

A quick check (often by a system analyst or PMO) to filter out obviously invalid requests:

Step 3: Detailed Evaluation

For requests that pass screening, perform a formal evaluation using quantitative and qualitative methods.

3.1 Financial Analysis (Tangible Costs & Benefits)

Net Present Value (NPV)

NPV = Σ (Benefit_t – Cost_t) / (1 + r)^t – Initial Investment
Decision rule: Accept if NPV > 0. Higher NPV is better.

Return on Investment (ROI)

ROI = (Average annual net benefit / Initial investment) × 100%
Example: Investment $200k, annual net benefit $50k → ROI = 25% over 4 years? Wait, careful: Simple ROI = Total net benefit / Investment × 100. If total net benefit over life = $250k, then ROI = 125%. But often annualized.

Payback Period

Time to recover initial investment. Shorter is less risky.
Example: Investment $100k, annual net cash flow $40k → payback = 2.5 years.

Cost-Benefit Analysis (CBA)

List all tangible (hardware, software, salaries) and intangible (customer satisfaction, employee morale) costs and benefits. For intangibles, assign a proxy value or use a scoring approach.

Example CBA Table for a CRM project

3.2 Weighted Scoring Model (for comparing multiple projects)

• Define criteria (e.g., strategic alignment, urgency, risk, cost, benefit, technical difficulty).
• Assign weights (total 100%).
• Score each project on a scale (e.g., 1–100) for each criterion.
• Multiply score × weight, sum to get total weighted score.

Detailed example with 2 projects:

3.3 Risk Assessment

Identify potential risks for each project:

• Technical risk: New technology, integration complexity.
• Operational risk: User resistance, process disruption.
• Schedule risk: Tight deadlines, dependency on external vendors.
• Financial risk: Cost overruns, benefits not realized.
  For each risk, estimate likelihood (low/medium/high) and impact (low/medium/high). High-risk projects may require a risk mitigation plan before approval.

Step 4: Prioritization and Ranking

Combine financial scores, weighted scores, and risk ratings into a prioritized list. Common prioritization techniques:

• MoSCoW: (Must have, Should have, Could have, Won’t have) – more for requirements, but can be adapted for projects.
• Kano model: separates basic, performance, and delight features.
• Simple ranking: The steering committee orders projects by a single combined criterion (e.g., “value / cost” ratio).

Step 5: Approval Decision

The steering committee (or IT governance board) makes the final decision. Possible outcomes:

• Approved as submitted: Proceed to preliminary investigation or directly to project initiation.
• Approved with modifications: e.g., reduce scope, extend timeline, or find cheaper alternative.
• Deferred: Review again in 6 months when resources are available.
• Rejected: Document reasons; inform requester; may be resurrected later if conditions change.

Step 6: Communication and Documentation

• Publish the approved project list to all stakeholders.
• For rejected/deferred projects, provide a clear explanation (e.g., “Low ROI compared to other projects” or “Dependency on another project that was cancelled”).
• Keep a project backlog for future cycles.

2.3 Real-World Example of Review & Selection

Scenario: A medium-sized logistics company receives three project requests in one month.

Evaluation:

• NPV (10% discount rate, 3 years):
  • Project 1: $500k×3 = $1.5M benefits – $150k cost = $1.35M / (1.1^1 etc.) ~ $1.1M NPV.
  • Project 2: $200k×3 = $600k – $100k = $500k NPV.
  • Project 3: $1M×3 = $3M – $400k = $2.6M NPV, but risk high.
• Weighted scoring: assign lower weight to risk? Or require mitigation.
• Decision: Approve Project 1 and Project 2. Approve Project 3 conditionally – first do a proof-of-concept with 6 months of clean data.

2.4 Key Takeaway for Review & Selection

This is a business decision, not just a technical one. Use a mix of financial models, scoring, and risk analysis. Always involve stakeholders from different departments to avoid bias.

---

3. Preliminary Investigation (Feasibility Study)

3.1 Definition and Purpose

A preliminary investigation (also called initial study, feasibility analysis, or project scoping) is a short, focused research effort to determine whether a proposed project is feasible and worth a full-scale system analysis.

• Duration: Typically 1–4 weeks.
• Cost: Usually 1%–5% of the estimated project cost.
• Output: A Preliminary Investigation Report with a clear go/no-go recommendation.

3.2 Why Preliminary Investigation is Critical

• Prevents wasting resources on projects that are impossible, too costly, or not aligned.
• Clarifies vague requests into actionable problems.
• Builds early stakeholder buy-in.
• Provides a rough budget and schedule for the next phase.

3.3 Detailed Steps of Preliminary Investigation

Step 1: Understand the Request

• Meet with the requester (and key users) to discuss the problem in detail.
• Review existing documentation – RSS, process maps, error logs, previous studies.
• Observe the current system if possible (e.g., shadow a user for 2 hours).
• Create a preliminary problem statement in clear, measurable terms.

Example vague request: “Our order entry system is too slow.”
After investigation: “On average, entering a 10-line order takes 4 minutes, compared to the industry standard of 1 minute. 80% of the delay occurs when the system checks inventory across three warehouses.”

Step 2: Define Scope and Boundaries

• In scope: Which processes, departments, locations, and user roles are included?
• Out of scope: What is explicitly excluded to prevent scope creep?
• Interfaces: Which external systems or organizations will the new system interact with?

Example scope statement:
“This project will cover the sales order entry process for domestic customers only. International orders, warehouse management, and invoicing are out of scope. The system must interface with the existing ERP and CRM.”

Step 3: Conduct Feasibility Analysis (Five Types)

3.1 Technical Feasibility

• Does the required technology exist and is it mature?
• Does the organization have the hardware, software, and network capacity?
• Does the IT team possess the necessary skills, or can they be trained/hired?
• Are there integration challenges with legacy systems?

3.2 Economic Feasibility (Cost-Benefit)

• Rough order of magnitude (ROM) estimate: ±50% accuracy.
• Identify one-time costs and recurring costs.
• Identify tangible and intangible benefits.
• Compute a simple payback or break-even point.

Example economic feasibility table (ROM)

3.3 Operational Feasibility

• Will users accept the new system?
• Does the system solve the real problem?
• Does it fit with existing workflows and culture?
• Are there legal or ethical concerns?

3.4 Schedule Feasibility

• Can the system be delivered before a critical deadline?
• Are there any external dependencies?

3.5 Legal / Compliance Feasibility

• Does the system comply with data protection laws (GDPR, CCPA, HIPAA)?
• Are there industry standards (PCI-DSS, SOX)?

Step 4: Identify Alternatives (Optional but Valuable)

• Do nothing: Continue with current system (baseline).
• Improve existing system: Modify, add modules, or train users.
• Buy a commercial package: Off-the-shelf (COTS) with configuration.
• Build custom: In-house development or outsourced.
• Cloud/SaaS: Subscription model.

Step 5: Estimate Resources for Full Analysis

If the project goes ahead, what will the requirements analysis phase cost and take?

• Analyst time (e.g., 2 analysts × 6 weeks = 12 person-weeks)
• User time (interviews, workshops, reviews)
• Travel
• Software for prototyping

Step 6: Prepare the Preliminary Investigation Report

Typical structure:

1. Executive Summary: One page: problem, findings, recommendation.
2. Introduction: Background, request summary, investigation methods.
3. Current System Description: As-is process, pain points, data flow.
4. Problem/Opportunity Statement: Clear, quantified.
5. Scope and Boundaries: In/out of scope.
6. Feasibility Findings: Technical, economic, operational, schedule, legal.
7. Alternative Solutions: Brief comparison.
8. Estimated Time & Cost for Next Phase.
9. Recommendation: Go / No-go / Modified go.
10. Appendices: Data collected, interview notes, rough cost estimates.

Step 7: Present to Steering Committee

• Focus on key risks and assumptions.
• Be prepared to answer: “What happens if we do nothing?” and “What is the single biggest reason this might fail?”

3.4 Real-World Example of a Preliminary Investigation

Context: A regional hospital receives a request from the emergency department (ED) to replace the paper-based patient tracking board with a digital status board.

Preliminary investigation steps:

1. Understand request: Interview ED nurses and doctors.
2. Scope: Include ED admission, triage, room assignment, and discharge.
3. Feasibility:
   • Technical: Medium technical risk due to API integration.
   • Economic: Feasible. Payback < 4 months.
   • Operational: Feasible with change management.
   • Schedule: Feasible.
   • Legal: Compliant with HIPAA if properly configured.
4. Recommendation: Go, but with a condition: First negotiate API access with the ADT vendor.

3.5 Common Pitfalls in Preliminary Investigation

3.6 Key Takeaway for Preliminary Investigation

Think of it as a low-cost insurance policy. It takes a few weeks but saves months of wasted work. Always produce a written report, and always include a clear go/no-go recommendation.

---

Final Summary Table – Project Selection