Single Blog

Benefits of software development planning

With the move to a primarily agile delivery approach, where more emphasis is put on discovery, experimentation, and iteration than on deadlines, you might wonder if project plans still matter.

Whilst it is true that in some environments, dates and forward running plans may take a back seat to ongoing product development, there are some environments where regardless of the delivery or organizational culture, delivery dates are still very highly valued. Examples of this are:

• In a client/agency engagement. The agency will be expected to provide outline delivery dates to the client as part of the bid and tender process, especially where the agency will be charging on a time and materials basis.

• In a startup environment with phased funding. The startup will need to know that their runway of funding provides sufficient support to achieve the MVP or next phase of the delivery.

• In a complex project that is responding to external deadlines, i.e. regulatory governmental requirements that have a fixed date. Failure to deliver before these external deadlines could result in excessive fines for the organization.

How to create a software development project plan

In order to create a software development plan you will need to determine your inputs (what material and information are required regarding the proposed initiative) and your desired outputs, that is to say, what artifacts your organization values in terms of sections of the software plan, or what will have the most value to include.

In order to establish these parameters, it is often best to have a meeting or a series of meetings with the identified stakeholders for the project. This will allow the discovery of the following:

1. What material has already been prepared in relation to this project?

2. What further discovery or documentation work needs to be completed?

3. What details are required from a software development plan, as dictated by the nature of the project and the culture of the organization?

Clarifies the process and project outputs

It is important to align stakeholders early on regarding what will or will not be delivered as part of the project. Failure to do so is likely to result in difficult conversations further down the line with the risk that large requests for change in scope are submitted to the project, causing time and cost disruptions.

It is also important to align project team members on the software development process for consistent delivery of the business value. Especially while many software design assumptions change during agile progress, leaving the shareholders and development team lost in the big picture.

Provides milestones for tracking progress

In order to keep track of project progress, especially in client/agency engagements, the client may find it beneficial to request milestones. An example could be “design phase complete”, “prototype built” or “MVP delivery complete”.

This should help to focus the minds of the whole team on shipping the product as early as possible, which allows for valuable early quality testing and feedback. This way the software development team knows how their work is going and whether they need to readjust.

A releases plan provides a method for allowing the client and stakeholders to check in on delivery timelines more regularly to determine if the project is staying on track. Some clients may institute break clauses in their contract if the milestones are too far delayed, allowing them to pivot to another solution provider.

Allows you to forecast your resource requirements

Once you have an idea of the plan and software development life cycle to be used, you will be in a position to start building out your project team. In another article, we covered Agile Outsourcing, where we drive deeper into building the design team and software development team.

The software development plan will also help you identify at what point these team members need to be onboarded. It may not be the case that the entirety of the resource is required for the full duration of the project.

For example, the initial software development planning phase and design phase tend to require much more from design team and shareholders than the development phases, but much less from software development team members.

In order to determine the size and scope of your development team you will need to consider the following software projects factors:

• Scope of the software project and how this can be logically split into either modules, journeys, user stories, features, or other splits
• Expected pace of software development life cycle and project delivery phases
• Required project team members (Designers/Front End/Back End/QA/Platform Engineers etc)
• Critical path of delivery for project’s success
• Dependencies along software development project progress

Throughout this the “mythical man-month” fallacy should always be kept in mind, that is to say, that often in software development, merely adding more resources to a project does not always guarantee that the pace of delivery will increase, and often, doing so (especially at the wrong time in the project) can result in a reduction in delivery speed.

Your software development planning tools should be integrated with team members worklogs so that you can track how the project progresses.

5 key questions project plan needs to 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 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 involving as many of your stakeholders as possible and keep them involved in project monitoring. For predominantly agile projects you could use a kick-off format known as the “Agile inception deck”, which asks the questions in a slightly more tailored way.

How to create a software project plan in 10 steps

1. Define your project workflow

Defining the workflow prompts you to define the phases of your software development project at a high level, without diving too much into the nitty-gritty of tasks and specific deliverables. Your workflow might look something like this:

Initiation > Planning > Launch > Delivery > Closing

This activity will allow you to group together linked tasks at the project delivery level, before diving down into too much detail. Often there can be an excessive focus on the launch and delivery phases, which can lead to misalignment regarding timelines if the lead time for the preceding and following phases are ignored.

2. Set your planning horizon

The longer a project runs, the more likelihood there is for future estimates to be inaccurate. It can therefore be somewhat less valuable to write a detailed plan for things that are going to be happening more than 6 months in the future. This is because the sheer amount of unknowns that can cumulatively impact a project’s timeline would amount to significant inaccuracies over this time period.

3. Break it down into development phases

Once you have an idea of the specific deliverables required for the project, you can start to separate these out into discrete logical packages of work. A great way of achieving this for agile projects is by making use of the user story map, where small deliverables are separated out according to the chronological user journey map.

4. Give your team the context

When estimating, resist the urge to prime the team with your suggestions or opinions on the duration of specific tasks, as this may anchor them to an incorrect estimate. The best estimates are sourced in a “blind estimate” fashion whereby multiple team members submit their views, then all the views are released at once so that one strong voice in the room doesn’t influence others. Check out our article on estimating software projects for more details on using techniques such as Delphi estimation and planning poker in order to achieve this.

5. Uncover estimation constraints

When asking for a rough estimate, prompt further with open questions such as “why”, “how will you achieve this”, “explain this to me in a bit more detail” to allow team members to explore their rough estimate on their own minds. Such questioning will allow them to think through the assumptions they have used and allow them to revisit them if they discover new information as part of this reflection.

6. Question the estimates

Allowing a contingency for unforeseen complexity or additional scope is always a wise strategy. The longer and more complex the project, the more contingency is required. Unfortunately, due to the human nature of optimistic biases, projects are rarely over-estimated or under-budget, so building in between 10-25% (or even more) of contingency is always a wise approach.

7. Plan time for the validated learning

It is not unforeseen that projects may experience delays, so it is important to be prepared for these delays and determine how you are going to deal with them. Maintaining a realistic risks and issues log and a list of mitigations can help with this. Some projects like to undertake 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.

8. Plan the transition to service

Some well-delivered projects can fall at the final hurdle, by having insufficient time allowed to hand the completed system over to the BAU run & maintain teams, as well as providing 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 organization. Make sure you engage with the service delivery teams, who will often have a “transition to service” checklist full of non-functional requirements which should be baked into the software development project plan from the beginning.

9. Post-project review & optimization

Another often neglected part of the project lifecycle is the lessons learned session towards the end. This is because once the project has been completed, project teams often disband quickly with the resource being re-allocated to other initiatives. Unfortunately, this leads to a lack of learning and forces future projects to spend time learning the same lessons over and over, which can be costly and inefficient.

In the post-project phase, it is also important to measure the metrics you set down in the business case. This will allow you to determine whether the project is delivering the expected benefits and if not, how it can be optimized to improve this.

10. Milestones

As mentioned earlier in the article, any software project plan should have separate and incremental milestones, rather than just a big bang of delivery at the end of the project. This allows the project team to determine how on track they are against smaller deadlines and also allows the client to have a good handle on the health of the engagement.

Conclusion

Despite the rise of agile software development where “responding to change” is valued over “following a plan”, plans are still required nevertheless. Whilst it is possible in theory to just spin up a team of developers and let them start work, discovering dependencies and blockers as they go, this is likely to only be successful for the smallest innovation projects.

For complex projects, a blend of traditional project management approaches is required to provide the level of project organization, governance, and oversight that a client is likely to require. Firm releases and project monitoring stop software projects from spiraling out of control with the endless scope and complexity increases and provide opportunities for the client to pause, pivot, or continue.