Unit 4: Activity Planning and Risk Management - Subjective Questions

Activity planning is the process of identifying, organizing, estimating, sequencing, and scheduling the activities required to complete a software project.

Major objectives:

• Feasibility assessment: Determine whether the project can be completed within the available time, budget, and resources.
• Resource allocation: Identify the people, tools, infrastructure, and budget required for each activity.
• Detailed scheduling: Establish the start time, completion time, duration, and dependencies of project activities.
• Risk identification: Detect activities that may cause delays, cost overruns, or quality problems.
• Coordination: Ensure that team members understand their responsibilities and the relationships between tasks.
• Progress measurement: Provide milestones and baselines against which actual performance can be compared.
• Change control: Make it easier to determine the effect of a change on cost, schedule, scope, and resources.

Thus, activity planning converts broad project objectives into a practical and measurable course of action.

A project schedule is a time-based plan showing when project activities should start and finish, who will perform them, and how they depend on one another.

Steps in schedule preparation:

1. Define project scope: Clearly specify deliverables, constraints, and completion criteria.
2. Develop a Work Breakdown Structure: Divide the project into manageable work packages and activities.
3. Identify dependencies: Determine which activities must precede or follow others.
4. Estimate effort: Calculate the human effort required for each activity, usually in person-hours or person-days.
5. Estimate duration: Convert effort estimates into calendar time after considering resource availability.
6. Assign resources: Allocate suitable team members, tools, and facilities.
7. Construct a network model: Represent activity relationships using a network diagram.
8. Identify the critical path: Determine the sequence of activities that controls project duration.
9. Set milestones: Define measurable review and delivery points.
10. Create and approve the baseline: Record the accepted schedule for future monitoring and control.

A good schedule should be realistic, dependency-aware, resource-feasible, and capable of being updated when circumstances change.

Managing the task focuses on the execution of individual work items, whereas managing the plan focuses on the overall coordination and control of the project.

The two are closely related. Poor management of individual tasks affects the overall plan, while an unrealistic plan makes effective task management difficult. A project manager must therefore maintain both task-level visibility and plan-level control.

A network planning model is a graphical representation of project activities and the logical dependencies among them. It helps managers determine the order of work, calculate project duration, and identify schedule-sensitive activities.

Basic elements:

• Activities: Tasks that consume time and usually require resources.
• Events or nodes: Points representing the start or completion of activities.
• Dependencies: Logical relationships showing the required sequence of activities.
• Paths: Sequences of connected activities from project start to finish.
• Milestones: Significant zero-duration events used to monitor progress.

Common representations include Activity-on-Arrow and Activity-on-Node diagrams. Modern scheduling tools generally use Activity-on-Node diagrams.

A network model provides:

• Earliest and latest start and finish times.
• Total duration of the project.
• Critical and non-critical activities.
• Float or scheduling flexibility available to activities.
• Effects of delay in one activity on dependent activities.
• Opportunities for parallel execution.

Techniques such as the Critical Path Method and PERT use the network planning model for schedule analysis.

The time dimension deals with estimating and arranging project work along a calendar. Accurate treatment of time is essential because effort and duration are not always equivalent.

• Effort: The amount of human work needed to complete an activity. It is measured in person-hours, person-days, or person-months.
• Duration: The number of working periods from the start to the finish of an activity.
• Elapsed time: The total calendar time taken, including weekends, holidays, waiting periods, and other non-working intervals.
• Milestone: A significant project event or review point, normally having zero duration.

For example, an activity requiring person-days of effort does not necessarily have a duration of days when two people are assigned. Communication, task indivisibility, learning time, and coordination overhead may prevent a direct reduction.

A simplified relationship is:

However, a practical estimate must also consider resource calendars, dependencies, productivity differences, interruptions, and uncertainty. Therefore, project schedules should separately record effort, working duration, and elapsed calendar time.

The critical path is the longest-duration path through a project network. It determines the earliest possible completion time of the project.

Procedure for identifying it:

1. List all activities, durations, and dependencies.
2. Draw the project network.
3. Perform a forward pass to calculate earliest times:
   • is the earliest start.
   • , where is activity duration.
   • When an activity has several predecessors, use the largest predecessor finish time.
4. Perform a backward pass to calculate latest times:
   • is the latest finish without delaying the project.
   • .
   • When an activity has several successors, use the smallest successor start time.
5. Calculate total float:

6. Activities with zero total float normally form the critical path.

Significance of float:

• It indicates how long an activity can be delayed without delaying project completion.
• It helps managers prioritize monitoring and allocate scarce resources.
• Activities with small float are near-critical and require attention.
• A delay in a critical activity directly delays the project unless corrective action is taken.

The critical path can change when activity durations, dependencies, or resources change.

Change management is a controlled process for evaluating and implementing modifications to project scope, requirements, schedule, budget, technology, or resources.

Recommended change-control process:

1. Submit a change request: Record the proposed change, its reason, urgency, and expected benefits.
2. Classify the change: Identify whether it concerns scope, defects, technology, schedule, resources, or compliance.
3. Perform impact analysis: Evaluate effects on effort, cost, schedule, quality, risks, dependencies, and contractual commitments.
4. Evaluate alternatives: Consider rejection, postponement, partial implementation, or implementation in a later release.
5. Approve or reject: An authorized project manager, product owner, sponsor, or change control board makes the decision.
6. Update the plan: Revise the schedule, budget, risk register, requirements, and configuration baselines.
7. Communicate the decision: Inform all affected stakeholders and task owners.
8. Implement and verify: Apply the approved change and confirm that it achieves the intended result.
9. Maintain traceability: Preserve links between the request, decision, implementation, testing, and release.

Uncontrolled change causes scope creep and unstable schedules. Controlled change ensures that necessary modifications are accepted only after their complete consequences are understood.

Goals and milestones may require readjustment when the original assumptions are no longer valid or when project performance significantly differs from the baseline.

Common reasons:

• Changes in customer requirements or business priorities.
• Delays in critical activities.
• Loss or unavailability of key resources.
• New technical, legal, or security constraints.
• Inaccurate effort and duration estimates.
• Occurrence of previously identified or unexpected risks.
• Reduction in budget or movement of a market deadline.

Systematic process:

1. Compare actual progress with the approved baseline.
2. Identify the root cause and size of the variance.
3. Reassess scope, resources, dependencies, risks, and remaining work.
4. Consider options such as adding resources, reducing scope, changing sequence, overlapping activities, or extending deadlines.
5. Prioritize goals using business value, urgency, and feasibility.
6. Define revised milestones with measurable completion criteria.
7. Obtain stakeholder approval for major changes.
8. Update schedules, budgets, responsibilities, and risk plans.
9. Communicate the revised baseline to the team.
10. Monitor the new milestones closely.

Readjustment should preserve essential business objectives and quality standards rather than merely hiding poor performance.

A project risk is an uncertain event or condition that, if it occurs, can affect project objectives such as scope, time, cost, quality, or business value. A risk may represent a threat or an opportunity, although risk management often emphasizes threats.

Major risk categories:

• Project risks: Threaten the project plan, such as schedule slippage, cost overruns, poor estimates, or resource shortages.
• Technical risks: Arise from design complexity, immature technology, integration difficulties, performance limitations, or quality problems.
• Business risks: Include loss of market demand, changes in strategy, funding withdrawal, or low return on investment.
• Operational risks: Relate to deployment, maintenance, support, infrastructure, or business continuity.
• People risks: Include skill shortages, staff turnover, communication failures, and low productivity.
• External risks: Include supplier failure, regulatory change, natural disasters, economic conditions, and geopolitical events.
• Security and compliance risks: Include data breaches, privacy violations, licensing issues, and failure to satisfy standards.

Risks can also be classified as known, predictable, and unpredictable. Classification supports systematic identification and assignment of suitable responses.

The main risk response strategies are:

• Avoidance: Change the project approach so that the threat no longer exists. For example, replace an unstable experimental framework with a proven platform.
• Mitigation or reduction: Reduce the probability or impact of the risk. For example, create a prototype to reduce uncertainty about system performance.
• Transfer: Shift financial or operational responsibility to another party. For example, outsource a specialized security audit under a fixed-price contract.
• Acceptance: Acknowledge the risk and take no immediate preventive action when response costs exceed the expected loss. For example, accept a minor delay risk for a low-priority internal feature.
• Contingency planning: Prepare actions to be executed if the risk occurs. For example, maintain a backup cloud provider in case the primary provider fails.
• Escalation: Transfer the decision to higher management when the risk is outside the project manager's authority.

For opportunities, strategies include exploit, enhance, share, and accept. The selected response should be assigned to a risk owner and supported by triggers, resources, deadlines, and fallback actions.

Risk identification is the systematic process of discovering uncertain events that could affect project objectives and documenting their characteristics.

Process:

1. Review scope, estimates, assumptions, constraints, contracts, and the schedule.
2. Examine each activity, dependency, resource, technology, and external interface.
3. Identify causes, risk events, and possible consequences.
4. Classify risks into suitable categories.
5. Assign preliminary owners and record the risks in a risk register.
6. Repeat the process throughout the project because risks evolve over time.

Identification techniques:

• Brainstorming and facilitated workshops.
• Interviews with experts and stakeholders.
• Checklists developed from previous projects.
• SWOT analysis of strengths, weaknesses, opportunities, and threats.
• Assumption and constraint analysis.
• Root-cause analysis and cause-and-effect diagrams.
• Review of the Work Breakdown Structure and network schedule.
• Delphi technique for collecting anonymous expert opinions.
• Lessons-learned databases and historical records.
• Prompt lists such as technical, organizational, environmental, and commercial categories.

A useful risk statement follows the structure: cause, uncertain event, and effect. The risk register should record its description, category, owner, triggers, probability, impact, and proposed response.

Risk assessment estimates the seriousness of identified risks so that management attention can be prioritized.

Qualitative assessment:

• Uses descriptive or ordinal scales such as low, medium, and high.
• Rates probability, impact, urgency, detectability, and proximity.
• Often uses a probability-impact matrix.
• Is quick and suitable for initial screening.
• Depends considerably on expert judgment.

Quantitative assessment:

• Assigns numerical values to probability and consequences.
• Uses techniques such as expected monetary value, decision trees, sensitivity analysis, PERT, and Monte Carlo simulation.
• Estimates possible cost or schedule outcomes.
• Requires more reliable data and effort than qualitative assessment.

Risk exposure is commonly calculated as:

where is the probability of the risk and is its estimated impact.

For example, if a risk has a probability of and a potential loss of , then:

Risk exposure supports prioritization, but managers should also consider risks with low probability and catastrophic impact.

Risk planning is the process of deciding how identified and assessed risks will be handled. Its purpose is to reduce threats, improve opportunities, and ensure that actions are ready before critical events occur.

An effective risk response plan should contain:

• Risk identifier and description: A unique reference and clear risk statement.
• Cause and consequence: The source of uncertainty and its possible effect.
• Probability and impact rating: The assessed priority of the risk.
• Selected strategy: Avoid, mitigate, transfer, accept, exploit, enhance, or share.
• Preventive actions: Steps taken before occurrence to lower probability or impact.
• Contingency actions: Steps activated after a trigger or risk event occurs.
• Triggers or warning signs: Measurable conditions indicating that the risk is approaching.
• Risk owner: The person accountable for monitoring and responding.
• Action owner: The person responsible for a specific response activity.
• Schedule and budget: Dates, resources, management reserve, and contingency reserve.
• Residual risks: Risks remaining after the planned response.
• Secondary risks: New risks created by the response itself.
• Fallback plan: Alternative action if the primary response is ineffective.

Risk actions should be incorporated into the main project schedule rather than maintained as disconnected intentions.

Risk management is a continuous and iterative process rather than a one-time activity.

Risk management cycle:

1. Plan risk management: Define the approach, roles, categories, scales, reporting format, and review frequency.
2. Identify risks: Discover and document threats and opportunities.
3. Assess risks: Analyze probability, impact, urgency, and overall exposure.
4. Prioritize risks: Rank risks so that resources are focused on the most important ones.
5. Plan responses: Select strategies, owners, preventive actions, contingencies, and reserves.
6. Implement responses: Execute approved risk-related activities.
7. Monitor and control: Review risks, triggers, responses, and remaining exposure.
8. Close and learn: Close obsolete risks and record lessons for future projects.

Monitoring and control activities include:

• Conducting periodic risk review meetings.
• Tracking indicators and early-warning triggers.
• Reassessing probability and impact.
• Checking whether planned responses are effective.
• Identifying new, residual, and secondary risks.
• Performing risk audits and variance analysis.
• Updating the risk register and project schedule.
• Escalating risks beyond the project manager's authority.
• Using trend reports such as the number of high-exposure risks over time.

The objective is to keep total project exposure within acceptable tolerance while maintaining traceability and accountability.

Schedule risk evaluation determines the likelihood that uncertain activity durations or events will delay milestones or the final completion date.

Evaluation process:

1. Identify activities with uncertain durations and risky dependencies.
2. examine the critical path and near-critical paths.
3. Calculate the total and free float of each activity.
4. Estimate optimistic, most likely, and pessimistic durations.
5. Consider resource availability, calendar constraints, rework, and external approvals.
6. Perform sensitivity analysis to find activities with the greatest effect on completion.
7. Use PERT or Monte Carlo simulation to estimate the probability of meeting target dates.
8. Prepare schedule reserves and mitigation actions for high-risk activities.

Important measures:

• Float: Low or zero float indicates that an activity has little tolerance for delay.
• Criticality index: In simulation, this is the proportion of trials in which an activity lies on the critical path.
• Schedule sensitivity: Activities with high duration variability and high criticality are especially risky.
• Merge bias: A milestone with several incoming paths can be delayed if any one of them is late.

Simulation produces a distribution of possible completion dates rather than a single deterministic date. This allows management to select a deadline associated with an acceptable confidence level and establish an appropriate contingency reserve.

The Program Evaluation and Review Technique, or PERT, uses three time estimates for each activity:

• : optimistic time, assuming favorable conditions.
• : most likely time, representing normal conditions.
• : pessimistic time, assuming unfavorable conditions.

PERT approximates the activity duration using a beta distribution. The most likely estimate receives four times the weight of each extreme estimate. Therefore, the expected activity time is:

The activity standard deviation is approximated by:

Hence, the variance is:

For a path containing several independent activities, the expected path duration is:

The path variance and standard deviation are:

Main assumptions:

• Activity durations can be represented by a beta-like distribution.
• Activity duration estimates are statistically independent.
• The sum of durations on a sufficiently large path is approximately normal.
• The selected critical path remains relevant during probability calculation.
• The three estimates are reasonably accurate and unbiased.

These assumptions may be weak in software projects where activities are correlated or where the critical path changes.

For each activity, PERT uses:

Activity 1:

Activity 2:

Activity 3:

Expected project duration:

Path variance:

Path standard deviation:

For completion within weeks:

From the standard normal distribution:

Therefore, the approximate probability of completing the project within weeks is .

Risk Adjusted Portfolio Performance, or RAPP, evaluates portfolio return or business value relative to the risk undertaken. It prevents managers from selecting projects solely because they promise high benefits while ignoring uncertainty.

A general risk-adjusted measure can be expressed as:

where:

• is the expected portfolio return or value rate.
• is the minimum acceptable or risk-free return.
• is the standard deviation or risk of portfolio return.

This form is similar to the Sharpe ratio. Depending on organizational practice, risk may also include schedule exposure, loss probability, Value at Risk, or expected shortfall.

Application to software portfolios:

• Estimate the expected value of each software project.
• Assess cost, schedule, technical, market, and operational uncertainty.
• Include correlations between project outcomes.
• Calculate the combined expected portfolio value and risk.
• Compare alternative portfolios using a consistent risk-adjusted measure.
• Select a portfolio that provides adequate value without exceeding organizational risk tolerance.

RAPP should not be used alone. Strategic alignment, mandatory projects, resource constraints, project dependencies, security obligations, and long-term capability development must also be considered.

Portfolio optimisation is the selection of a combination of projects that maximizes expected strategic value or return for an acceptable level of risk and resource usage. Diversification reduces concentration by distributing investment across projects with different technologies, markets, durations, risk profiles, and business objectives.

For a two-project portfolio, the expected return is:

The portfolio variance is:

where and are portfolio weights, and are project risks, and is the correlation between outcomes.

• If , the projects move together and diversification provides little benefit.
• If , portfolio risk can be reduced.
• If , some combinations may theoretically eliminate variability.

Diversification 2.0 extends traditional financial diversification by considering shared resources, technology dependencies, strategic themes, cyber risk, environmental factors, data, and common suppliers. A portfolio that appears financially diversified may still be exposed to one cloud provider or one scarce technical skill.

Optimisation must therefore consider value, risk, correlation, resource capacity, dependencies, mandatory work, and strategic balance.

Both the Critical Path Method, or CPM, and PERT use project networks to analyze dependencies and determine project completion time, but they treat activity duration differently.

Similarities:

• Both require activities and dependencies to be identified.
• Both calculate a critical path.
• Both support scheduling, monitoring, and prioritization.
• Both can be implemented using project management software.

In software projects, CPM is useful when durations are reasonably stable, while PERT is valuable for research, integration, and unfamiliar technologies. A practical manager may combine them by using three-point estimates in a critical-path network.