Most teams have a plan somewhere. Fewer can say which version is current, or what it says about the thing everyone is now arguing over.
That’s the job of a software development plan, and the standard behind it has been replaced twice. IEEE 1058-1998 gave way to ISO/IEC/IEEE 16326:2009, and BSI lists ISO/IEC/IEEE 16326:2019, published in December 2019, as the current edition.
If a contract names a standard, it should cite that edition.
What Is a Software Development Plan?
Scope, methodology, schedule, resources, risks and quality criteria for one software product all get fixed in a single planning document, and that document is the plan.
The delivery team and product owner want scope, task order and the definition of done. Sponsors look for budget, dates and risk exposure, and a client or acquirer uses it to monitor how the developer works.
The defense data item description DI-IPSC-81427 (1994) defines development broadly. New builds, modification, reuse, reengineering and maintenance all count.
Software Development Plan vs Project Plan and SPMP
People mix the plan up with a few neighbors. The closest is the software project management plan (SPMP), which is the IEEE 1058 name for a document written for software projects of any type or size.
A general project plan is looser and carries no development method detail. The project charter comes earlier, authorizes the project and names the sponsor.
The plan points to a software requirement specification instead of copying requirements into itself. That keeps one source of truth for what the product must do.
The SDLC is a different thing again. It’s a generic set of phases, and the plan applies one of the software development lifecycle models to a dated schedule for a specific product.
Standards Behind the Plan
IEEE Std 1058-1998 covered the format and contents of software project management plans for any type or size of project.
IEEE SA lists it as superseded by 16326. ISO describes the 2009 edition of ISO/IEC/IEEE 16326 as the harmonization of IEEE 1058-1998 and ISO/IEC TR 16326:1999.
That 2009 edition has since been withdrawn. ISO/IEC/IEEE 16326:2019, published on 13 December 2019, is the current edition as of October 2026 (BSI).
When a contract asks for a standard, cite ISO/IEC/IEEE 16326:2019. A template that still names IEEE 1058 as current is working from a superseded document.
Defense work uses DI-IPSC-81427 instead, first issued on 5 December 1994. EverySpec lists revisions A (2000) and B (2017).
What Should a Software Development Plan Include?
Scope and deliverables come first, including what ships and what is explicitly left out. Methodology follows, with the delivery approach and its cadence.
Estimates go in as ranges of effort, cost and duration, never single numbers. The schedule covers phases, milestones and dependencies, and the roles part says who decides what.
The risk register lists each risk with likelihood, impact, owner and mitigation. Quality criteria cover the definition of done, acceptance criteria and the test approach. Release steps close it out with deployment, rollback and handover.
Each part answers a question the team would otherwise argue about later.
The defense format weights things differently. It opens with requirements and constraints, then the development process, then methods and standards for software products.
Roles and release steps shrink to a line each on a four-person team. Scope exclusions, the risk register and acceptance criteria stay at full length.
How to Write a Software Development Plan
Order matters here, because each step feeds the next.
- Lock scope and requirements. List the deliverables and name what is excluded.
- Pick a methodology that matches how stable the requirements are.
- Estimate in ranges, using story points, function points or COCOMO II depending on the stage.
- Build the schedule by breaking work into packages, mapping dependencies and setting milestones.
- Assign roles, with one owner per decision.
- Register the risks. Score likelihood and impact, assign mitigation and set up change control.
- Write the definition of done, the acceptance criteria and the rollback conditions.
- Baseline it. Get sign-off on one version and keep the document under version control.
Requirements engineering feeds the first step. A plan written before requirements settle carries that instability into everything after it.
When the idea is unproven, run a feasibility study before committing to a plan at all.
Sign-off means the sponsor and product owner both agree with the tech lead on one baseline. After that, every change goes through a change request.
A Worked Example
The scenario is hypothetical: a small team building an appointment-booking web app for one clinic.
| Plan part | Example entry |
|---|---|
| Scope | Patient booking, clinic calendar view, email reminders. Excluded: payments, native mobile apps |
| Method | Scrum, two-week sprints |
| Estimate | 4 to 6 months, kept as a range until three sprints give velocity data |
| Top risk | Unknown clinic calendar format. Mitigation: a technical spike in sprint one |
| Release | Staged rollout to one clinic, rollback to the previous build |
Five rows, one page. It still answers every question the team would otherwise settle by argument.
Agile, Waterfall or Hybrid: Which Methodology Fits the Plan?
Waterfall suits requirements that are fixed and bound by contract. If they’re going to change, agile fits better. Hybrid is for the awkward middle, where the budget or release date is fixed but the scope isn’t.
Teams can pick from plenty of software development methodologies, but for what goes into the plan they boil down to waterfall, Scrum, Kanban and hybrid.
PMI’s Pulse of the Profession 2024 puts predictive approaches at 44% of projects, hybrid at 32% and agile at 26%. The same report finds teams perform equally well with all three, so fit matters more than the label.
| Approach | Plan fixes | Plan leaves open | Fails when |
|---|---|---|---|
| Waterfall | Scope, phase gates, dates | Little | Requirements change mid-build |
| Scrum | Sprint length, product goal, capacity | Scope inside the backlog | Stakeholders need fixed scope and date |
| Kanban | WIP limits, flow policies | Order of incoming work | Plan needs dated milestones |
| Hybrid | Budget and release date | Backlog between milestones | Nobody defines what is frozen |
Waterfall: Fixed Scope and Phase Gates
A waterfall plan fixes scope up front and moves through requirements, design, build, test and release gates. Milestones are dated and tied to gate approvals, which leaves a clear audit trail for contracts.
It breaks the moment a requirement changes after sign-off, because that reopens every later phase.
Scrum: Fixed Cadence, Open Scope
Scrum fixes the rhythm and leaves scope open. Sprints are fixed-length events of one month or less (Scrum Guide, 2020), so the plan mostly needs a sprint length and a product goal. Team capacity goes in too.
The gain is that scope adjusts every sprint as the backlog changes. The cost shows up when a stakeholder needs both a fixed scope and a fixed date, because this plan will not give them either.
Kanban: Flow Limits Instead of Iterations
Kanban plans around flow. Work-in-progress limits and pull policies replace sprint commitments.
That fits maintenance queues and continuous delivery teams well. It misses dated milestones unless a roadmap sits on top.
Hybrid: Fixed Frame, Flexible Inside
The PMI report also notes that hybrid has no universally accepted definition. So the plan has to state which parts are fixed.
It works when the contract fixes budget and date and the backlog flexes between milestones. It stops working when nobody writes down which scope is frozen and which is negotiable.
For the plan, one question decides: who carries the cost of a change. The trade-offs between agile and waterfall run deeper than a plan needs to show.
How to Estimate Effort, Cost and Duration
Most plans lean on story points with planning poker, which give relative estimates inside the team. When size has to come from requirements, function point analysis does that job, and COCOMO II turns a size input into parametric effort.
With story points, each member picks a card and the outliers explain their number until the team lands on a relative size. Velocity then converts points into calendar time.
Function point analysis sizes the functionality a user requests, independent of programming language. The count is the same whether the code is assembly or Java.
Allan Albrecht of IBM introduced it in 1979, and ISO/IEC 20926:2009 now defines the IFPUG method.
COCOMO II estimates effort and schedule from a size input plus cost drivers. It needs calibration to local project data.
A 1997 Air Force Institute of Technology thesis tested COCOMO II.1997.0 against Space and Missile Systems Center data. It found poor accuracy, with the model typically underestimating.
The numbers around all this are worth knowing. At initial concept, an estimate can land anywhere from 4x high to 0.25x low (Construx, 2018 edition). Todd Little’s analysis of that cone drew on 100+ projects (IEEE Software, 2006).
Any velocity forecast sits on sprints of one month or less (Scrum Guide, 2020). And ISO last confirmed ISO/IEC 20926:2009 in 2024, so the IFPUG method is still current (ISO).
Construx advises against tying commitments to completion until work has narrowed the cone. In the plan, that means a range first and a date only after the first sprints or a design milestone.
The sources disagree on the shape of that range. Little’s 2006 data contradicted the cone as usually drawn, so treat the band as a rough guide, not a law.
How to Set the Timeline and Milestones
Start with a work breakdown structure, which splits deliverables into work packages small enough to estimate and assign. Dependencies come next, meaning which package blocks which. An API contract that has to exist before the client build starts is the usual example.
The critical path is the chain of dependent packages that sets the earliest finish date. Milestones sit on top as dated checkpoints with an exit condition, such as requirements sign-off, feature complete, release candidate and go-live.
The critical path method defines the critical path as the longest-duration path through the schedule network. Activities on it carry zero float, so a slip there moves the end date.
Oracle’s Primavera P6 documentation spells out the same mechanics: a project with negative float is behind schedule. Check float at every milestone review, not only when something looks late.
Write each milestone as a condition, not a date alone. “Feature complete” should mean every item meets the definition of done.
| Format | Shows | Best for | Weakness |
|---|---|---|---|
| Gantt chart | Durations, dependencies | Fixed-date phases, contracts | Goes stale when scope moves |
| Roadmap | Themes, target quarters | Backlog-driven delivery | No dependency detail |
| Sprint calendar | Sprint and review dates | Scrum teams | Silent beyond the horizon |
Put buffer in front of milestones that carry external commitments. Padding every task hides the slack, and the team spends it anyway.
Who Owns What: Roles, Responsibilities and Tools
Every decision needs one named owner. Scope and priority go to the product owner, technical design to the tech lead, test sign-off to the QA lead, and budget to the sponsor.
| Decision | Owner | Consulted |
|---|---|---|
| Scope change | Product owner | Sponsor, tech lead |
| Technical design | Tech lead | Developers, QA lead |
| Test sign-off | QA lead | Product owner |
| Release go or no-go | Product owner | Sponsor, tech lead, operations |
In Scrum teams the product owner orders the product backlog and answers for the product goal. That makes the role the natural owner of every scope question in the plan.
Once a team grows past the core five, a catalog of software development roles and responsibilities saves arguments about who signs what.
For communication, a daily team sync and a weekly stakeholder update cover most needs, with a milestone review on top. Keep one channel for status and a separate one for blockers.
The escalation path should say who hears about a blocked critical-path item, and within how long.
On tooling, Jira handles backlog and sprint tracking, Azure DevOps covers work items and sprint planning, GitHub holds the repository, issues and code review, and Confluence is where the plan document itself lives.
Pick one tool for the backlog and one for the document. Two backlogs drift apart within a sprint, at least in my experience.
How to Plan for Risk, Scope Creep and Change
Each entry in a risk register needs a description, likelihood, impact, score, owner, mitigation and trigger.
Score likelihood against impact on a risk assessment matrix, then review the top items at every milestone. The trigger field matters most, because it tells the owner when to act.
Unstable requirements show up in nearly every plan, and the fix is building the least certain feature first and reviewing scope at each milestone. Losing a key person hurts less if you pair on critical modules and write decisions down.
Third-party dependencies get an early spike to test the integration. Technical debt needs capacity reserved in every sprint or phase.
CISQ’s 2022 report puts the cost of poor software quality in the US at $2.41 trillion, with accumulated technical debt at roughly $1.52 trillion.
Treat technical debt as a planned cost with its own line in the schedule. Debt that appears only when a deadline slips has no budget behind it.
Scope creep arrives as small requests, so every change should follow one path.
- Submit a change request.
- Assess the effect on schedule, budget and risk.
- Get approval from the named owner.
- Update the baseline.
A Disputed Failure Statistic
The 1994 Standish CHAOS report put project success at 16 percent. Planning documents still cite it to justify heavy risk sections.
Eveleens and Verhoef (IEEE Software, 2010) applied Standish’s definitions to 5,457 forecasts from 1,211 real projects. The Standish figures did not reflect the reality of those cases, because the definitions rest solely on estimation accuracy of cost, time and functionality.
Read the 16 percent as a score for estimate accuracy against a one-sided yardstick, not a failure rate. In the register, track estimate drift per milestone instead of a pass or fail label.
Quality Criteria, Testing and Release Planning
Quality splits into two checks that people keep merging. Every work item has to meet the definition of done. Whether a feature gets accepted is a different question, answered by its acceptance criteria.
Definition of Done and Acceptance Criteria
The definition of done applies to every item. The Scrum Guide (2020) calls it a formal description of the state of the increment when it meets the quality measures required for the product.
An item that misses it cannot be released or even presented at the Sprint Review. A typical version means code reviewed, tests passing, documentation updated and the build deployed to staging.
Acceptance criteria attach to one story and describe behavior a user can observe. Write them before the sprint starts, as testable statements.
Well-written acceptance criteria also give the QA lead a test script. One source, two uses.
Test Strategy
ISO/IEC/IEEE 29119-3:2021, published in October 2021, provides test documentation templates that apply in any software development lifecycle model.
The plan states test levels (unit, integration, system, acceptance), environments, entry and exit criteria, and who signs off.
A separate software test plan can carry the detail. The development plan only points to it.
Plans often justify early testing with the claim that defects cost 100 times more in production. Laurent Bossavit traced the chart to course notes at an internal IBM training program with no supporting data (The Register, 2021).
He also reported that one study cited for Boehm’s cost curve showed a 2:1 ratio in the opposite direction (TechWell, 2013). Justify early testing with your own defect data instead of an inherited multiplier.
Release Plan
Release planning is a runbook, not a date.
The release date ties to milestone exit criteria. Deployment steps are ordered, each with an owner, and rollback conditions get trigger thresholds agreed before release day.
Handover covers documentation, support contacts and monitoring dashboards.
DORA’s 2024 report measures delivery through deployment frequency, lead time for changes, change failure rate, deployment rework rate and time to recover from a failed deployment. Any of them makes a workable release target for the plan.
Where a Software Development Plan Breaks Down
Plans go stale. A baseline nobody revises becomes a contract the team works around, and changes drift into chat threads and skip change request management entirely.
They can also outweigh the project. A startup building a first release needs a one-page version with scope, exclusions, top risks and the next milestone. The worked example earlier in this article is already close to that size, and I’d take a current one-pager over a forty-page document nobody opens.
Estimates harden too. A sponsor who converts a range into one date removes the buffer the range carried, so the plan looks precise and is wrong from day one.
Then there’s the model mismatch. Teams practicing continuous deployment ship small changes on demand, so a dated plan adds little. A roadmap and a strict definition of done carry the load instead.
A working rule: write the full plan when a contract, budget or regulator requires one. Otherwise start with the one-page version and expand it only when a risk or a stakeholder demands more.
Software Development Plan FAQ
How long does software development take?
No universal figure exists. Duration follows from scope, team capacity and methodology, so the plan states a range and ties each date to a milestone.
Re-forecast after the first sprints, once real velocity replaces assumptions.
Is there a free software development plan template?
Yes. The defense format DI-IPSC-81427 is a public document, and EverySpec hosts downloadable copies.
ISO/IEC/IEEE 16326:2019 is sold, not free. For a commercial project, the eight-part structure and the worked example in this article make a workable starting template.
How long should the plan be?
Long enough to cover every part, short enough that a reader finds the owner, the next milestone and the top risk within a minute.
A small team can work from one page. Contract work tends to run longer because the client or regulator expects detail.
How often should the plan be updated?
Revise it at every milestone review and whenever a change request is approved.
Each revision gets a new version number and a note on what changed. A plan edited silently loses its value as a baseline.
What to Change First When a Milestone Slips
When a milestone slips, the software development plan changes scope first, the date second and the team last.
Scope moves fastest because the scope list is already ranked by priority. Defer the lowest-priority items, re-forecast the date as a range, and resize the team only if both of those fail.
Team changes come last because a new developer consumes onboarding time before adding output. The sponsor accepts a smaller first release in exchange for a date that holds.
This order was verified as of October 2026, and a contract that fixes scope reverses the first two steps. Read the contract before opening the backlog.
Every approved cut updates the baseline, which makes managing change in software projects the natural next skill to build. Managing change in software projects starts from that baseline.
- How Software Teams Write SOPs for Releases and Deployments - October 22, 2026
- Notepad++ Android Options: Apps That Come Close - October 21, 2026
- Data Management Services: A Practical Guide for Growing Companies - October 21, 2026
