This is the first of a several part series on the process of scoping a pricing web and app projects. Here we’re just going over some of the basics and making sure we’re all on the same page as far as definitions, general process, etc. before moving onto more information on actually putting together your project specs.
Pricing and scoping projects is perhaps the biggest headache in development, especially for smaller shops. The larger the project, the more complex the scope and higher the price. Smart scoping and accurate estimation will increase your organization’s efficiency, cover your back in difficult situations, and is the first step towards good future client interactions. Below, we are going to break down each step we take when scoping and pricing a project. The aim of the “Break It Down” series is to become your worksheet for pricing and scoping your own projects.
Determining Unknowns
Scoping a project is about figuring your time and costs. Once you estimate your time, then you can estimate price. There are a few things to keep in mind when figuring out times.
- Do you know how to do everything you are going to be doing? Have you done it before?
- What are the items that you don’t know about, and how long it will it take you to either learn or find someone who can do that work?
- Do you know all the technologies involved in the project or will you need to hire out a portion of the work?
Pro Tip:
If you have to hire a person or group to work with a technology that your team does not know, also hire a secondary consultant to double check their work.
These are key items because they can all contribute to creating unknowns that are potentially very time consuming. Sometimes, if there are no unknowns, a big project can turn into a small, very profitable project. But if you have unknowns that turn into problems, a very small project can become a major loss, a lot of stress, an upset client and potentially much worse.
Landing the Sale Before You Scope Anything
So many times I’ve heard the question from potential clients during the sale, “Is this a 10K, 100K, or million dollar project?” The fact is, clients often have no idea what they are actually looking at in cost. Before they hire you, you need to let them know at least some sort of range. Based on my experience, these are the ranges we typically give clients. Yours will be different based on your own experience.
- < $10,000
- $10,000-$25,000
- $25,000-$50,000
- $50,000-$100,000
- $100,000+
Doesn’t it bug you when you want to buy something but the salesperson won’t tell you how much it will cost? Or the website doesn’t show any pricing for the product? Clients are the same! Give a ballpark estimate, one of the ranges above, but remember to be explicit that this is only an estimate not the actual cost.
This is a tactic that we use, but I know that there are a lot of companies that would not go with this strategy. We make sure to be as clear as possible for our clients that it is just a range and an idea, but that we will provide a more thorough idea of cost as soon as we have the project spec’d out.
Pro Tip:
Something else that could be very useful to you is instead of selling projects by talking about price, try selling just discoveries. If all you’re selling is the discovery process, and all other items are forthcoming, you just have one thing you’re selling. Makes it easier right?
How to Determine Project Size
So, the big questions are, how do you know which range to give, and what do you do next? The range is generally based on experience. If you don’t have experience doing that kind of job, skip giving a range and go through the process outlined below. So long as you tell the client that you’ll have something for them soon, and actually provide it, you should be fine.
Internally, we often define project size based on what the client wants and what it will take to get them where they want to be. In addition to a budget projection document or proposal, we provide the following items:
For Small Projects:
- A budget projection document
- An information architecture
- A contract
For Medium Sized Projects:
- A budget projection document or proposal
- An information architecture
- Feature set explanations
- Sometimes, user stories
For Large Projects:
- An information architecture
- Feature set explanations
- Schemas for data flow
- User stories
- User process flow charts
- A project plan
Each of the items above helps us determine the price of that project. The more you plan a project, the fewer variables you have, the more closely you will be to the actual time it will take you. This is where project scoping comes in. The key thing to remember throughout this process is to break it down. Break down the features, tasks, hours and costs as much as you can!
BrainLeaf’s Pricing and Scoping Glossary:
Before getting into how to scope all of this stuff, we need to make sure we’re on the same page about a few definitions.
Project
A project can be a website, an app, a change order, or any set of tasks that lead to a completed system. In a lot of cases internally, we use the term project to refer to web software we are building and the term website to refer to more marketing-based systems.
Website – A set of pages on the internet. In general, as noted above, we use this more often than not to refer to marketing-based web projects that have less functionality, and almost never to software systems.
Information Architecture
A way of defining a website or project by listing its pages, sub-pages, pages sections, processes and functionality. Information Architecture is different from other methods of defining a system because it defines what items are on the pages and the states of those items rather than how the full feature set works.
Design
The actual designing of the page. This could be done in HTML and CSS or in a photo editing system such as Photoshop. Either way, this is the task category that is in charge of defining and streamlining usability, setting look and feel, and maximizing marketability.
Coding / Slicing
Turning an image such as a Photoshop file into a web page.
Programming
Integrating Content Management System features or doing feature development. Programming is a broad term used to define a lot of different tasks, but Google has it defined as “The act of writing computer programs,” which is definitely accurate, but I am sure that someone somewhere has written a book on what exactly this means.
Features vs. Pages
Google defines a feature as “a distinctive attribute or aspect of something.” But in this case, let’s use a quote from Wikipedia on Feature Oriented Programming – “each program is defined by a unique composition of features.” This is important because a page can contain a feature, a portion of a feature, or be itself a feature, but a feature is rarely just a page.
Example:
The feature may be a news article system. Part of this feature is the news feed that goes onto the home page. The home page is not the feature: the feature exists on the homepage and is supported through a number of other pages on the site which make up the feature. This is important because when you write up an information architecture, you have to know what features have tendrils into different pages and understand the connections within the system.
Okay, enough learning already! Take a break and do a World Cup dance.
In our followup blog post, we break down how to price and scope a small web project.
