How to ensure your software project is delivered on time

Feb 05, 2014

Table of contents:

1. Why do software projects go over time and budget?
2. How to ensure software projects are delivered on time
3. Conclusion

One of the big problems with creating software either for a client or inside an organisation is project management. Software development is notorious for being delivered late and over budget.

The problem seems to exist for organisations both large and small, and even when outside consultants are brought in to specifically manage the project. Public Sector and Government based projects often seem to be the worst offenders with projects going massively over budget and delivered far past the original deadline.

The problem is therefore rooted not in the tools, personnel or types of projects, but rather, how the project is managed.

In this post I’m going to look at the project management of software development, where projects go wrong and what you can do to ensure that you deliver your projects on time and on budget.

Why do software projects go over time and budget?

In my experience there are many reasons why software development projects go over time and budget. However I think there are two main culprits that cause the majority of failed projects.

Unforeseen problems

The Waterfall model of software development is where a specification is written at the start of a project and then the project flows sequentially through a series of steps until completion. These steps are generally Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation, and Maintenance.

The problem with this process is, it is highly likely that you will only realise a problem once you are already too far along with the project. The Waterfall model does not allow you to go back up stream and so you end up with software that was based on incorrect assumptions from the project’s conception.

If you don’t catch these unforeseen problems before it is too late, you will end up delivering software that is inadequate for the intended purpose. This means the software will have to be modified or redeveloped to incorporate changes that were only brought to light at the end of the development.

Scope creep

The second big problem to impact software projects is scope creep. This is usually the case when a client will continue to ask for more and more changes that were outside of the original specification.

Scope creep is very different to just dealing with unforeseen circumstances. Unforeseen circumstances arise when the agreed specification does not meet the intended goal. Scope creep occurs when additional features or functionality are added to the scope of the project when the initial feature set has not been proved to be incorrect.

There is a big difference between scope creep and managing an agile project. With an agile project, short sprint cycles are used to build, learn and iterate. Scope creep is fanciful superfluous features that do not solve a problem for the end user.

Scope creep usually occurs when there is little understanding of the requirements of the project, weak project management and poor communication between each party. If the client continues to request additional features that do not move the project closer to the original goal then it is up to the project management team to say no to those requests.

How to ensure software projects are delivered on time

So how do you ensure that software projects are delivered on time and on budget? I really believe that delivering software projects is not difficult as long as you stick to the following three rules.

Always use agile development

Waterfall development is like the curse of project management. If you are working for a client or an organisation that does not understand how to manage software projects, the Waterfall model is always how they assume it should work. This is because the Waterfall model is a relic from other industries.

Instead you should break down a project into short sprints of planning, development and feedback. This build, learn, iterate model will allow you to make incremental progress and ensures that you stay on course to meet the goals of the project.

This isn’t to say that you should just jump in without thinking of the bigger picture. I hear of lots of projects which are “agile” when in reality the project team is just going round in circles because they don’t have a clear destination.

Instead you should map out the scope of the project so you have a good idea of all of the components that are required to meet the goal.

Manage deliverables

A second big mistake I see when managing software projects is the project is thought of as one deliverable, rather than many smaller ones.

After you have mapped out the project and identified the key components that are required to meet the goal, you should write task lists and group them into buckets of deliverables.

This means you shouldn’t break a project down into server side code, client side code, design and copy. Instead you should take each component, or feature, and determine what you need to deliver it.

For example, if you were building an application to handle customer enquiries, you might decide that the chat window was one of the most important components of the project. You would then work on the server side code, the client side code and the design to finish that feature as a deliverable so you can get feedback from the client.

If what you build does not meet the goals of the project you need to find out as soon as possible. If you wrote all of the server side code for the project first, it would take a long time before you would find out that the chat feature did not meet the client’s requirements.

Once you have grouped the tasks into appropriate feature buckets, you then need to identify what features are the most important and what aspects are either unknowns or will be difficult to implement.

It should go without saying that you need to tackle the hard stuff first. You might really love User Interface design, but if you don’t get the mechanics of the application working first you might end up throwing a lot of work away.

As you progress with the project you should be constantly reevaluating your priorities. A software project is constantly evolving. Just because a particular feature was high priority at the start does not mean that is should remain a high priority for the life of the project. As you build and learn you should be constantly questioning your assumptions.

So the big change here is, you should manage deliverables rather than splitting the tasks down into different disciplines. This means forming cross-functional teams of a server side person, a client side person, designer and a project manager. This shows how important it is if you can master all four disciplines as you don’t have the latency of communication between four people when a single person can do the work themselves.

Cut scope to hit deadlines

As I mentioned above, one of the two reasons why software projects fail is because of scope creep. Even if you have a strong project manager that refuses to accept scope creep, underestimating the initial scope of a project is an easy mistake to make.

At the outset of a project the client will usually give you a list of features and requirements. It is your job to estimate the duration of the project based upon your assumption of how the project will unfold. However in just about every software project there will always be bumps in the road.

Therefore in order to hit deadlines, sometimes you just have to cut scope.

Every software project should have a singular goal or metric that the client is hoping to hit. Any feature or bit of functionality that does not progress the client towards this goal should be cut first. This allows you to deliver the project on time and on budget and puts the client in a position where they can start earning value from your work immediately.

Whilst it can be difficult to convince a client to cut scope, you have to reassure them that it is in their best interest. Usually the initial scope of a project will be incorrect as it is often based on assumptions. The client will be in a much better position to iterate on their application with less features when the application is in the hands of their customers. Delivering a feature full application late is much worse than getting the initial product out into the world.

Once you decide to take this course of action you need to just decide what to cut and cut it. I’ve seen lots of projects that end up in an even worse position when the stakeholders can’t come to a consensus around what to cut.

Anything that can be delivered once the project has been launched can be immediately cut. Again, it is much better to just get the project out the door rather than building every possible feature you can think of that you might one day need.

Conclusion

I really don’t think managing software development projects is that difficult. I think the big challenge is often to convince people that they shouldn’t manage a project using the Waterfall model and they should think of the project as a set of deliverables to meet a goal.

When you use the Waterfall model you take a big risk in assuming that you know exactly how the application needs to work at the very beginning. In just about every software development project there will be unforeseen circumstances or required features that are just impossible to know at the outset. Instead of taking the big risk of planning everything at the start, break the project down into shorter cycles so you can learn more about the requirements of the project as you get further along into building the product.

The second shift in mentality should be to split the project into deliverables rather than disciplines. The faster you can get real working features into the hands of the client or the customer the better chance you have of project success.

When you split a project down into the different disciplines you end up wasting a lot of time in isolation. Instead of writing all of the server side code for the entire project in one go, split it down into smaller chunks that can be presented to the client for feedback. This ensures that you remain on target and you don’t have to throw away lots of work that isn’t required.

Managing software projects is not difficult, it just needs to a shift in mentality from the old world way that clearly does not work.