Business-focused custom software

Software estimates can be tricky. One challenge is remembering what to include. When people put together their estimates, they usually focus on the features but often forget some critical pieces that aren’t functionality specific.

You might think that as a customer you don’t need to concern yourself with this. To a degree you are correct. But if your software roll-out has dependencies that make hitting target dates critical, you’ll want to feel confident that the estimates are accurate. Also, some developers who charge on an hourly basis can low-ball projects by providing estimates that exclude these tasks. It will be a rude awakening for you when you realize that the software is done but not deployed and your budget is gone.

So it doesn’t hurt to ask the developer if they have included these tasks in their estimate:

System setup

This might include any of the following:

• Install software (developer tools, database, etc.)
• Setup and configure any existing code

I’ve worked on projects where the system setup took weeks! That’s pretty unusual, but you don’t want to miss this step when thinking about how much time something will take.

Testing and fixes

Everyone knows the software won’t be perfect at first – that’s why it needs to be tested. But developers need to test the software too, and they’ll need time to troubleshoot issues and fix the problems. Make sure the estimate includes time for this.

Meetings and status reports

Not all projects require a lot of meeting time, but most involve some kind of status reporting even if it is via email. This takes time and needs to be included. And some projects require meetings for other purposes, like integration or code reviews.

Deployment and Installation

Most software needs some kind of install program or process. Even web applications need a process for moving the software to the production server. And there are often configuration issues that need to be addressed even after software is deployed.

Documentation

Most developers hate writing documentation, so it isn’t surprising that this slips through the cracks. But most software should have some kind of documentation, even if it is a simple readme file that identifies source code setup or pre-requisites.