The Truth About Software Project Delays
If you could completely eliminate delays in your software projects, would you? Every single software developer on the planet would probably answer with a resounding “Yes!” After all, if you can fix the duration and frequency of delays, you’ll acquire a reputation as a fast developer. Clients will seek you out as somebody who can deliver on time and keep projects moving along. At that point, you’ll be able to give yourself a hefty raise (or negotiate one with your boss).
Unfortunately, delays in software project sometimes feel out of control. That’s because they can seem to come from every direction.
If it was as easy to fix as pushing a button, nobody would ever experience these kinds of delays again. Yet this is one of the most common issues developers face. Is it because they lack talent? Of course not. It’s because they keep making the same costly mistakes over and over again.
Of course, sometimes it’s truly outside our control. Issues arise that lead to project delays and there isn’t really anything we can do.
But if you want to drastically reduce delays in your software projects, keep reading:
Reason 1: Team Member Turnover
This is among the most common causes of project delays and problems. Perhaps ironically, it’s made even worse by depending on an in-house team. As of the time of this writing, an average developer working at a startup in Silicon Valley will only stay at that startup for between 1-2 years. It’s not uncommon for projects to take 6 months. So you have a problem — developers leaving in the middle of the project.
This problem is compounded by sick leave, vacation time, childbirth, and emergencies. When you have a key team member leave in the middle of the project, what happens? Right. The project slows to a crawl and you have to go into damage control mode with your client (see reason 3).
If you’re someone who has never looked at outsourcing before, it might surprise you to know that the best remote outsourcing agencies build their project management systems to defend you against turnover. For example, at Capital Numbers, we work in small, agile teams, ensuring that even if someone has to leave for weeks or months, they can quickly be replaced with no additional downtime.
Reason 2: Third Party Technology and Integrations
The second most frustrating issue for lots of developers is dealing with third party technology. It’s maddening when technology and integrations don’t do what they’re expected to do. Sometimes you have to connect with the customer support for these software and applications, sometimes it isn’t even available, and often you don’t even know that something isn’t working until it’s supposed to be working and isn’t.
So this clearly leads to delays. Sometimes the third party software needs to be updated, customized, or otherwise attended to before it’ll even work. For example, we recently had to rescue a project that depended on third party technology. This technology was beyond the skills of their in-house team to work on and customize. The result? A 6-month delay in which the client was simply wasting time and money, until he came to us and we fixed it.
The best thing to do in this situation is to map out potential uses for third party software during the planning phase (below). Highlight any unknowns or potential pitfalls around this technology. That way you can perform the necessary research before making it a critical part of the process.
Reason 3: Poor Expectation Management
Almost any client based business has issues with managing the expectations of their client. They want to make their client happy so they often make promises in terms of deadlines and deliverables that can’t be kept. Here are the two key areas where you expectation management might be failing:
Lack of Planning
Your clients may not want to “waste” time in long onboarding processes or in consultations that take weeks. The fact is, these sessions are necessary if you want good outcomes.
The work you do in planning and onboarding your clients, mapping out strategies, and determining expectations will pay off in dividends in the middle and end stages of the project. If a client asks that their dollars be spent only in the actual work of development, simply insist that it’s a bad idea to start development without knowing where the project is going.
If you do start quickly, but then have to stop in the middle, you’ll lose as much time or more than if you skipped the planning stage.
Unclear Software Requirements
Similar to the above, your team should have a very clear picture about what the software can and should actually do. If you don’t, there’s no point in even starting to develop the software. Your project will rapidly lose momentum if you have to stop regularly to omit certain requirements or add new ones.
Ambiguity kills speed. Either the developer will have to guess at the requirements, which is risky and might cause a rework later, or they’ll have to stop and ask for clarification. The best thing to do is to clarify project requirements before development even starts.
A broad list of requirements is not enough. Get as detailed and specific as possible if speed is important to you.
Reason 4: Slow Internal Interfacing
Consider — how long does it take your decision makers to make the critical decisions needed to move a project forward? Moreover, how well can your teams respond to requests from the development team? In lots of cases, the developers will need things from the marketing or sales teams. How well they all work together will go a long way toward keeping the project moving forward smoothly.
Proper planning and good client management will account for most of your success. What you do at the beginning stage of the project will lay the groundwork and expectations for the rest of the project. Try to account for as many unknowns as possible and don’t just “wing it” because this will lead to delays. Instead, encourage open communication from the very beginning, speedy responses between teams, and consider using remote developers to account for high team member turnover.