Unit 4: Activity Planning and Risk Management

I. Foundations of Activity Planning

Software project management converts project objectives into coordinated activities while controlling time, cost, scope, quality, resources, and uncertainty.

Defining characteristics:

• Goal orientation: Every activity should contribute to a deliverable, milestone, or acceptance criterion.
• Dependency awareness: Activities may be constrained by logical sequence, resource availability, or external approval.
• Continuous control: Actual progress is compared with the baseline plan throughout execution.
• Uncertainty management: Estimates and schedules must account for technical, operational, and business risks.
• Progressive refinement: Near-term work is planned in greater detail than distant work.

A. Objectives

Objectives define the measurable results that activity planning and risk management must achieve.

• Specific outcomes: State what will be delivered, such as “release authentication module version 1.0.”
• Measurable criteria: Attach indicators such as response time below 200 ms or defect density below 1 defect/KLOC.
• Constraints: Record limits on budget, completion date, staffing, technology, security, and quality.
• Priority: Resolve trade-offs among scope, time, cost, and quality; a fixed launch date may require reduced scope.
• Traceability: Link objectives to requirements, work packages, milestones, tests, and acceptance decisions.

II. Activity Scheduling and Control

This area translates scope into activities, dependencies, estimates, resource assignments, and dates against which execution can be controlled.

A. Project Schedule

A project schedule is a time-based representation of planned activities, milestones, dependencies, resources, and deadlines.

• Inputs: Use the work breakdown structure, effort estimates, resource calendars, constraints, and dependency information.
• Activity record: Specify identifier, description, duration, predecessor, owner, start date, and finish date.
• Milestones: Represent zero-duration control points, such as requirements approval or production deployment.
• Baseline: Freeze an approved schedule for comparison with actual performance.
• Presentation: A Gantt chart displays activities against calendar time and exposes overlap, delay, and progress.

B. Managing the task

Managing the task ensures that each assigned unit of work produces its intended output within agreed constraints.

• Assignment: Give every task one accountable owner, even when several people contribute.
• Entry criteria: Start coding only when necessary requirements, designs, environments, and dependencies are available.
• Completion criteria: Define “done” through evidence such as reviewed code, passing tests, and updated documentation.
• Monitoring: Track remaining effort and blocked work, not merely percentage complete.
• Escalation: Surface impediments early; for example, an unavailable test environment may threaten several dependent tasks.

C. Managing the Plan

Managing the plan means maintaining an achievable model of future work as actual project information emerges.

• Plan-versus-actual control: Compare actual start, finish, effort, and cost with their baselines.
• Forecasting: Recalculate expected completion using remaining work and current productivity.
• Rolling-wave planning: Detail the next iteration while retaining broader estimates for later releases.
• Corrective action: Reassign resources, remove lower-priority scope, overlap suitable tasks, or renegotiate dates.
• Integrity: Update estimates transparently without rewriting the baseline to conceal variance.

D. Network Planning Model

A network planning model represents activities and their logical dependencies as a directed graph.

• Nodes and links: In an activity-on-node network, nodes are activities and directed links indicate precedence.
• Dependency types: Finish-to-start is common; testing starts after implementation finishes.
• Merge and burst points: A merge activity has multiple predecessors, while a burst activity enables multiple successors.
• Rules: The network should have no circular dependencies and should connect all required project work.
• Use: The model supports critical-path calculation, schedule compression, and impact analysis.

E. Time Dimension

The time dimension converts effort and dependency information into durations and calendar dates.

• Effort versus duration: 20 person-days of effort does not always mean 20 working days; parallel workers may shorten duration.
• Calendars: Account for weekends, holidays, part-time assignments, maintenance windows, and staff availability.
• Forward pass: Calculate earliest start and finish times:

EF = ES + d
ES(successor) = max(EF of all predecessors)

• Symbols: ES is earliest start, EF is earliest finish, and d is activity duration.
• Backward pass: Work from the project deadline to obtain latest permissible start and finish times.

F. Identifying Critical Path

The critical path is the longest-duration path through the network and determines the earliest possible project completion.

• Calculation: Perform forward and backward passes, then calculate total float:

Float = LS - ES = LF - EF

• Symbols: LS and LF are latest start and finish; ES and EF are earliest start and finish.
• Critical activities: Activities with zero total float are normally critical.
• Example: Paths of A-B-D = 12 days and A-C-D = 15 days make A-C-D critical.
• Caution: The path can change when durations, dependencies, calendars, or completed work change.

III. Adaptive Project Control

Adaptive control preserves project viability when approved assumptions, priorities, or environmental conditions change.

A. Managing Change

Managing change provides a controlled process for evaluating and implementing alterations to scope, schedule, cost, or quality.

• Change request: Record the requested alteration, justification, originator, urgency, and affected deliverables.
• Impact analysis: Estimate consequences for effort, cost, dependencies, risks, tests, documentation, and benefits.
• Authority: A sponsor, product owner, or change control board approves, rejects, or defers the request.
• Implementation: Update requirements, configuration items, schedule forecasts, and stakeholder communications.
• Configuration control: Preserve version history so the approved product baseline remains identifiable.

B. Readjusting Goals and Milestones

Goals and milestones should be revised when evidence shows that the original targets are no longer feasible or valuable.

• Trigger conditions: Major delay, budget reduction, regulatory change, failed technology, or changed business priority may justify revision.
• Goal adjustment: Reprioritize outcomes rather than lowering targets informally.
• Milestone adjustment: Move dates only after analysing downstream dependencies and contractual effects.
• Options: Reduce scope, stage delivery, increase resources where productive, or extend the deadline.
• Governance: Obtain approval and communicate the revised baseline, rationale, ownership, and acceptance criteria.

IV. Software Project Risk

Project risk is an uncertain event or condition that can affect objectives positively or negatively; risk management concentrates primarily on threats while also recognizing opportunities.

A. Introduction to Risk

Risk combines uncertainty with potential consequences for project objectives.

• Distinction: A risk may occur; an issue has already occurred and requires immediate action.
• Risk statement: Use cause-event-effect form, such as “Because the API is unstable, integration may fail, delaying system testing.”
• Exposure: A simple quantitative measure is:

Risk exposure = Probability × Impact

• Interpretation: A 0.3 probability of a $20,000 loss produces expected exposure of $6,000.
• Dynamic nature: Probability and impact change as information, controls, and project conditions change.

B. Categories of Risk

Risk categories improve identification by prompting examination of different sources of uncertainty.

• Project risks: Schedule slippage, inaccurate estimates, staff turnover, resource conflict, and supplier delay.
• Technical risks: Unproven technology, performance failure, integration difficulty, defects, and cybersecurity weaknesses.
• Business risks: Funding withdrawal, market change, weak user adoption, or loss of strategic relevance.
• Operational risks: Deployment failure, inadequate support, poor training, or unreliable infrastructure.
• External risks: Legislation, economic change, natural events, geopolitical disruption, and vendor failure.

C. Dealing with Risk

Risk responses seek to alter probability, impact, ownership, or exposure.

1. Threat responses: Avoid the threat, mitigate its likelihood or effect, transfer liability through insurance or contracts, or accept it with reserves.
2. Opportunity responses: Exploit the opportunity, enhance its probability or benefit, share it with a partner, or accept it.

• Contingency action: Execute a predefined response when a trigger occurs, such as switching suppliers after a missed delivery threshold.
• Residual risk: Record exposure remaining after the chosen response.
• Secondary risk: Check whether the response itself introduces new uncertainty.

D. Risk Identification

Risk identification systematically discovers and documents uncertainties that could affect project objectives.

• Techniques: Use brainstorming, interviews, checklists, assumption analysis, SWOT analysis, and lessons from earlier projects.
• Structural review: Examine each work package, dependency, interface, estimate, supplier, and milestone.
• Risk register: Record identifier, cause, event, effect, category, owner, trigger, and current status.
• Participation: Include developers, testers, users, operations staff, suppliers, managers, and security specialists.
• Timing: Repeat identification at initiation, planning, iteration boundaries, major changes, and reviews.

E. Risk Assessment

Risk assessment evaluates identified risks so management attention is directed toward significant exposure.

• Qualitative assessment: Rate probability and impact using defined scales, such as 1–5, and place risks in a probability-impact matrix.
• Quantitative assessment: Use expected monetary value, decision trees, sensitivity analysis, or simulation when adequate data exist.
• Impact dimensions: Consider schedule, cost, scope, quality, safety, security, reputation, and benefits.
• Prioritisation: High-probability, high-impact risks normally receive immediate ownership and response planning.
• Urgency: A moderate risk with an imminent trigger may outrank a larger but distant risk.

F. Risk Planning

Risk planning converts assessed risks into funded, owned, and time-bound responses.

• Response plan: Specify action, owner, due date, required resources, trigger, and expected reduction in exposure.
• Contingency reserve: Allocate time or money for known uncertainties; management reserve addresses less predictable uncertainty.
• Fallback plan: Define an alternative when the primary response fails.
• Integration: Add mitigation tasks and contingency allowances to the project schedule and budget.
• Proportionality: Response cost should be justified by the exposure reduced or opportunity created.

G. Risk Management

Risk management is the continuous process of identifying, analysing, responding to, and monitoring uncertainty.

• Cycle: Identify risks, assess exposure, plan responses, implement actions, monitor outcomes, and reassess.
• Ownership: A risk owner monitors the risk; an action owner performs a specific response.
• Reviews: Examine top risks, triggers, overdue actions, residual exposure, and emerging risks at regular status meetings.
• Indicators: Track measures such as defect trends, staff turnover, schedule variance, and supplier performance.
• Closure: Close a risk when it expires, becomes impossible, is fully resolved, or becomes an issue.

H. Evaluating Risk to the Schedule

Schedule-risk evaluation estimates how uncertainty in activity durations may affect milestones and project completion.

• Sources: Include estimation error, dependency failure, resource contention, rework, approval delay, and external delivery dates.
• Sensitivity: Focus on critical and near-critical paths because small delays may consume their limited float.
• Scenario analysis: Compare optimistic, most likely, and pessimistic completion forecasts.
• Simulation: Monte Carlo analysis repeatedly samples duration distributions to estimate probabilities such as “80% chance of completion by 30 June.”
• Response: Add targeted buffers, reduce dependencies, prototype uncertain work, or protect scarce resources.

V. Probabilistic Scheduling

Probabilistic scheduling represents uncertain activity durations explicitly instead of treating one estimate as certain.

A. Applying the PERT Technique

The Program Evaluation and Review Technique estimates activity duration from optimistic, most likely, and pessimistic values.

• Expected duration:

te = (o + 4m + p) / 6

• Variance:

Variance = ((p - o) / 6)^2

• Symbols: te is expected duration, o optimistic time, m most likely time, and p pessimistic time.
• Example: For o = 4, m = 7, and p = 16 days, te = 8 days and variance is 4 days².
• Limitation: PERT depends on judgement-based estimates and can understate correlated risks shared by several activities.

VI. Portfolio-Level Risk and Value

Project portfolio management selects and balances projects collectively so that risk, return, capacity, dependencies, and strategic value are considered together.

A. Risk Adjusted Portfolio Performance (RAPP)

RAPP evaluates portfolio value in relation to the amount of risk accepted, rather than ranking projects solely by expected return.

• Principle: A lower-return project may be preferable when it produces a more reliable return or reduces portfolio exposure.
• Generic measure:

RAPP = (Expected portfolio return - Required return) / Portfolio risk

• Symbols: Required return is the minimum acceptable return; portfolio risk may be represented by volatility, loss exposure, or another defined measure.
• Project context: Returns may include financial benefit, strategic contribution, compliance value, or service improvement.
• Use: Compare alternative portfolios only when return and risk are measured consistently.

B. Portfolio Optimisation and Diversification 2.0

Modern portfolio optimisation constructs a feasible mix of projects while recognizing strategic, resource, dependency, and systemic risks.

• Optimisation objective: Maximize value or risk-adjusted performance subject to budget, staffing, timing, and policy constraints.
• Diversification: Avoid excessive concentration in one technology, customer, market, supplier, or risk source.
• Dependencies: Account for projects that share platforms, specialists, data, vendors, or benefits; apparent diversification may therefore be misleading.
• Scenario-based approach: Test portfolios against funding cuts, demand changes, delays, security events, and resource shortages.
• Dynamic rebalancing: Review the portfolio as project evidence and strategy change, then accelerate, pause, reshape, or terminate projects accordingly.