Problem Identification and Systems Planning

Introduction

Systems analysis begins before software, databases, or network architectures are discussed. Its first responsibility is to understand why change is needed, whose interests are involved, what the proposed system should accomplish, and under what conditions it must operate. Poorly defined problems frequently produce technically competent systems that solve the wrong problem. Effective systems planning therefore connects organizational purpose, stakeholder needs, evidence, feasibility, and controlled decision-making.

A system is an organized set of interacting components that transforms inputs into outputs in pursuit of a purpose. In information systems, the components may include people, processes, data, technology, policies, facilities, and external actors. Systems thinking examines both individual components and the relationships among them. This is important because a local improvement can produce undesirable consequences elsewhere—for example, automating order entry may reduce clerical work while increasing warehouse errors if inventory data are inaccurate.

This chapter explains how analysts identify business problems and opportunities, define scope and objectives, analyze stakeholders, document constraints and assumptions, develop success criteria, and prepare a business case. It also considers ethics, governance, uncertainty, and the practical use of contemporary technologies such as artificial intelligence.

Learning Objectives

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

1. Distinguish a problem, opportunity, symptom, and root cause.
2. Apply systems thinking to organizational situations.
3. Identify and analyze stakeholders and their interests.
4. Define project scope, objectives, constraints, assumptions, and exclusions.
5. Formulate measurable success criteria and indicators.
6. Compare alternative interventions using a structured business case.
7. Recognize feasibility, ethical, governance, and implementation risks.
8. Communicate a problem statement and planning recommendation professionally.

1. From Symptoms to Defensible Problem Statements

A business problem is an undesirable condition that prevents an organization from achieving a goal. A business opportunity is a favorable possibility that the organization may exploit to create value, reduce risk, or improve performance. A symptom is an observable sign of a deeper condition. For example, falling customer satisfaction may be a symptom; inconsistent service procedures, inaccurate information, or excessive waiting may be underlying causes.

Analysts should avoid treating a requested solution as the problem. “We need a mobile application” is a proposed intervention, not a problem statement. A stronger statement identifies the affected process, evidence, impact, and desired direction without prematurely selecting technology:

The student-services office takes an average of six working days to resolve enrollment inquiries. Incomplete information and repeated manual data entry cause delays, resulting in avoidable student visits and staff overtime. The office needs a reliable way to provide status information and route exceptional cases.

This statement is specific enough to investigate but does not assume that a mobile app, chatbot, or database is necessarily the answer.

Problem, Opportunity, and Symptom

A useful problem statement usually contains five elements: the current condition, the desired condition, evidence of the gap, organizational impact, and affected stakeholders. It should be neutral about solutions until alternatives have been evaluated.

Root-Cause Analysis

Root-cause analysis asks why the condition exists rather than merely describing it. Common techniques include the “five whys,” cause-and-effect diagrams, process observation, document analysis, and comparison of actual performance with policy or standards. The five-whys technique is not a literal requirement to ask exactly five questions; it is a disciplined sequence that continues until an actionable systemic cause is identified.

For example:

• Deliveries are late. Why? Picking is delayed.
• Why? Staff cannot locate some items.
• Why? Storage locations in the system are inaccurate.
• Why? Relocations are recorded on paper and entered later.
• Why? The process lacks an immediate update mechanism and ownership rule.

The final explanation is more useful than “warehouse staff are slow,” which incorrectly assigns blame and may lead to an ineffective intervention.

2. Systems Thinking and the Organizational Context

Systems thinking views organizational performance as the result of interactions, feedback, boundaries, and flows. A system boundary defines what the analysis includes; the environment contains external influences such as regulators, suppliers, competitors, customers, and economic conditions.

Four concepts are especially valuable:

• Inputs and outputs: Resources, information, requests, and materials enter a system and are transformed into services, decisions, or products.
• Feedback: Information about results influences later actions. A performance dashboard is useful only if someone can act on its information.
• Interdependence: A change in one component affects others. A new sales process may affect finance, inventory, customer support, and compliance.
• Emergence: System-level behavior can arise from interactions and may not be visible by studying one component alone.

A context diagram can help establish a system boundary. It shows the system of interest and the external entities that exchange information or resources with it. A process model then describes activities, decisions, roles, and flows within the boundary. These models are communication tools, not substitutes for evidence.

Figure: A context diagram establishes the system boundary and external information exchanges.

Systems thinking also encourages analysts to consider unintended consequences. A performance target based only on speed may cause staff to close cases prematurely. A target based only on cost may reduce service quality. Balanced planning therefore considers efficiency, effectiveness, quality, equity, security, and sustainability.

3. Stakeholder Analysis

A stakeholder is an individual, group, or institution that affects, is affected by, or perceives itself to be affected by a system or project. Stakeholders include users, customers, managers, owners, technical staff, suppliers, regulators, auditors, and communities. Some stakeholders have formal authority; others possess practical knowledge or can influence adoption.

Stakeholder analysis should answer four questions:

1. Who experiences the current condition?
2. Who makes decisions or controls resources?
3. Who supplies information, performs work, or maintains the system?
4. Who bears risks or receives benefits, including people not represented in meetings?

A stakeholder register records role, interests, influence, expected impact, concerns, and engagement approach.

A power–interest matrix is a useful starting point: stakeholders with high power and high interest require close management; those with high power and low interest require appropriate assurance; those with low power and high interest should still be consulted because they often possess essential operational knowledge. The matrix is not a substitute for ethical inclusion. People with little formal power may experience the greatest consequences.

Stakeholder conflict is normal. A manager may seek standardization, while staff seek flexibility; customers may want personalization, while privacy officers seek data minimization. Analysts should make such conflicts visible and help decision-makers negotiate trade-offs rather than hiding disagreement in technical language.

4. Scope, Boundaries, and Requirements for Planning

Scope defines what a proposed initiative will and will not address. Scope may be expressed through organizational units, processes, locations, products, data, users, time periods, and interfaces. A scope statement should identify:

• purpose and intended outcomes;
• included processes and user groups;
• excluded processes and interfaces;
• assumptions and dependencies;
• major deliverables;
• success measures;
• decision authority and review points.

Scope creep occurs when additions are accepted without evaluating their effects on time, cost, risk, quality, or architecture. Scope control does not mean refusing all change. It means documenting requests, assessing impacts, and approving changes through governance.

A distinction must be made between requirements and objectives. An objective states a desired result, such as reducing average service resolution time. A requirement states a capability or condition, such as recording the time a case is received and resolved. Objectives guide value assessment; requirements guide analysis, design, and verification.

A business process describes how work is performed to produce a result. Analysts should examine the current (“as-is”) process before designing the future (“to-be”) process. Useful evidence includes transaction records, interviews, observation, policy documents, forms, error logs, and customer feedback. Analysts should compare sources because stated procedures and actual practices often differ.

5. Objectives, Constraints, and Assumptions

An objective should be specific, measurable where possible, achievable, relevant to organizational purpose, and time-bounded. This is often called the SMART approach, although professional judgment is still required. “Improve service” is too vague. “Reduce the median response time for standard requests from three working days to one working day within six months of implementation” is more testable.

A constraint is a restriction that limits possible solutions. Constraints may arise from:

• budget or staffing;
• deadlines and regulatory dates;
• existing technology and integration interfaces;
• legal, privacy, security, or accessibility obligations;
• organizational policy;
• vendor contracts;
• skills and operational capacity.

An assumption is a condition treated as true for planning purposes but not yet verified. Examples include the availability of clean customer data, continued access to a vendor interface, or the ability of staff to attend training. Assumptions should be recorded with an owner and validation date. An unrecorded assumption is a hidden risk.

6. Success Criteria and Measurement

Success criteria translate aspirations into observable evidence. They should identify a measure, baseline, target, time frame, data source, and responsible owner. A useful indicator can be expressed conceptually as:

Here, “performance” must be defined consistently; it may be a time, error rate, cost, volume, or quality score. The expression is not a universal financial or statistical formula, but a planning aid for describing the distance between current and desired states. Units must match: a target of 1 day and a current value of 3 days produce a gap of −2 days if calculated as desired minus current.

Common measures include:

• cycle time or response time;
• completion rate and error rate;
• cost per transaction;
• adoption and successful-use rate;
• customer or employee satisfaction;
• availability and incident frequency;
• compliance exceptions;
• accessibility and equity outcomes.

Measures can create harmful incentives. If staff are judged only by number of cases closed, complex cases may be neglected. Analysts should use a balanced set of indicators and define measurement rules precisely. For example, “average response time” can be distorted by extreme values; the median may better represent a typical case, while a percentile can reveal service performance for slower cases. The choice depends on the decision purpose and data quality.

Benefits should be classified as tangible or intangible, direct or indirect, and financial or non-financial. A benefit map connects outputs to outcomes: training and system functions produce changed work practices, which may produce faster service and improved trust. The causal chain should be tested rather than assumed.

7. Feasibility and the Business Case

A business case explains why an initiative should be undertaken and compares alternatives. It is not merely a request for funding. A robust business case includes the problem or opportunity, strategic alignment, stakeholders, alternatives, expected benefits, costs, risks, feasibility, implementation approach, and recommendation.

A common feasibility framework examines:

• Technical feasibility: Can the organization build, acquire, integrate, secure, and maintain the solution?
• Economic feasibility: Are expected benefits proportionate to total costs and risks?
• Operational feasibility: Will people, processes, and governance support adoption?
• Schedule feasibility: Can the work be completed when the benefit is needed?
• Legal and ethical feasibility: Can it operate lawfully and fairly?
• Organizational feasibility: Does it fit strategy, culture, authority, and capacity?

Costs should include acquisition, development, migration, training, support, security, compliance, transition, and decommissioning—not just purchase price. Benefits may include avoided costs, increased revenue, reduced risk, improved quality, and public value. Where benefits are uncertain, scenarios or ranges are more honest than false precision.

For a simple undiscounted comparison, net benefit is:

If total benefits are measured in currency, both terms must use the same currency and time basis. This simple relationship ignores the time value of money, uncertainty, taxation, and non-financial value; it is suitable only for an initial screening. More detailed financial appraisal may use discounted cash flow, but analysts must state assumptions about the discount rate, timing, and risk.

Alternatives should include maintaining the current situation, process improvement without new software, commercial acquisition, custom development, and staged or pilot implementation. “Do nothing” is an alternative with continuing costs and risks, not a cost-free baseline.

8. A Structured Planning Process

A practical planning sequence is as follows:

1. Recognize the trigger. Record the event, complaint, strategic goal, regulatory change, or opportunity that initiated investigation.
2. Frame the situation. Describe the current condition, desired condition, evidence, and affected parties.
3. Collect evidence. Use multiple sources and distinguish observed facts from opinions.
4. Model the system. Identify boundaries, actors, processes, information flows, feedback, and dependencies.
5. Analyze stakeholders. Record interests, influence, concerns, and representation gaps.
6. Define scope. State inclusions, exclusions, interfaces, assumptions, and constraints.
7. Establish objectives and measures. Define baselines, targets, owners, and review dates.
8. Generate alternatives. Avoid premature commitment to a favored technology.
9. Assess feasibility and risk. Compare alternatives against technical, economic, operational, schedule, legal, ethical, and organizational criteria.
10. Recommend a path. Present evidence, uncertainties, trade-offs, and decision gates.
11. Obtain authorization. Confirm sponsor, resources, governance, and next-stage deliverables.

A decision log should record the decision, date, participants, evidence, assumptions, unresolved issues, and authority. This supports accountability and prevents repeated debates.

9. Illustrative Case: Municipal Permit Service

Background

This fictional case illustrates planning rather than reporting an actual organization. A municipal office processes permits for small businesses. Applicants submit paper forms or email attachments. Staff re-enter information into a departmental database and communicate by telephone.

Problem

Applicants report uncertainty about application status, while staff spend substantial time answering progress inquiries. Managers believe a digital portal would help, but no evidence yet shows whether a portal alone would solve the problem.

Analysis

Interviews, observation, and a sample of case records reveal three related causes: forms frequently omit required information; status changes are not recorded consistently; and responsibility for communicating delays is unclear. The apparent problem—too many telephone calls—is therefore a symptom of process and information weaknesses.

Stakeholders include applicants, intake staff, inspectors, managers, the information-security officer, records administrators, and accessibility advocates. Applicants need understandable status information. Staff need reduced duplication without losing discretion for unusual cases. Regulators require legally valid records and retention controls.

The initial scope includes application intake, completeness checking, status recording, notifications, and staff work queues for one permit category. It excludes redesign of inspection policy and payment processing. Assumptions include the availability of an identity-verification service; this must be validated before procurement.

Alternatives

1. Improve forms, define status rules, and introduce a shared work queue without a public portal.
2. Acquire a configurable permit-management platform and implement a portal in stages.
3. Develop a custom portal integrated with existing systems.

Alternative 1 is relatively inexpensive but offers limited applicant self-service. Alternative 2 may provide faster capability but creates vendor dependence and migration work. Alternative 3 offers flexibility but has greater delivery and maintenance risk.

Objectives and success criteria

The proposed pilot objective is to reduce incomplete submissions and unnecessary status inquiries while preserving accessibility and auditability. Candidate criteria are:

• reduce incomplete applications by 30% within four months of pilot launch;
• provide applicants with a current status for at least 95% of active cases;
• reduce avoidable status inquiries by 40% without increasing unresolved complaints;
• achieve successful completion by users with assistive technologies in usability testing;
• record all status changes with authorized user, timestamp, and reason.

These criteria must be confirmed against reliable baselines. The percentage targets are planning targets, not guaranteed outcomes.

Approach and outcome

The recommended approach is a staged pilot beginning with process clarification, improved forms, and a staff work queue. A limited applicant status view follows after security, accessibility, records, and data-quality checks. A pilot review compares results with the baseline and examines unintended effects, such as exclusion of applicants with limited internet access.

The case demonstrates that systems planning may recommend a sequence of organizational and technical changes rather than an immediate large-scale implementation. It also shows why a business case must consider process quality, stakeholder inclusion, governance, and measurable outcomes.

Learning points

• A requested portal was not accepted as the problem definition.
• Root causes involved process, data, roles, and communication.
• Scope protected the pilot from absorbing unrelated policy changes.
• Success criteria combined efficiency, quality, accessibility, and auditability.
• Staged implementation reduced uncertainty and created a decision point.

10. Ethical, Governance, and Contemporary Issues

Systems planning has ethical consequences because decisions determine whose needs are visible, whose data are collected, and who bears risks. Analysts should apply data minimization, purpose limitation, access control, retention rules, and appropriate transparency. Personal data should not be collected merely because future use is imaginable. Sensitive decisions require clear accountability and appeal mechanisms.

Accessibility and inclusion should be considered from the beginning, not added after design. A digital service should have alternatives where exclusion is foreseeable. Analysts should investigate language, disability, connectivity, literacy, economic access, and cultural factors.

Artificial intelligence can support planning by summarizing interview transcripts, identifying themes, generating process-model drafts, or exploring scenarios. However, AI-generated material may contain fabricated evidence, reproduce bias, omit minority views, or expose confidential data. Human analysts must verify source material, protect information, disclose appropriate use, and retain decision accountability. AI should assist reasoning, not replace stakeholder engagement or authorization.

Contemporary planning increasingly addresses cloud dependency, cybersecurity, interoperability, sustainability, algorithmic accountability, and resilience. These issues should be treated as design and governance concerns from project initiation. A system that is efficient but insecure, inaccessible, environmentally unsustainable, or legally indefensible is not a successful system.

Challenges and Limitations

Problem identification is affected by incomplete data, political pressure, conflicting narratives, organizational silos, and fear of exposing poor performance. Stakeholders may describe desired solutions rather than underlying needs. Historical data may reflect biased procedures and therefore should not automatically be treated as an objective baseline. Benefits may appear only after complementary changes in policy, training, or culture.

Models simplify reality. A context diagram can hide power relationships; a process model can suggest certainty where work is improvisational. Quantitative targets can encourage gaming. Feasibility estimates are uncertain, particularly for integration, migration, behavioral change, and security. Analysts should therefore document confidence levels, test assumptions, use pilots where suitable, and establish review gates.

Best-Practice Checklist

Before recommending a project, the analyst should be able to answer “yes” to most of the following:

• Is the problem stated independently of a preferred technology?
• Is there evidence from more than one source?
• Have symptoms been distinguished from causes?
• Are affected and influential stakeholders identified?
• Are vulnerable or underrepresented groups included?
• Are scope, exclusions, dependencies, constraints, and assumptions explicit?
• Are objectives measurable and linked to organizational value?
• Are baselines, data sources, and owners defined?
• Have realistic alternatives, including “do nothing,” been compared?
• Have technical, economic, operational, legal, ethical, and schedule feasibility been considered?
• Are risks, uncertainties, and unintended consequences documented?
• Is there a clear decision, sponsor, governance route, and next step?

Chapter Summary

Problem identification is the disciplined starting point of systems analysis. A credible analyst distinguishes problems, opportunities, symptoms, root causes, and proposed solutions. Systems thinking reveals boundaries, interdependence, feedback, flows, and unintended consequences. Stakeholder analysis identifies people who influence or experience change, including those without formal power.

Effective planning defines objectives, scope, exclusions, constraints, assumptions, dependencies, and measurable success criteria. A business case compares alternatives—including the current state—against technical, economic, operational, schedule, legal, ethical, and organizational considerations. Evidence should be collected from multiple sources, and assumptions and uncertainties should be made visible. Ethical planning requires privacy, security, accessibility, inclusion, accountability, and responsible use of AI. The best recommendation is not necessarily the largest technical solution; it is the intervention most likely to create defensible value under real organizational conditions.

Key Terms

Problem: An undesirable condition that prevents achievement of a goal.

Opportunity: A favorable possibility for improvement, growth, or risk reduction.

Symptom: Observable evidence of an underlying condition.

Root cause: A fundamental contributing condition that can be addressed.

Systems thinking: Analysis of components, relationships, boundaries, feedback, and context.

System boundary: The stated limit of what an analysis or system includes.

Stakeholder: A person or group that affects, is affected by, or perceives itself affected by a system.

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

Scope: The processes, users, data, locations, and deliverables included in an initiative.

Scope creep: Uncontrolled expansion of approved work.

Objective: A desired result that guides action and evaluation.

Constraint: A restriction limiting available choices.

Assumption: An unverified condition treated as true for planning.

Dependency: A condition or activity on which an initiative relies.

Success criterion: An observable condition used to judge achievement.

Baseline: A measured description of current performance.

Feasibility: The practicality of an alternative under relevant conditions.

Business case: A structured justification for undertaking an initiative.

Decision gate: A formal point at which evidence is reviewed before proceeding.

Systems model: A simplified representation used to understand structure, behavior, or relationships.

Review Questions

5 Short Answer Questions

1. Distinguish a business problem from a symptom and provide an example.
2. What is the purpose of defining a system boundary?
3. Name four categories of feasibility used in systems planning.
4. Why should assumptions be recorded and assigned an owner?
5. What information should a success criterion contain?

5 Long Answer Questions

1. Explain how systems thinking can reveal unintended consequences of an apparently beneficial intervention.
2. Describe a systematic method for conducting stakeholder analysis and explain why low-power stakeholders should not be ignored.
3. Discuss the relationship among objectives, requirements, scope, constraints, and assumptions.
4. Explain the main components of a business case and the limitations of a simple net-benefit comparison.
5. Evaluate the ethical responsibilities of an analyst planning a system that uses personal data and artificial intelligence.

3 Analytical / Application Questions

1. A college receives complaints that scholarship decisions are delayed. Develop a problem statement, identify possible symptoms and root causes, list stakeholders, and propose three measurable success criteria.
2. A retailer proposes a mobile application because customers abandon online orders. Analyze whether the application is necessarily the correct solution. Identify evidence to collect and at least three alternative interventions.
3. For a public-service portal, construct a scope statement containing inclusions, exclusions, constraints, assumptions, dependencies, and a staged implementation recommendation.

Multiple Choice Questions with Answers

Question 1

Which statement is the strongest problem statement?

A. The organization needs a mobile application.

B. Staff should purchase a modern database.

C. Service requests take six days to resolve because information is incomplete and repeatedly re-entered.

D. Customers dislike the current software.

Correct Answer: C. Service requests take six days to resolve because information is incomplete and repeatedly re-entered.

Question 2

What is a symptom?

A. A fundamental contributing condition

B. An observable sign of a deeper condition

C. A formal project constraint

D. A proposed technical intervention

Correct Answer: B. An observable sign of a deeper condition

Question 3

Which activity best reflects systems thinking?

A. Examining only the fastest individual task

B. Selecting technology before interviewing users

C. Considering relationships, feedback, boundaries, and unintended consequences

D. Ignoring external stakeholders

Correct Answer: C. Considering relationships, feedback, boundaries, and unintended consequences

Question 4

Which item is a constraint?

A. The desired reduction in response time

B. An assumption that data are accurate

C. A legal requirement governing personal data

D. A proposed system function

Correct Answer: C. A legal requirement governing personal data

Question 5

Which stakeholder generally requires close management in a power–interest matrix?

A. High power and high interest

B. High power and low interest

C. Low power and high interest

D. Low power and low interest

Correct Answer: A. High power and high interest

Question 6

What is the main purpose of a baseline?

A. To define the project sponsor

B. To measure current performance for comparison

C. To eliminate all project risks

D. To specify a programming language

Correct Answer: B. To measure current performance for comparison

Question 7

Which alternative should normally be considered in a business case?

A. Only custom development

B. Only the solution preferred by the sponsor

C. Maintaining the current situation

D. Only the most expensive solution

Correct Answer: C. Maintaining the current situation

Question 8

If total benefits are ₹900,000 and total costs are ₹650,000, the simple net benefit is:

A. ₹250,000

B. ₹1,550,000

C. ₹650,000

D. ₹900,000

Correct Answer: A. ₹250,000

Question 9

Why is a staged pilot useful in systems planning?

A. It removes the need for stakeholder analysis.

B. It reduces uncertainty and permits evidence-based review before expansion.

C. It guarantees that the final system will have no defects.

D. It avoids defining success criteria.

Correct Answer: B. It reduces uncertainty and permits evidence-based review before expansion.

Question 10

Which is an appropriate responsibility when using AI during planning?

A. Accepting generated summaries without verification

B. Uploading confidential data to any public tool

C. Verifying outputs, protecting information, and retaining human accountability

D. Replacing stakeholder engagement with automated analysis

Correct Answer: C. Verifying outputs, protecting information, and retaining human accountability