Planning

Planning is the set of activities related to the structure and management of a software project. In a large project, this will likely be handled by a project manager (or even a project management team). However, even on small projects, there are still planning activities that should be undertaken.

Project planning is concerned with:

• Identifying project goals, which can include direct goals (e.g. build product x), and indirect goals (e.g. provide Jerry with the opportunity to grow design skills)¹. Goals are typically product driven, but may also be organizational.
• Identifying resources (e.g. hardware, software, staff that are available) and constraints (e.g. must run in Windows).
• Identifying risks to your project, and devising a plan to adjust and accomodate these risks. e.g. your Open Source database might not be fast enough for what you’re suggesting, so as a backup, you might switch to a faster commercial database; you would need to budget for the cost and effort required to make that change if it was required. This could be listed as a contengency in the project plan.
• Determining an overall schedule, including milestones and time constraints. e.g. must be able to demo at a conference in October; must be delivered in time for the holiday buying season.

Creating a Project Plan

You should aim to capture this information in a project plan:

• Goal: You typically want a succinct project statement that captures the overall purpose of this project. You also want to identify key high-level requirements that must be included.
• Resources: Identify resources required and available for the project. Typically this includes an estimate of staff required, plus any additional hardware or software systems that are needed. If you believe that you are missing something that you need, identify it!
• Risks. What risks can you identify at this stage? These can be technical or non-technical. For every risk, you should identify a mitigation strategy e.g. We have identified Windows 11 as a target but it is not releasing until midway through the project. There is a risk of technical compabitility issues. If this is a problem, we have permission to drop Windows 11 support and revert to Windows 10 for testing.
• Schedule: Finally, you need a list of critical deadlines. e.g. must be able to demo feature X at a conference in October.

Here’s an example:

Project Tracking

The most common means of tracking project schedules is called a Gantt Chart, which is a high-level schedule showing all tasks and their dependencies.

Key concepts:

• Task: Some “piece of work” to perform. Usually an independent task, though it may be have predecessors or successors.
• Milestones: Important deadlines that you want to highlight. Typically you’re ordering tasks in a way that ensures that you meet milestones.
• Tasks and dependencies: Work that needs to be complete (tasks) and order that needs to be enforced (dependencies).
• Critical path: The longest path in your project; the path that determines the overall duration of the project (i.e. the thing that “everyone else is waiting for”). Often there is enough “slack” in a project that tasks can go over scheduled time without harming your ability to hit milestone dates; the critical path is the one set of tasks which, if delayed, will delay the project.

Since tasks are assigned to people, it’s also a way of identifying resources as well, since most of the resources in a software project are people.

With the rise of Agile, Burndown Charts have become popular. They show the amount of work remaining in a Sprint at any given time, and can be often generated on-the-fly from an issue tracking system. They are significantly more useful for Agile projects, since they focus less on the details of what is being built, and more on the team’s velocity.

Estimating Time & Effort

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

– Douglas Hofstadter. Gödel, Escher, Bach (1979)

It is extremely difficult to determine a realistic, detailed schedule at the beginning of a project. However, for planning purposes, we need some structure in place that identifies critical deadlines or milestones, and clearly defines targets that we need to hit.

The recommended process for determining how long a project will take to complete is:

1. Look at similar projects that you have delivered, and use those as a guideline for the resources that you will need, timelines and so on. Different types of software have different project characteristics, so you should model your expectations on your team’s capabilities, and compare to projects that are similar (e.g. building a new compiler will likely take significant up-front research; other projects may not require this).
2. Identify major milestones: these are targets that you know you need to meet for the project to be considered successful e.g. final shipment date. Work backwards as much as you can from the final date, and fill in intermediate milestones ².
3. Fill in project phases based on the work that needs to be done. In the diagram above, you can see that the team has considered research, design and setup phases before actual implementation work. These phases may vary based on your style of project.

https://xkcd.com/1658/