Defining project scope in software engineering

Introduction

When businesses are searching for a vendor for their software projects, the number one question on their minds is often, ‘how much will the project cost?’. But unlike products we purchase off the shelf, custom software development doesn't come with a clear price tag.

Instead, vendors work with clients to fully understand their vision, their needs and their budget. Then, they can use that information to define the scope (which includes specific goals like deliverables, features, functions and tasks) and provide an estimated cost and timeline for the particular project.

For more insights into how the process works, let's take a look at the two most common approaches to estimating costs, as well as a few things to keep in mind when comparing vendor quotes.

The 2 approaches to estimating a software project

Scope-based approach

The first is the scope-based or fixed-cost approach, which provides a hard cost for a specific set of features.

Once the vendor and client have completed the discovery process, the vendor prepares a document outlining exactly what is to be built, how long it will take to build, and exactly what it will cost the client.

One benefit to this approach is that, as long as the scope does not change, there will be no uncertainty about cost or timeline, so a company with strict budget constraints can plan ahead with relative security.

However, this approach requires the vendor and client to be very precise in outlining the scope of the project. Like a contractor providing a fixed cost for a construction project, a software vendor needs to see a fully finished blueprint in order to understand and convey the final cost.

Under the scope-based system, there is no room for flexibility, and any changes or additions will incur additional time and cost.

Another ‘pro’ for the scope-based approach is that any surprise costs are the responsibility of the vendor and not the client. If the vendor estimates any piece of the software scope incorrectly, as long as the discrepancy isn't due to a change order, the extra cost is on them.

This added security comes at a price, because when vendors take on a fixed-cost or scope-based project, they build in a risk budget to protect against those unforeseen costs, and there's no refund if that risk budget turns out to be unnecessary. Just like an insurance premium, clients have to pay whether they end up using it or not. This means that, if everything goes perfectly, the fixed-cost approach will end up costing the client more than the capacity-based approach.

Capacity-based approach

The capacity-based approach offers a lot more flexibility than the other. While vendors and clients still work together to outline the goals of the project, the vendor does not provide a guaranteed price or timeline. Instead, the vendor assigns a dedicated team of specialists to the project, and the client pays for the team's time and any expenses related to the project.

Capacity-based projects usually move forward in small increments called ‘sprints’, wherein the developers complete small segments of the project and then sync with the client to assess progress against goals and discuss any changes that need to be made.

While this approach does not come with a predetermined price, experienced vendors can give clients a fairly accurate idea of what the total bill will look like based on the size of the team and the estimated time required to complete the project.

The individual sprints give both parties an opportunity to compare progress to cost and make adjustments to the roadmap as necessary to stay within the client's budget.

Choosing an approach

It's up to each customer to identify the approach that works best for them, but at Syberry we usually recommend the capacity-based system, because it allows clients the most flexibility and control over the project.

What's more, in situations where the blueprints are clearly defined ahead of time, this approach almost always comes out cheaper for the client because it doesn't include that risk budget, which the client must pay whether there are unexpected setbacks or not.

Whichever route a company chooses to go, we recommend getting quotes from several vendors before choosing a partner. If vendors are using the same hourly rates, the difference in quotes from one to the next should not be more than 15 to 20 percent. If any quote seems ultra high, you should question this, but extra small quotes are the biggest red flag, as they may indicate the vendor has misrepresented the cost to win the contract and will surprise the client with a large invoice later.

The last thing anyone wants is to sign on with a vendor that has artificially inflated a fixed-cost budget or underestimated the cost of a capacity-based project upfront only to expand the timeline and the bill once work begins. If the estimate seems too good to be true, it probably is.

Whether you choose the scope-based or capacity-based approach, ensuring both parties have a clear understanding of the goals for the software before any work begins is one of the keys to a smooth, efficient process.

If you'd like to learn more about ensuring a successful custom software project, you can read the reasons why software projects fail.