Tips and tricks for creating a software project schedule

Every project plan should contain an overall project schedule. Stakeholders want to know when results are delivered, and people involved want to know when their activities are planned. There are some standard techniques for creating schedules. In this article we give practical advice for making a workable plan for any software project.

This article is part of a series that accompanies the university course on software project management by Joost Schalken, Jeroen Arnoldus and Sieuwert van Otterloo. The series consists of  (1) creating a vision, (2) project scope, (3) managing non-fuctional requirements, (4) effort estimation, (5) risk management, (6) planning and scheduling, (7) organisational change,  and (8) recommended project management books and articles.

Use the right tool

A project schedule is typically presented in the form of a Gantt Chart. This is a tabular chart with time flowing from left to right. The chart shows activities as horizontal blocks. One can see by looking at the blocks what people are working on, and it is possible to show delivery of products by adding triangles at the end of a block.

There are many ways of making Gantt charts. The easiest way to do it is in presentation software such as powerpoint. The advantage of presentation software is that the charts are easy to create or modify. The tool however does not check any consistencies. It is therefore only useful for planning really simple projects, of for creating summaries of more complicated actual Gantt charts.

A more advanced tool for project planning are spreadsheet programs such as excel. With excel one can not only indicate the activities using colored cells, but also compute the number of hours per activity, per person and per week. These types of overviews are excellent for pure software projects, where most of the constraints are based on available hours of staff. One can not only see the schedule, but model total effort and cost.

Finally, one can use specialized planning software. A very good free tool is Ganttproject. A more extensive and expensive tool in Microsoft project. We prefer the free tool, because it makes it easier to share schedules between project team members.

Pick the right team

When starting to plan a project, one often already has a budget or an estimated number of hours. There is a special relation between effort, duration and the average teamsize: effort = avg-teamsize * duration. Using this equation, one could try to determine the ideal teamsize by dividing the effort by the available time. In practice however this does not lead to good schedules: using this method is similar to trying to make a baby in one month using nine women: this is simply not possible. A much better way of creating a schedule is by choosing a teamsize based on best practices, and accept the resulting duration. An ideal software development team consists of about seven people. One can do projects with one, two or more teams: more than two teams leads to extra overhead and should be avoided, especially by inexperienced organisations and project managers. In addition to one or two complete software teams (testers, lead developers, scrum master and product owner) one might need specialists for special or additional non-software tasks (e.g. content creating, graphics, interviews, field test). Once you have the right team, one can start planning deliveries and will find out what a realistic end date is.

Split the scope in multiple deliveries

Many clients or sponsors ask for an early end date of a project, because they assume that most results will be delivered at the end of the project. In modern software project management, one should plan multiple deliveries, with the most important functionality delivered in the first half of the project. This way, the stakeholders of the project will get value much earlier in the project and the final date is no longer a major point to negotiate. Agile coach Henrik Kniberg drew an excellent cartoon called Making sense of an MVP, reproduced below, on what intermediate deliverables for a car would look like. Even if the car is only delivered at the end, the customer is moving around much sooner.

Allow time for feedback

Most organisations and users have a limited capacity for learning new software: the users need time to absorb changes to their new way of working. As a result, software teams should not only plan time to develop software, but should also plan time for acceptance tests: time needed by the users to try out and work with new software, ask questions, report bugs or make change requests. One can often do this in parallel: users can test during development, and can absorb the result of a sprint while the development team already works on the next sprint. Nevertheless this should be explicitly planned, especially for projects with a very ambitious schedule. When developing software to be used for a special occasion with a fixed deadline (e.g. the Olympics), it is a best practice to use at most half the time for development by development teams, and leave half the time for the users to test, accept and configure the software.

In practice, most schedule contain ample time for Acceptance tests (abbreviation UAT for user acceptance tests). These are test phases where actual users can try out and comment on the systems.

Use critical path analysis for complex projects

The most interesting projects from a planning project are project where there is combined hardware and software development. In these projects one often has planning constraints, such as specifying and ordering hardware, merging hardware and software, and installing and shipping the hardware and software for combined delivery. In these projects many activities are constrained not only by available resources, but also by the fact that activities can only start when others have finished.

Based on a network of activities and constraints, one can compute a critical path: this path consists of all activities that cannot be pushed earlier. Once the critical path is found (and it has no gaps), one knows that a certain planning is optimal. The activities on the critical path should be monitored closely, as a delay on the critical path will delay the project. Delays on the other activities will not immediately affect the whole project. In the example below we conputed the critical path by hand (in green). By adding the numbers (indicating days needed for activity) one sees that this project will take at least 13 days.

Final advice: Do not add people to late projects

In this blog post we already gave the example of making a baby in one month using nine women. This is in fact a classic example, that was described in the classic book by Fred Brooks (the mythical man month). This book, that dates from 1975, contains several ‘ancient’ lessons on software development planning, and most of these lessons are still valid. One important ‘law’ from this book is that one cannot speed up projects that are behind by adding people. “Adding more people to a late project will only make it later”. The new people need to be trained by the current people and will bring more communication overhead. The only way to get back on schedule for late projects is to reduce scope. This is something of a recurring theme in this series on software project management (we gave the same advice in our post on estimation, and gave advice on how to make scope flexible in our blog posts on defining scope and creating non-functional requirements). Software projects are complex endeavours and if the project or team is large enough some amount of obstacles or staff illness is almost certain. The only way to get back on track is by reducing the scope, making sure something is delivered.