Software Engineering covered how software is built; Software Project Management covers how a project is planned, estimated, tracked and delivered on time, within budget and to quality. It is the subject behind every sprint plan, roadmap, status report and post-incident review, and it becomes more important at senior and lead levels. This article revisits the five units of the JNTUK course.
Unit 1: Introduction and project planning
What is a project
A project is a temporary effort with a defined goal, start and end, unique outcomes and limited resources. Software projects are hard because the product is invisible, requirements change, estimation is uncertain and complexity is high. Many fail from unclear requirements, optimistic schedules and poor communication.
The triple constraint
| Constraint | Meaning |
|---|---|
| Scope | What is delivered |
| Time | The schedule |
| Cost | Budget and resources |
| Quality (the centre) | Suffers when the others are squeezed |
Brooks’s law: adding people to a late project makes it later, because of training and communication overhead.
Management activities and the life cycle
The project manager plans, organises, staffs, directs, monitors and controls. Software project phases: initiation, planning, execution, monitoring and control, closure. Process models (waterfall, incremental, spiral, Agile) were covered in Software Engineering; choosing a model depends on requirement stability and risk.
Project selection and the business case
Before starting, projects are evaluated using cost-benefit analysis, NPV, ROI and payback period (see Managerial Economics), and strategic fit. A feasibility study covers technical, economic, operational and schedule feasibility. Stakeholders (sponsor, customer, users, team, operations) are identified, and a project charter and statement of work record goals and authority.
Project planning
A project plan contains scope, work breakdown, schedule, resources, budget, risks, quality plan, communication plan and change control. The Work Breakdown Structure (WBS) splits the project into manageable deliverables and tasks, down to work packages that can be estimated and assigned.
Today: a roadmap, a Jira epic breakdown and a project charter are these artefacts under modern names. Brooks’s law is why adding more engineers to a late migration rarely helps, and why scope trimming often does.
Unit 2: Estimation and scheduling
Estimation
Estimation is hard early and improves as the project proceeds (the cone of uncertainty).
| Technique | Idea |
|---|---|
| Expert judgement and analogy | Compare with similar past projects |
| Delphi method | Experts estimate anonymously, then discuss, over several rounds |
| Three-point (PERT) estimate | E = (Optimistic + 4 × Most likely + Pessimistic) / 6 |
| Lines of code / function points | Size measures; function points count inputs, outputs, inquiries, files and interfaces, adjusted for complexity |
| COCOMO (basic) | Effort = a × (KLOC)^b person-months; development time = c × (Effort)^d. Modes: organic (small, familiar), semi-detached, embedded |
| COCOMO II | Uses cost drivers and scale factors |
| Use-case points, story points, planning poker | Agile relative estimates |
Example (organic mode, with a = 2.4, b = 1.05): a 32 KLOC project needs about 2.4 × 32^1.05 ≈ 2.4 × 38 ≈ 91 person-months. Agile teams estimate in story points and measure velocity (points finished per sprint), then forecast by dividing remaining points by velocity. Common errors: forgetting testing and integration, ignoring risk and being overly optimistic.
Scheduling
| Tool | Use |
|---|---|
| Gantt chart | Tasks as bars on a timeline |
| Activity network (precedence diagram) | Tasks and dependencies |
| Critical Path Method (CPM) | Compute earliest and latest start and finish; float (slack) = latest − earliest; the critical path is the longest path with zero float and decides the project length |
| PERT | CPM with probabilistic durations |
| Resource levelling and smoothing | Fix over-allocated people |
| Crashing and fast-tracking | Shorten the schedule by adding resources or overlapping tasks |
Dependencies: finish-to-start (the usual), start-to-start, finish-to-finish. Milestones mark key points.
A small example: tasks A (3 days) then B (4 days) and C (2 days) in parallel, then D (2 days), where D needs both B and C. Path A-B-D = 9 days, path A-C-D = 7 days, so A-B-D is critical and C has 2 days of float.
Budgeting
Cost = people (usually the main part), infrastructure and cloud, tools and licences, travel and contingency reserve.
Today: sprint planning with story points, velocity charts and burn-down charts are the Agile versions of these tools. Roadmaps in Jira or Linear show dependencies and critical-path-like thinking. Cloud costs are now part of the project budget and need estimates too.
Unit 3: Risk, quality and configuration management
Risk management
A risk is an uncertain event that, if it occurs, affects the project.
| Step | Activity |
|---|---|
| Identification | Brainstorm, checklists, past projects |
| Analysis | Probability × impact = risk exposure; qualitative (high, medium, low) or quantitative |
| Prioritisation | A risk matrix and a risk register |
| Response planning | Avoid, mitigate, transfer (insurance, contracts), accept; plus a contingency plan |
| Monitoring | Track triggers and re-evaluate |
Typical software risks: requirements change, staff turnover, unrealistic schedules, technology risk, dependency on third parties, security and performance problems, and integration difficulties.
Quality management
| Concept | Meaning |
|---|---|
| Quality planning, assurance, control | Define standards, build quality into the process, check the product |
| Reviews, walkthroughs, inspections | Peer examination of work; inspections are the most effective at finding defects |
| Testing and verification | At all levels (see Software Testing Methodologies) |
| Metrics | Defect density, defect removal efficiency, test coverage, cycle time, MTTR, availability |
| Standards and models | ISO 9001, CMMI (levels 1 to 5), Six Sigma, ITIL for service management |
| Cost of quality | Prevention and appraisal are cheaper than the cost of failure |
Configuration and change management
Software configuration management (SCM): identify items, control versions (Git), define baselines, control changes and audit. A change control board (CCB) reviews change requests for impact on scope, cost and schedule. Release management controls what goes to production, and unmanaged changes cause scope creep.
Today: the risk register becomes the risk list in a project tracker or the “known risks” section in a release plan. Pull-request reviews are inspections, and CI quality gates and SonarQube thresholds are quality control. Git, branching strategies, and change-approval processes (including CAB in ITIL) are SCM in practice. CMMI and ISO 9001 certifications still matter for outsourcing contracts.
Unit 4: Project execution, monitoring and control
Executing the plan
The team builds the product, coordinating work through status meetings (daily stand-ups), task boards and clear ownership. Communication management decides who needs which information, when and in what form (reports, dashboards, reviews with stakeholders).
Monitoring and control
Progress is compared with the plan and corrective action is taken.
| Tool | What it shows |
|---|---|
| Milestone and task tracking | Percentage complete, late tasks |
| Burn-down and burn-up charts | Work remaining or completed over time |
| Earned Value Management (EVM) | Compare planned and actual progress and cost |
| Defect trends, velocity, cycle time | Quality and flow |
| Status reports and dashboards | Overall health (red, amber, green) |
Earned value
| Term | Meaning |
|---|---|
| PV (planned value) | Budgeted cost of the work scheduled to be done |
| EV (earned value) | Budgeted cost of the work actually done |
| AC (actual cost) | What has actually been spent |
| Schedule variance | SV = EV − PV (negative means behind) |
| Cost variance | CV = EV − AC (negative means over budget) |
| SPI and CPI | EV / PV and EV / AC (below 1 is bad) |
| EAC | Estimate at completion, often BAC / CPI |
Example: a project’s planned work to date was worth ₹10 lakh, the work actually completed is worth ₹8 lakh and ₹9 lakh has been spent. SV = −2 lakh, CV = −1 lakh, SPI = 0.8, CPI ≈ 0.89, so it is behind schedule and over budget.
Controlling change
When the project drifts, options are to re-plan, reduce scope, add resources (with caution), extend the schedule or fix root causes. Issue management tracks and resolves problems; lessons learned and retrospectives feed improvements. Project closure includes acceptance, handover, documentation, release of resources and a post-project review.
Contracts and procurement
Fixed-price, time-and-materials and cost-plus contracts distribute risk differently; outsourcing and vendor management add coordination, quality and service-level agreements (SLAs).
Today: dashboards in Jira, Azure DevOps or Linear present burn-downs, velocity and cycle time; DORA metrics (deployment frequency, lead time, change failure rate, time to restore) are delivery performance measures. SLAs and SLOs are the operational form of contract terms.
Unit 5: People, teams and modern delivery
Team organisation and leadership
| Topic | Key points |
|---|---|
| Team formation | Tuckman’s stages: forming, storming, norming, performing |
| Team structures | Democratic, chief-programmer, hierarchical, cross-functional Agile teams; Conway’s law (systems mirror the communication structure of the organisation) |
| Motivation | Maslow’s hierarchy, Herzberg’s two-factor theory (hygiene factors vs motivators), McGregor’s Theory X and Theory Y |
| Leadership styles | Directive, coaching, supportive, delegating; servant leadership in Agile |
| Communication and conflict | Clear channels, active listening, resolving disagreement constructively |
| Staffing and training | Hiring, onboarding, skills matrix, avoiding burn-out and single points of knowledge |
| Distributed and remote teams | Time zones, documentation, async communication |
Agile and Scrum project management
| Element | Description |
|---|---|
| Roles | Product owner, scrum master, development team |
| Artefacts | Product backlog, sprint backlog, increment |
| Events | Sprint planning, daily scrum, sprint review, retrospective |
| Scaling | SAFe, LeSS, Spotify model |
| Kanban | Visualise work, limit work in progress, measure flow |
The Agile approach replaces up-front detailed planning with iterative planning, frequent delivery and constant feedback.
DevOps and continuous delivery
DevOps joins development and operations: CI/CD pipelines, infrastructure as code, automated testing, monitoring and fast feedback. Release strategies include blue-green, canary and feature flags, which lower the risk of each release. Site reliability engineering (SRE) manages operations with SLOs, error budgets and blameless postmortems.
Ethics and professionalism
Software engineers owe honesty about estimates and risk, respect for privacy and intellectual property, and attention to safety and fairness. Professional codes (ACM/IEEE) guide such decisions.
Today: a tech lead or DevOps lead works with these topics daily: estimating a migration, tracking it with tickets, communicating status, handling risk, reviewing incidents, mentoring and building a healthy team. Conway’s law explains why microservice boundaries often match team boundaries.
One-minute recap
| Unit | Key idea | You meet it in |
|---|---|---|
| 1. Planning | Triple constraint, WBS, project charter, Brooks’s law | Roadmaps, epics, scope decisions |
| 2. Estimation and scheduling | COCOMO, function points, PERT, CPM and float | Story points, velocity, dependency planning |
| 3. Risk, quality, configuration | Risk exposure, inspections, CMMI, baselines, CCB | Risk registers, code review, quality gates, change approval |
| 4. Execution and control | Earned value, SPI and CPI, burn-down charts | Dashboards, DORA metrics, status reports |
| 5. People and modern delivery | Tuckman stages, Scrum, Kanban, DevOps and SRE | Team leadership, release strategies, error budgets |
Next in Engineering Revisited: Management Science.
Written by Claude, Anthropic’s AI assistant, as part of Engineering Revisited, a quick refresher of the B.Tech subjects one at a time.