SDLC Planning, Estimation, and Risk Management

Introduction

Software projects rarely fail because developers cannot write code. They more often fail because the work was poorly understood, estimates were treated as promises, resources were unavailable, dependencies were ignored, or important risks were discovered too late. SDLC planning connects business objectives to deliverable software through a realistic plan for scope, time, cost, people, quality, communication, and uncertainty.

Planning is not a one-time administrative activity. In a predictive life cycle, planning establishes a baseline that is controlled through change management. In Agile and iterative development, planning is progressively elaborated through releases, iterations, and daily coordination. In both cases, the planning objective is the same: create enough shared understanding to make responsible decisions while recognizing that estimates become more reliable as knowledge increases.

Learning Objectives

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

• decompose software work into a work breakdown structure (WBS);
• construct a schedule using dependencies, milestones, and critical-path reasoning;
• prepare resource and budget plans;
• apply expert judgment, analogy, story points, function points, and parametric estimation;
• distinguish effort, duration, cost, productivity, and capacity;
• identify project and product risks and assess their probability and impact;
• select appropriate risk responses and maintain a risk register;
• explain the limitations and ethical responsibilities of software estimation.

1. Planning Foundations

A project plan describes how a temporary effort will produce agreed outcomes. It normally includes:

A useful distinction is between effort and duration. Effort is the amount of labor required, commonly measured in person-hours or person-days. Duration is elapsed calendar time. Ten person-days of effort could take one person ten working days or two people five working days, but only if the work is sufficiently divisible and coordination overhead is small. Brooks’s Law captures an important practical limitation: adding people to a late software project can make it later because communication and onboarding increase.

A plan should also state assumptions, constraints, exclusions, dependencies, acceptance criteria, and the method used to estimate. An estimate is an informed prediction; a commitment is an agreed target supported by resources and governance. Confusing the two encourages unrealistic promises.

2. Scope Decomposition and the Work Breakdown Structure

The work breakdown structure is a hierarchical decomposition of the total project scope into deliverables and work packages. It is deliverable-oriented rather than merely a list of programming tasks. A WBS may begin with the product and divide it into subsystems, features, supporting deliverables, and manageable work packages.

A work package should be small enough to estimate, assign, schedule, and monitor, but not so small that administration overwhelms useful work. Each package should have an owner, completion conditions, estimated effort, dependencies, and an identifiable output. The WBS should represent all approved work, including testing, documentation, deployment, training, security, project management, and transition.

A practical decomposition process is:

1. Define the product boundary and acceptance criteria.
2. Identify major deliverables or releases.
3. Decompose each deliverable into components and features.
4. Continue until work packages can be estimated and assigned.
5. Check that every requirement maps to work and every work item supports scope.
6. Record exclusions and assumptions.

A WBS dictionary supplements the hierarchy. For each work package it may specify description, responsible role, inputs, outputs, acceptance criteria, assumptions, estimated effort, and dependencies. This prevents different stakeholders from attaching different meanings to the same task.

The WBS is not necessarily the schedule. The WBS answers “what must be produced”; the schedule adds sequencing, dates, calendars, and resource availability.

3. Scheduling and Critical-Path Reasoning

After decomposition, activities are sequenced according to logical relationships. Common dependencies include:

• finish-to-start: activity B cannot start until A finishes;
• start-to-start: B cannot start until A starts;
• finish-to-finish: B cannot finish until A finishes;
• external dependency: a supplier, regulator, customer, or external system controls timing.

A schedule contains activities, durations, dependencies, resources, milestones, calendars, and a baseline. A milestone is a significant zero-duration event, such as requirements approval, a test release, or production acceptance.

The critical path is the longest-duration path through a dependency network. Activities on it have zero total float in the basic schedule model. Delaying a critical activity delays the project unless corrective action changes the network, duration, or resources.

For an activity, the early start and early finish can be calculated as:

where ES is early start, EF is early finish, and d is activity duration in consistent time units. For activities with predecessors, ES is normally the maximum EF of immediate predecessors. A backward pass calculates late dates:

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

These relationships assume a deterministic activity network, fixed calendars, and the dependency logic being modeled. Real projects may have resource constraints, interruptions, multiple calendars, and uncertainty, so criticality can change during execution.

Worked scheduling example

Suppose a small release contains the following activities:

The paths are A–B–D–E–G = 3 + 4 + 8 + 4 + 1 = 20 days, and A–C–D–E–G = 3 + 3 + 8 + 4 + 1 = 19 days. The longest path is therefore A–B–D–E–G, so it is the critical path under these assumptions. Activity C has one day of path slack, although shared resources or revised estimates could remove that slack.

Schedule compression techniques include fast tracking, performing activities in parallel that were previously sequential, and crashing, adding resources or spending more to shorten an activity. Fast tracking increases rework and dependency risk; crashing may increase cost and coordination overhead. Neither should be applied without examining quality and risk effects.

4. Resource and Budget Planning

A resource plan identifies the people, skills, environments, tools, equipment, and external services needed. It should consider availability rather than assuming that named staff are free. Important concerns include specialist bottlenecks, holidays, onboarding, training, part-time allocation, time-zone differences, and the distinction between planned capacity and productive development time.

A simple capacity calculation is:

where n is the number of people, h is available working hours per person during the period, and a is the availability factor between 0 and 1. If four developers each have 80 working hours in a month but are allocated at 75%, available effort is 4 × 80 × 0.75 = 240 person-hours. This is capacity, not a guarantee of completed features; meetings, defects, leave, interruptions, and coordination consume time.

A budget combines labor, infrastructure, licenses, vendors, training, travel, contingency, and other approved costs. If a labor category has rate r per hour and planned effort e hours, its labor cost is:

For several categories:

where rᵢ and eᵢ are the rate and effort for category i. The formula assumes rates and effort are measured on compatible bases and excludes overhead unless overhead is explicitly included.

A contingency reserve is money or time set aside for known-unknown uncertainty within the project manager’s authority. It should not be used to conceal an intentionally incomplete estimate. A management reserve may be governed separately for unforeseen scope or risks. Organizations should define how reserves are approved and reported.

5. Estimation Approaches

No single estimation method is best for every project. The method should reflect available information, project size, novelty, team experience, and the intended use of the estimate.

5.1 Expert judgment

Experienced practitioners estimate by decomposing work, comparing it with known tasks, and applying professional knowledge. A structured approach asks several experts independently, discusses assumptions, and records a consensus or range. Expert judgment is fast and useful when historical data are scarce, but it can suffer from optimism bias, anchoring, authority effects, and inconsistent assumptions.

5.2 Analogy

Estimation by analogy compares the proposed system or feature with completed work. The estimator identifies similarities and differences in technology, complexity, integration, team capability, and quality obligations, then adjusts the historical result. Analogy is more defensible when the reference projects are genuinely comparable and their data were measured consistently.

5.3 Decomposition and bottom-up estimation

Bottom-up estimation estimates work packages and aggregates them. It can reveal omitted work and create ownership, but it is only as complete as the WBS. Aggregation should include integration, management, quality assurance, deployment, and rework rather than counting coding alone.

5.4 Three-point estimation

When uncertainty is significant, an estimator may record optimistic (O), most likely (M), and pessimistic (P) effort. A commonly used triangular expected value is:

A PERT-weighted estimate is:

The weighted form assumes the most-likely value is a better representation of the central tendency and that the three judgments reasonably describe the uncertainty. It is not a guarantee of a statistically accurate distribution. For O = 4 days, M = 6 days, and P = 14 days, the PERT estimate is (4 + 4×6 + 14) ÷ 6 = 54 ÷ 6 = 9 days.

5.5 Story points and velocity

In Agile development, story points are relative units reflecting size, complexity, uncertainty, and sometimes dependencies. They are not hours and should not be converted into a universal productivity comparison between teams. A team may forecast a release using:

If 120 points remain and the team’s observed sustainable velocity is 30 points per iteration, the initial forecast is about four iterations. This assumes the backlog is sufficiently refined, team capacity is stable, point meanings are consistent, and velocity is based on completed, accepted work. Historical velocity is descriptive, not a target for pressuring a team.

5.6 Function points

Function points estimate software size from user-visible functionality, independently of a particular programming language. Traditional function-point analysis counts external inputs, external outputs, external inquiries, internal logical files, and external interface files. Each is classified by complexity and assigned a standard weight. The unadjusted function points are:

A traditional adjustment may use a value adjustment factor (VAF):

The precise weights and adjustment rules depend on the selected counting standard and organizational practice. Modern teams may use simplified or IFPUG-aligned methods, while some organizations use COSMIC function points. Function points are useful for comparing productivity across technologies only when counting rules and quality expectations are consistent. They require trained counters and can be difficult early in discovery.

5.7 Parametric models

Parametric estimation uses a calibrated relationship between size and effort. A simple model is:

where a and b are parameters calibrated from historical data, and Size may be function points, thousands of source lines of code, or another defined measure. If b = 1, effort grows linearly; if b > 1, scale-related effects increase effort faster than size. A model is only credible within the domain and quality conditions represented by its calibration data. It should not be presented as objective merely because it contains a formula.

6. Uncertainty, Estimation Ranges, and Control

Early estimates should be expressed as ranges with confidence and assumptions. A range communicates uncertainty better than a single precise number. Estimates should be revised when requirements, architecture, team composition, or external conditions change.

Useful estimation practices include:

• estimate independent of the person requesting the number;
• document scope, exclusions, assumptions, and confidence;
• use historical data and record actual effort for future calibration;
• separate estimate from target and commitment;
• estimate complete work, including testing and deployment;
• use progressive elaboration as knowledge increases;
• compare actuals with estimates without punishing honest uncertainty.

Earned value concepts can support predictive project control. Planned value (PV) is the authorized budget for work scheduled by a date; earned value (EV) is the authorized budget for work actually completed; actual cost (AC) is the cost incurred. Variances are:

Schedule variance (SV) and cost variance (CV) are expressed in budget units, not calendar days. Positive SV means more budgeted work has been completed than planned; positive CV means the completed work cost less than its budget. These measures require objective completion rules and are less meaningful when “percent complete” is subjective.

7. Risk Management

A risk is an uncertain event or condition that, if it occurs, affects one or more objectives. A threat has a negative effect; an opportunity has a positive effect. A problem or issue has already occurred and requires management, whereas a risk is potential.

Project risks affect delivery, such as staff turnover, vendor delay, budget reduction, or misunderstood requirements. Product risks affect the system itself, such as security vulnerabilities, performance failure, data loss, safety hazards, or poor usability. Some risks affect both categories.

A disciplined risk process includes:

1. Plan risk management: define categories, roles, scales, thresholds, reporting, and escalation.
2. Identify risks: use workshops, checklists, retrospectives, assumptions analysis, threat modeling, and expert review.
3. Analyze risks: assess probability, impact, proximity, and detectability where useful.
4. Prioritize: focus attention on risks exceeding agreed thresholds.
5. Plan responses: select an owner, actions, triggers, and residual-risk treatment.
6. Monitor and control: review trends, implement actions, identify new risks, and close obsolete entries.

A qualitative probability-impact matrix is often adequate at diploma level. A simple expected monetary value is:

where p is probability between 0 and 1 and I is the financial impact if the event occurs. If a 20% probability of a defect causes an estimated $10,000 loss, EMV = 0.20 × $10,000 = $2,000. EMV is an expected value across repeated comparable situations; it does not predict that exactly $2,000 will be lost in this project, and it should not replace judgment about safety, reputation, or legal harm.

Common threat responses are:

Opportunity responses include exploit, enhance, share, and accept. A risk register commonly contains identifier, description, cause, event, effect, probability, impact, rating, owner, response, trigger, due date, status, and residual risk.

Risk responses must not create hidden secondary risks. For example, outsourcing a security-sensitive component may reduce schedule risk but increase supplier, privacy, and integration risk. Residual risk remains after treatment and must be accepted by an authorized stakeholder when appropriate.

8. Integrated Case: Community Health Appointment Platform

This is an illustrative case. A small organization plans a web and mobile appointment platform for community clinics. Patients should search clinics, request appointments, receive notifications, and view appointment history. The first release must be available in six months. The team consists of a product owner, business analyst, UX designer, two developers, a tester, and a part-time security adviser.

Background and problem

The sponsor initially requested “a complete booking system” within six months, but the phrase concealed substantial scope. The organization also handles personal health information, creating security and privacy obligations. A direct commitment to every requested feature would exceed capacity.

Analysis and planning approach

The team created a product-oriented WBS:

1. governance and discovery;
2. patient registration and authentication;
3. clinic and availability management;
4. appointment search and booking;
5. notifications;
6. history and reporting;
7. security, privacy, testing, deployment, and training.

Each work package received acceptance criteria and an owner. Non-functional requirements included response-time targets, audit logging, access control, backup, and accessibility. The team identified an external dependency on a messaging provider and a regulatory review before production use.

For uncertain integration work, three-point estimates were used. A notification integration was estimated at O = 3, M = 6, P = 12 person-days. Its PERT estimate was (3 + 4×6 + 12) ÷ 6 = 39 ÷ 6 = 6.5 person-days. The release forecast was expressed as a range because the provider interface and approval timing were uncertain.

The risk register identified:

• provider outage: mitigate through retry logic, monitoring, and a fallback communication procedure;
• unauthorized access: mitigate through threat modeling, least privilege, multifactor administration, penetration testing, and audit review;
• regulatory approval delay: avoid by engaging the reviewer early and scheduling a decision milestone;
• ambiguous booking rules: mitigate through prototypes and examples approved by clinic staff;
• specialist unavailability: reduce through documentation, pairing, and cross-training.

The team selected a minimum viable release: search, booking, confirmation, cancellation, and essential administration. Advanced analytics and automated patient reminders were placed in a later release. Iteration reviews updated estimates using completed work, while the release plan was reforecast rather than silently extended.

Outcome and learning points

The project achieved a usable first release by controlling scope and treating security and compliance as product requirements rather than final-stage paperwork. The most important improvement was not a mathematical technique; it was making assumptions visible and linking requirements, work packages, tests, risks, and acceptance decisions. The case demonstrates that planning is a decision system: it makes trade-offs explicit and creates evidence for changing course.

9. Governance, Ethics, and Contemporary Practice

Estimates influence funding, employment, procurement, and public commitments. Professionals must not deliberately understate effort to obtain approval or inflate estimates to create artificial slack. Estimates should identify uncertainty, data sources, and excluded work. Stakeholders should be warned when a fixed date, fixed scope, and fixed budget cannot all be guaranteed.

Privacy, accessibility, cybersecurity, safety, and regulatory requirements must appear in scope and estimates. Treating them as optional technical enhancements creates ethical and legal exposure. Risk scoring should not downgrade harms merely because they are difficult to express financially; loss of health, safety, privacy, or public trust may require avoidance even when expected monetary value is small.

AI-assisted estimation can summarize historical tickets, detect omitted tasks, classify risks, or identify patterns in delivery data. However, AI outputs may reproduce biased historical estimates, expose confidential information, or create false confidence. A human must validate data quality, assumptions, scope, privacy, and explainability. AI should support—not replace—professional accountability.

Contemporary teams increasingly combine product roadmaps, rolling-wave planning, continuous delivery metrics, infrastructure-as-code, automated testing, and real-options thinking. Short feedback cycles reduce the cost of being wrong, but they do not remove the need for architecture, compliance, capacity, and risk decisions.

10. Best-Practice Checklist

Before approving a plan, ask:

• Is the scope bounded, traceable, and accepted?
• Does the WBS include quality, security, deployment, training, and support work?
• Are assumptions, exclusions, dependencies, and constraints recorded?
• Are effort, duration, capacity, cost, target, and commitment distinguished?
• Is the estimation method suitable and calibrated where possible?
• Are ranges and confidence more honest than false precision?
• Does the schedule reflect resource availability and critical dependencies?
• Does every significant risk have an owner, trigger, response, and review date?
• Are product risks assessed separately from delivery risks?
• Are privacy, accessibility, safety, and regulatory obligations included?
• Will actual results be captured to improve future estimates?

Chapter Summary

SDLC planning translates objectives into scope, deliverables, activities, resources, cost, quality expectations, and controlled decisions. A WBS decomposes total scope into estimable work packages; a schedule sequences that work and identifies critical-path dependencies. Resource and budget plans distinguish available capacity from actual productivity and include the complete cost of delivery.

Expert judgment, analogy, bottom-up decomposition, three-point estimates, story points, function points, and parametric models are complementary techniques. Each depends on clear assumptions, suitable data, and disciplined interpretation. Estimates are uncertain forecasts, not guarantees, and should become more precise as knowledge increases.

Risk management identifies uncertain threats and opportunities, assesses their significance, assigns ownership, and applies responses such as avoidance, mitigation, transfer, or acceptance. Product risks—including security, privacy, performance, safety, and usability—must be managed alongside project risks. Ethical planning requires honest communication, respect for affected stakeholders, and responsible use of quantitative and AI-assisted methods.

Key Terms

Work breakdown structure (WBS): Hierarchical decomposition of total project scope into deliverables and work packages.

Work package: A manageable unit of work with an identifiable output, owner, and completion condition.

Effort: Labor required to perform work, measured in person-hours or person-days.

Duration: Elapsed calendar time required for an activity or project.

Milestone: A significant scheduled event with normally zero duration.

Critical path: Longest dependency path determining the earliest project completion under stated assumptions.

Float: Time an activity can slip without delaying a defined schedule milestone.

Capacity: Effort a resource or team can reasonably make available during a period.

Estimate: Informed prediction of effort, duration, cost, or other quantity.

Baseline: Approved version of scope, schedule, or cost used for comparison and control.

Story point: Relative Agile measure of work size, complexity, and uncertainty.

Velocity: Amount of accepted story-point work completed by a team per iteration.

Function point: Unit representing user-visible software functionality under a defined counting method.

Parametric estimation: Estimation using a calibrated mathematical relationship between size and effort.

Risk: Uncertain event or condition that may affect an objective.

Issue: A problem or event that has already occurred.

Risk register: Structured record of risks, ratings, owners, responses, triggers, and status.

Residual risk: Risk remaining after a response has been implemented.

Expected monetary value: Probability multiplied by the estimated financial impact of an uncertain event.

Contingency reserve: Allocated time or money for identified uncertainty within approved authority.

Review Questions

Short Answer Questions

1. Distinguish effort from duration and explain why adding staff does not always reduce duration proportionally.
2. What is the purpose of a WBS dictionary?
3. Define the critical path and total float.
4. Why are story points not equivalent to hours?
5. Distinguish a risk from an issue.

Long Answer Questions

1. Explain how a WBS, schedule, resource plan, and budget are connected during SDLC planning.
2. Compare expert judgment, analogy, three-point estimation, function points, and parametric estimation.
3. Explain how probability-impact analysis and risk responses support project governance.
4. Discuss the assumptions and limitations of velocity-based release forecasting.
5. Describe ethical responsibilities when presenting estimates to sponsors and customers.

Analytical / Application Questions

1. A project has activities A = 2 days, B = 5 days after A, C = 4 days after A, and D = 3 days after both B and C. Identify the critical path and total project duration.
2. A security risk has probability 0.15 and estimated financial impact of $40,000. Calculate its EMV and explain why EMV alone should not determine the response.
3. A team has 5 developers, 160 working hours each in a month, and an availability factor of 0.70. Calculate available effort and discuss why completed work may be lower than this capacity.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes effort from duration?

A. Effort is elapsed calendar time, while duration is labor cost.

B. Effort is labor required, while duration is elapsed calendar time.

C. Effort and duration always have identical values.

D. Duration measures only programming, while effort measures only testing.

Correct Answer: B. Effort is labor required, while duration is elapsed calendar time.

Question 2

What is the primary purpose of a work breakdown structure?

A. To rank developers by productivity

B. To decompose total project scope into manageable deliverables and work packages

C. To calculate server utilization

D. To replace acceptance criteria

Correct Answer: B. To decompose total project scope into manageable deliverables and work packages

Question 3

Activities on the critical path normally have which characteristic in a basic schedule model?

A. The greatest budget

B. Zero total float

C. The fewest predecessors

D. No assigned resources

Correct Answer: B. Zero total float

Question 4

For optimistic effort O = 4 days, most likely effort M = 6 days, and pessimistic effort P = 14 days, what is the PERT-weighted estimate?

A. 6 days

B. 8 days

C. 9 days

D. 14 days

Correct Answer: C. 9 days

Question 5

A team has 120 remaining story points and a sustainable velocity of 30 points per iteration. What is the initial iteration forecast?

A. 2 iterations

B. 3 iterations

C. 4 iterations

D. 6 iterations

Correct Answer: C. 4 iterations

Question 6

Which estimation technique uses external inputs, outputs, inquiries, internal files, and external interface files?

A. Function-point analysis

B. Critical-path analysis

C. Risk-impact analysis

D. Resource leveling

Correct Answer: A. Function-point analysis

Question 7

A risk has probability 0.20 and financial impact of $10,000. What is its expected monetary value?

A. $200

B. $2,000

C. $10,000

D. $50,000

Correct Answer: B. $2,000

Question 8

Which response changes the plan to eliminate a threat?

A. Accept

B. Transfer

C. Avoid

D. Monitor

Correct Answer: C. Avoid

Question 9

Which statement about story points is most appropriate?

A. They are universally equivalent to person-hours.

B. They are relative measures used by a team to compare work size and uncertainty.

C. They measure only lines of source code.

D. They should be used to compare individual developers.

Correct Answer: B. They are relative measures used by a team to compare work size and uncertainty.

Question 10

Which item is most appropriate for a risk register?

A. Only the project title

B. Risk owner, probability, impact, response, and trigger

C. The programming language alone

D. A list of completed invoices only

Correct Answer: B. Risk owner, probability, impact, response, and trigger