Systems Development and Digital Project Management

Introduction

Digital systems shape how brands understand customers, create experiences, coordinate campaigns, sell products and protect reputation. A customer relationship management platform, e-commerce site, marketing-automation tool or analytics dashboard is not merely a technical asset. It is an organizational capability that influences brand promise, customer trust and managerial decision-making.

Systems development is the structured process through which an organization identifies a business need, defines requirements, designs or selects a solution, implements it and evaluates its value. Digital project management applies planning, coordination, governance and control to this process. For brand managers, the subject is important because many technology projects fail not because the software is technically unusable, but because objectives are unclear, users are excluded, data is poor, suppliers are weakly governed or expected benefits are never measured.

This chapter compares systems-development life cycles, explains agile and DevOps methods, examines requirements and vendor decisions, and presents practical tools for project, risk and benefits-realization management.

Learning Objectives

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

1. Compare waterfall, iterative, agile and DevOps approaches to systems development.
2. Distinguish business, functional, non-functional, data and transition requirements.
3. Evaluate vendors using structured criteria and procurement controls.
4. Analyse build-versus-buy decisions, including total cost, strategic fit and risk.
5. Apply project-management tools such as scope statements, work breakdown structures, schedules, risk registers and stage gates.
6. Develop a benefits-realization plan for a digital project.
7. Identify ethical, security, privacy and governance issues in implementation.

1. Systems Development as Organizational Change

A system-development project usually contains five connected dimensions:

• Technology: applications, infrastructure, interfaces, databases and security controls.
• Process: the activities and decisions the system supports.
• People: customers, employees, managers, suppliers and other stakeholders.
• Data: information collected, transformed, stored and used.
• Governance: accountability, standards, approvals, risk management and compliance.

A technically successful implementation can still be an organizational failure. For example, a new marketing platform may operate correctly but generate little value if campaign teams do not trust its data, if customer consent is not recorded, or if employees do not know how to use it. Consequently, systems development should be treated as socio-technical change rather than software installation alone.

A useful distinction is between outputs, outcomes and benefits. An output is what the project delivers, such as a configured CRM system. An outcome is the change enabled by that output, such as faster customer-service response. A benefit is the measurable organizational value, such as higher retention or lower service cost. Benefits require ownership after the project team has disbanded.

2. Systems-Development Life Cycles

A systems-development life cycle (SDLC) is a framework for organizing development activities. Life cycles differ in how they sequence work, manage uncertainty, involve users and authorize changes.

2.1 Waterfall

Waterfall organizes work into relatively distinct phases: initiation, requirements, design, development, testing, deployment and maintenance. Each phase is substantially completed before the next begins.

Waterfall is appropriate when requirements are stable, regulatory documentation is important, technology is well understood and late change would be extremely expensive. It can support formal approvals and predictable contractual arrangements. Its weakness is that users may not see a realistic working system until late in the project. Defects in assumptions may therefore be discovered after substantial investment.

2.2 V-model

The V-model extends sequential development by linking each development activity to a corresponding testing activity. Business requirements are associated with acceptance testing, system requirements with system testing, and detailed design with integration or component testing. The model emphasizes verification and validation, traceability and documented quality assurance. It is valuable in safety-critical or highly regulated environments, although it may remain inflexible where requirements change frequently.

2.3 Iterative and incremental development

In iterative development, the solution is refined through repeated cycles of analysis, design, construction and evaluation. Incremental development delivers the system in usable portions. A first increment may provide basic customer records, while later increments add segmentation, automation and advanced analytics.

These approaches reduce the risk of building a complete solution on incorrect assumptions. They also enable learning from user feedback. However, they require disciplined architecture, prioritization and integration management. Without these controls, increments can become disconnected features rather than a coherent product.

2.4 Agile development

Agile is a family of approaches based on short feedback cycles, close collaboration, adaptive planning and delivery of working increments. Scrum is a widely used agile framework. A product owner prioritizes a product backlog; a cross-functional team develops a potentially usable increment during a sprint; and reviews and retrospectives support learning and improvement.

Agile does not mean “no planning” or “no documentation.” It changes the level and timing of planning. A product vision and outcome measures remain necessary, while detailed requirements are elaborated when they become sufficiently near-term to be understood. Agile works best when users are available, priorities can change and the organization can release or test increments frequently.

2.5 DevOps

DevOps integrates development and IT operations through shared responsibility, automation, monitoring and rapid feedback. Continuous integration (CI) involves frequently merging and testing code. Continuous delivery (CD) keeps software in a releasable state; continuous deployment automatically releases approved changes to production.

DevOps extends agile beyond the development team. It addresses deployment, infrastructure, security, reliability and operational learning. Practices may include automated testing, infrastructure as code, version control, observability, release automation and rollback mechanisms. DevOps is not simply a toolset or a job title; it is a change in accountability and workflow.

Comparison of approaches

No life cycle is universally superior. Selection should consider uncertainty, regulatory obligations, integration complexity, user availability, release capability and the consequences of failure. Hybrid approaches are common: a project may use formal governance and procurement gates while an agile team develops the product in increments.

3. Requirements Engineering

Requirements engineering is the disciplined process of discovering, analysing, documenting, validating, prioritizing and managing what a system must achieve. Poor requirements are a leading cause of cost overruns and user dissatisfaction.

3.1 Types of requirements

• Business requirements: the organizational purpose, such as improving campaign attribution.
• Stakeholder requirements: needs expressed by particular groups, such as the customer-service team’s need for a unified customer view.
• Functional requirements: what the system must do, such as segment customers by purchase history.
• Non-functional requirements: qualities or constraints, such as response time, availability, accessibility, security and scalability.
• Data requirements: definitions, sources, quality rules, retention periods, ownership and permitted uses.
• Transition requirements: temporary or implementation-related needs, such as migration, training and parallel running.
• Regulatory requirements: obligations concerning privacy, accessibility, consumer protection, records or sector-specific controls.

A requirement should be clear, necessary, testable and traceable to a business objective. “The system should be user-friendly” is vague. “A trained campaign coordinator shall create and save a standard email segment in no more than five minutes without technical assistance” is more testable, although it still requires a defined test method and user profile.

3.2 Requirements elicitation

Useful techniques include stakeholder interviews, workshops, observation, document analysis, process mapping, surveys, prototypes, data analysis and examination of existing support incidents. Each technique reveals different evidence. Interviews expose goals and frustrations; observation reveals workarounds; prototypes test interaction assumptions; data analysis identifies volume and performance patterns.

Stakeholder analysis is essential because the person requesting a system may not be the person who uses it, is affected by it or bears its risks. A responsible analysis includes customers, frontline employees, marketing teams, IT, finance, legal and information-security specialists.

3.3 User stories and acceptance criteria

An agile user story often follows this structure: “As a [user], I want [capability], so that [value].” For example: “As a brand manager, I want to compare campaign conversion by audience segment, so that I can allocate budget more effectively.” Acceptance criteria define the conditions under which the story is complete. They should address normal, exceptional, security and data-quality conditions where relevant.

A requirements traceability matrix links business objectives to requirements, design elements, tests and acceptance decisions. Traceability helps demonstrate coverage and identify the impact of change.

3.4 Prioritization

A practical method is the MoSCoW classification:

• Must have: essential for the release to be viable or compliant.
• Should have: important but with an acceptable workaround.
• Could have: desirable if resources permit.
• Won’t have now: explicitly deferred.

Prioritization should consider value, urgency, risk, dependency, effort and regulatory necessity. It must not be used to disguise unresolved disagreement; stakeholders should understand who decides and on what evidence.

4. Build, Buy or Configure?

Organizations commonly choose among building a bespoke system, buying a packaged product, subscribing to software as a service (SaaS), configuring an existing platform or integrating several services.

4.1 Build

Building may be justified when the capability is strategically distinctive, no suitable product exists, data or process requirements are unusual, or control over the roadmap is essential. It can produce close fit and intellectual-property advantages. Costs include development, architecture, testing, security, maintenance, skills, infrastructure and future upgrades. A bespoke system also creates continuing dependence on the organization’s ability to retain technical knowledge.

4.2 Buy or subscribe

Buying can provide mature functionality, vendor investment, implementation expertise and faster deployment. Risks include functional mismatch, customization costs, vendor lock-in, uncertain pricing, data portability problems, service outages and limited influence over product changes. SaaS reduces infrastructure responsibility but does not remove the customer’s responsibilities for configuration, access control, data quality, lawful processing and supplier oversight.

4.3 Total cost of ownership

A useful comparison is total cost of ownership (TCO):

Here, each C is a cost over a defined evaluation period, usually expressed in the same currency and either nominal or present-value terms. Acquisition may include licences; implementation includes integration and migration; operation includes hosting and administration; support includes supplier and internal support; change includes upgrades and enhancement; exit includes data extraction, replacement and transition. TCO is not a prediction of benefits and should not be compared across options unless scope, period and assumptions are consistent.

If benefits and costs occur over several years, discounted cash flow may be used. The net present value is:

B_t is benefit in period t, C_t is cost in period t, r is the discount rate per period, and n is the final period. The calculation assumes cash flows can be estimated and that the discount rate is appropriate. A positive NPV indicates that discounted benefits exceed discounted costs under the stated assumptions; it does not by itself prove strategic fit or feasibility.

4.4 Vendor evaluation

A request for proposal should describe outcomes, requirements, service expectations, data responsibilities, implementation assumptions and evaluation rules. A weighted scoring model can make evaluation transparent:

where w_i is the weight assigned to criterion i and s_i is the normalized supplier score for that criterion. Weights should sum to 1, or to 100 percent if percentage weights are used. Scores must use a consistent scale. The model supports judgement; it does not replace reference checks, demonstrations, security review or contractual analysis.

Typical criteria include functional fit, integration capability, security and privacy, accessibility, usability, implementation capacity, service-level performance, total cost, financial stability, roadmap, data portability and cultural fit. A vendor should be tested with realistic scenarios rather than a marketing demonstration alone.

5. Digital Project Management

A project is a temporary effort undertaken to create a unique product, service or result. Project management coordinates scope, schedule, cost, quality, resources, communication, procurement, risk and stakeholder expectations.

5.1 Project initiation

A project charter should state the problem, objectives, scope boundaries, sponsor, project manager, stakeholders, assumptions, constraints, major risks, governance arrangements and approval authority. Objectives should be measurable where possible. “Improve digital engagement” is weaker than “increase the proportion of consented customers receiving relevant offers while maintaining unsubscribe and complaint rates below agreed thresholds.”

5.2 Scope and work breakdown structure

The scope statement defines what is included and excluded. A work breakdown structure (WBS) decomposes deliverables into manageable work packages. It should be deliverable-oriented rather than merely a list of departments. For a CRM implementation, major deliverables might include approved process design, configured platform, cleansed data, tested integrations, trained users and operational support.

Scope control is especially important in agile environments. A fixed release goal can coexist with a changing backlog, but changes should be evaluated against capacity, dependencies, risk and expected value. Uncontrolled addition of features is scope creep.

5.3 Scheduling and critical path

A schedule identifies activities, dependencies, durations, resources and milestones. In a precedence network, the critical path is the longest sequence of dependent activities that determines the shortest possible project duration. A delay to a critical-path activity generally delays the project unless corrective action changes the network or duration.

Agile teams use sprint plans, release forecasts, capacity discussions and progress measures such as completed work. Velocity can support forecasting within a stable team and product context, but it is not a universal productivity measure and should not be used to compare teams.

5.4 Governance and stage gates

Governance defines who decides, who advises, who executes and who is accountable. A steering committee may approve funding and major changes; a product owner may prioritize product work; security and legal specialists may approve relevant controls; and an operational owner may accept the system into service.

Stage gates are formal decision points, such as approval of the business case, design, pilot, go-live and post-implementation review. Agile delivery can operate within gates when the gates assess evidence and readiness rather than demand that every detail be known at project initiation.

6. Risk, Quality and Change Management

Risk is an uncertain event or condition that may affect objectives. A risk register normally records description, cause, event, consequence, owner, probability, impact, response, trigger and status. Probability and impact ratings are useful for prioritization but are ordinal judgements unless supported by quantitative evidence.

Common digital-project risks include:

• unclear ownership of customer data;
• integration failure or incompatible interfaces;
• privacy breach or excessive data collection;
• supplier insolvency or service degradation;
• unrealistic migration assumptions;
• inadequate accessibility or usability;
• resistance from employees;
• cybersecurity vulnerabilities;
• benefits that cannot be measured; and
• dependence on a small number of specialists.

Responses include avoiding the risk, reducing probability or impact, transferring part of the exposure contractually, accepting it with monitoring, or exploiting a positive opportunity. A risk owner is accountable for response, while an issue is a problem that has already occurred and requires resolution.

Quality assurance concerns confidence that appropriate processes are being followed; quality control concerns inspection and testing of outputs. Testing should include functional, integration, performance, security, accessibility, data migration, user acceptance and recovery tests as appropriate. A test that confirms a feature works does not prove that the system supports the intended business outcome.

Change management addresses how people adopt new processes and tools. Effective plans explain why change is needed, identify affected groups, provide role-specific training, involve respected local champions, offer support and measure adoption. Resistance may signal poor design, workload concerns or legitimate ethical objections rather than irrational opposition.

7. Implementation and Benefits Realization

Implementation may use a direct cutover, phased rollout, pilot, parallel running or a hybrid. Direct cutover is fast but exposes the organization to concentrated risk. Phased rollout limits exposure and enables learning but extends the transition. Parallel operation provides comparison but increases cost and workload.

A readiness review should consider tested functionality, data quality, security approval, support arrangements, training completion, communications, rollback or contingency plans, supplier readiness and unresolved defects. Go-live is a decision under uncertainty, not the end of responsibility.

Benefits realization begins with a benefits map connecting capabilities to outcomes and measurable benefits. For example:

A benefit measure requires a baseline, target, measurement method, timing and owner. Where possible, evaluation should compare results with a credible baseline or control group. An increase in sales after implementation is not automatically caused by the system; seasonality, pricing and media activity may also contribute.

Useful financial indicators include return on investment (ROI):

Benefits and costs must be defined consistently, measured over the same period and stated in comparable monetary terms. ROI can be misleading when important benefits are non-financial or when attribution is weak. Customer trust, accessibility, compliance and employee capability may be strategically important even if they are difficult to monetize.

8. Ethical, Legal and Governance Considerations

Digital projects often process personal data and influence customer treatment. Responsible implementation requires data minimization, purpose limitation, accuracy, retention controls, access management, transparency and lawful processing under applicable privacy law. Consent should not be treated as a box-ticking exercise; customers should understand what they are agreeing to and be able to withdraw it where applicable.

Algorithmic segmentation and personalization can produce unfair exclusion, discriminatory outcomes or manipulative targeting. Teams should assess training data, proxies for protected characteristics, explainability, human oversight and the consequences of error. AI-generated content or recommendations should be reviewed for factual accuracy, bias, intellectual-property concerns, privacy leakage and brand safety.

Accessibility should be designed into requirements and tested with people who have diverse abilities. Security should follow a secure-by-design approach, including least-privilege access, strong authentication, encryption where appropriate, logging, vulnerability management and incident response.

Contracts should address service levels, security obligations, audit rights, subcontractors, data location where relevant, breach notification, intellectual property, exit assistance, data export and deletion. Governance is not solely a legal function: brand, marketing, procurement, IT, compliance and operations must share accountability.

9. Illustrative Case: Aurora Apparel Loyalty Platform

Background

Aurora Apparel, a fictional international clothing brand, operated separate systems for online sales, stores, email campaigns and customer service. Marketing teams frequently duplicated customer records and could not reliably distinguish customers who had consented to promotional communication.

Problem

The company proposed a loyalty platform to unify customer profiles, reward purchases and personalize communications. The initial proposal focused on software features and assumed that implementation would take three months. Stakeholder interviews revealed conflicting definitions of “active customer,” incomplete consent records, regional privacy constraints and limited store connectivity.

Analysis

The project team mapped current processes and identified business, data, functional and non-functional requirements. It concluded that an immediate global rollout would create excessive data and adoption risk. A weighted vendor evaluation gave significant weight to consent management, integration, accessibility, data portability and implementation capability rather than only to feature count.

The build-versus-buy analysis favoured configuring a commercial platform. Bespoke development offered greater control but would require substantial internal expertise and delay the loyalty launch. The selected supplier was required to demonstrate data export, deletion workflows, role-based access and realistic store-to-online scenarios.

Approach and solution

Aurora used a hybrid life cycle. Governance followed formal stage gates, while a cross-functional agile team delivered a pilot in two markets. The first increment provided identity resolution, consent capture and basic rewards. Later increments added segmentation and campaign integration. Automated tests were used for interfaces, and operational monitoring was established before expansion.

The benefits plan assigned ownership to marketing, customer service and privacy leaders. Measures included consent-record completeness, duplicate-record rate, repeat purchase frequency, customer complaints, campaign conversion and employee adoption. A data-quality workstream was funded separately instead of assuming that migration would solve historical inconsistencies automatically.

Outcome

The pilot exposed an ambiguous consent message and a store workflow that encouraged staff to bypass required fields. These issues were corrected before wider deployment. The platform did not immediately increase revenue, but it improved data traceability and reduced duplicate communications. The company postponed advanced personalization until it had stronger evidence about data quality and customer acceptance.

Learning points

The case illustrates that requirements discovery, governance and benefits ownership are as important as software selection. A pilot can reveal process and ethical problems that a technical demonstration will not. It also shows why implementation should be treated as a learning cycle rather than a single go-live event.

10. Contemporary Practice and Best Practices

Current digital delivery increasingly combines cloud services, APIs, low-code configuration, automation, data platforms and AI-enabled capabilities. These technologies can accelerate delivery but also increase dependency on suppliers, data flows and automated decisions. Organizations should therefore maintain architectural standards, data ownership, security controls and clear accountability.

Best practices include:

1. Start with a measurable business problem and customer value, not a preferred technology.
2. Involve users, technical specialists, legal advisers and operational owners early.
3. Separate essential requirements from attractive but low-value features.
4. Evaluate vendors using realistic demonstrations, reference checks and contractual safeguards.
5. Include migration, training, accessibility, security and support in the initial plan.
6. Use iterative delivery to learn, but retain disciplined governance and documentation.
7. Treat data quality and consent as product requirements.
8. Assign a named owner to every material benefit.
9. Monitor adoption, service performance, risk and outcomes after launch.
10. Plan for exit, replacement and recovery before supplier dependence becomes critical.

Challenges and Limitations

Life-cycle models simplify complex organizational realities. Agile methods may be difficult where procurement rules, fixed contracts or regulatory approvals require extensive early definition. Waterfall methods may be appropriate in some settings but can conceal uncertainty if documentation is mistaken for understanding. Weighted scoring models can create false precision, while financial appraisal may undervalue trust and capability. Benefits attribution is often difficult because business outcomes have multiple causes. Finally, no framework eliminates judgement: effective project leadership requires evidence, communication, ethical awareness and willingness to revise assumptions.

Chapter Summary

Systems development is a socio-technical process involving technology, people, processes, data and governance. Waterfall and V-model approaches emphasize sequential control and traceability; iterative, agile and DevOps approaches emphasize learning, collaboration, automation and rapid feedback. The appropriate approach depends on uncertainty, regulation, integration, user involvement and operational capability.

Requirements engineering converts business needs into testable, prioritized and traceable requirements. Build-versus-buy decisions should examine strategic fit, capability, risk, total cost of ownership, vendor dependence and exit options. Digital project management controls scope, schedule, quality, resources, risk, stakeholders and change through tools such as charters, WBSs, schedules, risk registers and stage gates.

Successful implementation requires readiness assessment, adoption support, secure and accessible design, data governance and post-launch monitoring. Benefits realization connects delivered capabilities to outcomes, measures, baselines and accountable owners. Ethical implementation requires privacy protection, fairness, transparency, security and responsible use of AI and customer data.

Key Terms

Agile: An adaptive approach emphasizing collaboration, short feedback cycles and incremental delivery.

Benefits realization: The planning and monitoring of value expected from a project after delivery.

Build-versus-buy: Analysis of whether to develop, configure, subscribe to or purchase a solution.

Continuous delivery: Keeping software in a releasable state through frequent integration and testing.

DevOps: Practices and culture integrating development, operations, automation and feedback.

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

Iteration: A repeated development cycle used to refine a solution.

Non-functional requirement: A quality, constraint or performance expectation of a system.

Product backlog: A prioritized list of work and desired product improvements.

Project charter: A document authorizing and defining a project at a high level.

Requirement traceability: Linking objectives, requirements, designs, tests and acceptance decisions.

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

Scrum: An agile framework using roles, events and time-boxed sprints.

Stage gate: A formal review point at which continuation or change is authorized.

Systems-development life cycle: A framework for organizing system development and maintenance activities.

Total cost of ownership: The full cost of acquiring, implementing, operating, changing and exiting a solution.

User acceptance testing: Testing by representative users to determine whether a solution meets business needs.

Vendor evaluation: Structured assessment of suppliers against defined criteria.

Review Questions

Short Answer Questions

1. What is the difference between an output, an outcome and a benefit?
2. Identify two circumstances in which a waterfall approach may be suitable.
3. What is the purpose of acceptance criteria?
4. Name four costs that may be included in total cost of ownership.
5. What information should a risk register contain?

Long Answer Questions

1. Compare waterfall, agile and DevOps approaches in terms of planning, feedback, delivery and risk.
2. Explain how business, functional, non-functional, data and transition requirements differ.
3. Discuss the advantages and limitations of buying a commercial platform rather than building a bespoke system.
4. Explain how governance and stage gates can be combined with agile delivery.
5. Discuss why benefits realization must continue after a system goes live.

Analytical / Application Questions

1. A retailer wants a customer-data platform but has unstable requirements, weak data quality and strict privacy obligations. Recommend a development and implementation approach, justifying your choice.
2. Design five weighted criteria for evaluating vendors for a marketing-automation platform. Explain the weight and evidence you would require for each criterion.
3. A new loyalty system has been delivered, but adoption is low and campaign complaints have increased. Diagnose possible causes and propose a benefits, risk and change-management response.

Multiple Choice Questions with Answers

Question 1

Which approach most directly emphasizes shared responsibility between development and operations?

A. Waterfall

B. DevOps

C. V-model

D. Parallel running

Correct Answer: B. DevOps

Question 2

Which is a non-functional requirement?

A. The system creates a customer segment

B. The system sends a coupon

C. The system is available 99.9% of the time

D. The system exports a campaign list

Correct Answer: C. The system is available 99.9% of the time

Question 3

What is the primary purpose of a requirements traceability matrix?

A. To calculate supplier profit

B. To link objectives, requirements, tests and acceptance decisions

C. To replace user acceptance testing

D. To determine employee salaries

Correct Answer: B. To link objectives, requirements, tests and acceptance decisions

Question 4

Which cost is most clearly part of total cost of ownership?

A. Only the initial licence fee

B. Only the development team’s salaries

C. Data extraction and transition when leaving a supplier

D. Only the first month of hosting

Correct Answer: C. Data extraction and transition when leaving a supplier

Question 5

In a weighted vendor score, what should happen to the weights?

A. They should be assigned randomly

B. They should sum to a consistent total such as 1 or 100 percent

C. They should always be equal

D. They should be hidden from suppliers and evaluators

Correct Answer: B. They should sum to a consistent total such as 1 or 100 percent

Question 6

What is the main purpose of a project charter?

A. To authorize and define the project at a high level

B. To record every line of source code

C. To replace the risk register

D. To guarantee that requirements will never change

Correct Answer: A. To authorize and define the project at a high level

Question 7

Which statement best distinguishes an issue from a risk?

A. A risk has already happened, while an issue may happen later

B. An issue is a possible future event, while a risk is a completed task

C. A risk is uncertain, while an issue has already occurred

D. There is no practical distinction

Correct Answer: C. A risk is uncertain, while an issue has already occurred

Question 8

Which implementation approach usually limits exposure by introducing a system in selected markets or groups first?

A. Pilot or phased rollout

B. Immediate global cutover

C. No-change implementation

D. Uncontrolled deployment

Correct Answer: A. Pilot or phased rollout

Question 9

Who should normally own a post-project benefit?

A. Only the software developer

B. A named business or operational owner accountable for the outcome

C. The procurement officer in every case

D. No one, because benefits are automatic

Correct Answer: B. A named business or operational owner accountable for the outcome

Question 10

Which practice best supports responsible use of customer data?

A. Collecting all possible data without a defined purpose

B. Ignoring consent after data migration

C. Applying purpose limitation, access controls and retention rules

D. Allowing every employee unrestricted access

Correct Answer: C. Applying purpose limitation, access controls and retention rules