A checklist for improving IT project schedules

With ICT Institute we visit a dozen software teams every quarter, in order to review their work and help them improve their project plan. About half the teams work in an agile fashion, the other half are using traditional project management. Most teams, luckily, are functioning well and are delivering value. Many teams are however behind schedule. They have underestimated the time needed.

To understand where and why these delays occur, we conducted interviews. In this article we publish the result of these interviews, in the form of a project planning checklist. Anyone making a project plan can use this checklist to make sure no common tasks are forgotten.

Research methodology

For each project or team we visited, we asked for a demonstration of a completed release: the currently live major version of their product or service. In most cases this version was 2 weeks – 6 months old, as many organisations have multiple releases per year. We ask for a demonstation and sometimes code for a code review, to make sure the project is closed and the release is finished. If we would not do this, we would be using personal estimations rather than actual data.
After the review, we would look at the initial project documents (project plan, investment deck or business plan) to determine the planned deadline for this release. Documented evidence is needed since plans are commonly revised during projects and not everyone remembers al changes (e.g. if the current manager joined the project halfway). Based on available documentation we determined the total delay, measured in weeks of the projects. Some projects were delivered on time. Most had a delay of less than three months. Some projects had multiple months of delays.
Based on our understanding of the total delay, we asked the available team members which steps had the most delays or unexpected setbacks. We deliberately asked about the planning aspects and not the cost or effort aspects. Not asking financial data made it easier to gather data in informal interviews, as financial data is often confidential. We tried to ask only factual questions, without making any judgements. The fact that the total delay was already on the table and that the team had been able to demonstrate their working project made it easier in interviews to discuss difficulties. We collected all common tasks and summarised the actual data in a range. E.g. if the minimum required for a tasks is two weeks and the median time 4 weeks, we have translated this in a recommendation to plan 2-4 weeks for this task. We validated this by asking in some of the interviews what they would plan again and what their planning recommendations would be to other projects. In most cases, their planned time would fall between the minimum and median, which is why these are the numbers we listed.

Applying the recommendations in practice

To illustrate how applying these recommendation will impact a project schedule, we have created a sample software project to build an app. The app could be any simple app, such as a casual game, a fitness tracker or an alarm clock. We have first shown a naive schedule, only including only the steps most familiar to developers. The overall schedule takes ten weeks: from the first week of July until the second week of september.

In real life however, one should take into account several additional steps. We identified five hidden steps, each taking at least one week. If one would not plan properly for these steps, the project is likely to be five weeks late. This is a schedule overrun of 50%: not uncommonn for IT projects. Luckily one can work start some of the additional steps earlier. Below is an improved project schedule is shown, with a total duration of 13 weeks.

This project schedule still has only one final delivery. As we explain in our previous post on project planning, it would be better to split the scope of the project in multiple releases. Indeed in our software project management course, we strongly encourage to plan at least three releases in every project. This gives even more opportunities for starting activities in parallel, increasing the chance that the project finished as planned.

The project task checklist

The following tasks have been underestimated in multiple projects. In some cases the tasks were not included in the planning at all. For each task we have listed a range for the  suggested duration. The range is for a medium sized project (4-20 project team members) in a medium sized company (not internationally distributed).

1. Hardware testing and selection: 2-6 weeks. The time is needed for determining budget, waiting for delivery and actual use over a longer time period.
2. Software library evaluation: 1-4 weeks. This often takes longer when libraries have multiple versions
3. Vendor selection: 3-8 weeks. Good vendors are often busy and will need time to write a good proposal.
4. Hiring/recruitment 2-8 weeks. One needs to advertise the opportunity, interview candidates and wait for candidates to become available.
5. Creating visual designs: 1-2 weeks. It is often better for the quality of the work to have one lead designer who designs all screens together based on a common style guide.
6. Validation of visual design: 1-3 weeks. There are often multiple stakeholders whose views have to be collected and who have to approve an improved version.
7. Bulk hardware procurement for initial run: 2-6 weeks. When buying hundreds or thousands of devices (e.g. tablets) it pays to shop around.
8. Setting up infrastructure for acceptance: 1-3 weeks. There are many small setup tasks and decisions that need to be taken, such as OS, database version and create scripts.
9. Setting up infrastructure for production: 3-6 weeks. Actual production servers are often high-spec and therefore expensive. Deciding how much to spend requires time for analysis and approval.
10. Obtain hardware or software certification: 8-16 weeks. In many cases, hardware needs to have CE or other stamps of approval. One needs to find an auditor, negotiate costs, submit devices for testing and wait for the verdict.
11. Investigate legal issues and create terms and conditions: 2-4 weeks. Even large corporates have only a small number of legal experts and these people are busy. Once they become available they will probable have questions that must be resolved before they can create the right legal terms and conditions.
12. Test with real outsider users: 2-6 weeks. The outsiders themselves probably need less than one week for the actual tests, but it takes time to distribute the software, some outside users will become available later. In some cases you will want to ask for further clarification before you can finalise the outcomes.
13. Decision making based on test data: 1-2 weeks. There is always a chance that the outcomes of a test are disappointing and that rework or a different solution is needed. One must plan time for finding such solutions.
14. Initial content creation: 2-4 weeks .Many IT systems require content to work well. Content creation is often not done by development teams, but is only started after the product is released.
15. Onboarding of pilot customers: 1-3 weeks. Pilot customers often need training or additional instruction material before they will start using the product.
16. Translations / roll-outs to new markets: 1-4 weeks. See example below.
17. Get app reviewed and published in app store: 1-2 weeks. This is especially true for Apple app store and less so for the Google Play store. Apple has a serious review process and real quality criteria, for instance regarding battery life.
18. Make improvements on nonfunctional aspects such as performance: 4-8 weeks. These types of improvements typically take longer than expected. One first has to determine goals and start measuring before one can start development.

Trends

People tend to underestimate tasks they have not completed before. E.g. people with a lot of software development experience but without experience in developing hardware, tend to underestimate the number of steps and complexity of each steps. People tend to focus on the parts they know well and neglect the other parts, such as infrastructure, content creation, hardware or field-testing.

People do not allow for enough time for reviews and decision making. It is often assumed by project teams that senior managers can make decisions on the same day that they receive the input for the discussion. In many projects however the findings need to be processed, other people have to be consulted and a decision meeting has to be organised. There is a minimal lead time for all these steps. Adding more project resources does not speed up these steps.

Non-software development steps, such as procurement and legal issues are underestimated or not planned altogether. In our blog post on organisational aspects we explain why these steps are important and what the common steps are.

This article was written based on the joint experience and review comments from Jeroen Arnoldus, Joost Schalken-Pinkster, Kurt Rosa, Allard Oelen and the students of the VU software project management course. If you have  additional data to add to our benchmark, send an email to sieuwert (at) ictinstitute.nl. Image source: Loic Djim via Unsplash