Systems Development, Project Management and Governance

Introduction

Business organisations depend on information systems to process transactions, support decisions, serve customers and coordinate employees. Developing or acquiring such systems is not merely a technical activity. It requires managers to clarify business needs, evaluate alternatives, allocate resources, control risks, manage change and ensure that the resulting system creates measurable value.

This chapter examines the systems development life cycle (SDLC), agile development and prototyping. It then connects these approaches with requirements analysis, feasibility assessment, implementation planning, project control, IT governance and organisational change management. The central principle is that a successful system is not simply delivered on time and within budget; it must also be usable, secure, ethically acceptable, aligned with strategy and adopted by its intended users.

Learning Objectives

After studying this chapter, you should be able to:

1. Compare traditional SDLC, agile and prototyping approaches.
2. Formulate clear, testable and prioritised system requirements.
3. Conduct technical, economic, operational, legal and schedule feasibility analysis.
4. Prepare an implementation plan involving scope, schedule, resources, risks, testing and deployment.
5. Apply project-control techniques, including milestones, change control and earned-value measures.
6. Explain the purpose and principles of IT governance.
7. Apply change-management practices to improve system adoption and organisational outcomes.

1. Systems Development as a Business Process

Systems development is the structured process of identifying an organisational need and creating, acquiring, configuring or improving an information system to address it. The process may involve business analysts, project managers, programmers, database specialists, cybersecurity professionals, vendors, managers and end users.

A development project normally transforms a problem or opportunity into a working capability. For example, a retailer may begin with excessive stock-outs, formulate requirements for an inventory system, compare cloud and on-premises options, configure or build a solution, train employees and measure improvements in availability and inventory accuracy.

A project differs from routine operations. A project is temporary, has a defined objective, consumes constrained resources and produces a distinct deliverable. Operations, by contrast, are continuing activities such as processing daily sales transactions or maintaining a help desk. Nevertheless, a project must eventually be transferred into operational management, so development and operations should be planned together.

2. The Systems Development Life Cycle

The SDLC is a framework for organising systems development into connected phases. A common version contains:

1. Initiation and planning – define the business problem, objectives, stakeholders, scope and initial business case.
2. Requirements analysis – determine what users and the organisation need the system to do.
3. System design – specify processes, data, interfaces, controls, infrastructure and security.
4. Development or acquisition – build, configure or purchase the solution.
5. Testing – verify that the system satisfies requirements and operates reliably.
6. Implementation – deploy the system, migrate data, train users and introduce new procedures.
7. Operation and maintenance – monitor performance, correct defects, enhance capabilities and eventually retire or replace the system.

The phases are often illustrated as sequential, but responsible development includes feedback and iteration. Defects discovered during testing may require design changes; new regulatory obligations may alter requirements; and user evaluation may lead to revised interfaces.

The traditional or predictive approach

In a predictive, often called waterfall, approach, substantial analysis and design occur before development. Each phase produces formal deliverables and approval gates. This approach is appropriate where requirements are stable, compliance documentation is important, technology is well understood and late changes would be costly. Examples include payroll systems with established rules, regulated systems and infrastructure projects with tightly controlled specifications.

Its strengths include clear accountability, predictable documentation, easier contractual control and systematic review. Its weaknesses include delayed user feedback, difficulty accommodating changing requirements and the risk that a technically correct system does not solve the real business problem.

Agile development

Agile development treats systems as evolving products rather than one-time deliveries. Work is divided into short iterations, commonly called sprints, during which a cross-functional team produces a potentially usable increment. A product owner prioritises the product backlog, the team estimates and completes work, and stakeholders review the result. Feedback is then used to revise priorities.

Agile values working software, collaboration with customers, response to change and incremental delivery. It does not mean that planning, documentation or governance are unnecessary. Rather, planning occurs at several levels: a broad product vision, a release plan and detailed iteration plans. Documentation should be sufficient for operation, maintenance, compliance and knowledge transfer.

Agile is valuable when requirements are uncertain, users can provide frequent feedback and early delivery has business value. Its limitations include difficulty estimating the final scope precisely, the risk of prioritising short-term features over architecture or security, and the need for engaged stakeholders. Agile also requires disciplined product ownership and a team capable of making timely decisions.

Prototyping

A prototype is an early representation of a proposed system or part of it. It may be a paper sketch, clickable interface, spreadsheet model, simulation or limited working application. Prototyping is especially useful when users cannot express requirements clearly or when usability is critical.

Two forms are particularly important:

• Throwaway prototyping: a temporary model is created to explore requirements and then discarded.
• Evolutionary prototyping: the initial model is progressively refined into the final system.

Prototypes make abstract ideas visible and expose misunderstandings early. However, users may mistake a prototype for a production-ready system. A prototype may omit security, scalability, error handling and data-quality controls. If an evolutionary prototype becomes the final product without redesign, technical debt can result.

Comparative evaluation

In practice, organisations combine these approaches. A project may use predictive governance and approval gates, agile delivery teams and prototypes for high-risk interfaces. The choice should follow the nature of the problem, not fashion.

3. Requirements Engineering

Requirements engineering is the disciplined process of discovering, analysing, documenting, validating, prioritising and managing what a system must provide and the constraints under which it must operate.

Types of requirements

Business requirements state the organisational outcomes sought, such as reducing order-processing time by 30% or improving visibility of inventory.

User requirements describe what a particular user needs to accomplish, such as allowing a warehouse supervisor to approve a stock adjustment.

Functional requirements specify system behaviours. For example: “The system shall calculate the reorder quantity when stock falls below the approved threshold.”

Non-functional requirements specify qualities or constraints, including performance, availability, security, accessibility, usability, maintainability, legal compliance and interoperability. For example: “The system shall display a confirmed order within two seconds for 95% of requests during normal operating conditions.”

A requirement should be clear, necessary, feasible, testable and traceable to a business objective. Ambiguous terms such as “fast,” “user-friendly” or “secure” should be converted into measurable acceptance criteria.

Requirements elicitation and analysis

Analysts obtain requirements through interviews, workshops, observation, document analysis, surveys, interface reviews, data analysis and examination of existing systems. Each method reveals different information. Observation may reveal workarounds that employees forget to mention in interviews, while workshops expose disagreements among departments.

A useful user-story form is: “As a [role], I want [capability], so that [business value].” The story should be supported by acceptance criteria describing the conditions that determine whether it is complete. Process models, use-case descriptions, data models and prototypes provide additional precision.

Stakeholders frequently have conflicting interests. Sales staff may want flexible discounts, finance may require strict approval, and customers may expect immediate service. The analyst must identify the underlying business rules, make conflicts explicit and obtain an authorised decision.

Prioritisation and traceability

The MoSCoW technique classifies requirements as:

• Must have: essential for the solution to be viable or compliant.
• Should have: important but with a temporary workaround.
• Could have: desirable if resources permit.
• Won’t have now: deliberately excluded from the current release.

A requirements traceability matrix links business objectives to requirements, design elements, test cases and implementation evidence. Traceability helps demonstrate coverage, identify untested requirements and assess the effects of proposed changes.

4. Feasibility Analysis and the Business Case

Feasibility analysis determines whether a proposed system is practical and worthwhile. It should be completed before major commitment and revisited when assumptions change.

The principal dimensions are:

• Technical feasibility: Can the organisation obtain the required technology, integration, skills, capacity, security and support?
• Economic feasibility: Do expected benefits justify development, acquisition, operation, training, migration and retirement costs?
• Operational feasibility: Will the system fit work practices, organisational culture, policies and user capabilities?
• Legal and regulatory feasibility: Can the solution comply with privacy, intellectual-property, accessibility, records-management, employment and sector-specific obligations?
• Schedule feasibility: Can the system be delivered in the required time without unacceptable risk?
• Organisational and strategic feasibility: Does the project support strategic priorities and have credible executive sponsorship?

A simple financial appraisal can use net benefit:

Benefits may include additional revenue, avoided losses, reduced processing costs, improved compliance and better customer retention. Costs include one-time costs and recurring costs. Monetary estimates should state assumptions and distinguish tangible from difficult-to-measure benefits.

Return on investment can be expressed as:

ROI is meaningful only when the period, cost categories and benefit assumptions are consistent. It should not be the sole decision criterion: a legally required security system may have limited direct revenue, and a strategically essential platform may produce benefits over many years.

Worked feasibility example

An organisation estimates first-year benefits of $180,000 and first-year costs of $120,000. The net benefit is $60,000. Using the stated ROI definition:

This calculation assumes that all amounts are comparable, occur within the same evaluation period and exclude financing effects. Management should still test sensitivity: if benefits are 20% lower and costs are 10% higher, the result may be substantially less attractive.

5. Implementation Planning

An implementation plan converts an approved solution into coordinated action. It should identify:

• scope, exclusions, deliverables and acceptance criteria;
• work breakdown structure and task dependencies;
• schedule, milestones and decision gates;
• roles, skills, budget and procurement needs;
• data cleansing, migration and reconciliation activities;
• infrastructure, security and access preparation;
• testing levels and defect-management procedures;
• training, communication and support arrangements;
• deployment strategy, rollback procedures and business continuity;
• post-implementation review and benefits measurement.

A work breakdown structure decomposes the project into manageable deliverables and work packages. Milestones are significant control points, such as requirements approval, completion of user acceptance testing or production go-live. A schedule should show dependencies rather than merely listing dates. For example, data migration testing cannot be completed until the target data structure is available.

Common deployment strategies include:

• Direct cutover: the old system stops and the new system starts immediately. It is fast but carries high operational risk.
• Parallel running: old and new systems operate together for a period. It reduces transition risk but increases cost and workload.
• Pilot implementation: the system is introduced to one site or group first. Lessons can be applied before wider deployment.
• Phased implementation: modules, locations or functions are introduced in stages. This limits exposure but may require temporary integration between old and new systems.

The appropriate strategy depends on risk, criticality, data complexity, user readiness and the availability of rollback arrangements.

6. Project Control and Risk Management

Project control compares actual progress and performance with an approved baseline. Control does not mean preventing all change; it means making changes visible, evaluated and authorised.

A project control system should monitor scope, schedule, cost, quality, resources, risks, issues, dependencies and benefits. Status reports should distinguish facts from forecasts and should identify decisions required from sponsors.

Earned-value analysis

Earned-value management integrates scope, schedule and cost. Its basic measures are:

• Planned Value (PV): budgeted value of work scheduled by a particular date.
• Earned Value (EV): budgeted value of work actually completed by that date.
• Actual Cost (AC): actual cost incurred for completed work.

The schedule variance and cost variance are:

A positive SV indicates more budgeted work has been completed than planned; a negative SV indicates less. A positive CV indicates that completed work cost less than its budgeted value; a negative CV indicates an overrun. These measures use monetary units, even schedule variance, so they should be interpreted carefully.

Performance indices are:

An index above 1.00 is favourable under the standard definitions. These measures assume that work has been objectively assessed and that the baseline is credible.

Example: Suppose PV = $100,000, EV = $90,000 and AC = $95,000. Then SV = −$10,000, CV = −$5,000, SPI = 0.90 and CPI ≈ 0.95. The project has completed less work than planned and has spent more than the budgeted value of that work. Management should investigate causes rather than simply demand faster work.

Risk management

Risk is an uncertain event or condition that could affect objectives. Risk management involves identification, analysis, response planning, ownership and monitoring. Responses to threats include avoiding, reducing, transferring or accepting the risk. Opportunities may be exploited, enhanced, shared or accepted.

A risk register records the risk description, cause, consequence, probability, impact, rating, owner, response and status. Typical systems risks include unclear requirements, vendor failure, cybersecurity incidents, poor data quality, inadequate skills, integration failure and user resistance.

7. IT Governance

IT governance is the system by which an organisation directs and controls information technology so that it supports strategy, delivers value, manages risk and uses resources responsibly. Governance is distinct from management. Governance establishes direction, accountability and oversight; management plans and executes activities within that direction.

Core governance principles include:

1. Strategic alignment: technology investments support organisational objectives.
2. Value delivery: expected benefits are defined, measured and realised.
3. Risk management: technology, security, continuity, privacy and compliance risks are identified and controlled.
4. Resource responsibility: people, budgets, data, infrastructure and suppliers are used effectively.
5. Performance measurement: outcomes and service quality are monitored.
6. Accountability and transparency: decision rights, reporting lines and evidence are clear.

Governance mechanisms may include a board or executive technology committee, project steering committee, architecture review board, information-security function, data-governance council, portfolio review and internal audit. Policies define expectations, standards define required practices, and procedures describe operational steps.

A governance framework should clarify who approves investment, who owns data, who accepts risk, who authorises access and who may approve changes to production systems. Separation of duties is important: for example, the person who develops a change should not be the sole person who authorises and deploys it in a critical environment.

Governance also has ethical responsibilities. Systems should respect privacy, minimise unnecessary data collection, protect confidential information, provide accessibility and avoid discriminatory outcomes. Where AI is incorporated, organisations should address data provenance, explainability appropriate to the use, human oversight, bias testing, security and accountability for decisions. Compliance is a minimum obligation; responsible governance also considers affected stakeholders and social consequences.

8. Change Management and Adoption

A technically successful implementation can fail if people do not understand, accept or use the new system. Change management is the structured preparation and support of individuals and groups as they move from a current state to a desired future state.

Change affects processes, roles, authority, skills, performance measures and organisational identity. Resistance may arise from fear of job loss, increased workload, poor previous experiences, lack of trust, inadequate training or genuine concern that the proposed design is unsuitable.

Effective change management includes:

• stakeholder analysis and impact assessment;
• visible sponsorship by credible leaders;
• early, honest and two-way communication;
• involvement of representative users in design and testing;
• role-based training and practice environments;
• local champions or super-users;
• support during transition and rapid issue resolution;
• reinforcement through performance measures, recognition and leadership behaviour;
• measurement of adoption, competence, satisfaction and business outcomes.

A useful distinction is between communication and participation. Sending information does not create ownership. Employees should have appropriate opportunities to question assumptions, test prototypes, report risks and influence workable solutions. Participation does not mean every preference can be adopted; it means decisions are informed and explained.

Post-implementation review should examine whether the system meets requirements, whether benefits are being realised, whether controls operate effectively and what lessons should inform future projects. Benefits should be assigned to accountable owners rather than treated as the project team’s responsibility alone.

9. Integrated Illustrative Case: University Student-Service Platform

The following is a fictional illustrative case.

Background and problem

A university used separate systems for applications, enrolment, fee payments and student support. Students repeatedly entered the same information, staff maintained spreadsheets and management lacked a reliable view of service demand. The university proposed a single student-service platform.

Analysis

The project team identified students, academic departments, finance, registry, information technology, disability services and senior management as stakeholders. Requirements included online status tracking, secure document submission, payment integration, role-based access and accessibility. A non-functional requirement required common pages to load within three seconds for at least 95% of normal requests.

Workshops revealed conflicting priorities. Registry wanted strict data validation, while academic departments wanted flexible local fields. A prototype of the student dashboard exposed navigation problems that had not appeared in written requirements. The project therefore adopted a hybrid approach: executive governance and formal stage approvals, agile iterations for interfaces and integrations, and throwaway prototypes for usability testing.

Feasibility analysis found that a cloud platform was technically and economically plausible, but data protection obligations required contract review, retention rules and a clear incident-response process. Operational feasibility depended on redesigning several manual procedures and training staff.

Approach and implementation

The steering committee approved a phased pilot for one faculty. The plan included data cleansing, interface development, security testing, user acceptance testing, staff training and a rollback procedure. A product owner prioritised the backlog, while the project manager maintained the integrated schedule, risk register and budget baseline.

A major risk was inaccurate historical data. The team created reconciliation reports and required business owners to approve migrated records. Another risk was resistance from administrative staff who feared that automation would remove their roles. Leaders explained that responsibilities would shift toward case resolution and student support, and staff participated in workflow design.

Outcome

The pilot reduced duplicate data entry and enabled students to track requests online. Several requirements were deferred because they were not essential to the pilot and would have delayed deployment. After reviewing service data and user feedback, the university improved the dashboard before expanding to other faculties.

Learning points

The case demonstrates that requirements are discovered through interaction, not merely written at project initiation. It also shows why governance, feasibility, data quality, user participation, phased deployment and benefits measurement must be integrated. A delivery method alone cannot compensate for weak decision rights or poor adoption planning.

10. Challenges, Limitations and Best Practices

No development approach eliminates uncertainty. Predictive methods may create false confidence in early estimates. Agile methods may produce local optimisation or architectural weakness if long-term design is neglected. Prototypes may hide operational complexity. Business cases may overstate benefits, while implementation plans may underestimate data migration and organisational change.

Best practices include:

• begin with a clearly stated business problem and measurable outcomes;
• involve affected users and control scope deliberately;
• use prototypes and iterations where uncertainty is high;
• retain appropriate architecture, security and compliance discipline;
• make assumptions, dependencies and exclusions explicit;
• establish one accountable owner for each major decision;
• baseline scope, schedule and cost, then control changes transparently;
• test data, interfaces, controls, security, performance and usability;
• plan deployment, support and rollback before go-live;
• measure adoption and benefits after implementation;
• treat governance and ethics as continuous responsibilities rather than final approvals.

Chapter Summary

Systems development is a business and organisational process as well as a technical one. The SDLC provides a structured view of planning, requirements, design, development, testing, implementation and maintenance. Predictive approaches suit stable and regulated work; agile approaches support incremental delivery and changing requirements; prototyping helps users and analysts discover ambiguous needs. These approaches can be combined.

Requirements should be expressed in clear, testable and traceable terms, including both functional and non-functional requirements. Feasibility analysis considers technical, economic, operational, legal, schedule and strategic dimensions. Implementation planning coordinates scope, resources, data, testing, training, deployment and support. Project control uses baselines, milestones, risk registers, change control and, where suitable, earned-value measures.

IT governance aligns technology with strategy, value, risk, resources and accountability. Change management addresses the human and organisational conditions required for adoption. Ethical governance requires attention to privacy, security, accessibility, fairness and responsibility, especially when AI is used. Ultimately, system success is measured by sustained business value and responsible outcomes, not by delivery alone.

Key Terms

Systems development life cycle (SDLC): A structured framework for developing, implementing, operating and retiring information systems.

Predictive development: An approach that defines substantial scope and plans activities before delivery.

Agile development: An iterative approach based on collaboration, incremental delivery and response to change.

Prototype: An early representation of a proposed system or feature used for learning and evaluation.

Requirements engineering: The process of eliciting, analysing, documenting, validating and managing requirements.

Functional requirement: A statement of what a system must do.

Non-functional requirement: A quality, constraint or performance condition placed on a system.

Acceptance criterion: A condition used to determine whether a requirement or work item is complete.

Traceability: The ability to link requirements to objectives, designs, tests and evidence.

Feasibility analysis: Assessment of whether a proposed project is practical and worthwhile.

Business case: A justification for an investment based on expected benefits, costs, risks and strategic fit.

Implementation plan: A coordinated plan for deploying a solution and transitioning it into operation.

Baseline: An approved reference point for scope, schedule or cost against which performance is compared.

Risk register: A record of identified risks, their causes, impacts, owners and responses.

Earned value: The budgeted value of work actually completed.

IT governance: Direction and control of IT to achieve value, alignment, accountability and risk management.

Change management: Structured support for people and organisations moving to a new way of working.

Benefits realisation: The process of measuring and securing the intended value from a project.

Technical debt: Future cost or risk created by expedient technical decisions or inadequate design.

Review Questions

Short Answer Questions

1. What are the principal phases of the systems development life cycle?
2. Distinguish a functional requirement from a non-functional requirement.
3. Why is prototyping useful when requirements are ambiguous?
4. What is the difference between governance and management?
5. State two purposes of a requirements traceability matrix.

Long Answer Questions

1. Compare predictive SDLC, agile and prototyping approaches, including their strengths, limitations and appropriate applications.
2. Explain the dimensions of feasibility analysis and discuss why ROI should not be the only basis for a systems investment decision.
3. Describe the major components of an implementation plan for a business information system.
4. Explain how IT governance supports strategic alignment, value delivery, risk management and accountability.
5. Discuss the role of change management in achieving successful system adoption.

Analytical / Application Questions

1. A retailer has stable regulatory requirements but uncertain customer-interface needs. Recommend a development approach and justify how different methods could be combined.
2. A project has PV = $200,000, EV = $180,000 and AC = $210,000. Calculate SV, CV, SPI and CPI, and interpret the results.
3. A hospital is replacing a patient-record system. Identify five major risks, assign an appropriate response to each, and propose a deployment strategy with reasons.

Multiple Choice Questions with Answers

Question 1

Which approach is most appropriate when requirements are uncertain and users can provide frequent feedback?

A. Agile development

B. Direct cutover

C. Predictive development only

D. Routine operations management

Correct Answer: A. Agile development

Question 2

Which of the following is a non-functional requirement?

A. The system shall create a purchase order

B. The system shall approve a refund

C. The system shall display 95% of pages within three seconds

D. The system shall calculate tax

Correct Answer: C. The system shall display 95% of pages within three seconds

Question 3

What is the primary purpose of a throwaway prototype?

A. To replace all production testing

B. To explore and clarify requirements before final development

C. To eliminate the need for governance

D. To operate as the permanent system without redesign

Correct Answer: B. To explore and clarify requirements before final development

Question 4

Which feasibility dimension examines whether a solution fits work practices and user capabilities?

A. Technical feasibility

B. Operational feasibility

C. Schedule feasibility

D. Economic feasibility

Correct Answer: B. Operational feasibility

Question 5

If PV = $100,000, EV = $90,000 and AC = $95,000, what is the CPI?

A. 0.90

B. 0.95

C. 1.06

D. $5,000

Correct Answer: C. 1.06

Question 6

Which statement best describes IT governance?

A. It is only the programming of business applications

B. It directs and controls IT to support strategy, value and risk management

C. It replaces all project management activities

D. It concerns only hardware procurement

Correct Answer: B. It directs and controls IT to support strategy, value and risk management

Question 7

Which deployment method introduces a system to one location or user group before wider implementation?

A. Pilot implementation

B. Direct cutover

C. Parallel running everywhere

D. Retirement implementation

Correct Answer: A. Pilot implementation

Question 8

What does a requirements traceability matrix connect?

A. Employees to salary grades only

B. Requirements to objectives, designs, tests and evidence

C. Vendors to office locations only

D. Risks to unrelated projects only

Correct Answer: B. Requirements to objectives, designs, tests and evidence

Question 9

Which action is most likely to improve user adoption?

A. Excluding users until after deployment

B. Providing role-based training and involving representative users in testing

C. Removing all feedback channels

D. Changing performance measures without explanation

Correct Answer: B. Providing role-based training and involving representative users in testing

Question 10

A negative cost variance in earned-value analysis means that:

A. Completed work cost more than its budgeted value

B. More work was completed than planned

C. The project has no remaining risk

D. The project is necessarily ahead of schedule

Correct Answer: A. Completed work cost more than its budgeted value