Three Mistakes to Avoid When Scoping Your Project or Idea

Whether you’re the client or the agency, there are some big mistakes that can be made in the early part of a project that could lead to cost overruns, delays, and plenty of angst on one or both sides. If you’re the client, there are things you can do to help the process be successful. And if you’re with the agency, there are ways to both impress the client and make sure the designers and developers working with the client won’t be caught off guard.

Don’t Assume Features Are Easy to Produce

When it comes to web or mobile app development, there are very few things that are as easy as “just add a button here” sounds. For instance, a phrase like that will trigger a number of questions in a developer’s mind, like:

  • What does that button do?
  • Does it call data from, or put data in, a database?
  • Does it use AJAX or PHP (or any other language), and therefore will the page refresh?
  • Can the feature be implemented purely on the front end, or is back end code required?

These are the things developers think about when asked to add new items/features to a website or app. It sounds easy to a non-developer, even to some of the Olio staff that don’t code every day, but not to a seasoned developer.

Another example is hosting. Complex web apps have complex hosting requirements; you may choose:

  • NGINX instead of Apache
  • the long-term support edition of Laravel instead of the most recent stable version
  • Ubuntu Linux over CentOS Linux

And so on. Marketing sites, blogs, and other small websites fit great on shared hosting services that cost less than $10 a month, but products/web apps often need to be hosted on a virtual private server/cloud virtual machine or a dedicated server for scale, security, manageability, custom software requirements, and so on. Instead of $5 or $10 a month, you’re looking at at least $25 or $30 a month, up to $300 a month, *without* any management or support.

Outline The Work

Similar to assuming things (features, buttons, charts) are easy to implement, if you don’t outline the work to be done, it’s easy for features, big and small, to get missed. A table of contents outlining the major deliverables in the app is usually what the whole document falls back on

To help prevent this, what Olio likes to do is create a section for each major deliverable in the project scope, and then roll that up into a point form list. Once that’s done, you’ve essentially got a really good checklist for the major things in the project; then you can rely on each section to specify how the app should look, how it should work, back end implications, and so on.

Have a Blanket Statement of What the App Won’t Do

Some developers will assume that the website/app they’re working on should do things that aren’t specified in the scope, or they may pepper you with questions about other niceties that may not have come up during the initial scoping period.

To help prevent this type of scope creep, and to maximize the developer’s time, it’s a good idea to have some blanket statements covering a set of non-required features versus putting the ‘what it won’t have’ in each section. For example, one paragraph that says something along the lines of:

Assume, unless otherwise noted in the description for the module/application, that table views will not have filtering, sorting, pagination or any other data manipulation or reading aid. If you feel an application or view requires a reading aid, please advise and we will accommodate it in the plan.

A short statement like that helps ensure everyone has the same expectations for what the app will and won’t do, but also gives you the opportunity to focus on what the app *does* do when writing the project scope.

If you have any questions about the mistakes we have identified, or want to chime in with your own things to avoid when scoping out a project, we would love to hear them!

Derek Silva