Project, Risk and Change Management

Introduction

Information systems succeed only when technical development is connected to disciplined project management, organizational readiness, and measurable business value. A system may be technically correct yet fail because its scope was poorly defined, users were not prepared, vendors were inadequately governed, risks were ignored, or expected benefits were never realized. Project, risk, and change management therefore form an integrated part of systems analysis and design.

Project management coordinates people, processes, technology, time, cost, quality, and stakeholder expectations to deliver a defined outcome. Risk management deals with uncertainty that may affect objectives. Change management helps people and organizations adopt new ways of working. Benefits realization ensures that the delivered system produces the intended operational and strategic improvements.

This chapter presents practical and analytical foundations for managing information-systems projects in a Bachelor of Computer Applications context.

Learning Objectives

After studying this chapter, students should be able to:

• define project scope, deliverables, constraints, assumptions, and success criteria;
• estimate resources, effort, duration, and cost using suitable techniques;
• construct and interpret work breakdown structures, schedules, and critical paths;
• apply earned value analysis to monitor project performance;
• identify, assess, respond to, and monitor project risks;
• manage quality, suppliers, communication, teams, and stakeholders;
• explain organizational change, adoption, training, and resistance;
• connect project outputs with benefits realization and governance;
• evaluate ethical, security, privacy, and regulatory implications of project decisions.

1. The Project Management Context

A project is a temporary endeavor undertaken to create a unique product, service, or result. An information-systems project may produce a mobile application, enterprise resource planning module, data warehouse, cybersecurity platform, or business-process automation solution. Operations, in contrast, are continuous activities that maintain existing services.

Projects are constrained by several interacting dimensions:

These constraints are interdependent. Adding functionality can increase effort, cost, and risk. Compressing a schedule may require more people or reduce testing. A project manager must therefore make trade-offs transparently rather than optimizing one constraint in isolation.

A project life cycle commonly includes initiation, planning, execution, monitoring and control, and closure. Agile approaches repeat these activities in short iterations, whereas predictive approaches perform more planning before implementation. Hybrid approaches combine predictive governance with iterative delivery.

2. Initiation, Governance, and Scope

Initiation establishes why the project exists and whether it should proceed. A business case normally describes the problem, alternatives, expected benefits, estimated costs, risks, strategic alignment, and consequences of doing nothing. A project charter authorizes the project, identifies the sponsor and project manager, states high-level objectives, and defines initial constraints.

Governance specifies who makes decisions, who is accountable, how escalation occurs, and how evidence is recorded. A steering committee may approve funding and major changes, while a product owner prioritizes business value and a project manager coordinates delivery. The RACI model can clarify responsibility:

• Responsible: performs the work;
• Accountable: owns the result and approves it;
• Consulted: provides relevant expertise;
• Informed: receives updates.

Scope management protects the project from uncontrolled expansion, commonly called scope creep. A scope statement should specify objectives, inclusions, exclusions, assumptions, constraints, acceptance criteria, and major deliverables. Requirements traceability links each requirement to design elements, implementation tasks, tests, and acceptance evidence.

A work breakdown structure (WBS) decomposes the total approved scope into progressively smaller deliverables and work packages. The WBS is deliverable-oriented: it describes what must exist, not merely a list of departmental activities. A work package should be small enough to estimate, assign, schedule, and monitor, but not so small that administration becomes excessive.

A baseline is an approved version of scope, schedule, or cost against which performance is measured. Changes to a baseline should be evaluated through formal change control. A useful change request records the requested change, rationale, affected requirements, effort, cost, schedule, risks, dependencies, and approval decision.

3. Estimating Resources, Effort, Cost, and Time

Estimation is forecasting, not certainty. Estimates should identify assumptions, confidence, dependencies, and uncertainty. False precision can be more harmful than a clearly expressed range.

Common techniques include:

• Expert judgment: estimates based on experienced specialists; fast but vulnerable to bias.
• Analogous estimation: comparison with a similar completed project; useful early when detailed information is limited.
• Parametric estimation: uses a measurable rate, such as cost per function point, when historical data are reliable.
• Bottom-up estimation: estimates work packages and aggregates them; detailed but resource-intensive.
• Three-point estimation: uses optimistic, most-likely, and pessimistic values to represent uncertainty.

For a three-point estimate using the beta-weighted PERT convention:

Here, E is expected effort or duration, O is the optimistic estimate, M is the most-likely estimate, and P is the pessimistic estimate. All three values must use the same unit, such as person-days. The formula assumes that the three estimates reasonably describe uncertainty and is most useful when extreme values are plausible but not dominant.

The approximate standard deviation under the same convention is:

This is an approximation, not a guarantee of actual variation. Estimates should be recalibrated using historical project data.

A resource estimate must distinguish elapsed duration from effort. If one analyst works for five days, the effort is five person-days. Two analysts working for five days represent ten person-days, although the task may not finish in five days because of dependencies, coordination, or limited parallelism.

Worked Example: Three-Point Estimate

A testing activity has an optimistic duration of 4 days, a most-likely duration of 7 days, and a pessimistic duration of 16 days.

The approximate standard deviation is:

The estimate is therefore 8 days, with substantial uncertainty. The result should not be interpreted as a promise that testing will finish exactly on the eighth day.

Cost estimates may include labor, software licenses, cloud services, equipment, training, travel, vendor fees, contingency, and ongoing support. Direct costs can be traced to the project; indirect costs, such as shared infrastructure, require an allocation method. Contingency reserves address known-unknowns, while management reserves are generally controlled outside the cost baseline for unforeseen work according to organizational policy.

4. Scheduling and Critical-Path Analysis

A schedule translates work into ordered activities with durations, dependencies, milestones, resources, and dates. Typical dependency types include finish-to-start, start-to-start, finish-to-finish, and start-to-finish. Finish-to-start means the successor cannot begin until the predecessor finishes.

The critical path is the sequence of activities with the longest total duration through a project network. Activities on this path have zero total float under the calculated schedule. Delay to a critical activity may delay the project unless corrective action changes the network.

For activity i, the standard forward-pass relationships are:

where ESᵢ is early start, EFᵢ is early finish, and dᵢ is duration. For an activity with predecessors, its early start is the greatest early finish of those predecessors. The backward pass uses:

where LSᵢ is late start and LFᵢ is late finish. Total float is:

These equations assume a precedence network, fixed activity durations, and a defined project completion date. Calendars, resource limits, holidays, and task splitting may require scheduling software and professional judgment.

Worked Scheduling Example

Suppose analysis takes 3 days. Design takes 4 days after analysis. Development takes 8 days after design. Testing takes 3 days after development. Documentation takes 2 days after design and may occur in parallel with development. The main path is analysis → design → development → testing, lasting 18 days. The documentation path lasts 3 + 4 + 2 = 9 days, so it has 9 days of float if no other constraints exist. However, resource conflicts may reduce that float.

Schedule compression may use crashing, which adds resources at additional cost, or fast tracking, which overlaps activities that were previously sequential. Both approaches increase risk; fast tracking particularly increases rework and coordination risk.

5. Monitoring Performance with Earned Value

Earned value management integrates scope, schedule, and cost. Three quantities are required for a reporting date:

• Planned Value (PV): budgeted value of work scheduled to be completed;
• Earned Value (EV): budgeted value of work actually completed;
• Actual Cost (AC): actual cost incurred for completed work.

The main variances and indices are:

Schedule variance (SV) and cost variance (CV) are expressed in monetary value, even though SV is used as a schedule signal. Positive SV indicates more budgeted work has been completed than planned; positive CV indicates that completed work cost less than its budgeted value. SPI and CPI equal 1 when performance matches the plan; values below 1 indicate unfavorable performance. These measures require a credible baseline and objective completion rules.

Worked Example: Earned Value

A project has PV = $50,000, EV = $45,000, and AC = $60,000.

The project is behind the approved plan and is spending inefficiently relative to the value of completed work. Management should investigate causes rather than simply increase funding.

6. Risk Management

A risk is an uncertain event or condition that, if it occurs, affects one or more objectives. A threat has negative consequences; an opportunity has positive consequences. An issue is a current condition, not an uncertain future event.

Risk management is a continuous process:

1. establish context and objectives;
2. identify risks through workshops, interviews, assumptions analysis, checklists, lessons learned, and technical reviews;
3. analyze probability, impact, proximity, and dependencies;
4. prioritize risks in a risk register;
5. plan responses;
6. assign owners and trigger conditions;
7. monitor residual risk and emerging risks.

A qualitative matrix classifies risks using categories such as low, medium, high, and extreme. A quantitative expected monetary value can be used when probability and financial impact are reasonably estimated:

Here, p is probability, from 0 to 1, and I is the financial impact. For threats, I is normally negative; for opportunities, it is positive. EMV is an average decision-support measure, not a prediction of the exact outcome and not appropriate when probabilities or impacts are arbitrary.

For example, a 20% probability of a $30,000 loss has an EMV of 0.20 × (−$30,000) = −$6,000. A decision involving several correlated risks should not be evaluated by simply adding EMVs without considering dependencies.

Threat responses include avoid, mitigate, transfer, and accept. Opportunity responses include exploit, enhance, share, and accept. Contingency plans define actions if a trigger occurs. A risk owner monitors and manages a risk; the owner is not necessarily the person who performs every response action.

7. Quality, Configuration, and Procurement Management

Quality means conformance to agreed requirements and fitness for intended use. Quality assurance improves the processes used to create the system; quality control inspects deliverables and identifies defects. Testing is important but cannot compensate for unclear requirements or weak design practices.

A quality management approach should define standards, review points, test levels, acceptance criteria, defect priorities, traceability, and reporting. Configuration management controls versions of requirements, code, infrastructure, test data, and documentation. Without configuration control, teams may test one version, deploy another, and be unable to reproduce failures.

Supplier management begins with a clear statement of work, service levels, deliverables, acceptance criteria, intellectual-property provisions, security requirements, data-processing responsibilities, audit rights, warranties, exit provisions, and dispute mechanisms. Fixed-price contracts transfer some cost risk to the supplier but may encourage disputes over scope. Time-and-materials contracts offer flexibility but expose the buyer to cost growth. Vendor selection should consider capability, financial stability, security maturity, support quality, and ethical conduct—not only price.

8. Teams, Communication, and Stakeholders

Project teams need clear roles, psychological safety, appropriate authority, and mechanisms for resolving conflict. Conflict may concern priorities, resources, technical choices, or interpersonal relationships. Evidence-based discussion, explicit decision criteria, and documented decisions are generally more effective than informal escalation.

Communication planning identifies audiences, information needs, format, frequency, owner, and channel. Executives may need concise risk and benefit reports; developers need technical decisions and acceptance criteria; users need process impacts and training information. Communication is successful when the intended audience understands and can act—not merely when a message has been sent.

Stakeholder analysis considers power, interest, influence, impact, and attitude. Stakeholders should be engaged proportionately. Ignoring frontline users often creates adoption risks that are invisible in technical status reports.

9. Organizational Change and Adoption

Change management addresses the human and organizational transition from a current state to a desired future state. A useful analysis distinguishes:

• Current state: existing processes, behaviors, systems, incentives, and pain points;
• Transition state: learning, migration, experimentation, disruption, and support;
• Future state: stable processes, roles, controls, and performance expectations.

People may resist change because of perceived loss of status, workload, autonomy, competence, or job security. Resistance is not automatically irrational; it may reveal usability, fairness, privacy, or operational problems. Effective responses include early involvement, transparent reasons, role-based training, champions, pilot testing, feedback channels, leadership modeling, and post-implementation support.

Adoption should be measured through indicators such as active usage, completion of critical workflows, error rates, support requests, user satisfaction, process cycle time, and compliance. Login counts alone are weak evidence of value.

A change impact assessment maps changes to people, processes, technology, policy, data, controls, and performance measures. It should also identify accessibility requirements and the needs of users with different languages, abilities, devices, and levels of digital literacy.

10. Benefits Realization

A project output is what the project delivers; an outcome is the change produced by using that output; a benefit is a measurable improvement resulting from the outcome. For example, a redesigned claims system is an output, faster claim processing is an outcome, and lower operating cost or improved customer satisfaction is a benefit.

A benefits plan should define each benefit, baseline condition, target, measurement method, owner, realization date, dependencies, and risks. Benefits often require operational changes outside the project team’s control. The business owner therefore remains accountable after project closure.

Financial indicators may include return on investment. A simple ROI measure is:

where net benefit equals total benefits minus relevant costs, and investment includes the costs defined by the organization. The measure must state its time period and whether benefits and costs are discounted. A simple ROI can mislead when benefits occur over many years, are uncertain, or are non-financial. Strategic value, compliance, resilience, safety, and user experience may require additional measures.

11. Ethics, Security, Privacy, and Regulation

Project decisions affect employees, customers, citizens, and communities. Ethical project management requires honest reporting, fair procurement, respect for privacy, accessibility, non-discrimination, responsible data use, and avoidance of conflicts of interest. A manager must not conceal defects or manipulate progress metrics to protect a schedule.

Security and privacy should be designed into requirements, architecture, testing, supplier contracts, and operations. Relevant controls may include least privilege, segregation of duties, encryption, secure development practices, audit logging, backup and recovery, vulnerability management, incident response, and retention limits. Legal obligations vary by jurisdiction and industry; projects should consult applicable data-protection, accessibility, intellectual-property, employment, and sector-specific requirements.

AI-enabled tools can support estimation, document analysis, risk identification, testing, and communication. However, generated outputs require human validation because models may reproduce bias, expose confidential information, hallucinate requirements, or produce insecure code. Organizations should define approved tools, data restrictions, review responsibilities, provenance, and accountability.

12. Illustrative Case: University Student-Service Platform

Background

A university decides to replace separate paper and spreadsheet processes for admissions, fee clearance, course registration, and support requests with an integrated student-service platform. This is an illustrative case.

Problem

The sponsor initially requests a complete replacement within six months. Interviews reveal conflicting priorities: administrators want strong reporting, students want mobile access, finance requires reliable payment reconciliation, and faculty members want accurate registration data. The initial request is too broad for the proposed deadline.

Analysis

The project team creates a product vision, stakeholder map, WBS, requirements traceability matrix, risk register, and benefits plan. A minimum viable release is defined as online registration, payment-status visibility, and support-ticket tracking. Automated timetable optimization and advanced analytics are deferred. Major risks include data migration errors, payment-provider integration, privacy breaches, resistance from staff, and insufficient support during registration.

Approach and Solution

The team uses a hybrid approach. Governance, privacy controls, procurement, and release approval are predictive; interface development and user feedback occur in two-week iterations. A pilot is conducted with one department. Data migration is rehearsed using masked data, and reconciliation reports are reviewed by finance. Staff champions participate in design workshops and provide peer support. A vendor contract includes acceptance tests, security obligations, service levels, data return, and exit assistance.

The risk register assigns owners and triggers. For example, a failed migration reconciliation triggers a rollback and investigation rather than a rushed production release. Change requests are assessed for student impact, legal implications, cost, and schedule before approval.

Outcome

The pilot identifies confusing terminology and a missing accessibility feature before institution-wide deployment. After correction, the platform is released in stages. Benefits are measured through registration completion time, support-ticket resolution, payment reconciliation errors, user satisfaction, and adoption by department. The project is considered successful not because every requested feature was delivered, but because the prioritized release was adopted and produced measurable improvements.

Learning Points

The case demonstrates that scope prioritization, risk ownership, user involvement, supplier controls, iterative validation, and benefits ownership are interconnected. A technically functional platform would still have failed if migration, privacy, training, or operational support had been neglected.

13. Practical Management Guidance

Effective project leaders should:

• establish a clear problem, measurable objectives, and decision authority;
• estimate using transparent assumptions and ranges;
• maintain scope, schedule, cost, risk, issue, decision, and change logs;
• review dependencies and critical activities regularly;
• use objective acceptance and quality criteria;
• communicate bad news early and with evidence;
• involve users and operational owners throughout delivery;
• protect security, privacy, accessibility, and ethical standards;
• treat vendors as governed partners rather than substitutes for accountability;
• plan transition, support, training, and benefits measurement before deployment;
• conduct a lessons-learned review and transfer ownership to operations.

Challenges and Limitations

No framework eliminates uncertainty. Estimates may be distorted by optimism bias, political pressure, missing historical data, or unstable requirements. Critical-path calculations can become unreliable when resources are shared or durations are highly uncertain. Earned value can reward completion of low-value work if scope quality is weak. Risk matrices can create false precision, and benefits may depend on external conditions. Change models are useful guides but cannot replace listening, experimentation, and contextual judgment.

Agile delivery reduces the cost of learning through short feedback cycles, but it does not remove the need for architecture, governance, security, budgeting, or regulatory compliance. Predictive planning can provide control, but excessive documentation may delay learning. The appropriate approach depends on uncertainty, criticality, organizational maturity, and the consequences of failure.

Chapter Summary

Project management coordinates scope, schedule, cost, quality, resources, stakeholders, suppliers, and value. Initiation establishes purpose and governance; scope statements, WBS structures, baselines, and change control protect delivery boundaries. Estimation should distinguish effort from elapsed time and communicate assumptions and uncertainty. Network scheduling identifies dependencies and critical paths, while earned value compares planned value, earned value, and actual cost.

Risk management continuously identifies, analyzes, responds to, and monitors uncertainty. Quality management, configuration control, procurement, communication, and team practices support reliable delivery. Change management addresses the transition of people and processes, while benefits realization connects outputs to measurable organizational outcomes. Ethical conduct, privacy, security, accessibility, and responsible use of AI are integral to professional practice. Successful systems projects deliver usable value and enable sustained adoption, not merely completed software.

Key Terms

Project: A temporary endeavor creating a unique product, service, or result.

Scope: The boundaries of work and deliverables included in a project.

Baseline: An approved reference point for measuring performance.

Work breakdown structure: A hierarchical decomposition of project deliverables and work packages.

Milestone: A significant point or event in a project schedule.

Critical path: The longest dependent sequence determining the shortest possible project duration.

Float: The time an activity may be delayed without delaying a defined successor or project completion.

Estimate: A forecast of effort, duration, cost, or resources.

Risk: An uncertain event or condition that may affect objectives.

Issue: A current problem requiring action.

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

Contingency plan: A planned response activated when a defined trigger occurs.

Quality assurance: Process-oriented activities that increase confidence in quality.

Configuration management: Control of versions and relationships among project artifacts.

Stakeholder: A person or organization that affects or is affected by the project.

Change control: The formal evaluation and approval of modifications to approved plans.

Adoption: The extent to which intended users accept and correctly use a solution.

Benefits realization: The management of activities that produce intended measurable value.

Earned value: Budgeted value of work actually completed.

Governance: The structures, authority, policies, and processes used to direct and control a project.

Review Questions

Short Answer Questions

1. Distinguish between a project, an operation, and an issue.
2. What is the purpose of a work breakdown structure?
3. Define risk owner and explain the owner’s responsibility.
4. Differentiate quality assurance from quality control.
5. Why is user adoption important to benefits realization?

Long Answer Questions

1. Explain how scope, schedule, cost, quality, and risk constraints interact in an information-systems project.
2. Describe the project life cycle and the governance decisions typically made at each stage.
3. Explain critical-path analysis, including early start, early finish, late start, late finish, and float.
4. Discuss how procurement, vendor contracts, configuration management, and acceptance criteria support project quality.
5. Explain how organizational change management can reduce resistance and improve system adoption.

Analytical / Application Questions

1. A project has PV of $80,000, EV of $72,000, and AC of $90,000. Calculate SV, CV, SPI, and CPI, and interpret the results.
2. A proposed feature has an optimistic duration of 5 days, most-likely duration of 9 days, and pessimistic duration of 17 days. Calculate the PERT expected duration and approximate standard deviation. State one limitation of the estimate.
3. Design a risk and benefits plan for a college attendance-monitoring system. Identify five risks, suitable responses and owners, and at least four measurable benefits with baselines and targets.

Multiple Choice Questions with Answers

Question 1

Which document formally decomposes project scope into deliverables and work packages?

A. Risk register

B. Work breakdown structure

C. Communication matrix

D. Service-level agreement

Correct Answer: B. Work breakdown structure

Question 2

Using the PERT convention, what is the expected duration when O = 4 days, M = 7 days, and P = 16 days?

A. 6 days

B. 7 days

C. 8 days

D. 9 days

Correct Answer: C. 8 days

Question 3

An activity has ES = 6 days and duration = 4 days. What is its EF?

A. 2 days

B. 6 days

C. 10 days

D. 24 days

Correct Answer: C. 10 days

Question 4

If EV is $45,000 and AC is $60,000, what is the cost variance?

A. $15,000

B. −$15,000

C. $105,000

D. $0.75

Correct Answer: B. −$15,000

Question 5

Which response addresses a threat by reducing its probability or impact?

A. Mitigate

B. Exploit

C. Share

D. Enhance

Correct Answer: A. Mitigate

Question 6

What distinguishes an issue from a risk?

A. An issue is always financial

B. An issue is a current condition or problem

C. A risk cannot affect scope

D. A risk is always negative

Correct Answer: B. An issue is a current condition or problem

Question 7

Which measure compares earned value with actual cost?

A. SPI

B. SV

C. CPI

D. PV

Correct Answer: C. CPI

Question 8

Who is primarily accountable for ensuring an organizational benefit is realized after delivery?

A. The compiler

B. The business or benefit owner

C. The test script

D. The network protocol

Correct Answer: B. The business or benefit owner

Question 9

Which practice most directly supports reproducibility of tested and deployed system versions?

A. Configuration management

B. Fast tracking

C. Informal communication

D. Scope expansion

Correct Answer: A. Configuration management

Question 10

Which is the strongest evidence of successful system adoption?

A. The system has many login screens

B. The project team completed its meetings

C. Users complete intended workflows and operational benefits improve

D. The vendor delivered a brochure

Correct Answer: C. Users complete intended workflows and operational benefits improve