Do I need a scope document to get a quote?

No. Scope documents are used to justify an inflated development cost.

Question asked by James on October 30, 2016
Paul Keck Badge

Your Developer’s Dirty Little Secret

If your development firm requires a scope document to give you a fixed price, you’re likely getting handled by sales. The numbers you see in a proposal are meant to look attractive and win the work. They are not meant to represent the actual estimated deadlines or cost.

Shark in the water

Your Development Projects Always Take Longer Than Promised

Why is that? Because software is complicated with all kinds of dependencies. Large delays, like milestone approvals, can be quantified easily. However, they seem be forgotten just as easily by the end of the project when looking in the rear view. The small delays, like an email sitting in someone’s inbox, often go unnoticed and can mount up pretty quickly.

A significant portion of delays creep in when new information or additional clarifications to requirements force change. Changes occur on large and small scales too, and can really cut into time left before launch.

Your Development Projects Always Cost More Than Promised

Why is that? Because software is complicated with all kinds of dependencies. When people are waiting on delays or rebuilding things because of new information, resources are burning time but not making progress. This translates into a higher cost which the development company must make back somehow (more about that later).

You‘re Not Alone

The 2015 version of the Standish Group’s CHAOS Report has recently been released, and the results are not surprising. These reports have been published yearly since 1994 and are a sobering view of software project definition and management. Data from 50,000 projects was included in the report, and covers all kinds of projects ranging size and complexity.

The report shows that only 29% of all projects were successful in 2015. Success is measured by being on time, on budget, and with a satisfactory result. Satisfactory means “roughly” on time and budget with deliverables “mostly” meeting the original intent. Additionally, the typical overruns for time and cost amount to 189% of the original estimates! That’s almost double, and it’s the average.

189% project budget overrun average

A Major Shift To Agile Workflows

The old-school project planning methods started things off with a waterfall lifecycle, which assumes that software development follows a nice and tidy path with phases that go like this:

Image credit: Article on

Most of us know that projects never actually pan out this way unless you have very strict requirements, the blind resolve to follow them no matter what, and a large budget that embraces waste.

Instead, we all follow some form of agile work flow where change is expected and iterations tackle partial deliverables. Each iteration roughly follows the waterfall lifecycle, but the project as a whole does not, and requirements change often. You can jump on the phone with any development shop, and they’ll tell you that they’re “very agile” because anything else is considered out-dated.

A Major Shift To Lean Methods

Lean methods are terribly effective when developing software, and we’ve certainly latched onto them at BOUNDLESS too. The buld-measure-learn loop shown below is the driving force for Lean. It is used to focus on small numbers of features starting with the most essential ones that address the greatest need for users. The idea is to measure the effectiveness of those features with real people, adjust the plan, and then continue development. This makes requirements even more volatile because even the project team can’t fully anticipate what should happen next. From our experience however, it’s by far the best way to build good software. Many startup founders know about Lean methods already, and every development shop will soon be touting their “lean capabilities” on top of agile.

Build measure learn loop

Something Doesn’t Add Up, Though…

OK, so many development shops claim to operate in a way that allows requirements to change based on users. They also write traditional contracts which rely heavily on requirements so they can promise deliverables at a fixed cost. They're written with a scope that fully describes the piece of software to be built, and assigns a cost to do the work based on estimates. This scope and cost is the requirements phase of a waterfall lifecycle shown in the earlier diagram above. There is also some level of design built into a contract so that reasonable estimates can be achieved.

Wait a minute... If the requirement and design phases are locked away in a contract, how can development shops be “Lean” or “Agile” at all?

They can’t. However, they can pretend to be. There are a few ways the uncertainty of software development is handled when a company is bound by a traditional contract. And none of them are good for the customer or for the success of the app. Have a look…

Build In Cost And Time Buffers

This method is probably the most effective, and is employed by larger companies with a good amount of experience. They know that complexities and unknowns translate into higher cost, so a time and cost buffer is built into the estimates. The more questions that exist when creating a bid, the larger the buffer. Of course, you need better salespeople with higher salaries to sell the same product at higher margins. This also increases the buffer. This buffer is then tapped when requirements are changed or clarifications are encountered. In short, big companies charge a lot more than necessary for the vast majority of projects.

Change Orders

Designers, architects, and coders need to make hundreds of decisions during a project which have no associated requirements. Each of those decisions is an opportunity to charge more money and push deadlines. So project managers will present a select number of these decisions to the client. Change orders usually sound reasonable at the time, but they can have a huge impact on deadlines and cost (remember the 189% statistic?). They also serve as a great way to document client decisions when the inevitable “What the hell happened?” question is asked.

Silently Cut Or Scale Back Features

Any given product feature can be build many ways, and each way has an associated effort. Decisions can easily be made along the way to reduce cost when budgets start to run thin. Features built this way still technically fulfill the requirements, so the development company is safe. They can also mount up and make for a crappy user experience.

It’s also fairly easy to eliminate features completely if they’re not spelled out in the requirements. For example, you might assume that “The ability to create users” includes the ability change user details after you’ve created them. That’s pretty implicit, right? Well if you don’t like the decision to cut the user edit screen, you can always fork over some more money for a change order :)

Finally, there is a huge time-sync called “testing” that can easily be cut when time and money runs out. Contracts very rarely specify the amount of testing that’s required to make software great, and testing time can easily be used for new features when schedules go sideways.

Development Shops Know This Already

Having the experience, development companies know there will be changes that extend timelines and raise the budget. They also know that there will be plenty of opportunity to save money along the way without client input. The client doesn’t know this. So they’re on the hook for all the money if things go peachy, and more cost if they don’t.

It’s time we take a hard look at the contracting process for app development, and make some changes.

The Root Of The Problem

Traditional contracting drives this bad behavior because the agreements typically define the following in restrictive ways:

  1. Scope is defined so the client knows exactly what is being delivered.
  2. Price is fixed so the client knows what it will cost.
  3. Price also defines effort and calendar time, so these are fixed too.
Yay! Now the client knows exactly how everything will play out… Which is just another way of saying that there is a false sense of security.

So How Do We Fix It?

We need to discard the notion that scope/price/time can be successfully defined in a complete way at all. Here’s what a good software contract contains:

  1. Loose scope focused on users and outcomes instead of features
  2. A pretty darn good estimate of price based on experience
  3. A pretty darn good estimate of time to complete based on experience

The contract sets the expectations properly. Scope (in terms of features), cost, and time to complete are all subject to change based on smart decisions made by smart people during the project. These decisions must also be based on aggressive priority management, but that’s another article entirely. Participants in the agreement can trust that the right decisions will be made because reputable companies want their projects and their clients to be successful.

Traditional contracts which define and restrict these control factors end up pitting contractor against client. They make for poor working relationships and poor software quality. Since the control factors are in conflict all the time, writing contracts which make this clear is the first step toward actually working together.

Instead of writing contracts that we “think” are good, Let’s start writing contracts that allow us to work together and build good software.

Have a question you need answered?

We've been helping entrepreneurs like you build great apps for a long time.

IMG_0133-2.jpg contact-paul.png

At BOUNDLESS, my co-founder and I have over 35 years of collective experience building software. We’ve helped many startups clarify their ideas, find workable solutions, and build their apps. We love answering questions and helping entrepreneurs get started. Fill out the form below and we'll answer your questions regarding building an MVP, lean app development, choice of technologies or any other subject you think is relevant!

Thank you for your question! Here at BOUNDLESS we take helping people very seriously. Someone will be in touch shortly to follow up with any questions or to give you an answer to your question.

Use Lean methods to plan and validate your app idea before you build it.

Over 50 pages of step-by-step instructions on how to develop your idea and validate your business plan before you spend time and money building your app.

I want to get started on my own