How to Tell When You’ve Been Given a Good Project Estimate

Let’s say you are a member of your organization’s IT Department, and you have engaged a third party vendor to develop a customized software solution for your company. When they provide you with a cost estimate for the statement of work, you will have to determine whether the estimate at hand provides good value for your company and can be delivered by the proposed timeline.

Here are five suggestions for how to determine if your software vendor has made a good project estimate:

Don’t Cut Corners During the Design Phase

In the hurry to get a Development SOW signed, design is often taken as ‘easy’ or as a ‘given’; however, rough drawings or high-level descriptions of what software should do does not provide enough information to understand the true complexity of a project. Good design often takes months. Companies who have deep experience in software development will have an active design team that will work hand-in-hand with the project Architect AND end users to detail each and every flow, feature, and edge case for a project. If your software vendor provides you flow diagrams, high fidelity prototypes (such as Invision click-throughs), detailed written requirements, and have had at least two full design feedback sessions with your software end users, you are in a good place. Money spent on design will almost always save you time and expense on the overall project.

Estimation Documentation is Not Kept Secret

A good project manager will have systematically estimated a project from a breakdown of project tasks. A bad project manager will present an entire screen or flow to a developer and say, “How much time do you think all of this will take you?” You can easily tell the difference between these two types of managers by asking to see some supporting documentation for an estimate. Now, you may not be invited to see their cost breakdown structure, but they should be able to tell you how many FTEs are expected to work on the project at any given time, and they can also show you a proposed project schedule, broken up by features. If you ask for supporting documentation and they are able to provide it within a day or two, they are likely of the good project manager sort.

Their Schedule is Consistent with Your Schedule

As the client, this software project probably isn’t the only thing on your plate. You are the one who has the information about the availability of your employees to liaise with the software vendor, so if you see a proposed project schedule that is much shorter than any other project you have done, you need to interject and say something. It’s likely that the vendor will have a clause in the SOW that requires a certain response time from your employees, so you might be on the hook for a change order if your employees are not able to keep up. If the vendor anticipates being too fast for you, it’s possible that they could staff fewer developers on the project.

QA is Loud and Proud and Takes a Bunch of Time

QA is one of the most underestimated phases of software development. Software developers innately don’t anticipate producing a lot of bugs, and it can be very tough to understand how “wrong” you can be in your work. Additionally, it is often in the QA phase that edge cases with particular data sets will surface – this is difficult to anticipate, even with thorough design. A good software vendor will have come to peace with their inconsistencies and will estimate At Least 40% time for QA on top of Development and perhaps more depending on the complexity of the project.

Previous Projects Are Mentioned

You may not see any visual evidence for this, but if the vendor project manager has cited previous projects as a basis for their current estimate, it’s likely that they have an understanding for how your team works or the scope of work at hand. You can have a conversation with them to try to figure out how much they have taken previous experience, either with your team or from another project, into account when creating their estimate. If they haven’t, perhaps you should get a competing estimate from a different team.

While it might be considered a ‘win’ in some ways to get a project estimate that is lower than it should be, the purpose of project estimation is to make sure that everyone has a thorough understanding of what the project is. The project scope and timeline will drive the project costs – not the other way around. If you make the most of the conversation about what is going to be done, what resources are available to do it, and how long individual tasks will take, the costs will follow naturally, and you will be able to deliver your project on an expected schedule and budget.