Software project management and estimation

In short

Software project management is the planning, estimating, scheduling, staffing, tracking and risk control needed to deliver software of agreed scope and quality within time and cost. Estimation is its hardest part: size (LOC or function points) is estimated first, then effort and cost through models such as COCOMO, Putnam's software equation or expert/Delphi judgement, and only then a schedule through CPM/PERT or Agile velocity. It is examined in every Indian university software engineering paper and in GATE CS (function points, COCOMO, PERT, CMM levels carry direct marks), and used daily by project managers, delivery managers, scrum masters and pre-sales teams at TCS, Infosys, Wipro, HCLTech, LTIMindtree, Cognizant and Accenture India, where a fixed-price bid is literally an estimate with money on it. The recurring theme in both exams and interviews is that estimates are ranges derived from measured history, not single numbers pulled from confidence.

Explained

What software project management covers

• The four P's (Pressman): *People* (the most important resource), *Product* (scope and decomposition), *Process* (the framework chosen), *Project* (the plan and its tracking).
• Core activities: feasibility and scoping → size/effort/cost estimation → scheduling and staffing → risk management → configuration management → monitoring and control → quality assurance → closure and post-mortem.
• Software Project Management Plan (SPMP, IEEE 1058 style): objectives, deliverables, WBS, estimates and basis of estimate, schedule, staffing plan, risk register, communication plan, SCM plan, quality plan, assumptions and exclusions.
• Why software estimation is hard: software is invisible and non-repeatable, requirements change, productivity varies several-fold between individuals, and there is no "material quantity" to measure as in civil works.
• The cone of uncertainty: at concept stage estimates can be off by about 4× either way; the range narrows as requirements, design and code firm up. Hence estimate as a range plus confidence, and re-estimate at each milestone.
• Triple constraint: scope, time, cost (with quality at the centre) — fixing all three makes the estimate a wish, not an estimate.
• Work Breakdown Structure (WBS): hierarchical decomposition of deliverables into *work packages* small enough to estimate and own (commonly 8-80 hours). Types: product-based, process-based, hybrid. The WBS is the spine of estimation, scheduling and tracking.

Size estimation: LOC and Function Points

• Lines of Code (LOC/KLOC): simple and automatically countable, but language-dependent, unknown before design, and it penalises concise code. Count only delivered source lines; state whether comments and blanks are included.
• Function Point Analysis (FPA, IFPUG): measures functionality from the user's view, so it is language-independent and available from requirements. Five function types are counted and weighted *simple / average / complex*:
  • External Inputs (EI) 3/4/6 · External Outputs (EO) 4/5/7 · External Inquiries (EQ) 3/4/6 · Internal Logical Files (ILF) 7/10/15 · External Interface Files (EIF) 5/7/10.
• Sum of weighted counts = Unadjusted FP (UFP). Then 14 General System Characteristics (data communications, distributed processing, performance, heavily used configuration, transaction rate, online data entry, end-user efficiency, online update, complex processing, reusability, installation ease, operational ease, multiple sites, facilitate change), each rated 0-5, give the Value Adjustment Factor.
• Backfiring / gearing factor: LOC = FP × average LOC per FP for the language (roughly 320 for Assembly, 128 C, 107 COBOL, 53 Java, 40-50 C#, 26-30 Python — published tables such as Capers Jones' vary and are revised, so quote the source).
• Variants: Mark II FP, COSMIC Function Points (ISO/IEC 19761, better for real-time), use-case points, object points (COCOMO II application composition).
• Other product metrics: Halstead's volume and effort from operator/operand counts; cyclomatic complexity for module-level risk.

Effort, cost and the COCOMO family

• Approaches: (a) *empirical/algorithmic models* (COCOMO, Putnam); (b) *expert judgement* and Delphi / Wideband Delphi (anonymous rounds until convergence — removes the loudest-voice bias); (c) *estimation by analogy* with completed projects; (d) *bottom-up (activity-based)* summing WBS work packages; (e) *top-down* allocation by phase percentages; (f) *price-to-win* (not an estimation technique, a commercial decision — the classic exam criticism).
• Three-point estimate: beta/PERT mean (a + 4m + b)/6, or triangular (a + m + b)/3, applied per work package to absorb optimism.
• COCOMO (Boehm, 1981) — three modes by project type: *Organic* (small, familiar, in-house, ≤ ~50 KLOC), *Semi-detached* (medium size, mixed experience), *Embedded* (tight hardware/regulatory constraints).
• Basic COCOMO gives effort from size only (rough, order-of-magnitude). Intermediate COCOMO multiplies by an Effort Adjustment Factor (EAF) = product of 15 cost drivers in four groups — *product* (RELY, DATA, CPLX), *computer* (TIME, STOR, VIRT, TURN), *personnel* (ACAP, AEXP, PCAP, VEXP, LEXP), *project* (MODP, TOOL, SCED); each rated very low → extra high, nominal = 1.00. Detailed/Complete COCOMO applies drivers phase-wise (plan/requirements, design, code and unit test, integration and test) and module-by-module.
• COCOMO II (1995-2000) replaces it for modern work: three sub-models (application composition using object points, early design using unadjusted FP and 7 early-design multipliers, post-architecture using 17 effort multipliers), size counted as new + equivalent reused/modified code, and an exponent driven by five scale factors — PREC (precedentedness), FLEX (development flexibility), RESL (architecture/risk resolution), TEAM (team cohesion), PMAT (process maturity, tied to CMM/CMMI). Exponent > 1 means diseconomy of scale: double the size, more than double the effort (communication paths grow as n(n−1)/2).
• Putnam's model / SLIM: effort varies roughly as the inverse *fourth power* of the schedule, so compressing a schedule is extremely expensive; it also implies an *impossible region* below which no amount of staff delivers.
• Brooks's law: "Adding manpower to a late software project makes it later" — training, partitioning limits and communication overhead dominate. Rayleigh staffing curve: staff ramps up, peaks around design/coding, tapers in test; square-wave staffing wastes effort.
• Team structures: *chief-programmer (hierarchical)* — fast decisions, single point of failure; *democratic/egoless* — good for research and small expert teams, slow on large ones; *matrix/mixed control* — the usual Indian services model, with practice/competency pools lending people to delivery.
• Model limitations (exam-standard): calibration is from old, mostly US, mostly waterfall data; COCOMO needs size, which is what you don't know early; it does not model COTS/low-code assembly, iterative rework, or distributed offshore-onsite coordination well. Hence organisations calibrate the constants on their own historical database — which is exactly what CMMI level 4 asks for.

Scheduling, tracking and control

• Steps: WBS → activity list → dependency (precedence) network → duration estimates → CPM/PERT analysis → resource levelling → baseline → track.
• Gantt (bar) chart: activities against a calendar, with milestones; shows *what and when*, poor at showing dependencies. Network diagrams (activity-on-node) show logic and the critical path.
• CPM: deterministic durations; forward pass gives Earliest Start/Finish, backward pass Latest Start/Finish; total float (slack) = LS − ES = LF − EF; the critical path is the longest path with zero float — delay there delays the project. Crashing shortens it at extra cost.
• PERT: probabilistic, three time estimates per activity, uses the beta mean and standard deviation; lets you state a probability of meeting a date. Limitation: it ignores near-critical paths, so it is optimistic (merge-event bias).
• Milestones and reviews: deliverable-based, binary (done/not done) — avoids "90% complete for six weeks".
• Earned Value Management (EVM): converts physical progress into money so schedule and cost are measured on one scale — Planned Value (BCWS), Earned Value (BCWP), Actual Cost (ACWP), with SPI and CPI indices and an EAC forecast.
• Other tracking tools: burndown/burn-up charts, cumulative flow, defect arrival and backlog trends, effort variance, schedule variance, size variance, Cost of Quality.
• Metric categories: *process* metrics (improve the organisation), *project* metrics (control this project), *product* metrics (quality of the artefact); defect density per KLOC or per FP, review effectiveness, rework percentage, productivity in FP per person-month.

Risk management and configuration management

• Risk types: project (schedule, cost, staffing), technical (design, implementation, interface, performance), business (market, strategy, management, budget); also known/predictable/unpredictable risks.
• Boehm's top risks (still asked): personnel shortfalls, unrealistic schedules and budgets, wrong functionality, wrong user interface, gold plating, continuing requirements change, shortfalls in externally furnished components or outsourced tasks, real-time performance shortfalls, straining computer-science capability.
• Process: identification (checklists, taxonomy) → analysis (probability × impact → risk exposure) → prioritisation (risk table, top-10 list) → RMMM plan (mitigation, monitoring, management) with triggers and owners → periodic review. Responses: avoid, transfer (insurance, penalty clauses), mitigate, accept (with contingency reserve).
• Software Configuration Management (SCM): identify configuration items → version control → baselines → change control through a Change Control Board (ECR/ECO) → status accounting → configuration audit. Prevents regression, lost work and unreproducible builds; underpins release and change management.
• Change and scope control: every change is re-estimated (impact analysis) before acceptance; uncontrolled acceptance is scope creep, the commonest cause of fixed-price losses.

Agile estimation and tracking

• Story points: unitless relative size combining effort, complexity and uncertainty, usually on a Fibonacci-like scale (1, 2, 3, 5, 8, 13, 20/21); planning poker is Delphi in card form, with t-shirt sizing or affinity estimation for large backlogs.
• Velocity: story points completed per sprint, averaged over the last 3-5 sprints; remaining sprints = remaining backlog points ÷ velocity. Velocity is a *team's* measure and must never be compared across teams or used as a productivity target.
• Ideal days vs story points: ideal days are easier to explain but invite confusion with calendar days; points avoid re-estimation when a different person picks up the story.
• Release/roadmap planning: fixed scope → ask for date; fixed date → ask what scope fits. Burndown (work remaining) and burn-up (scope plus done) charts track it; capacity planning accounts for leave, support load and a focus factor.
• Where Agile and classical estimation meet in Indian practice: sprint-level story points for execution, FP or COCOMO-style sizing for the commercial bid and for fixed-price "Agile at contract level" engagements.

Standards, contracts and Indian practice

• CMMI (Capability Maturity Model Integration, SEI → CMMI Institute → ISACA): maturity levels 1 *Initial*, 2 *Managed*, 3 *Defined*, 4 *Quantitatively Managed*, 5 *Optimizing*. Project planning, project monitoring and control, estimation, risk management and measurement are explicit practice areas. Indian IT services firms were early and heavy adopters — many of the world's first Level 5 assessed units were in India (TCS, Infosys, Wipro, HCL and others); appraisal versions and names changed with CMMI v2.0/v3.0, so check the current model before quoting.
• Other frameworks and standards: ISO 9001:2026 (QMS; succeeded the 2015 edition on 16 September 2026), ISO/IEC 12207 (software life-cycle processes), ISO/IEC 15288 (systems), ISO/IEC 33001 series (process assessment, successor to SPICE/15504), ISO/IEC 25010 (product quality model), ISO/IEC 20926 (IFPUG FP counting), ISO 21500/21502 and PMI's PMBOK Guide (7th edition, principles-and-domains based) plus PRINCE2 and the PMP/CAPM/PSM/CSM certifications Indian managers hold. ISO/IEC 27001 and ISO 22301 cover the security and continuity clauses now standard in client contracts.
• Contract models: *fixed price* (vendor carries estimation risk; needs frozen scope and a change-request process), *time and materials* (client carries risk), *fixed capacity / managed team*, *outcome or transaction based*. Effort-rate quoting uses person-month or per-hour rates; loaded cost per person-month in India typically runs around ₹1-3 lakh depending on city, skill and onsite/offshore mix, while billing rates are higher — figures vary by year and contract, so use the organisation's own rate card.
• Indian legal and compliance context: Information Technology Act 2000 with the 2008 amendment (s.43A/72A on data; electronic evidence is separate — Evidence Act s.65B, now s.63 of the Bharatiya Sakshya Adhiniyam 2023), the Digital Personal Data Protection Act 2023 (Rules notified 13 November 2025; consent, retention and breach-intimation duties apply from 13 May 2027, so projects running past that date must budget the work now), Indian Contract Act 1872 for SOW/MSA terms, Copyright Act 1957 for software IP and licence compliance, GST on services, labour and shops-and-establishments rules for shift and overtime planning, and SEZ/STPI conditions for export units. Government projects follow GFR 2017 and the GeM/CPPP tender route, often with earnest money, liquidated-damages and MeitY/STQC quality clauses.

Key points

• Estimation order - size → effort → cost → schedule → staffing; never start from a deadline and work backwards.
• Function point - size measured from user-visible functionality, language-independent, usable at requirements stage.
• VAF - 0.65 + 0.01 × ΣFi over 14 GSCs, so the adjustment range is 0.65 to 1.35 (±35%).
• Basic COCOMO - effort from KLOC and mode only; Intermediate adds 15 cost drivers (EAF); Detailed applies them phase-wise.
• COCOMO modes - organic (a=2.4, b=1.05), semi-detached (3.0, 1.12), embedded (3.6, 1.20); intermediate uses a = 3.2 / 3.0 / 2.8.
• COCOMO II - exponent E = 0.91 + 0.01 × Σ(5 scale factors) with 17 post-architecture multipliers; models reuse and process maturity.
• Diseconomy of scale - exponent b > 1 means effort grows faster than size because communication paths grow as n(n−1)/2.
• Putnam's equation - effort varies roughly as 1/td⁴, so schedule compression is punitively expensive.
• Brooks's law - adding people to a late project makes it later (ramp-up, repartitioning, communication).
• Rayleigh curve - staffing should ramp up and taper, not be flat; peak near design/code.
• Critical path - longest path through the network, zero float; total float = LS − ES.
• PERT - te = (a + 4m + b)/6, σ = (b − a)/6; gives a probability for a target date but is optimistic at merge points.
• EVM - SPI = EV/PV (schedule), CPI = EV/AC (cost); both < 1 means late and over budget; EAC = BAC/CPI.
• Risk exposure - probability × impact (in rupees or days); drives the top-10 risk list and the RMMM plan.
• SCM baseline - a reviewed, frozen configuration changed only through the Change Control Board; prevents scope creep and regression.
• Delphi/planning poker - anonymous, iterated expert estimation; removes authority bias and converges on a range.
• Velocity - team-specific points per sprint; a planning input, never a cross-team productivity target.
• CMMI levels - 1 Initial, 2 Managed, 3 Defined, 4 Quantitatively Managed, 5 Optimizing; levels 4-5 require a calibrated measurement base.

Formulas and examples

Example 1 — Function points → LOC → basic COCOMO → cost. A college ERP module is counted as: 24 EI (average), 16 EO (average), 12 EQ (simple), 6 ILF (average), 3 EIF (average); ΣFi = 42.

• UFP = 24×4 + 16×5 + 12×3 + 6×10 + 3×7 = 96 + 80 + 36 + 60 + 21 = 293
• VAF = 0.65 + 0.01×42 = 1.07 → FP = 293 × 1.07 = 313.5 FP
• Java at 53 LOC/FP → 313.5 × 53 ≈ 16,616 LOC = 16.6 KLOC
• Organic mode: E = 2.4 × (16.6)^1.05 = 2.4 × 19.10 = 45.9 person-months
• D = 2.5 × (45.85)^0.38 = 2.5 × 4.279 = 10.7 months; P = 45.85/10.7 = 4.3 persons
• At ₹1.2 lakh loaded cost per person-month: 45.85 × 1.2 = ₹55.0 lakh, i.e. ₹55,02,000/313.5 ≈ ₹17,550 per FP
• Implied productivity = 16,616/45.85 ≈ 362 LOC per person-month (≈ 6.8 FP/PM)

Example 2 — Intermediate COCOMO, embedded. A 32 KLOC telecom firmware project; drivers: RELY very high 1.40, CPLX high 1.15, ACAP high 0.86, TOOL low 1.10, rest nominal.

• EAF = 1.40 × 1.15 × 0.86 × 1.10 = 1.523
• Nominal effort = 2.8 × 32^1.20 = 2.8 × 64 = 179.2 PM → E = 179.2 × 1.523 = 272.9 PM
• D = 2.5 × (272.9)^0.32 = 2.5 × 6.019 = 15.0 months; average team = 272.9/15.0 ≈ 18 persons
• Note: some texts compute D from the *nominal* effort; state which convention you use. Compare with basic COCOMO embedded (3.6 × 64 = 230.4 PM) — the drivers add about 18%.

Example 3 — PERT and CPM. Network A → B → D and A → C → D (weeks):

• Path A-B-D = 4+7+5 = 16 weeks (critical); path A-C-D = 4+5+5 = 14 weeks → total float of C = 2 weeks
• σ²path = 1.78 + 2.78 + 1.78 = 6.34 → σ = 2.52 weeks
• Probability of finishing in 19 weeks: Z = (19 − 16)/2.52 = 1.19 → ≈ 88%. For an 85% commitment date: 16 + 1.04×2.52 ≈ 18.6 weeks.

Example 4 — Earned value at a review. BAC = ₹80 lakh over 20 weeks. At week 10: PV = ₹40 lakh, EV = ₹34 lakh, AC = ₹38 lakh.

• SV = 34 − 40 = −₹6 lakh (behind); CV = 34 − 38 = −₹4 lakh (over)
• SPI = 34/40 = 0.85; CPI = 34/38 = 0.895; % complete = 34/80 = 42.5%
• EAC = 80/0.895 = ₹89.4 lakh → overrun ≈ ₹9.4 lakh; ETC = 89.4 − 38 = ₹51.4 lakh
• Schedule forecast ≈ 20/0.85 = 23.5 weeks. Action: control scope, improve throughput, or re-baseline with the client.

Example 5 — Putnam trade-off and Agile velocity. (a) L = 50,000 LOC, Ck = 8,000. At td = 1.5 years: K = 50,000³ ÷ (8,000³ × 1.5⁴) = 48.2 person-years (≈578 PM). At td = 2.0 years: K = 15.3 person-years (≈183 PM) — a 33% longer schedule cuts modelled effort by about 68%; the fourth-power term makes crash schedules uneconomic (real projects are less extreme, but the direction holds). (b) Backlog 520 story points; last three sprints delivered 45, 52, 47 → velocity = 48 points/sprint → 520/48 = 10.8 → 11 two-week sprints ≈ 22 weeks. If velocity is quoted as a range (45-52), the honest answer is 10-12 sprints, not 10.8.

Where it is used

• Indian IT services delivery: fixed-price bids and SOWs at TCS, Infosys, Wipro, HCLTech, Tech Mahindra, LTIMindtree and Cognizant India use FP or story-point sizing, rate cards and CMMI-defined estimation procedures; pre-sales solutioning teams own the basis of estimate.
• Product and GCC engineering: release planning, capacity and velocity tracking at global capability centres in Bengaluru, Hyderabad, Pune and Chennai (banking, telecom, SaaS, semiconductor software).
• Government and public digital projects: UIDAI/Aadhaar, NPCI's UPI, GSTN, IRCTC and CRIS (Railways), NIC and state e-governance programmes — tendered through GeM/CPPP under GFR 2017 with milestone payments, liquidated damages and STQC/MeitY quality gates.
• BFSI and regulated software: RBI/SEBI/IRDAI-driven change programmes where risk registers, audit trails, DPDP Act 2023 and ISO/IEC 27001 controls are explicit project work packages.
• Job roles that test this directly: project manager, delivery/engagement manager, scrum master, technical programme manager, PMO analyst, estimation/metrics (SEPG) analyst, and tech leads asked to size features; tools include Jira, Azure DevOps, MS Project, Primavera P6 and SPR/SLIM/COCOMO-based estimators.
• Exams and certifications: university software engineering papers, GATE CS, PMP/CAPM, PRINCE2, CSM/PSM, Certified Function Point Specialist.

Interview questions

• Q: Why is a function point estimate preferred to LOC for a fixed-price bid? A: FP can be counted from the requirements, before any code or language choice exists, and is comparable across technologies, whereas LOC is known reliably only after coding and varies with language and coding style.
• Q: What does the exponent b > 1 in COCOMO mean physically? A: Diseconomy of scale — as size grows, integration, communication and management overhead grow faster than the code, so effort per KLOC rises.
• Q: Basic versus intermediate versus detailed COCOMO? A: Basic uses only size and mode; intermediate multiplies by an EAF from 15 cost drivers; detailed applies the drivers phase-wise and module-wise for more accuracy.
• Q: Can you halve a 12-month schedule by doubling the team? A: No — Putnam's relation makes effort rise roughly with the inverse fourth power of time, and Brooks's law says ramp-up, repartitioning and communication overhead can make a late project later; practical compression is limited to about 75% of nominal.
• Q: SPI = 1.05 and CPI = 0.80 — what is happening? A: The project is ahead of schedule but significantly over cost, typically from overtime, extra staff or a bad rate assumption; forecast EAC = BAC/0.80, a 25% overrun.
• Q: What is total float and why does it matter? A: The time an activity can slip without delaying the project (LS − ES); zero-float activities form the critical path and get management attention and the best people.
• Q: Why is PERT's probability estimate usually optimistic? A: It computes variance only along the single critical path and ignores near-critical parallel paths that can become critical (merge-event bias).
• Q: Why are story points unitless and not in hours? A: They express relative size and uncertainty, so they stay valid whoever picks up the story, and they are converted to time only through the team's measured velocity.
• Q: How would you estimate a project with no historical data? A: Use Wideband Delphi with several experts plus analogy to the nearest known system, give a three-point range, decompose to work packages for a bottom-up cross-check, and re-estimate at the first milestone once actuals exist.
• Q: What is the difference between a risk and an issue? A: A risk is a possible future event with a probability and impact, managed by an RMMM plan; an issue has already occurred and needs corrective action and possibly re-baselining.
• Q: What does CMMI level 4 require that level 3 does not? A: Quantitative management — processes measured statistically against defined baselines and models, so estimates are calibrated on the organisation's own data rather than textbook constants.
• Q: A client wants fixed scope, fixed date and fixed price. What do you do? A: State the constraint explicitly: offer a fixed price on a frozen scope with a priced change-request process, or a fixed date with prioritised scope (MoSCoW), plus a contingency reserve justified by the risk register.

Common mistakes

• Treating an estimate as a commitment: quoting a single number with no range, assumptions or basis of estimate, then being held to it.
• Mixing up COCOMO coefficient sets — using the basic a (2.4/3.0/3.6) in the intermediate formula instead of 3.2/3.0/2.8, or forgetting that KLOC is thousands of lines, not lines.
• Forgetting the EAF, or multiplying the 15 cost drivers when most are nominal 1.00 and only the non-nominal ones change the product.
• Computing VAF wrongly: it is 0.65 + 0.01 ΣFi over 14 characteristics (range 0.65-1.35), not a percentage or a sum of weights.
• Confusing effort with duration: 45 person-months is not 45 months, and dividing effort by any number of people ignores Brooks's law and the Rayleigh curve.
• In CPM/PERT, declaring the shortest path critical, missing a second critical path, or adding standard deviations instead of variances.
• Reporting progress as "percent complete" by effort spent rather than by earned value or completed deliverables — the classic 90% syndrome.
• Using velocity to compare or rank teams, which inflates point estimates and destroys the measure.

Related topics

SDLC and Agile · Requirements engineering and UML · Software testing basics · Clean code and code reviews · Software architecture: monoliths and microservices · Git and version control