A common stereotype of software development projects is that they are going to go over budget and not be done on time. This stereotype is well earned as a significant amount of projects do go over budget and take longer than expected. The million dollar question is why? I think it boils down to a few factors depending on who you partner with to do the development work. Below are the top factors I have found to cause budget overruns and missed deadlines.
-
-
- The software development company knowingly underestimates the project
- The software development company is incompetent to do the project
- The person putting together the estimate is too optimistic
- The project isn’t scoped out properly
- The client changes direction frequently
- Scope creep
- Estimating Software is very hard to do
- Having to estimate new tasks when taking over a project from another company
- Developing apps is hard
-
The software development company knowingly underestimates the project
I wish I could say that this doesn’t happen, but unfortunately it happens all the time. When I put together an estimate, I try really hard to be conservative in all the hours. Often after submitting a proposal I will be informed that my bid was significantly higher than other companies’ estimates. A certain degree of variation in estimates can be expected. When another company’s is several factors cheaper than my estimate, I know something is off. We have been doing app development for 10 years and I have a very good sense of how long most tasks take. While a really low estimate can be attributed to any one of the items I listed above, I know that underestimating projects happens all the time. Some companies just want to get you in the door and get a signed contract in place and then don’t care if they go way over budget.
The software development company is incompetent to do the project
Incompetency can factor in several different ways. If a dev shop doesn’t know what they are doing for part or all of your project than any estimate they give you is just made up numbers. So the numbers aren’t based in reality to begin with. The length of time it takes a developer to do a task that they are unqualified for can vary dramatically. A really good senior level developer that has a broad development background can usually pick up the skills needed to do an unfamiliar task pretty quickly. An average or bad entry level developer may spend days or weeks on a task trying to figure it out and may never make progress. Another big factor is the knowledge level of the company. If a developer has a mentor to help them through a challenging task, it can exponentially speed up their ability to get the task done quickly. If the overall knowledge level of a company is low or you have an independent developer that doesn’t know what they are doing than you might just get a huge unexpected bill for some or all of the tasks worked on.
The person putting together the estimate is too optimistic
Optimism in regards to estimation is a widespread character flaw of many developers. I see this at my company all the time when I ask different developers to help me estimate a task. The problem happens when a developer assumes that everything will go perfectly when they code the task. In their mind they think of the quickest path to completion. The reality is development rarely happens without any issues.
-
-
-
-
- Bugs happen even to the best of developers.
- Developers get stuck on an issue for longer than expected.
- The development tools have a bug in them.
- Apple’s or Google’s software has a bug in it that you have to work around.
- There is poor documentation on what you are trying to do.
- The client makes more tweaks than normal.
- These are just a couple of the endless factors that can make a given task take longer than expected. When estimating a task you have to draw upon experience and know the ability of your team to come up with a realistic estimate for each task.
-
-
-
The project isn’t scoped out properly
Fully scoping out a project is a balancing act for most app development companies. We prepare many estimates to land one contract. Putting together estimates is a time consuming task. When we prepare an estimate we break down the project in a line item google spreadsheet. I explain to potential clients that my estimate only covers the items listed and we work with them to make sure we have a comprehensive list. I make sure they understand that any items out of the scope of that document will increase the budget and time to get the project done. I know that many companies simply do not go to that level of detail when preparing an estimate. I try and explain to potential clients that every single task that needs to be done in an app, no matter how small, is going to have a time associated with coding that task. Often what they assume will be easy to do will actually be complicated. That goes both ways though: often what they think is going to be hard is actually simple. The problem that often happens is that a “simple” app will need tons of auxiliary management pages to make the simple task doable. People are often shocked when I start listing out all the things that will need to be built out to make their app functional. Many apps that are simple on the surface can be extremely complex to build out and will require a huge budget to achieve.
The client changes direction frequently
A huge unknown when I am putting together an estimate is what a new client is going to be like to work with. It is super frustrating to have a client that is constantly changing directions after development has started. When a client like this understands that a change in direction usually means an increase in budget than it isn’t that big of a deal. Changing direction often means that time spent previous to the change often has to be thrown out or that programming tasks have to be done over or at least modified. These things always have an impact on budget and time frame. Few things frustrate me more than a client that shifts direction frequently and then complains about budget overruns or missed deadlines.
Scope creep
Scope creep is almost universal. Little things come up that were unforeseen when you first scoped out the project. When I prepare an estimate I always assume a little bit of scope creep is going to happen and build in the budget to handle that. I add a 20% contingency bucket of hours on top of my base hourly bid to cover unforeseen complications and minor scope creep items. Frequently changing direction and scope creep are the number one factors to budget overruns on the projects that Clever Coding works on. On a large scale project it can be easy to end up with hundreds of small tweaks and scope increases that can easily cause a significant budget overrun and timeline increase. Big scope increase items are easy to catch. We always bring those items to the clients attention and estimate out the task and increase the timeline accordingly. But often the pattern of endless small tweaks is not caught early enough to make the client aware of what they are doing to the budget and timeframe.
Estimating Software is very hard to do
I have estimated literally thousands of projects in the last 20 years. To be absolutely honest it is educated guesswork at best and pulling numbers out of the air at worse. Some tasks are easy to estimate. We have done similar things hundreds of times and I pretty much know how long it is going to take. Since we have been doing app development for 10 years this covers the bulk of tasks that get estimated. Some tasks have a little bit more unknown to them. Maybe we have done similar stuff many times before, but nothing exactly like what a potential client needs done. These tasks take a little more educated guess work than the simple tasks. Some tasks are just downright hard to estimate. We have potential clients bring some amazing ideas to us that are unique in nature. Depending on the technology that will need to be used to develop the task and how many online resources will be available to help the developer, it can be really hard to estimate these sort of tasks. When estimating such tasks, I get super conservative and make the potential client fully aware of the unknown factors involved. Sometimes on these truly unique features of an app you get it right, sometimes you overestimate how long it will take and sometimes you are flat out wrong and don’t estimate enough hours. I strive really hard to provide conservative and accurate estimates. I get it right the majority of the time, but because of the complex nature of software development and the many unknown factors I still get it wrong from time to time. That is way I try and be as transparent as possible in how I arrived at the numbers I did.
Having to estimate new tasks when taking over an app project from another dev company
We take over projects that were started at another app development company all the time. I call these project rescues. I am extremely proud of all the projects that were not getting finished at another company that we are able to take over and help get over the finish line. I have heard countless horror stories of projects gone bad at other software development companies. We have helped rescue many such projects. We always start these projects by doing a code review of what the other developers created and then providing an estimate for what it will take to finish the task. The problem is that taking over someone else’s code can be a bit of a pandora’s box. Especially when there is a significant amount of code. When providing an estimate you can not simply review tens of thousands (or more) lines of code and know exactly how well it is going to perform. There is no easy way to predict how many bugs you are going to find or what parts of an app are going to need to be rewritten. I always try and be conservative with our estimates and I explain to clients that after we get in and have been working with the code for a few days/weeks we may have to adjust the budget depending on what we discover. The truth is you never really know what you are going to get when you take over another app development company’s code.
Developing Apps is hard
To end I would just like to state what I hope is obvious to most people. App development is complicated and is more of an art form than anything. It takes a lot of talent to build elegant solutions to complex problems. If you had ten skilled developers build an app you would get ten different ways of doing it. On the surface they make all look the same, but the code underneath will always be unique to each developer. Each solution will have its advantages and drawbacks. If you have skilled developers then all ten solutions should be totally acceptable ways of creating the app. Creating an app is an extremely creative process. As you journey down the path from idea to reality, you never really know what the journey will hold. There will be detours and bumps along the way and usually at least a couple of items that get downright nasty to complete.
Conclusion
These are the most common reasons I have found to cause app development projects to go over budget and miss deadlines. The reality is you could add another hundred reasons to the list. This is what makes deciding who to partner with to develop your app such a complicated task. You should always investigate several companies before you make your decision. Get several estimates before you decide who to go with. If an estimate seems too good to be true, than it probably is. You really do get what you pay for in software development. If you decide to go the cheap route you will often end up with cheap/buggy code. You should put a premium on past experience. Make sure the app development company you choose has a proven track record of delivering high quality apps. Get references and check them. Understand the companies app development process and make sure that it is going to be a good fit for you. There are many high quality app development companies out there. But the reality is there are probably more bad ones than good ones. If you do your homework and choose wisely you will have the best opportunity to have your app project done on budget and on time.