Software development requires one of the most difficult and essential project management skills – the ability to plan ahead. Statistics show that 68% of software projects fail.
Now that’s an incredibly high number. However, the reasons that many software development projects fail might not be as obvious as you think. So let’s explore some of the major factors that lead to failure.
Management May Push Timing
It’s no secret that management wants deliverables ready as soon as possible, especially if it’s for a client. More often than not, management will implement a timing schedule to ensure that major project milestones are completed within a certain period of time so that the project may be delivered to the client on the date promised in the deliverables.
However, management doesn’t develop the product. Even if they have experience with development, the tech industry changes so rapidly that their insight is limited, their skills just not up to date. Because of that, their calculation of delivery time may not reflect the reality of the project. It takes a bold and caring employee to risk termination and tell their manager that their timing schedule is not realistic.
While managers may believe that this employee is the problem, not their schedule, it’s important that management realize this is the employee that cares the most about the success of the project and the one who has the most realistic outlook on how long a project will take. As such, they should be open to suggestions and critique from their development team as they craft their schedule. As for the employee dealing with a time-focused manager, there’s not much you can do (except show your boss this article and hope for the best!)
If a developer believes that a project will take four months, but management sets a two-month schedule, chances are that the resulting product will be useless to both the client and the company. It will have failed to meet the client’s requirements and they will walk away unhappy. It will also have wasted the company’s time and resources, leaving management unhappy and the developer usually taking the blame. This is what we call a failed project.
Changing Client Needs
A software development company’s clients are generally not tech-oriented. (Obviously, if they were, they could develop their own software.) This makes the process of understanding the client’s needs difficult because the client isn’t exactly sure what he needs. Companies generally hire business analysts to extract the client’s requirements and exact specifications for the project before any planning or development occurs. Problems arise when one of the requirements provided changes. Because pinpointing a client’s requirements can be difficult, it’s entirely possible that there was a miscommunication or misunderstanding that occurred during the process. It is also possible that the client simply changed their mind.
However, a simple change of mind translates into big problems for a developer. While the software project can be modified at any time, even after it has been delivered to the client, it is not an easy process; nor is it a quick one.
Let’s say that your business analyst told you that the client needed “boiled chicken.” Now they’ve come back to you after you’ve put the chicken in the pot saying that client actually wanted “fried chicken.” It’s still chicken, but not the same chicken. Now you either have to salvage the boiled chicken, which isn’t likely, or trash that and start over. All of that time and hard work has been wasted.
Clients’ needs must be clearly understood the first time. If there is a critical change in requirements, client must be billed for the extra work and given a new time schedule. Obviously, the client needs to understand from the beginning that there is a real cost in money and time when requirements, and therefore, the definition and scope of the project changes.
Delay in Client Responses
I remember one of my university professors explaining how many people believe that software project development is an unsocial job because of the many hours spent alone behind a computer. However, anyone with experience in the field will tell you that it is actually an extremely social job.
The ability to communicate with clients and understand their needs requires strong communication skills. And it’s not a one and done scenario. Clients may need to be contacted at multiple points during the development phase.
However, it’s rare that a client will get back to you instantaneously, or even on the same day. A delay in response puts the project on hold because the developer cannot just assume what the client means or wants and move forward. Instead, it is a waiting game while the client comes to a decision. Occasionally the developer can find other aspects of the project to work on while waiting for a response, but often no progress can be made without it.
However, this isn’t often taken into account during the timing schedule. The proposed date remains the same and the developer must play catch up to make up for the time lost while waiting for a response. If this happens too many times, the project will ultimately fail because the process has been rushed or the deadline will simply not be met.
Relating Software Projects to Other Projects
Software projects differ from most other products. They are more comparable to creative works like art and literature in that they require creation, research, trial and error and testing. Thinking of software as a generic product that is just bought and sold is incorrect and actually works against the objective of the project.
Software Distribution is Important
Even when inspired by a specific client, a software project should never be developed for them alone. The development of a specific solution to solve specific problems should be scalable. It should address not only the current operational issues it would solve and the processes that it would make more efficient, but should also anticipate future issues and functionality as the company grows.
So while you can develop software that meets a client’s needs, like using WordPress instead of some other CMS, it is important to develop with a broader distribution strategy in mind. It is important to create a piece of software that can be customized to meet the exact needs of your client, but then can also be customized by other potential users. If you lack a comprehensive distribution strategy and you are not developing something for an extremely large, non-competitive, and well-paying company like NASA, then you should seriously reconsider your strategy.
When developing software, think of how the industry or niche would be able to use it, and what aspects of it need to be customizable to suit the all potential users, including your client.
Timing is Flexible
One of the largest problems with failing software projects is the timing. Generally, larger companies speak in years or quarters, saying that their software is “expected to be released in Q4, 2013” and that they “are on it.” This is because developers are creatives in an industry where so much can go wrong, where so much can change, where the business relies on its ability to deliver. These companies anticipate this fact and plan for it because, more often than not, the number of things that go wrong far outweighs the number of things that go right.
The reason they do not set specific dates is because timing a creative project isn’t realistic. You can provide a ballpark estimate, but setting a date is setting yourself up for failure. Big companies leave themselves play-room with the release date because setting a date is like making a promise that likely cannot be kept. And when you are not able to keep your promise, your reputation suffers, your clients suffer, and your business suffers.
When you order your dinner at a restaurant, there is a time limit. There is a set amount of time that driving from Point A to Point B will take. And even these have a tendency to vary. However, there is no set time for when an artist will feel that the work is complete. A work of art takes as long as it takes to create, and forcing an artist to rush will only result in sloppy work and dissatisfaction with the project from the artist himself and the party it was meant for.
In fact, when it comes to software, there never is a time when the product is truly finished. Like Google Search or Windows or the development of the apps on your phone, good software is never “finished;” it’s always improving, changing, updating. That’s how it stays relevant. That’s how it keeps making money.
Like Driving To an New Destination
Software development can be like driving a car to a previously unvisited destination. You know how to drive, but you don’t know the way. You know where you want to go, but you don’t know which path to follow. You sometimes make wrong turns, sometimes you get a flat and you have to stop and change it. Sometimes the road is rocky and you go slower. Sometimes there are accidents. When you reach your destination, or even before you reach it you often realize there was a shorter or better way.
Any software developer can relate to the experience of driving a car to a new destination. These wrong turns, accidents, delays, desires to backtrack, they’re all part of the reason why there is such a high rate of failure in software development. It’s also why dates of delivery are often inaccurate. If the timeframe was met, it was simply by chance. When you invite friends over, how many of them give you a specific time and actually show up at that time? Few, if any. Most times they give you a range, saying I’ll be there between five and six, or I’ll be there in five or ten minutes.
Bridging the Divide
Now this seems like an impossible situation – how can we run a business if we don’t have set deliverables and a time schedule? Businesses need timing, companies need profit, and employees must get paid.
It is here that I would like to return to our discussion of the nature of software and distribution. As I’ve mentioned, considering how you will “resell” the software is an important part of development. If developed knowledgably and marketed effectively, the software can be resold very easily.
Remember dinner? You wait for it, you eat it, you wash the dishes, and it cannot be served again. Software is drastically different, so rather than focusing on “delivery time,” focus on the “continuous delivery” with release points that include a set of new or improved features as well as the distribution of the software. It’s always better to provide a range than a date. Clients will appreciate your honesty and your developers will appreciate your understanding of their needs.
So double the timing – triple the timing. It doesn’t matter, as long as everyone is comfortable with the timing, and also if you are able to sell it to 200 people rather than just one client.
Defects and Unexpected Behaviors
There’s no software on earth that runs without a defect, or bug. Every piece of software has bugs. Have you ever used your computer when you experienced an error or something that just went absolutely haywire for seemingly no reason? That’s a defect. It is impossible to get rid of every defect.
Even large, well-respected companies deal with bugs. Take a look at the following chart that shows the number of bugs experienced by Mozilla Firefox, a popular Internet browser, over several years.
Notice the trend? The number of bugs Firefox experiences increases. An increasing number of bugs in software is ultimately a good sign because it means that your software is still being developed, that it is still vital and relevant to its users. This is the kind of software we should all aspire to create.
But bugs mean that something is not working. So what should we do, just leave them be? Of course not! Prioritize the bugs from critical to minor and fix the most important ones first. A developer can never find all of the bugs that need to be fixed on his own. While we are not bug hunters, bugs have a way of hunting us down.
The most important thing to remember is that you must focus on fixing the critical bugs that are affecting the usability of the software first. Using a bug catching mechanism allows you to detect many bugs and give generic errors like “Cannot continue due to an unexpected behavior. Please try again.”
So how do bugs influence the failure of software? It comes back to the timing schedule. You can clearly see that bugs increase over time. You recognize that they are unforeseen. And they take time to analyze and fix, which is just one more reason why trying to give an exact completion date for a project is not a wise business decision.
Spend Time Educating
It is important that your clients understand the nature of project development before signing on to develop a project. If you have a client that demands a deadline for completion, you should work on educating them about project development and decide whether or not this is someone you can work with. Failure to understand this basic process will ultimately lead to a failed project.
If you spend more time educating your client than trying to force your developers to perform within rigid deadlines, you will find that both your client and your developer will be happier with the process and the completed product, which is really what we all want, isn’t it?
Flexible is the keyword here. Creative projects require flexible schedules, and software development is a creative project.
Get In Touch
Contact us today to learn more about our custom programming options. The initial consultation is free!
Editorial by Jani Seneviratne.
