6 Common Reasons Software Projects Take Longer Than Expected
It is true that one of the major problems with building web or mobile apps is that software projects take longer than planned.
In this article, we take an honest look at the common reasons why projects run over their initial time estimates. For each item, we offer suggestions on how, as a software product/software owner, you can help manage these issues and keep your project on track.
1. Software Planning: Insufficient Effort/Optimistic Estimates
It truly takes time and experience to make an accurate software plan. With software, you have hundreds of tasks and several resources to coordinate with overlapping dependencies. And unlike building a house, these tasks are largely intangible.
The truth is, not all clients want to spend 1-2 weeks for planning upfront. They want to focus their dollars on pure development. This is completely fine, as long as everyone recognizes that the plan driving the project is a loose roadmap and nothing more.
When you do take the time to make a solid plan, your team should have the experience to include all the non-development tasks, like environment set-up and test plan creation, that go into building great software. When your plan ignores a lot of small, necessary tasks, it is only reasonable that your project will take longer than planned.
Another common phenomenon in project planning and estimation is that software developers provide optimistic estimates. By this, I mean they think they can complete tasks sooner than is realistic. A good project manager will add a buffer to estimates so to account for unknowns along the way.
When reviewing a software project plan, ask your team about non-development tasks and if they are included. You can also ask them how accurately their developers estimate their work, and if collaboration, testing, and re-work are included in the estimates.
2. Software Requirements: Changing, Missing, or Unclear
A project plan is based on requirements. It goes without saying that if you change your requirements or identify missing requirements during the project, the project scope will be impacted.
One place that a project can lose momentum, however, is with unclear requirements. When there is ambiguity, a software developer will do one of two things: guess, possibly causing rework later, or will ask for clarification.
In both cases, the project timeline could be impacted. By guessing, there may be rework later in the project. If the developer stops to ask, the time spent to ask, clarify, and then wait for the answer also adds time. If there are enough unclear requirements, then you will start to see the project slip.
During the requirements phase of your project, take the time to make sure your requirements are clear, detailed and don’t leave room for ambiguity.
In the example of building a house, it is not sufficient to say you want a door to the back porch. You need to say how big the is door, is it a single door or double door, does it have windows and a cat flap, is it made out of wood or metal, and does it swing in or out.
2. Development Team: Losing Key Players
Software is a very transient industry with developers staying 1-2 years at each company before moving on. It is not uncommon for a project that lasts 4-6 months to have one or more of its team members leave for another job.
Because a project team builds momentum over the course of a project, if you lose a key team member during the course of development, it may cause a project delay.
A new resource will need to be found, or the work split between the remaining resources. In either case, it may disrupt the energy of the team and their ability to produce at the same rate as before.
As a product owner, you can ask your software partner what their contingency plans are for staff changes during your project. A software firm with a sizable team will be able to absorb the change fairly quickly. A smaller company may have partners they work with or may have known contractors in their network who can step in if necessary.
3. Business: Making Decisions and Providing Information
One thing that is squarely in the control of a client is getting the necessary information and decisions for your software delivery team, and doing so quickly.
At certain points along the project, your software team will need your input. They may need hi-resolution graphics from your marketing team, or API documentation from your internal IT team, or approval on a design. Sometimes the resource on your team can work on other things while they are waiting for your response, and sometimes not.
To keep your project on track, educate your internal stakeholders that being responsive and turning around requests quickly will speed up the project delivery and save on project costs.
4. Technology: 3rd Party Integrations/Technology Challenges
We have all experienced a time when our technology didn’t act like we expected. The truth is, sometimes technology will cause unforeseen issues and will simply not work the way you want it to.
In the case of custom software, you could run into issues if you are integrating with a 3rd party tool that is brand new, or really old, or if you are using the technology in a way that it wasn’t originally intended. The tools or components you are using might be sensitive to your hardware or operating system versions. Or it could be the weather… (probably not, but it might feel that way!)
If a roadblock caused by technology happens on your project, there are a number of things your team will do to determine the issue and fix it. It’s frustrating but all you can do is get through it.
With regards to the project, it is safe to say the issue investigation and experimenting with possible solutions will impact your project timeline.
During the project planning phase, a good project manager will highlight uncertainty around any unknown technologies and apply a risk factor and buffer to the tasks. Even so, tried and tested technologies can unexpectedly cause issues.
Ask your software team upfront if there are any risks with the technologies you are using or how you are using them and what steps are being taken in the plan to not let these known risks cause a schedule delay.
6. Software Reviews: Catching Issues Too Late
Frequent reviews and demos are one great way to stay on top of your project.
A good rule of thumb is to review the actual software being built every 2-3 weeks. This is enough time for your software team to make enough progress that you can see, while not getting so far off track that you can lose a lot of time re-working a bad assumption.
During the review it is a good idea to keep your requirements handy so you can confirm the development is staying on target. If it’s not, now is the time to discuss and get it addressed.
Want More Information? 6 Items That Are Non-Negotiable When Building Software
Before you get started in developing your software app, discover what is non-negotiable in building a successful software application. In this guide, we share how to build your application on a solid foundation from nearly twenty years of our own personal experience.
You can grab a copy of the guide below and share it with your team!