Software Project
Management

Project Definition

[Extra from Syllabus sheet]

A project is temporary work undertaken to deliver a unique product, service, or result. Building an online examination system for a university is a project. Running its help desk every semester is ongoing operations.

Importance of Software Project Management

[Extra from Syllabus sheet]

Software Project Management (SPM) is the planning, organization, direction, monitoring, and control of people and work to deliver software within agreed scope, time, cost, and quality constraints.

Software is intangible, requirements can evolve, components interact, and delivery depends heavily on people and specialized knowledge. A working demo, accepted milestone, or passing test provides more evidence of progress than hours spent. SPM helps define scope and goals, estimate time, cost and effort, allocate people and tools, prepare risk responses, coordinate stakeholders, and manage delivery against a baseline.

[Added for Understanding] Project types. Classify by the work driving the plan. A product-driven project starts with a defined deliverable, such as a specified results portal. An objective-driven project starts with a result, such as reducing exam administration time, and evaluates software and process alternatives. New development, enhancement and migration are also useful categories when estimating based on comparable projects.

Project Portfolio Management

[Extra from Syllabus sheet]

Project Portfolio Management (PPM) selects, prioritizes, funds, balances, and reviews projects and programs together to support organizational strategy under shared constraints. A program coordinates related projects to realize shared benefits. A portfolio may group unrelated projects competing for the same budget, people, or infrastructure.

1. Collect proposals and business cases. Screen for mandatory obligations, strategic fit, and basic feasibility.
2. Compare value, risk, dependencies, urgency, and scarce resources. Use financial metrics and a weighted score where appropriate.
3. Select and sequence a mix of investments. Assign funding and capacity, settle conflicts, and document the rationale.
4. Review benefits, resources, and risks periodically. Continue, redirect, defer, or stop investments as conditions change.

Example. An exam platform, a student analytics dashboard, and a regulatory reporting upgrade all need the same database engineer. Portfolio management sets the order and funding. The manager of the selected exam project plans and controls that project’s delivery.

Activities Covered by Software Project Management

Overview of Project Planning

Project planning is the process of deciding what to deliver, when, by whom, with which resources, and within which cost. Meet stakeholders, agree and prioritize goals, define deliverables, create a schedule, assess issues and risks, and present the plan for approval. The approved baseline is the reference for measuring later performance. The schedule forecast can evolve as fresh information arrives.

The plan acts as a roadmap. It reduces uncertainty, improves stakeholder communication and team coordination, and shows whether resources can support delivery on time and within budget. Later it provides the reference for measuring progress and taking action.

1. Meet stakeholders and prioritize goals
2. Define deliverables
3. Create the schedule
4. Identify issues and assess risks
5. Present the plan for approval

Stepwise Project Planning

The eight steps in the notes run from scope and objectives to review and publication. In the extended Stepwise sequence, step 0 selects the project, step 9 executes the plan, and step 10 refines it at lower levels. The outputs below follow the names in the notes where given. When risk or resource checks change a decision, revisit the relevant earlier step.

1. Objectives
2. Infrastructure
3. Characteristics
4. Products and activities
5. Effort
6. Risk
7. Resources
8. Review and approval
9. Execution

Advantages. Visibility, coordination, uncertainty reduction, efficient resource use, accountability, and a reference for control. Limitations. Early estimates and assumptions are uncertain, detailed plans cost time to maintain, and overrigid baselines can slow justified changes. Revisit estimates and risks as information improves.

Strategic Assessment and Technical Assessment

Strategic Assessment

Strategic assessment evaluates long-term fit and business value. Use it to prioritize proposals, compare benefits and risks, and decide which projects warrant investment. Check business objectives, market demand, competitive advantage, cost-benefit case, resources and opportunities. The decision may be to approve, defer or reject.

Technical Assessment

Technical assessment asks whether the proposed system can be built and operated in the available environment. Check architecture, hardware, software, tools, team expertise, integration, performance, scalability and security. Decide whether the system is feasible and identify the gaps or a suitable technology stack. Use a proof of concept or integration check when a key assumption is uncertain.

For an AI-based healthcare management system, strategic assessment tests digital healthcare alignment, market demand, and whether anticipated value supports a positive ROI. Technical assessment checks AI expertise, cloud infrastructure and machine-learning tools, integration with existing systems, and performance, security and scalability. An early prototype can test a major feasibility assumption.

Cost Benefit Analysis (CBA)

Cost Benefit Analysis (CBA) identifies, estimates, values, and compares costs and benefits over the project’s life to support investment choices. Costs include development, testing, deployment, operations, maintenance, support, hosting, training, infrastructure, hardware, software licenses and cloud services. Benefits include revenue, productivity, reduced operating cost, better decisions, customer satisfaction and competitive advantage. State how intangible benefits are assessed and avoid counting the same benefit twice.

1. Identify development, operating, training and infrastructure costs, including their timing.
2. Estimate benefits, including annual gains and one-off proceeds such as salvage.
3. Convert comparable impacts to money and document assumptions for intangible benefits.
4. Compare on a common time and price basis. Benefits above costs pass the stated test, equality is break-even, and lower benefits call for reconsideration or rejection.
5. Use the result with strategic fit, technical feasibility and risk to justify the investment, compare alternatives and allocate funds.

CBA helps surface financial risks early and assess feasibility and return on investment before committing resources.

Cash Flow Forecasting (CFF)

Cash Flow Forecasting (CFF) estimates actual timing of receipts and payments to protect liquidity. Inflows include client payments, funding, sales, and service receipts. Outflows include salaries, licenses, hardware, cloud, maintenance and training. Estimate receipts and payments per period, record credit collections when expected to arrive, calculate net flow and closing balance, then use that balance as the next opening balance. Review variances and update the forecast as due dates or costs change. This supports budgeting and investment decisions, identifies funding needs early, reduces cash shortage risk, and keeps work funded when required.

CBA asks whether the value justifies the investment. CFF asks whether cash is available when bills fall due. A profitable project can still face a cash shortage before customers pay.

Cost Benefit Evaluation Techniques

These techniques test feasibility, compare competing investments, and support efficient use of capital. A project can look attractive by one metric and still have a poor fit with the organization’s deadlines or risk tolerance.

[Added for Understanding] Time value of money. At a 10% discount rate, ₹110 received one year from now has a present value of ₹110 ÷ 1.10 = ₹100 today. Year 2 has two periods of discounting. Cash spent now is already at time 0 and has factor 1. Apply the specified rate using the same period as the cash flows.

Risk Evaluation

Risk evaluation analyzes identified uncertainties, estimates likelihood and impact on scope, schedule, cost, quality and benefits, and prioritizes responses. Typical categories are technical (defects, new technology, integration), project (delay, staffing, budget), business (market change, customer withdrawal, regulation), and external (pandemic, disaster, policy). Look for cost estimating errors, unclear customer requirements, delay, resource shortage, and external constraints. Compare risks using a common scale and develop responses for those beyond tolerance.

A risk matrix maps probability and impact to priority. This is one example policy, used consistently across proposals.

Identify → analyze → prioritize → select avoid, reduce, transfer or accept → monitor and update the risk register. High-priority risks require prompt action. Moderate risks receive review and controls as appropriate. Low risks can be accepted and watched. Evaluating risks improves early detection, planning, quality, resource use and cost control. It reduces uncertainty and improves the chance of meeting commitments and satisfying customers.

Objectives

Risk evaluation objectives. Identify uncertainties, estimate their likelihood and effect, rank them by severity, and plan a suitable response. Connect every rating to the objective it affects.

Project objectives should be SMART (Specific, Measurable, Achievable, Relevant, Time-bound), clear, consistent and prioritized. Common objectives are quality software, on-time delivery, budget control, customer satisfaction, resource utilization, risk reduction, maintainability, and compliance. Tie each to an observable measure where possible.

Translate the major objectives into observable targets. Quality meets requirements with few serious defects. Schedule meets agreed milestones. Budget limits unnecessary cost. Customer satisfaction measures user acceptance of reliable software. Resource utilization assigns people, hardware and software efficiently. Risk reduction limits exposure. Maintainability supports fixes and future enhancements. Compliance meets relevant organizational, security and regulatory requirements.

Project Schedule

A project schedule identifies start and finish dates, dependencies, milestones, and resource assignments. It coordinates teams, exposes delay early, balances workload, reduces idle time, supports progress tracking and helps the team meet customer deadlines.

Sequencing and Scheduling Activities

1. Identify activities from the WBS, such as requirements, design, coding, testing, and deployment.
2. Estimate duration, such as 2 weeks for requirements, 8 for coding, and 4 for testing. Record assumptions and availability.
3. Determine predecessors and dependency type. In a simple software sequence, design follows requirements, coding follows design, and testing follows coding. Finish-to-start (FS) links a successor’s start to its predecessor’s finish. Other types are start-to-start (SS), finish-to-finish (FF), and start-to-finish (SF). A lag adds waiting time and a lead allows overlap.
4. Allocate developers, testers, database engineers and UI designers. Resolve overbooking and account for calendars.
5. Build the schedule with a Gantt chart, network diagram, CPM or PERT. Check deadlines, milestones and resource feasibility before baselining.
6. Compare planned and actual dates regularly, update forecasts, and review changes to the baseline through change control.

Common problems. Missing dependencies, optimistic estimates, overloaded resources, holiday omissions, late approvals, and stale status. Give each task an owner, update remaining duration, and record calendar, resource and constraint assumptions. Make dependencies visible and inspect critical and near-critical sequences after changes.

Network Planning Models

A Gantt chart places activities on a calendar. A network shows their precedence, helps build and monitor the schedule, and exposes the effect of delays. Activity on Node (AON) puts activities in nodes, with arrows giving dependencies. Activity on Arrow (AOA) puts activities on arrows and events in nodes. CPM normally uses single duration estimates to identify the longest-duration path, float and schedule compression options. PERT uses three duration estimates to model uncertainty. Both use precedence and critical path analysis.

CPM versus PERT. CPM (Critical Path Method) uses specified durations, calculates critical paths and float, and supports time–cost trade-offs. PERT (Program Evaluation and Review Technique) estimates duration under uncertainty from optimistic O, most likely M, and pessimistic P estimates. Its mean is (O + 4M + P) ÷ 6 and variance is [(P − O) ÷ 6]². Module 4 works through the probability calculation.

[Added for Understanding] Read one dependency at a time. A predecessor must satisfy the stated link before its successor can proceed. In this example every link is finish-to-start with zero lag. If a task starts at elapsed time 3 and runs for 5 days, it finishes at time 8. Count the duration as a difference between time boundaries.

Forward Pass

Start at time 0 for activities with no predecessors. Visit tasks in precedence order. At a join, use the largest predecessor finish because every prerequisite must be finished. The largest finish among terminal activities is the earliest project finish.

Backward Pass

Start from the project finish and visit tasks in reverse precedence order. For an unconstrained CPM calculation, seed terminal activities with the earliest project finish. At a branch, the earliest allowable start among successors sets the latest permissible finish. Use a specified project deadline as the seed when the question requires it.

Activity Float

Total float is the delay a task can absorb before delaying the project finish under the stated schedule. Free float is the delay it can absorb before shifting any successor’s earliest start.

In the usual unconstrained CPM exercise, the longest precedence path is critical and its activities have zero total float. There can be more than one such path. A deadline earlier than the calculated finish can produce negative total float, which measures how much the stated schedule misses the deadline along affected paths.

Shortening Project Duration

Crashing reduces critical activity duration using extra capacity or faster methods, usually at higher direct cost. Fast tracking overlaps previously sequential work and may create rework. Resource optimization removes avoidable queues or reassigns people. Approved scope reduction defers low-priority work. Goals include meeting deadlines, avoiding penalties, using resources efficiently, and balancing time and cost.

[Corrected] When to crash. The cost-slope method is usually taught with CPM because it uses explicit time–cost estimates. Crashing is a schedule-compression option even when durations are uncertain. Assess effects on the full network and on schedule risk after any cut.

1. Draw the network and identify current critical paths.
2. Find durations, crash limits, and costs. Example: 6 days at ₹2,000 and 4 at ₹2,600 means ₹300 per day.
3. Choose the lowest incremental-cost feasible reduction covering all current critical paths. This may be one common activity or a combination across paths.
4. Shorten within limits and recompute paths after each change. Stop at target, infeasibility, or the economic limit stated in the problem.

Activity on Arrow Networks

An event is a zero-duration milestone reached after all incoming work. An arrow has activity and duration. Label all arrows clearly and number events in increasing precedence order. Use common start and finish events in the textbook network. A zero-duration dummy activity shows a logical dependency or keeps activities distinguishable when their head and tail events would otherwise coincide. Example: A and B start together, C depends only on A, and D depends on A and B. Use separate A and B end events, start C at A’s end, and add a dummy from A’s end to B’s end to make D wait for both.

Solving an AOA network. Set the start event to zero and compute each earliest event time using every incoming arrow. Set the latest finish event to the required finish, or the calculated earliest finish if the question supplies none. Move backward, checking every outgoing arrow. Then convert event times into each arrow’s dates and float.

For the seven-activity example, A connects events 1→2, B 2→3, C 2→4, D 3→5, E 4→5, F 5→6, and G 6→7. F can start only after D and E reach event 5, so this network needs no dummy arrow. Earliest events = [0, 3, 8, 7, 14, 18, 21]. Latest events = [0, 3, 8, 9, 14, 18, 21]. For E (4→5), total and free float both equal 14 − 7 − 5 = 2.

Basis and Need for Estimation

Effort is human work in person-hours, person-days, or person-months (PM). Duration is elapsed time and cost is money. A task taking 12 person-days might take 6 calendar working days with two equally productive people if the work is fully divisible. Dependencies, ramp-up, communication and shared resources can prevent that speedup. Estimate labor cost by multiplying role-specific effort by rates, then add applicable non-labor costs.

Effort estimates support manpower, scheduling, budgeting, bidding, risk assessment, customer commitments and project control. Start with the requirements and size (functions, objects, lines of code or work packages). Adjust for complexity, team skill and experience, process, technology, stability, reuse, risk, customer involvement, tools, and available historical productivity. Record assumptions, give a range where uncertainty is high, and revise when scope and productivity become clearer.

Problems with Overestimates and Underestimates

Common causes include unclear requirements, scarce historical data, unfamiliar technology, estimator inexperience, frequent changes, imposed deadlines, and ignored risk. Decompose work, cross-check independent methods, use peer review and historical data, include explicit contingency, and re-estimate based on actuals.

Before finalizing, check the design and scope assumptions with the team, apply risk analysis, and compare with a suitable calibrated model such as COCOMO or function-point productivity. Track the estimates against actual effort and revise remaining work. A defensible contingency covers uncertainty explicitly and can be reviewed separately.

Software Effort Estimation Techniques

Albrecht Function Point Analysis

Allan J. Albrecht introduced function point sizing at IBM, presenting it in 1979. The unit measures user-visible functional size independently of programming language. Use it for size, cost and effort estimates, productivity, comparisons, planning and scheduling. Set the application boundary first. A file here is a logical group of data as seen by users.

Counting sequence. Define the boundary → identify each user-recognizable function → classify complexity → multiply counts by weights and sum UFP → if requested, rate the fourteen GSCs, calculate VAF, and multiply for adjusted FP.

[Added for Understanding] How the complexity counts are used. A DET is a user-recognizable data field. An FTR is an internal logical file read or maintained, or an external interface file read, by a transaction. A RET is a recognizable subgroup of a logical data file. Transaction matrices use DET and FTR. Data-file matrices use DET and RET. The five function types use the weighting table after the complexity has been assigned.

[Corrected] External Inquiry uses EQ. EI denotes External Input. One transcription lists EI twice.

Classic adjustment. The 14 General System Characteristics (GSCs) are data communications, distributed data processing, performance, heavily used configuration, transaction rate, online data entry, end-user efficiency, online update, complex processing, reusability, installation ease, operational ease, multiple sites, and facilitate change. Rate each using the scale below. Sum for Total Degree of Influence (TDI, also called DI in the notes). Use adjustment when the question calls for it.

[Corrected] Influence ratings. 0 = none, 1 = incidental, 2 = moderate, 3 = average, 4 = significant, 5 = strong. The note labels 3 as significant and skips 4.

Advantages and limitations. Early functional sizing, language independence, the user’s perspective, and comparable productivity support estimation, planning and resource allocation. Accurate classification takes training and time on large systems. Different analysts may draw different boundaries or classify functions differently. The method and the classic adjustments fit some types of systems better than others.

Function Point Mark II (Mk II)

[Extra from Syllabus sheet]

Mark II (Mark 2), associated with Charles Symons and documented by the UK Software Metrics Association, measures user-recognizable logical transactions. Identify the application boundary, then each complete transaction with input, processing and output. For each transaction count input data element types I crossing into the system, entity type references E used by its processing according to the counting rules, and output data element types O crossing back out. For example, a candidate registration has fields entering the boundary, referenced data entities for validation and storage, and a confirmation leaving it. Add the weighted sizes of the transactions. Apply a technical adjustment only if the question explicitly provides and requests an adjustment convention.

Exam comparison. Albrecht counts five function categories and assigns complexity weights. Mk II sizes the input, processing and output of each logical transaction directly with weighted element and entity counts.

Object Points and COCOMO II Application Composition

Object Points (also called Application Points) measure screens, reports, and third-generation language (3GL) components in an application-composition environment. Count each object, classify screens by views and reports by sections, considering number and source of data tables. Apply complexity weights, deduct reused proportion, then divide by New Object Points per person-month. A screen with four views is one screen classified using four views.

[Corrected] Object Point bands. Read the total-table columns as mutually exclusive: fewer than 4, 4–7, and 8 or more. The notes also list source descriptors of <2 server and <3 client, 2–3 server and 3–5 client, and >3 server and >5 client. The historical screen matrix leaves exactly eight views unclear when it prints “>8” after “3–7.” This guide puts eight views in the highest band as a teaching convention. Use any explicit matrix supplied in the question.

Typical PROD values for very low, low, nominal, high and very high capability/tool maturity are 4, 7, 13, 25, 50 NOP/person-month.

Constructive Cost Model (COCOMO)

[Extra from Syllabus sheet] COCOMO 81 and the wider COCOMO II model. The notes already supply Application Composition in Object Points.

Barry Boehm’s COCOMO 81 maps software size in KLOC (thousand delivered lines of code) to effort and development time. Organic projects have a familiar setting and relatively flexible constraints. Semidetached projects have mixed experience and intermediate constraints. Embedded projects face tight operational, hardware, software, or regulatory constraints. Choose the mode from the project description or exam prompt.

Intermediate COCOMO multiplies a × KLOC^b by the Effort Adjustment Factor (EAF), the product of rated effort multipliers for product, computer/platform, personnel and project attributes. Detailed COCOMO applies finer phase-sensitive cost drivers and distributes effort by activity/phase.

COCOMO II includes Application Composition for early object-based sizing, Early Design when coarse product and architecture information is available, and Post-Architecture when detailed drivers are known. A common calibrated effort form for the last two is PM = A × Size^E × ∏EM, with E = B + 0.01 × ΣSF. SF are scale factors, EM are effort multipliers, and size is in equivalent KSLOC after the model’s sizing and reuse rules. Use coefficients supplied by the question. Application Composition uses NOP ÷ PROD as above.

[Added for Understanding] Effort and schedule units. Enter 10, not 10,000, in a KLOC formula for 10,000 lines. Apply the schedule equation to the computed person-months. The average staffing ratio summarizes the whole schedule. Actual staffing can vary by phase.

Nature of Risk

A hazard is a source or condition with potential for harm. A risk is an uncertain event or condition affecting objectives. Threats have adverse effects and opportunities can create favorable effects. An issue is a problem already present. Example: a single developer understands the payment integration (hazard), that developer might leave before release (risk), and a resignation has been submitted (issue).

Types of Risk

Classify risks as technical (defects, unstable technology, integration, data loss), project/management (schedule, budget, staffing), business (market, sponsorship, customer withdrawal), and external (disaster, regulation, supplier or policy change). Categories can overlap. State the cause, uncertain event, and effect.

Managing Risk

Start with identifying uncertainty, then analyze likelihood and impact, evaluate priority, assign actions, and monitor/control results. Review the resulting risk register at regular checkpoints and when scope, staffing, dependencies or assumptions change. Residual risk remains after a response. Secondary risk arises because of a response.

For a positive opportunity, enhance its chance or impact, share it with a capable partner, exploit it by acting to make it happen, or accept it and watch for an opportunity to act. The threat responses below address likely losses.

Hazard Identification Techniques

[Extra from Syllabus sheet] Formal identification methods. The notes already list typical hazards.

Hazard Assessment

Identify hazards (unclear or changing requirements, skill gaps, technology failure, vulnerabilities, unrealistic schedules, budget shortage, third-party software reliance, loss of key staff, hardware or network failure). Analyze likelihood and severity for consequences such as delay, cost overrun, poor quality, missed requirements, lost data, security incidents or cancellation. Evaluate priority versus tolerance and decide controls. With comparable monetary impacts, use probability × loss. An ordinal matrix supports prioritization without claiming a monetary result.

Risk Planning and Control

Risk planning decides what to do about identified risks. Identify and analyze the threat, rank it, choose a response to manage probability or impact, assign responsibilities, and monitor and update the response plan.

Assign an owner, response, due date, trigger, and contingency for prioritized risks. Mitigation acts before a risk materializes. Contingency activates when its trigger is reached. The risk register records ID, cause/event/effect, category, likelihood, impact, priority, owner, response, trigger, status and review date.

Risk control. Track triggers, probability and impact, check mitigation effectiveness, identify new risks, and implement contingency when necessary. Update the risk register and communicate status to stakeholders.

1. Monitor
2. Compare
3. Take action
4. Update and communicate

Project Management in Risk Management

The project manager incorporates risk work into the approved plan, sets or proposes schedule and budget reserves within assigned authority, and escalates risks beyond tolerance. Risk owners track triggers and carry out actions. Sponsor or governance bodies decide major reserve, scope or investment changes. Assign response work in the schedule and use change control if the response changes an approved baseline.

Program Evaluation and Review Technique (PERT)

PERT is a probabilistic, time-focused network technique for planning, scheduling, monitoring and control when activity durations are uncertain, such as research and development. Its traditional event orientation makes milestones visible. It estimates completion time, identifies critical activities and the delays that can affect the finish, and estimates the chance of a specified deadline. Estimate optimistic time O under favorable conditions, most likely M under normal conditions, and pessimistic P under unfavorable conditions, with O ≤ M ≤ P. The notes also write these as t_o, t_m and t_p. The most likely time is a typical estimate. The PERT expected time weights this estimate together with both extremes. Identify activities and their dependencies, estimate O, M and P for each, compute expected time and variance, then draw the network. Run the forward/backward passes on the expected durations. Find the longest expected-duration path, then estimate deadline probability using that path.

The textbook estimate treats the expected critical path as controlling completion and approximates its duration as normal. Add variances on that path and take the square root once. Close parallel paths, switching critical paths, correlated durations and small samples weaken this approximation. For zero variance, the path is deterministic under the stated model.

[Added for Understanding] Reading the probability. A standard normal table of Φ(z) gives area to the left of z, which is the chance of finishing by the deadline in this approximation. The chance of finishing later is 1 − Φ(z). Keep variance in days² until you take the square root, so the numerator and denominator of z are both in days.

Creating Framework

[Extra from Syllabus sheet] Formal monitoring design.

Monitoring observes and reports actual performance. Control uses the evidence to take corrective action. A framework defines what to measure, who owns it, how and when to collect it, which approved baseline to use, and when a variance requires escalation. Agree reporting periods, thresholds, milestone criteria and decision authority. For example, for a milestone due at week 6, the QA lead provides accepted test counts each Friday. A threatened critical milestone is escalated immediately, with expected impact and action owner.

Collecting the Data

[Extra from Syllabus sheet]

Collect actual starts and finishes, remaining duration/effort, approved completion, delivered units, defects, risks, resource usage, invoices and actual cost as of the same status date. Sources include timesheets, task trackers, acceptance records, test reports, invoices and team status. Validate completeness, dates, units, accounting cutoff and consistency. Use objective completion rules. Under 0/100, a short task earns all its budgeted value on completion. Under 50/50, it earns half on start and half on completion. For larger work packages, allocate value to weighted milestones and earn each portion only when its criteria are met.

[Added for Understanding] Baseline, actual and forecast. The baseline says when you agreed to finish. The actual records events that have happened. The forecast says when you now expect to finish. A status date aligns all three readings, so a late invoice or an early status update does not distort the comparison.

Visualizing Progress

[Extra from Syllabus sheet] Progress views and how to interpret them.

Read a milestone trend. A release forecast of week 6, then week 7, then week 8 across successive reports indicates additional expected slippage. Check the critical path and bottleneck before choosing a recovery action. On a tracking Gantt, compare the baseline bar with actual and forecast dates for the same task.

Cost Monitoring

[Extra from Syllabus sheet]

Cost monitoring compares actual, committed and forecast expenditure with time-phased budget by work package. Record incurred labor and supplier costs consistently even if payment timing differs. Investigate rate, hours, procurement, rework and scope drivers. Costs below the planned spend can result from delayed work. Earned Value incorporates how much work was accomplished.

Separate costs incurred, commitments (such as an approved order) and payments already made. Example: an invoice due next month can represent work performed today. Keep the cash forecast and cost report aligned to their respective timing rules.

Earned Value Management (EVM)

[Extra from Syllabus sheet]

Earned value relates the budgeted value of completed work to both what was planned and what was spent. All three measures use the same scope and status date. Use the approved budget weights, since completing two low-cost tasks out of five need not earn 40% of the budget.

Negative variance or an index below 1 is unfavorable. SV is expressed in budget units, so report critical-path and calendar delays separately. If a denominator is zero, the ratio is undefined. At physical completion, traditional SV returns to zero when EV and PV both equal BAC, even if delivery was late.

Prioritizing Monitoring

Monitor critical/near-critical activities, high-risk work, expensive work, resource bottlenecks, milestones, quality gates, dependencies and approved changes most closely. Rank by criticality, risk, cost, schedule, quality impact, dependency and visibility. Identify key deliverables early and increase review frequency where an early warning allows timely action. This concentrates management attention, controls cost and schedule, reduces risk impact, and improves the chance that deliverables finish on time.

Getting the Project Back to Target

A project can drift because of schedule delay, cost overruns, resource shortages, technical problems, quality problems and rework, unexpected risks, changing requirements, poor estimates, or dependency delays.

1. Identify the deviation from the approved plan or tolerance.
2. Discover the root cause by checking the activities driving the delay or overrun.
3. Assess impact on schedule, cost, quality, resources, risks and commitments.
4. Develop an action. Prioritize critical tasks, remove avoidable waiting, review assignments, reallocate people or add skilled developers where feasible, and consider resequencing.
5. Implement within authority. If the approved schedule or baseline must change, obtain approval before updating it.
6. Remeasure after the action and check that the deviation narrows without creating unacceptable problems elsewhere.

Update the forecast when new evidence appears. Adding staff late can increase onboarding and coordination effort, so first check whether the work can be divided and the new people can contribute in time.

Change Control

Change control governs changes to approved scope, requirements, schedule, cost, resources, design, technology, quality and deliverables. Common change types are scope, schedule, cost, resource and technical changes. The process prevents unauthorized growth, tracks responsibilities, supports traceability and keeps estimates and stakeholder commitments aligned.

1. Submit a change request with reason, owner and proposed outcome. Record it in the change log.
2. Analyze scope, cost, schedule, quality, resources, risks, dependencies and alternatives with the team.
3. Authorized approver or Change Control Board (CCB) approves, rejects or defers. Record and communicate the decision.
4. Implement approved work. Verify the result against the request, then update the affected requirements, configuration, approved baseline and documentation. Record the outcome, monitor the impact, and close the request.

Example. Monitoring shows a testing delay. First recover by reassigning testers if within authority. If the sponsor wants to move the approved release date or drop an agreed feature, request change approval. Baseline changes require authorization; forecast updates represent current expectations.

Connect the three topics. Monitoring finds a deviation. Corrective action works to restore performance. If the action requires a baseline change, change control evaluates, authorizes, verifies and tracks it.

Managing Contracts

Introduction

A contract is a formal agreement defining deliverables, responsibilities, cost, schedule and conditions. Contract management covers planning, negotiation, execution, monitoring, payments, changes, disputes, documentation and closure. The agreement clarifies mutual responsibilities and the required software, quality and performance, so delivery can be assessed against cost, schedule and acceptance conditions. Managing the agreement includes contractual compliance, risk and record keeping.

• Customer / client. Specifies needs and acceptance criteria, reviews deliverables and pays under the agreement.
• Supplier / contractor. Delivers agreed work, reports performance and corrects deficiencies as required.
• Project manager. Coordinates milestones, evidence, risks, issues and change requests.
• Legal / procurement. Supports solicitation, award, interpretation, negotiation and disputes under the applicable process.

Types of Contract

Stages In Contract Placement

1. Requirement identification. Define objectives, technical requirements, outputs, budget, timeline and quality expectations.
2. Prepare contract documents. Specify scope, technical requirements, deliverables, evaluation criteria and draft conditions.
3. Invite suppliers. Use tender documents, a Request for Proposal (RFP) or Request for Quotation (RFQ). An RFP asks for a solution and commercial offer. An RFQ solicits prices for defined needs.
4. Receive proposals. Check proposed technical solutions, price, schedule, staff, experience, quality and risks.
5. Evaluate proposals. Score technical fit, cost, schedule, experience, quality and risk against declared criteria.
6. Negotiate. Agree scope, price, schedule, payments, responsibilities, warranty and change procedure.
7. Award. Notify the chosen supplier and prepare the agreed contract for signing.
8. Sign. Obtain formal agreement and signatures from the parties as required.
9. Administer. After placement, monitor deliverables, milestones, quality, cost, payments, changes and supplier performance.
10. Close. Record acceptance or termination, resolve obligations, settle final payments and archive records.

Typical Terms of a Contract

[Added for Understanding] Force majeure. The notes show a crossed-out “Force M…” fragment. A force-majeure clause can address specified circumstances beyond a party’s control that prevent performance. Read the agreed conditions, notice duties and consequences in the contract. See the ICC model clauses.

Contract Management

During administration, track the supplier’s deliverables and dates, inspect progress and quality, check invoices against authorized rates and milestones, update the risk and issue logs, and keep auditable records of variations, approvals and disputes. Close when applicable acceptance, payments and open obligations are settled, and archive agreements and records.

Acceptance

Acceptance is the customer’s formal confirmation that reviewed and tested products, services or outcomes meet the agreed contract requirements.

1. Define criteria. Set specific, measurable conditions during contract preparation.
2. Deliver. Supplier submits work according to the schedule.
3. Inspect and verify. Customer checks function, quality, performance, documentation and specification.
4. Test. Run agreed acceptance cases and collect evidence.
5. Identify deficiencies. List deviations, defects and incomplete requirements.
6. Correct and resubmit. Supplier fixes problems and customer retests as required.
7. Accept formally. Customer gives written confirmation once the conditions are satisfied or formally resolved.
8. Trigger the milestone. Apply payment and closure provisions.

Acceptance criteria can cover: functionality, performance, quality standards, security, user interface, documentation, technical specification compliance, successful acceptance tests, resolution of critical defects and delivery within the agreed schedule.

Provisional acceptance is temporary, often pending minor remaining items. Partial acceptance covers specified components or milestones. Final acceptance confirms that the full delivery meets the acceptance requirements. Conditional acceptance depends on stated conditions being fulfilled. The agreement defines their effects, including milestone payments and any ongoing warranty or support.

Introduction

People plan, create, verify and maintain software. Project managers use skills, communication, coordination and motivation to make that work dependable. Good tools and processes can still produce poor results when people lack the necessary support or team coordination.

Understanding Behavior

Look at how individuals react and how they work in groups. Different expectations and experience can lead two people to interpret the same request differently. Ask whether the issue arises from an individual need, a team norm, or an organizational rule before selecting an action.

Organizational Behavior: A Background

Organizational Behavior (OB) studies how people think and act at work, how groups function, and how organizational systems affect both. Software teams depend on knowledge, skills, cooperation and communication. Differences in experience, personalities, expectations, responsibilities, work styles, and cultures shape how people react to the same decision or technical change.

Organizational culture is the pattern of shared values, beliefs, policies, practices and behavior. Shared values and goals guide decisions. Clear communication enables information sharing. Teamwork enables cooperation and coordination. Leadership style shapes motivation and performance. Adaptability helps people accept changes, learn technology and solve problems. These support learning, innovation, shared responsibility, quality and customer satisfaction. Fear of failure and blame can lead to poor communication, low motivation and turnover.

Use manager–developer check-ins, clear developer–tester handoffs, two-way project team–customer communication and manager–team status updates. A vague verbal handoff can cause unclear expectations, wrong work and delay. A good handoff identifies what changed, who owns the next step, and how to confirm completion. Address conflicts through discussion, negotiation, collaboration, compromise, mediation and problem solving. People can resist changes to technology, requirements or process when the purpose or consequences are unclear. Explain the purpose, involve the affected people, provide training and gather feedback.

Selecting the Right Person for the Job

1. Identify required skills and role outcomes. Compare candidates or staff with a skills matrix covering knowledge, experience, technical and communication ability, problem solving, and teamwork.
2. Use structured interviews, work samples or evidence from prior work. Match roles such as developer, tester, UI designer or project coordinator to capability and capacity.
3. Check people’s skill levels and their ability to work in the team. Give complex tasks to qualified people, or pair less experienced staff with someone who can support them. Agree expectations and responsibilities.

Matching people to roles can improve productivity, quality, speed and resource use while reducing errors.

Instruction in the Best Methods

1. Define standard procedures and development practices, including coding, documentation and definition of done.
2. Train people on tools and technology and explain the project’s guidelines.
3. Demonstrate effective methods, ask the team to practice, and encourage appropriate tool use.
4. Observe performance, give feedback and revise the instructions when evidence warrants it.

Frederick Taylor’s scientific management linked selection, systematic training and study of work methods. For software, apply the training principle through demonstrations and evidence-based feedback while leaving room for engineering judgment. Training and feedback promote consistent work, reduce rework and help people learn new technology. Pair a new tester with an experienced engineer to demonstrate how requirements become reproducible acceptance tests, then review the new tester’s independent examples.

Good performance is more likely when the right person has an effective method, the support to use it and motivation to follow through. This sequence links selection and training to commitment and project success.

Motivation

Motivation is the drive and willingness to put effort toward a goal. Managers use job design, recognition and support to encourage commitment, creativity, productivity and responsibility. Job satisfaction is how positively a person feels about the job. Performance depends on motivation, ability, and a supportive work environment with time, information and tools. A motivated engineer can still be blocked by missing access or overloaded reviewers.

Use achievable goals, recognition and rewards, career growth, participation in decisions, constructive feedback, empowerment and a supportive environment. Fair pay and benefits, recognition, advancement and learning, flexible hours and manageable workload, interesting work, safe conditions and supportive colleagues and managers, and job security support satisfaction.

• Connect code to impact. Show who benefits and how the work supports a business goal.
• Grant technical autonomy. Let engineers estimate and choose implementation within agreed constraints.
• Tackle technical debt. Make time for refactoring and maintenance.
• Protect focus time. Reduce avoidable meetings and context switching.
• Measure outcomes. Use code quality and user value as evidence of performance. Lines of code and hours measure activity.

Common theory anchors. Maslow groups needs from basic and safety needs through belonging, esteem and self-actualization. Herzberg distinguishes hygiene factors (e.g. pay, conditions and policy) that affect dissatisfaction from motivators (achievement, recognition, responsibility and growth). McGregor’s Theory X and Theory Y describe contrasting managerial assumptions about whether people need close control or can exercise self-direction. Use these as explanatory frameworks in cases.

The Oldham–Hackman Job Characteristics Model

J. Richard Hackman and Greg R. Oldham link job design to critical psychological states and expected work outcomes. The model is commonly called the Hackman–Oldham Job Characteristics Model (JCM).

[Corrected] MPS uses multiplication for feedback. Multiply the average of the first three scores by autonomy, then by feedback. The addition sign before feedback in the notes gives a different and incorrect result.

With scores 5, 4, 6, 3 and 4, meaningfulness average = (5 + 4 + 6) ÷ 3 = 5, and MPS = 5 × 3 × 4 = 60. Outcomes the model anticipates include higher internal motivation, job satisfaction and quality, and lower absenteeism and turnover. Individual and work context affect the outcome.

Strategic application. Give a developer varied, challenging work, ownership of a whole feature, discretion over implementation and regular evidence of results. Job design can support organizational quality and user-value objectives.

Working In Groups

A work group is people interacting around work. Members exchange information, divide tasks and develop norms about communication, trust, cooperation and conflict. For example, a developer and tester can agree how to reproduce and prioritize reported defects. Psychological safety makes it easier to ask questions and raise defects early.

Becoming A Team

A team adds shared purpose, complementary skills, interdependent tasks, agreed norms and mutual accountability. Define roles, decision rights, shared goals, handoffs, and ways to handle disagreement. Tuckman’s stages illustrate how the group can develop that capacity.

[Corrected] Level of analysis. Forming through adjourning describe group and team development. Organizational-level behavior examines culture, structure, policies and incentives. The notes place the stages under the organization level.

Teams can revisit earlier stages when membership or goals change. Clear roles and visible commitments reduce social loafing. Invite independent views before discussing a high-impact decision to reduce groupthink.

Decision Making

[Extra from Syllabus sheet] Structured decision process and methods. The notes mention group decisions and leadership’s role.

Decision making involves defining the problem, gathering evidence, selecting criteria, generating options, comparing tradeoffs and risks, choosing through agreed authority, communicating the decision, implementing it and reviewing the result. Use individual decisions for urgent delegated matters, consultation to collect specialist input, voting for suitable shared choices, and consensus when broad commitment matters. Record the decision, rationale, assumptions and owner.

Leadership

Leadership is the ability to influence and guide people toward project objectives. Leaders provide direction, motivate, listen, communicate, resolve conflicts, make or enable decisions, build teams and help people adapt. Autocratic/directive leadership may suit an emergency, participative leadership draws on expertise and builds ownership, and delegative leadership fits mature teams with clear interfaces. A situational approach adapts to urgency, capability and responsibility.

Clear direction helps people understand priorities. Motivation and cooperation improve execution, and better decisions or constructive conflict resolution can improve project outcomes. During a process change, explain its purpose, involve the people doing the work, and review adoption and feedback.

Organizational Structures

[Extra from Syllabus sheet]

Structure determines where people report, who allocates resources, and who can settle project priorities. Consider an engineer shared across several projects.

Stress

[Extra from Syllabus sheet] Dedicated treatment of work-related stress.

Common stressors include unrealistic deadlines, ambiguity, conflicting requests, understaffing, interruptions, long hours, poor tools and hostile interactions. Watch for persistent overtime, more defects, withdrawal, absence and burnout. Address causes with priorities, realistic workload and staffing, role clarity, focus time, reasonable breaks, support and agreed escalation.

Health and Safety

[Extra from Syllabus sheet]

Health and safety includes ergonomics (adjustable seating, display height, lighting and rest), psychosocial hazards, safe electrical setups and workplaces, reporting incidents and near misses, and emergency readiness. Assess hazards, assign responsibility, explain procedures and review controls and reports.

Case Studies

[Extra from Syllabus sheet]

In a case answer, name the visible issue, link it to a course concept, propose an action and identify evidence that the action helped.

Project Evaluation and Communication

[Extra from Syllabus sheet] Standalone evaluation and communication planning. The notes cover evaluation cases, meetings and information systems.

Evaluate strategic fit and feasibility before approval, compare delivery and forecasts with baselines during execution, and evaluate outcomes after implementation. Ask whether outputs met acceptance criteria, whether cost, schedule and quality targets were achieved, whether users adopted the system, and whether expected benefits emerged. Separate observed results from forecasts and document uncertainties and follow-up.

Output versus outcome. A usable exam portal is an output. Fewer scheduling errors, faster results and improved student access are outcomes. At closeout assign a benefits owner and measurement date, since adoption and sustained benefits can take time.

Use a communication plan with audience, purpose, information, frequency, channel, owner and escalation rule. Keep a decision log and an action log. Communicate exceptions early with impacts, options and a decision deadline. Sensitive information goes to authorized recipients.

Project Review Meetings

A review meeting formally evaluates progress or outcomes, compares actual versus planned results, identifies risks, issues and delays, reviews deliverable quality, and agrees on solutions and actions to keep performance aligned with objectives, schedule and budget.

Preparation. Set agenda, gather planned and actual data, identify decisions and invite the project manager, relevant team members, developers, testers/QA, customer and senior management as appropriate. Conduct. Review status, clarify risks and issues, and encourage input. Evaluate. Compare actual results against milestones, budget, quality and objectives. Decide actions. Assign owners and deadlines. Follow up. Circulate minutes and check actions to closure.

Reviews improve communication, early problem detection, decision quality, deliverable quality, accountability and transparency. They help reduce risk and delay and improve the chances of finishing within time and budget.

Project Management Information Systems (PMIS)

A Project Management Information System combines tools, technologies, applications and procedures to collect, process, store and distribute project information for planning, monitoring, control and decisions. Tracks scope, schedule, cost, budget, resources, risks, quality, changes, deliverables and overall performance.

Objectives. Support planning and scheduling, monitor against the approved plan, track budget and resource utilization, identify deliverables, deviations, risks and potential delays, improve stakeholder communication, maintain accurate and consistent records, support managers’ decisions, and generate performance reports.

1. Data sources
2. MIS processing
3. Information outputs
4. Managerial decisions

Establish the baseline → collect actuals → compare performance → analyze deviations → report → take corrective action → update forecasts or approved plans. Example tools include Microsoft Project for schedules, Jira and Trello for work tracking, and Microsoft Power BI for dashboards. Integrate tools and clarify the authoritative system for each metric.

Applications and tradeoffs. Use PMIS for milestones, expenditure, utilization, collaboration, audits, decision support and consistent records. It improves access, traceability and reporting speed. Poor data, fragmented tools, configuration cost, training needs and permissions issues reduce effectiveness. Compared with scattered spreadsheets and emails, a shared PMIS can consolidate up-to-date information with controlled access, at the cost of setup and maintenance.

Example. Update testing status in Jira, import approved actual costs and work-package data, and compare them with the baseline in a dashboard. If the next milestone is slipping, the PM and QA lead use the evidence to remove the bottleneck and track recovery.

Web-Enabled Project Management

[Extra from Syllabus sheet]

Use browser-accessible collaborative tools for task boards, schedules, issue and risk logs, document versions, approvals, discussions, dashboards, notifications and remote access. For example, distributed teams share a live milestone board while restricting financial information to authorized roles.

Benefits include asynchronous collaboration, faster updates, a shared source of status and visibility across locations. Consider connectivity, access permissions, availability, privacy, vendor dependence, data exports, incident recovery and notification overload. Define owners, approval workflows, reporting norms and backup/export procedures.

Implementation and Handover

[Extra from Syllabus sheet] Implementation appears in the Module 7 title and a course outcome.

Verify release and operational readiness, including acceptance criteria, environment, migration and reconciliation, training, support ownership, monitoring, communications and rollback. Choose direct cutover (switch at once), parallel running (old and new coexist temporarily), phased rollout (introduce functions or locations gradually), or pilot (start with a representative group and learn before wider rollout). Assess exposure, operational capacity and recovery time.

Confirm readiness and approval → migrate or deploy → verify operation → monitor and support → hand over runbooks, credentials via approved channels, support contacts, configuration and unresolved items → confirm operational ownership. Establish how benefits will be measured after handover.

Project Termination and Closeout

[Extra from Syllabus sheet]

Projects may close after successful delivery or terminate early because of strategic change, budget cuts, failed feasibility, missing benefits or unacceptable risk. Common textbook termination modes are extinction (work ends), addition (a new organizational unit continues the work), integration (outputs or staff move into existing operations), and starvation (resources progressively withdrawn). Formal closure records the decision and obligations.

1. Obtain authorized closure or termination decision. Record reason, status and accepted, rejected or unfinished deliverables.
2. Obtain acceptance as applicable and hand over software, documents, access, support ownership and remaining actions.
3. Close supplier agreements, invoices and financial accounts. Check warranty, license, retention, and outstanding commitments.
4. Release or reassign resources. Archive plans, change logs, tests, acceptance records, decisions, baselines and final reports.
5. Hold a post-project review. Record planned versus actual results, lessons and recommended actions with owners. Set dates for future benefits evaluation.

Guest Lecture by Industry Experts or R&D Organizations

[Extra from Syllabus sheet]

The course sheet reserves this module for a guest lecture and leaves the subject to the speaker. Use the lecture to connect a concrete project problem with the estimation, risk, scheduling, monitoring, team or closeout methods taught elsewhere in the course.

For revision, record the project and its objective, the challenge and constraints, the options considered, the action taken, and the evidence of the result. For example, a speaker might explain a schedule recovery decision using the baseline, a bottleneck on the critical path and the schedule before and after the intervention. This example shows how to analyze a lecture case.