Software development milestones: the role in successful delivery

What are milestones in software development?

What are milestones? Who needs to create them? When are they needed? Does every project require milestones or only some? These are all questions you might be asking yourself when you hear about milestones in the context of your software development project. Let’s try and answer some of them now.

First off, what are milestones in the context of software development? You can find a more detailed explanation here, but the basic idea is that at the beginning of a project you break up the anticipated work into a series of steps and set deadlines for each step. Each completed step is a “milestone”. Knowing what work is expected to be done by what dates and keeping track of progress helps to keep the project on time and on budget.

Working without milestones

When our company started working on bigger projects, for the first couple of years we didn’t use milestones at all. It actually sounds shocking now! It’s not that we didn’t need them, or that we had anything against using them. We just didn’t think that the benefit they provided was worth the effort of producing them. This is because we’d developed an effective way of working on small website projects where setting up project milestones seemed excessive. As the projects grew in scope though, we needed to change to a large project mindset. After a while we came to realise this. Milestones actually play a significant role in completing a project successfully on time and on budget.

In short – any project or startup can survive without milestones. There’s no question about that. But, will every project be delivered on time without milestones? That’s much more unlikely. Milestones are hugely important for the team and project success. They help you stay accountable, stay on track and complete things on time.

Practical milestones

Essentially milestones are just target dates for specific bits of functionality. In practical terms then, when you start working on a project and you decide that you need milestones, what do you actually write? How do you set up and use milestones?

Well, typically it’s the vendor, not the client who sets the milestones. The agency doing the work (and in particular the programmers working on your project) will have some idea of how long different elements of the project will take them to complete. On the basis of their estimates, the overall project quote or estimate will have been created already. Milestones formalise those estimates into a timeline or plan that sets expectations on all sides about how the project ought to progress.

Milestones in action

For a clearer picture, let’s take a look at a specific example. In a previous article I used the example of an app that aggregates messages from lots of different sources (e.g. messenger, instagram, snapchat, whatsapp, viber, etc. ) and lets the user manage them from one place. Lets use that hypothetical app again here to explore the role of milestones.

There are all sorts of online services and products that help you create milestones. But we prefer to use Google Sheets. They’re highly customisable, everyone has access to them, they’re free; we’ve not found a compelling reason to use something else.

First off, you need a list of all the broad phases of your project. For the example we’re using we might have the following phases: create project brief, make wireframes, make demo app, develop design, develop the app itself. Then the main development stage needs to be broken down into more detail, by feature. For our example the list might look like this:

• Registration and login
• Connecting social networks

• FB integration
• Whatsapp integration
• Viber integration
• Snapchat integration
• Instagram integration

• Messaging interface and logistics
• Push notifications
• Profile settings
• Offline behavior
• Design implementation
• Etc.

Once all the steps to creating a completed product have been laid out, it’s time to set a target date for their completion. This might vary depending on the experience or availability of the programmers working on your project. So for example the target for week 1 might be the development of the 1st stage (registration and login functionality).

Real life milestones

Follow this link to see an example of some real life milestones that we set up for a project last year. Note that the document has several different tabs to show a month by month breakdown. Also notice the additional notes added for some items, about the fact that those items were not in the original scope or were not originally part of the milestone they’re now associated with. In this case these notes indicate that the project was somewhat ahead of schedule and had additional features added to the scope after the project was started. These sorts of notes wouldn’t be in the initial version of the document but show something of its ongoing use during the course of the project.

Finally, notice that several specific dates are marked for “sending a build”. These are the points during the project when it’s worth downloading the app as it stands so far and checking out the features already developed to make sure it’s exactly what you’re expecting.

Practicalities

Milestones also help the developer to understand the structure of the project. When they create the milestones they need to understand that each step is a visible, functioning element of the app. Often one function is dependent on another. For instance, the ‘forgot password’ functionality is unlikely to be in the first milestone, as it requires a ‘registration and login’ functionality to be developed first.

Internal and external role of milestones

Milestones can be set up for both internal and external use. Internal company milestones are typically a bit more detailed – they have a complete backlog of all features or tasks, which people are assigned to them, what status different parts of the project are at, etc. It also allows the company to control and improve developer estimates. By giving developers a reference point for the time that they’ve estimated the work will take them, it helps them to stay on track and deliver on time. At the same time it allows us as a company to track KPIs and see how we are doing in terms of fulfilling our estimates and how accurately each of the developers is estimating their work pace.

Client-facing milestones are slightly different. Their main role is to manage client expectations. They make sure the client understands the complexity and structure of their project. This then sets a bar for reasonable time and cost expectations. If a new feature is added after the initial scope, the client will see where it gets placed in the overall structure and see how other milestones need to be moved and deadlines set back to allow for the new functionality. Delays to the original timeframe are then clearly understood.

External milestones probably also include a little extra time to allow for unforeseen risks. When we place a date on an external milestone, this is a commitment we intend to stick to (assuming the project scope doesn’t get added to mid-project). Internally we push ourselves to keep ahead of the external milestones to allow some time for the unpredictable. This ensures that we always deliver our projects on time.