Software Development Planning - Perfect Project Plan in 10 Steps

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 > Closing

Sometimes 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.

Forecast resources

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?