You want working software delivered on time and on budget. That’s the goal. But the reality is IT projects, on average, end up 45% over budget while delivering 56% less value than expected.
To stay in front of these abysmal statistics, you need a solid software development plan. Your project plan is your roadmap - a roadmap that tells you and all of your team how to achieve working software on time and on budget.
We’re going to help you draft a perfect project plan, all in 10 simple steps.
- What is a software development plan?
- Why you need a software development plan
- 5 questions your project plan should answer
- 10 steps to create a software project plan
- 1. Define your project workflow
- 2. Decide on the scope of your project plan
- 3. Clarify process and project outputs
- 4. Estimate the workload
- 5. Question the estimate
- 6. Establish milestones to track progress
- 7. Forecast resources
- 8. Leave room for changes
- 9. Plan the transition to service
- 10. Conduct a post-project review
What is a software development plan?
Before we get into exactly how to draft a software development plan, let’s align on exactly _what _it is. A software development plan outlines how the project requirements will be turned into working software. It covers planning, ideation, development, documentation, deployment, launch, and maintenance details.
To get started putting together a software development plan, you should answer questions such as:
- What technologies will be required?
- Who will manage the project?
- Which teams and resources will be involved?
- Who are the key stakeholders?
- What are the external dependencies?
- What are the success criteria?
- What are the timelines and how have they been estimated?
- What are the estimated costs and what assumptions have been used to calculate them?
Why you need a software development plan
With the adoption of agile development, where more emphasis is put on discovery, experimentation, and iteration than on deadlines, you might wonder if a project plan is still necessary.
It may be true that in some situations dates and forward running plans may take a back seat to ongoing product development. But there are some situations where aligning to a project plan and specific deadlines is valuable. Examples of this are:
- In a client/agency engagement. The agency will be expected to provide delivery dates to the client as part of the bidding process. This is especially necessary when the agency will be charging based on time and materials.
- In a startup environment with phased funding. The startup will need to know that their funding runway provides sufficient support to achieve the MVP or the next phase of delivery.
- In a complex project that is responding to external deadlines. An example of this would be a project that is subject to regulatory governmental requirements that have a fixed date. Failure to deliver before these external deadlines could result in excessive fines for the organization.
5 questions your project plan should answer
Each software development project plan needs to have clear answers to the following 5 questions:
Who will be involved in the software project?
Why are we completing the project? (project’s success factors)
What will the project be expected to deliver?
When is the project required to deliver and what milestones will there be?
How will the project be delivered? I.e. What type of approach will be used and what technologies and tools will be used?
In order to get this information you will need to hold a productive project kick-off meeting that includes as many of your stakeholders as possible. These stakeholders should also be kept involved throughout the project lifecycle to hep monitor progress.
Note: For predominantly agile projects you could use a kick-off format known as the "Agile inception deck", which asks the questions in a slightly different way.
10 steps to create a software project plan
In order to create a software development plan you will need to determine your inputs and desired outputs._ Inputs _are the materials and information that are required for the proposed project. _Outputs _are what you plan to achieve.
In order to establish these parameters, it is often best to have a meeting or a series of meetings with the project’s stakeholders. This will allow the discovery of the following:
What material has already been prepared in relation to this project?
What further discovery or documentation work needs to be done?
What details are required from a software development plan, as dictated by the nature of the project and the culture of the organization?
Define your project workflow
Start your project plan by drafting a high-level project workflow. Think about the major phases of your project from beginning to end. This could look something like:
Initiation > Planning > Launch > Delivery > ClosingSometimes there is excessive focus placed on the launch and delivery phases without much thought for the previous phases. This exercise can help you to zoom out and see how each phase flows into the next. Make sure you get this high-level view before you dive into specific project details.
Decide on the scope of your project plan
When creating a project plan you need to decide how far into the project you’re going to plan. The scope of your project plan could be the full project or only part of the project. This depends on how significant (or lengthy) your project is going to be.
Any project that will be completed within 6 months should be planned in full upfront. But if you have a project that’s expected to take longer than that you should consider planning in phases.
The longer a project runs, the higher the likelihood that early estimates will be inaccurate. No matter how well thought-through your project plan is, it’s just difficult to account for the unknowns that could cumulatively impact a project long term. For projects lasting over 6 months, consider developing a project plan for only the first 6 months, then sit down and reset your project plan before the next phase of development.
Clarify process and project outputs
Before we get too far, you should decide what your project outputs should be. Clearly define what a successful end state would be. All stakeholders should be on the same page with this. Failure to do so could result in significant requests for changes to the project scope down the line. Such changes can cause costly disruptions to the project.
At this stage it’s also important to align on the software development process that will be used for delivery of the project. Sometimes assumptions will be made, so it’s important to proactively clarify for all stakeholders upfront so that there is no confusion. The goal here is to not lose track of the big picture!
Estimate the workload
The time has come to estimate the work required to achieve development success. When estimating, resist the urge to prime the team with any suggestions or opinions on the duration of specific tasks. Doing so can anchor them to an incorrect estimate. You want to leave for all members of the team to share their own estimates to achieve the most accurate estimation of work.
We recommend using a “blind estimate” technique such as Delphi Estimation or Planning Poker. Using these tools prompts all team members to share their views and one strong voice in the room doesn’t influence the team.
Question the estimate
It’s important to ask questions throughout the estimation process, as a good estimate can set up a project for success and a bad one can doom the project before it even begins.
Uncover estimation constraints by asking open ended questions. Examples might be “How will you achieve this?” or “Why did you suggest that estimate?” Questions like this help teams to think through their assumptions and reflect on new information that’s brought up.
Regardless of the method you use to estimate workload, you should always include some room for error. Allowing for a contingency due to unforeseen complexity or additional scope can help to protect the project from missing deadlines. The longer and more complex the project, the more contingency that’s required. Due to optimistic bias inherent to humans, projects are rarely overestimated or under-budget. Building in between 10-25% (or even more) of contingency is recommended for all projects.
Establish milestones to track progress
In order to keep track of project progress, especially in client/agency engagements, the client may find it beneficial to establish milestones. Milestones could be "design phase complete,” "prototype built," or "MVP delivery complete.” Having these milestones provides a method for the client and stakeholders to check in on delivery timelines more regularly. Some clients may institute break clauses in their contract if the milestones are too far delayed, allowing them to pivot to another solution provider.
While defining milestones can be beneficial for the client, it can also help maintain momentum on the vendor side. Defining milestones upfront helps the development team focus on shipping the product as early as possible. They know what’s next, and they focus solely on that.
Now that you have an idea of the workload and milestones required for your project, you can begin to forecast what resources will be required at different stages of the project. While you build out your development team, you should also identify the points of the project that each team member needs to be onboarded. You likely won’t need every resource for the full duration of the project.
For example, the initial software development planning phase and design phase tend to require more effort from the design team and stakeholders than will be required from them during the development phases. On the other hand, the software development team members likely won’t be needed as much in the early phases, but of course will be required during the development phases.
For more help building out your team, refer to our Agile Outsourcing article where we dive into more detail.
In order to decide on the team members required for your project, you will need to consider the following software project factors:
- Scope of the software project and how the work can be logically split into distinct segments such as modules, journeys, user stories, or features.
- Expected pace of the software development life cycle
- Technical skills of project team members (designers, front-end developers, back-end developers, QA, platform engineers, etc.)
- Critical path of delivery for project success
- Dependencies in achieving software development project progress
One thing to keep in mind is the “mythical man-month” fallacy. The idea is that merely adding more resources to a project will not guarantee that the pace of delivery will increase. Often doing so (especially at the wrong time in the project) will result in a _reduction _in delivery speed.
Leave room for changes
Something will go wrong. It’s a given in any software development project. Consider conducting a “pre-mortem” (rather than a post-mortem), which is a session held before the project starts, analyzing all the things that could or are likely to go wrong, with accompanying mitigations.
Even if you don’t conduct a formal “pre-mortem,” you should prepare for project issues and delays. Consider how you will deal with issues as they come up. Maintaining a realistic risks and issues log and a list of mitigations can help manage things throughout the project.
Plan the transition to service
Some well-delivered projects can fall at the final hurdle. Don’t overlook the work that’s required after software delivery.
Engaging with a service delivery team is a good start to this process. These teams will often have a “transition to service” checklist with non-functional requirements. These requirements should be baked into the software development project plan from the beginning.
You need sufficient time and resources to hand over the completed system or product over to the team who will maintain it. This should also include a plan for post-go-live support. This part of project management is how the project will be remembered, so it is important to get this right to maintain a good relationship with the client.
Conduct a post-project review
Project teams are often disbanded quickly and re-allocated to other initiatives at the end of a project. Because of this, a project post-mortem is often neglected. This post-project review should be included in the software project plan, so that resources are allocated in advance to do this work.
You don’t want to ignore this phase and force future projects to spend time learning the same lessons over and over. This can be costly and inefficient.
During the post-project review, ask open-ended questions to gather information and support reflection:
- What lessons were learned during this project?
- What went well? How can this be replicated in future projects?
- What did not go as-expected? What can be done to avoid this on future projects?
- Were project goals achieved?
- What benefits did the project provide to the business?
Agile software development can often be seen as prioritizing "responding to change" over "following a plan.” And while in theory it’s possible to just spin up a team of developers and let them start work, discovering dependencies and blockers as they go, it’s likely only to be successful for the smallest projects.
As projects become more complex, careful, detailed planning is required for virtually any project you undertake. Developing such a plan is critical to avoiding budget mismanagement and schedule failures.
The more work you put in up front to develop a solid project plan, the more likely you will be to achieve successful, timely, and on-budget software projects.