Systems Development and Technology Project Management

Introduction and Context

Banks, insurers, and other financial institutions depend on information systems for customer onboarding, payments, lending, claims processing, regulatory reporting, fraud detection, and management decision-making. An application may be acquired from a vendor, configured from an existing platform, developed internally, or delivered through a combination of these approaches. In every case, success depends on more than software functionality. The organization must understand its business problem, define requirements, evaluate feasibility, control risk, manage stakeholders, test the solution, support adoption, and govern change.

Systems development is the disciplined process of investigating a business need and producing or acquiring an information system that addresses it. Technology project management applies knowledge, methods, tools, and leadership to plan and control the work within agreed constraints. These disciplines are closely connected: a technically successful project can still fail if it does not improve business performance, comply with regulation, or gain user acceptance.

For banking, finance, and insurance students, this topic is especially important because information systems process valuable personal, financial, and risk data. Errors may cause financial loss, regulatory penalties, reputational damage, or harm to customers. A sound development life cycle therefore combines technical quality with business analysis, internal control, security, privacy, and responsible change management.

Learning Objectives

After studying this chapter, you should be able to:

1. Explain the systems development life cycle and compare predictive, agile, iterative, and prototyping approaches.
2. Identify, analyze, document, and prioritize business and system requirements.
3. Evaluate technical, economic, operational, legal, schedule, and organizational feasibility.
4. Explain project planning, scope, scheduling, risk, quality, governance, and stakeholder management.
5. Describe testing, implementation, training, change management, and post-implementation review.
6. Apply these concepts to the acquisition or development of a business application.
7. Evaluate ethical, security, privacy, regulatory, and artificial-intelligence issues in technology projects.

1. The Systems Development Life Cycle

The systems development life cycle (SDLC) is a framework for moving from an identified business need to a functioning and supported system. Although textbooks often present stages sequentially, real projects may revisit earlier activities as new information emerges.

A commonly used SDLC contains the following stages:

The SDLC provides control points. For example, a project should not enter detailed development without an approved scope and sufficiently understood requirements. In a regulated institution, approval may also be required from information security, risk, compliance, legal, architecture, procurement, and data-protection functions.

Predictive, Agile, Iterative, and Prototyping Approaches

A predictive or plan-driven approach attempts to define scope and requirements early, then progresses through controlled phases. It is appropriate when requirements are stable, interfaces are highly regulated, or extensive documentation and approvals are necessary. Its weakness is that users may not see a realistic working system until late in the project.

Agile development delivers working increments frequently. A product backlog contains prioritized work items, and short iterations produce potentially usable outputs. Agile values collaboration, feedback, adaptation, and delivery of business value. It does not mean the absence of planning or documentation. In a bank, agile teams still need security controls, audit trails, regulatory evidence, architecture standards, and release approvals.

Iterative development repeats analysis, design, development, and evaluation. Each cycle improves the product. Incremental development adds usable functionality in stages. These approaches reduce the risk of waiting until the end to discover that the solution is unsuitable.

A prototype is a preliminary model of a proposed system. A throwaway prototype is built to clarify requirements and then discarded. An evolutionary prototype is progressively refined into the final system. Prototypes are valuable where users find it difficult to describe desired functionality, such as a claims dashboard or relationship-manager interface. However, a visually impressive prototype may conceal weaknesses in security, scalability, data quality, or integration.

2. Requirements Analysis

Requirements describe capabilities, constraints, and qualities that a system must provide. Requirements analysis translates a business problem into a shared, testable understanding of the desired outcome.

Types of Requirements

Business requirements state the organizational purpose. Example: “Reduce the average time required to process a standard motor-insurance claim.”

Functional requirements specify what the system must do. Example: “The system shall calculate the claim reserve using approved policy rules and record the rule version used.”

Non-functional requirements specify qualities or constraints. Examples include response time, availability, confidentiality, accessibility, auditability, maintainability, and legal retention periods.

Data requirements define data entities, ownership, quality rules, classifications, retention, lineage, and permitted use.

Interface requirements define interactions with users, core-banking systems, payment networks, credit bureaus, identity services, or regulatory platforms.

A strong requirement is clear, necessary, feasible, prioritized, uniquely identified, and testable. Ambiguous language such as “the system should be user-friendly” should be converted into observable criteria, such as “a trained service employee shall complete a standard customer-address update in no more than five screens without consulting a procedure manual.”

Requirements Elicitation and Documentation

Business analysts use interviews, observation, document analysis, workshops, surveys, process mapping, data analysis, scenarios, and prototypes. Different methods reveal different knowledge. Interviews uncover expert judgment; observation exposes workarounds; document analysis identifies formal policy; data analysis reveals actual transaction patterns.

A use case describes interaction between an actor and a system to achieve a goal. A user story is a concise agile expression, often written as: “As a [role], I want [capability], so that [benefit].” Acceptance criteria define the conditions under which the story is complete.

A requirements traceability matrix links business objectives to requirements, design elements, test cases, and implementation evidence. Traceability is especially important in financial services because it helps demonstrate that regulatory and control requirements have been addressed.

Requirements should be prioritized. The MoSCoW method classifies items as Must have, Should have, Could have, and Won’t have for the current release. Prioritization should consider customer value, risk reduction, regulatory necessity, dependency, cost, and urgency rather than the loudest stakeholder’s preference.

Requirements Validation

Requirements validation asks whether the requirements are correct, complete, consistent, feasible, unambiguous, and verifiable. A review may identify conflicts, such as a request for unlimited historical access alongside a strict data-minimization policy. Each requirement should have an owner and an acceptance method. Formal approval creates a baseline, but change control must remain possible when assumptions prove false.

3. Feasibility and the Business Case

Feasibility analysis prevents an organization from investing heavily in an unsuitable solution. It is an informed judgment, not a guarantee.

A business case identifies alternatives, assumptions, costs, benefits, risks, dependencies, and decision criteria. Costs include software, hardware or cloud services, integration, data migration, consulting, training, internal labor, cybersecurity, support, licenses, and eventual retirement. Benefits may include additional revenue, lower processing cost, faster service, reduced fraud, improved control, and avoided regulatory loss.

Financial evaluation should distinguish cash flows occurring at different times. A basic net present value model is:

Here, CF_t is the net cash flow in period t, r is the discount rate per period, and n is the number of periods. Cash flows and the discount rate must use the same time unit. The model assumes that projected cash flows and the chosen discount rate are sufficiently reliable; it does not capture every strategic, ethical, or regulatory consideration.

For example, suppose a project costs $100,000 immediately and produces net benefits of $55,000 at the end of each of the next two years. At a 10% annual discount rate:

NPV = -100,000 + 55,000/1.10 + 55,000/(1.10)²

NPV ≈ -100,000 + 50,000 + 45,455 = -4,545

On these assumptions, the financial NPV is approximately negative $4,545. Management should not automatically reject the project: compliance, resilience, customer protection, or strategic benefits may justify it. Conversely, a positive NPV does not excuse unacceptable security or privacy risk.

4. Project Management for Technology Projects

A technology project is a temporary endeavor undertaken to create a unique product, service, or result. Operations are ongoing and repetitive; projects have a beginning and an end, although a project may create a system that enters operations.

The project charter authorizes the project and identifies its sponsor, objectives, high-level scope, authority, assumptions, constraints, budget, major risks, and success measures. Governance defines who makes decisions and who is accountable. A steering committee may resolve escalated issues, approve major changes, and confirm stage gates.

Scope, Schedule, and Dependencies

Scope specifies what is included and excluded. A work breakdown structure decomposes deliverables into manageable work packages. A schedule identifies activities, duration estimates, dependencies, milestones, and responsible parties. Common dependencies include finish-to-start relationships, where one activity must finish before another begins.

A critical path is the sequence of activities that determines the shortest possible project duration under the modeled assumptions. Delay to an activity with no schedule flexibility may delay the project. Estimates should be expressed with assumptions and ranges when uncertainty is material. A plan that hides uncertainty is less useful than a transparent plan with contingency.

Scope creep occurs when work is added without corresponding approval, resources, time, or funding. A change request should explain the reason, alternatives, impact on scope, schedule, cost, quality, security, compliance, and benefits. A change control board or delegated product authority then decides whether to approve, reject, defer, or replace work.

Risk Management

A risk is an uncertain event or condition that may affect objectives. Risk management involves identification, analysis, response, ownership, monitoring, and communication. A qualitative risk score is often represented as:

Probability and impact must be defined consistently, such as ordinal scales from 1 to 5. The product is a prioritization aid, not a precise probability of loss. A risk register records the description, cause, consequence, owner, rating, response, trigger, and status.

Responses include avoiding the risk, reducing its probability or impact, transferring some consequence through a contract or insurance arrangement, accepting it with authority, or escalating it. Examples include independent security testing, phased rollout, backup procedures, supplier due diligence, and contingency reserves.

Stakeholders and Communication

Stakeholders include customers, employees, managers, regulators, suppliers, auditors, security specialists, operations staff, and affected communities. A stakeholder analysis considers influence, interest, impact, expectations, and potential resistance. Communication should be timely, accurate, accessible, and suited to the recipient. Senior executives need decisions and exposures; developers need acceptance criteria and technical constraints; frontline employees need process and training information.

5. Acquisition, Configuration, and Development Decisions

Organizations may build internally, buy a commercial package, subscribe to software as a service, use a platform, outsource development, or combine these options. The decision should consider strategic differentiation, control, time to value, integration, data portability, supplier dependence, customization, total cost, security, resilience, and exit capability.

A request for proposal should state business requirements, service levels, security and privacy obligations, implementation responsibilities, data ownership, audit rights, incident notification, subcontracting, business continuity, service termination, and data return or deletion. Vendor demonstrations must be evaluated against documented scenarios rather than marketing claims.

Configuration is generally preferable to extensive customization when it meets requirements without weakening control or maintainability. However, forcing an organization to adopt an unsuitable process merely to avoid customization can create operational and compliance risk. Contracts should define measurable service levels, such as availability, response, recovery, support hours, and incident escalation. Availability percentages must be interpreted carefully: planned exclusions, maintenance, and measurement methods affect their meaning.

Cloud services may offer scalability and speed, but they do not transfer accountability for data protection, access control, resilience, or regulatory compliance. Shared-responsibility models must be explicitly understood.

6. Design, Data, Security, and Control

System design translates requirements into architecture, processes, data structures, interfaces, controls, and user experiences. A design review should consider functional fit as well as non-functional qualities.

Financial applications require strong identity and access management. Least privilege gives users only the access needed for their duties. Segregation of duties reduces the possibility that one individual can initiate, approve, and conceal a sensitive transaction. Authentication, authorization, encryption, logging, monitoring, backup, recovery, and vulnerability management should be designed rather than added at the end.

Data design should address accuracy, completeness, consistency, timeliness, uniqueness, lineage, and ownership. Migration requires profiling source data, mapping fields, cleansing exceptions, reconciling totals, protecting extracts, testing transformations, and obtaining business sign-off. A migration that technically completes but loses records or changes meaning is not successful.

Controls may be preventive, detective, or corrective. For example, an approval limit is preventive, an exception report is detective, and a recovery procedure is corrective. Audit logs should record relevant events, users, timestamps, actions, and outcomes while respecting privacy and retention requirements.

7. Testing and Quality Assurance

Testing provides evidence that a system meets requirements and is safe enough for its intended use. It reduces risk but cannot prove that every possible defect is absent.

Important test levels include:

• Unit testing: tests a small program component.
• Integration testing: tests interactions among components or systems.
• System testing: tests the complete solution against requirements.
• User acceptance testing: confirms that business users can perform intended processes and accept the outcome.
• Regression testing: checks that changes have not broken existing capability.
• Performance testing: examines response, throughput, capacity, and stability under defined conditions.
• Security testing: examines vulnerabilities, access control, configuration, and resistance to misuse.
• Operational readiness testing: checks monitoring, backup, recovery, support, and procedures.

A test case should identify preconditions, inputs, steps, expected results, actual results, evidence, and status. Test data should be representative without exposing unnecessary personal information. Defects should be classified by severity and priority, assigned to owners, retested after correction, and tracked to closure or formally accepted risk.

Testing should begin during requirements and design, not only after coding. Acceptance criteria convert requirements into observable tests. For a payment limit requirement, a test should cover values below, at, and above the limit, different currencies if relevant, unauthorized users, duplicate submissions, service interruption, and audit logging.

8. Implementation and Change Management

Implementation moves a solution into operational use. Strategies include:

• Direct cutover: the old system is replaced at once; it is fast but risky.
• Parallel running: old and new systems operate together; confidence increases but cost and reconciliation work also increase.
• Pilot: the solution is introduced to a limited branch, product, or user group before wider deployment.
• Phased implementation: functionality or organizational units are introduced in stages.

The appropriate strategy depends on risk, reversibility, urgency, data complexity, operational capacity, and customer impact. A cutover plan should define responsibilities, sequence, decision points, communication, backups, reconciliation, support coverage, rollback criteria, and escalation routes.

Change management addresses the human and organizational consequences of a new system. A useful approach includes leadership sponsorship, stakeholder involvement, communication of purpose, impact assessment, role-based training, user support, reinforcement, and measurement. Resistance is not automatically irrational; it may reveal workload concerns, loss of control, poor design, or legitimate risk.

Training should use realistic scenarios and should be evaluated through observation or task performance rather than attendance alone. After go-live, a hypercare period provides intensified support and rapid defect resolution. Benefits realization should measure whether intended improvements actually occur.

9. Case Study: Illustrative Digital Claims Application

Background

A fictional mid-sized insurer, Horizon Mutual, receives motor claims through branches, telephone, email, and a web form. Claims employees manually re-enter information into several systems. Customers cannot see claim status, and managers lack reliable information about processing times.

Problem

The average processing time is increasing, duplicate data entry creates errors, and customers make repeated calls for updates. The insurer also needs stronger evidence that claims decisions follow approved policies and that access to sensitive records is monitored.

Analysis

A cross-functional team maps the current process and identifies stakeholders: customers, claims handlers, assessors, fraud investigators, finance staff, IT, compliance, privacy, and an external repair network. Requirements include digital notification, document upload, status tracking, rule-version recording, role-based access, audit logs, integration with policy and payment systems, accessibility, and service continuity.

The team evaluates three alternatives: enhance the existing platform, acquire a commercial claims package, or build a bespoke application. The commercial package has strong workflow capability but would require expensive integration and vendor dependence. A bespoke system offers flexibility but has greater delivery and maintenance risk. Enhancing the existing platform is selected for the first release because it offers better integration and lower transition risk.

Approach and Solution

The project uses an agile delivery model within formal governance. A product owner prioritizes the backlog, while compliance and security specialists review each release. A prototype is tested with claims handlers before detailed interface design. The first release supports claim registration, status communication, and document management. A later release adds automated triage, subject to model validation and human review.

Testing includes integration, access-control, performance, migration, user acceptance, and operational recovery tests. A pilot is conducted in two branches. Staff receive scenario-based training, and customers are notified about the new digital channel without removing telephone access.

Outcome

After the pilot, the insurer identifies an unclear document requirement and a slow integration response. Both issues are corrected before wider rollout. Management reports shorter handling times and fewer status inquiries, while compliance confirms improved traceability. The project team also discovers that benefits depend on data quality and consistent use by employees, so post-implementation monitoring remains necessary.

Learning Points

The case demonstrates that requirements are socio-technical: they concern people, process, data, controls, and technology together. A prototype can reveal usability problems, but it cannot replace security and operational testing. Agile delivery and formal governance are compatible. Finally, automation should support accountable decisions rather than conceal responsibility.

10. Ethics, Regulation, and Contemporary Developments

Technology projects process information about identifiable people and financial behavior. Ethical practice requires purpose limitation, data minimization, transparency, appropriate consent or lawful basis, access control, retention discipline, and fair treatment. Organizations should assess whether a design creates exclusion, surveillance, unfair pricing, or barriers for customers with limited digital access.

Regulatory expectations vary by jurisdiction, but financial institutions commonly face obligations concerning privacy, consumer protection, outsourcing, operational resilience, cybersecurity, records, anti-money-laundering controls, and model risk. Compliance should be embedded in requirements and testing rather than treated as a final certificate.

Artificial intelligence can assist requirements classification, coding, testing, service support, fraud detection, forecasting, and document processing. Risks include inaccurate outputs, bias, lack of explainability, leakage of confidential data, insecure generated code, automation bias, and unclear accountability. AI-enabled systems require defined purposes, approved data, validation, monitoring, human oversight, access restrictions, documentation, and an escalation process. A generated answer or code fragment is not evidence of correctness.

Contemporary development increasingly uses DevOps and continuous delivery, in which development and operations collaborate through automated build, test, security scanning, deployment, and monitoring. Automation can improve consistency, but it must be controlled through version management, approvals, segregation of duties, rollback capability, and audit evidence. Low-code and no-code tools can increase business participation while creating risks of uncontrolled applications, inconsistent data, and weak security. Governance should identify ownership, approved platforms, testing expectations, and support responsibilities.

Best-Practice Checklist

A well-governed application project should:

1. Begin with a clearly defined business problem and measurable outcomes.
2. Involve affected users, control functions, and technical specialists early.
3. Document requirements in testable language and maintain traceability.
4. Compare build, buy, configure, outsource, and cloud alternatives.
5. Assess total cost, feasibility, supplier risk, security, privacy, and exit options.
6. Establish scope, authority, decision rights, risk ownership, and change control.
7. Design data quality, access, auditability, resilience, and recovery from the beginning.
8. Test functionality, integration, performance, security, migration, and operations.
9. Use an implementation strategy proportionate to customer and operational risk.
10. Train users, support adoption, measure benefits, and conduct a post-implementation review.

Chapter Summary

Systems development converts a business need into an operating information system through linked activities of planning, requirements analysis, design, acquisition or development, testing, implementation, operation, and review. Predictive approaches provide control where requirements are stable, while agile, iterative, and prototyping approaches provide feedback and adaptability. No approach eliminates the need for governance.

Requirements must be understandable, prioritized, feasible, traceable, and testable. Feasibility considers strategic, technical, economic, operational, legal, schedule, and organizational dimensions. Project management controls scope, schedule, resources, risk, quality, stakeholders, and decisions. Acquisition choices require attention to integration, total cost, supplier dependence, security, resilience, contracts, and exit capability.

Testing creates evidence of fitness, while implementation and change management address operational and human adoption. In financial services, security, privacy, auditability, segregation of duties, data quality, regulatory compliance, and customer protection are central design concerns. AI, cloud, DevOps, and low-code tools can increase value, but they introduce governance responsibilities. Successful projects therefore deliver not merely software, but a controlled, usable, ethical, and sustainable business capability.

Key Terms

Systems development life cycle: A structured framework for creating, acquiring, implementing, operating, and reviewing an information system.

Predictive development: A plan-driven approach that defines much of the scope and sequence in advance.

Agile development: An adaptive approach that delivers increments, collaborates with stakeholders, and responds to feedback.

Prototype: A preliminary model used to explore requirements, design, or usability.

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

Non-functional requirement: A quality, constraint, or condition governing how a system performs.

Requirements traceability: Linking objectives and requirements to design, tests, and evidence.

Feasibility analysis: Evaluation of whether a proposed solution is viable across relevant dimensions.

Business case: A justification describing alternatives, costs, benefits, risks, and assumptions.

Project charter: A document that authorizes a project and defines its high-level direction.

Scope creep: Uncontrolled addition of work without corresponding approval or adjustment of resources.

Risk register: A record of identified risks, ratings, owners, responses, and status.

Critical path: The sequence of schedule activities that determines modeled minimum project duration.

User acceptance testing: Business testing to determine whether a solution is acceptable for intended use.

Regression testing: Testing that checks whether changes have damaged existing functionality.

Direct cutover: Replacing the old system with the new system at one time.

Parallel running: Operating old and new systems together for a period.

Change management: Structured action to help people and the organization adopt a change.

Least privilege: Giving an identity only the access required for authorized duties.

Benefits realization: Measuring whether expected business outcomes are achieved after implementation.

Review Questions

Short Answer Questions

1. What are the main stages of the systems development life cycle?
2. Distinguish a functional requirement from a non-functional requirement.
3. Why is a requirements traceability matrix useful in a regulated organization?
4. State two advantages and two limitations of prototyping.
5. What is the purpose of user acceptance testing?

Long Answer Questions

1. Compare predictive, agile, iterative, and prototyping approaches, and explain when each may be suitable for a financial-services application.
2. Explain the dimensions of feasibility analysis and show how they contribute to a business case.
3. Discuss how scope, risk, stakeholder, and change management interact in a technology project.
4. Explain the major testing levels and why testing should begin before coding is complete.
5. Discuss security, privacy, data quality, auditability, and regulatory considerations in the design of a banking or insurance application.

Analytical / Application Questions

1. A bank wants to replace its loan-origination application in six months because of a regulatory deadline. Requirements are incomplete, several legacy systems must be integrated, and customer harm from failure would be high. Recommend an approach and implementation strategy, and justify your choice.
2. A vendor proposes a cloud-based claims platform with attractive functionality but refuses to provide detailed subcontractor information or a clear data-exit procedure. Analyze the risks and identify contract and governance conditions that should be required before approval.
3. A project reports a positive financial NPV but depends on an opaque AI model that may disadvantage customers with limited credit histories. Evaluate whether the project should proceed and propose safeguards.

Multiple Choice Questions with Answers

Question 1

Which requirement is a non-functional requirement?

A. The system shall calculate a premium from approved rating factors.

B. The system shall allow an employee to create a new claim.

C. The system shall display a standard claim record within two seconds under defined normal load.

D. The system shall send a confirmation message after claim submission.

Correct Answer: C. The system shall display a standard claim record within two seconds under defined normal load.

Question 2

What is the primary purpose of a requirements traceability matrix?

A. To replace user acceptance testing

B. To link requirements to design, tests, and evidence

C. To calculate the project’s discount rate

D. To select a programming language

Correct Answer: B. To link requirements to design, tests, and evidence

Question 3

Which approach is generally most suitable when requirements are stable and extensive formal approvals are necessary?

A. Predictive development

B. Throwaway prototyping only

C. Uncontrolled experimentation

D. Ad hoc development

Correct Answer: A. Predictive development

Question 4

A project has an immediate cost of $100,000 and benefits of $55,000 at the end of each of two years. At a 10% annual discount rate, what is the approximate NPV?

A. $4,545

B. $10,000

C. $55,000

D. −$4,545

Correct Answer: D. −$4,545

Question 5

Which testing level primarily checks interactions among separate components or systems?

A. Unit testing

B. Integration testing

C. User acceptance testing

D. Regression testing

Correct Answer: B. Integration testing

Question 6

What is a major advantage of a pilot implementation?

A. It eliminates the need for testing.

B. It introduces the solution to a limited group before wider deployment.

C. It guarantees that all requirements are complete.

D. It always costs less than every other strategy.

Correct Answer: B. It introduces the solution to a limited group before wider deployment.

Question 7

Which control principle gives users only the access needed for their authorized duties?

A. Least privilege

B. Parallel running

C. Scope baseline

D. Benefits realization

Correct Answer: A. Least privilege

Question 8

In a risk register, who is normally responsible for monitoring and responding to a particular risk?

A. The risk owner

B. Every customer automatically

C. The software compiler

D. The external auditor in every case

Correct Answer: A. The risk owner

Question 9

Which statement about agile development is correct?

A. Agile eliminates the need for governance and documentation.

B. Agile delivers feedback and working increments while adapting to change.

C. Agile requires all requirements to be fixed before work begins.

D. Agile cannot be used in regulated industries.

Correct Answer: B. Agile delivers feedback and working increments while adapting to change.

Question 10

Which issue is especially important when evaluating a cloud software supplier?

A. The color of the supplier’s logo

B. Whether the supplier provides data ownership, security, resilience, and exit arrangements

C. Whether the application has the longest possible user manual

D. Whether all customization is prohibited by law

Correct Answer: B. Whether the supplier provides data ownership, security, resilience, and exit arrangements