Writing quality software for clients is difficult at the best of times. Planning a timeline, planning resources and making sure you have the skills to complete the job, along with a myriad of other things to worry about – If your company is a solution provider, not an integrator (a digital agency) you also have to factor in the end result, and expected return that the client will even get out of the project (the end game) before you even start. So the question is, with so many things that require careful planning, why do software development timelines always appear to carry less weight with management than projects in other mediums?

I have recently had to work on a project where everything has been hard. Estimating a completion timeline has been hard(there was no solid one!). Architecting the solution for every possible foreseeable problem has been hard (lack of scope). Correctly assigning resources has been hard. We have also discovered many unforseen logic traps brought into the project along the development timeline that have extended the finish date.

The question has been why? And the answer has always been extraordinarily simple: Before i was brought onto the project, the project originally didn’t have a proper scope and had very little planning and little to no project management. No definitive estimate of hours was made. The project didn’t even have a complete list of required features when it started. Without going into too much detail this was mainly because what was being delivered had never been done before, and the ownership over the delivery was all but non-existent while it moved between a few hands. Regardless, it lead to complete madness.

While this is nearly never the case – i have literally never been on a project that was managed this way, it did bring something to the fore that seemed far far more important than it had ever seemed in my mind. Writing software to accomplish a goal is one thing, but writing software without a definitive plan of an end product is bordering on insanity.

If you want to make a good product, that your clients will be happy with, without going broke in the process. You HAVE to properly plan a software project. Writing good software is like building a house. You lay the foundations early, with a plan on how big the house will be – how many bedrooms, how many bathrooms. You can then plan the build out and book the correct amount of builders based on this. If you set out to build a 2 bedroom shack and halfway through decide it is meant to be a 5 story condo, certain things simply won’t work out.

All the parts of a project weave so heavily into each other that bad planning and project management has far reaching affects that sometimes go un-noticed, or are assumed to be unrelated to this fact.

Working out a proper estimate of hours is one of the most important parts of this process, as it affects nearly everything after this point. Staff working hours/conditions. Profitability. Being able to stick to a Timeline. Everything. In order to have an estimate of hours, you need to have a complete scope of work. In order to have a complete scope of work you need good communication with the client on their applications’ use and purpose – otherwise you end up having massive scope creep that then affects the things mentioned above and it all becomes a vicious cycle.

Many things link back to this, and it can affect every part of a business. High staff turn over is also often not a sign of bad environment, but a sign of bad project management. If competent developers continually have to burn the mid night oil to complete their work, they will eventually leave and work somewhere else. It is that simple. Unless you’re working at a start up, chasing the carrot that is your stock options, not having a quality work/life balance often leads to resentment by employees. I have seen it many times and the software industry is renowned for it. Proper resource allocation and timeline can usually solve this.

Once a developer works more than a certain amount of hours a day, certain things start to happen to even the most seasoned at their trade. Like hospital interns working double shifts, overworked developers start to make mistakes. Logic starts to go out the window, and the quality of their workmanship suffers. People wanting to finish that last feature, simply want to finish it – they want to go home. This reflects poorly on both the solutions they architect and the speed at which they can decisively get themselves out of any problems they come across along the way. Often late night solutions are harder to maintain, brittle and less than stellar examples to be handed over to a fresh set of eyes the next morning.

If the project is harder to maintain and debug because of these late night caffeine fuelled coding adventures, this then has a domino affect on the budget, development timeline, and in the end your clients patronage and your businesses reputation.

Additionally, as anyone who has read the Mythical Man Month will all too well know, if you’re running behind, you simply can’t add team members mid-project and expect things to magically speed up. Assigning proper resources to a project has to be done at the start, if wanting a linear development schedule.

This is why with software/web development it is unlike other mediums: you can’t simply “get er done” like you can with TV, radio, print, and direct marketing. This whole situation becomes really dire when people managing this product life cycle don’t have everything in order before they start: They don’t plan enough.

So the question is: Why does it seem that most project managers that actually work in software are so behind the eight ball when it actually comes to properly planning and managing their software projects?