Getting an idea from concept to solution can be a long journey; it requires a lot of patience to get right. It’s tempting to just call up an agency bursting at the seams with ideas and plans in hope that they can piece together your shards of genius Frankenstein-style. Even if they do, your creation would be more monstrosity than the perfection you originally envisioned! The better path would be to create a Scope of Work document that clearly presents these ideas in an actionable fashion.
What is a Scope of Work?
A Scope of Work (SOW) is the division of work to be performed under a contract or subcontract in the completion of a project, typically broken out into specific tasks with deadlines. When we refer to a “Scope of Work”, we typically refer to the document detailing that division of work.
One of the biggest problems that often occurs during a project life-cycle are discrepancies between the agency and client on:
- what needs to be done
- how it should be done
- how long it should take
This is the source of a lot of confusion and can lead to delays in delivery or even worse, the complete dissolution of the project and even legal action.
The SOW should contain any milestones, reports, deliverables, and end products that are expected to be provided by the performing party. As stated before, timelines for these deliverables are very important. In general, the more specific a SOW is, the better.
SOWs for Mobile and Web Applications
Here at WebFX, we specialise in mobile and websites, as well as many other digital services, and we do not commence any such project without a Scope of Work being created first. There are too many considerations, not always obvious to the client, that go into completing a successful project. Starting with a document places us and the client on common ground and allows us to give the client a solid guarantee of final quality and completion date. We do create Scope of Work documents for clients ($2,500TT + VAT) but we also feel it important that clients have the opportunity to create their own SOWs as well. Not only does it save them money, it allows them to understand and refine their ideas which ultimately results in a more polished end product.
Creating the SOW Section 1: Confidentiality Agreement
It’s a good idea to begin any SOW document with a confidentiality agreement. Remember, these are your ideas that you are submitting to another individual or company, and as such it’s a good idea to have a base layer of protection over them. Some clients opt to limit the amount of information they reveal to the person building their app or website. This is actually counter-productive, because as mentioned earlier, the more detailed you are in your SOW the better. The best strategy is to be very detailed in describing your solution but begin your SOW document with a confidentiality agreement. Non-Disclosure Agreements (NDA’s) are also typically used. It is a good idea to get an attorney to draft this but if you’re on a tight budget you can find some good templates online.
Creating the SOW Section 2: Overview
The next thing you want to do is prepare a brief of your project containing information like what your project is about, how it works, who it is for, target audience and brief business model.
For example, say you wanted to build a mobile app to allow people to order food from your restaurant. Your overview should be a mix of the following points:
- What is the project about – Allowing people to order food from anywhere using their Android or iOS phone.
- How does it work – The user selects the options for their order via the in-app menu and checks out. They have to enter their address and payment information during checkout. This service is only valid within a certain area. They can also opt to create an account with this information. After they pay with either PayPal, WiPay or Stripe, their bill is delivered in email. The order is also received at the POS of the outlet and the delivery driver changes the status of the order to “On The Way” when leaving. After the meal has been delivered, the driver changes the status to “delivered”. (Don’t get too detailed here, go for a broad overview and use a real-life situation if possible)
- Target Audience – We are situated close to the University of the West Indies so we are targeting students that are typically aged 18-30. (You can go more into describing the demographic but stay close to how it relates to the look and feel of your app rather than the marketing)
- Brief Business Model – We are adopting a pay first system in the app so users must pay with a credit card prior to completing their order. The delivery fee is also added to the total. The mobile app must support PayPal, WiPay and Stripe as payment options. (focus the business model mainly on what needs to be built)
Creating the SOW Section 3: Technical Section
This is where all the fine details of your solution are contained. Feel free to get as intricate and detailed as possible. It’s a great idea to use visual and graphical components to get your point across. Here are some things you can use:
- Charts (Pie, Bar, Line or whatever works best)
- Flowcharts (Very useful in demonstrating process flows)
- Graphics (image and icons)
- Video
- Examples (It’s a very good idea to show links to existing solutions that you would like your application to operate like)
Additionally, there are several components you need to capture within this section.
- List the technical solutions you require – If you require a mobile app and a website admin with a section for reports etc.
- Specify if the new solution requires some interaction or update to an existing solution – Describe the existing solution here in as much detail as possible. Additionally, specify if certain technologies must be used. For e.g. if your team is already adept at using the Drupal CMS so that’s your preference for the new website.
- List all the users who should have access to the app or website – Also, describe their categories and what they should have access to.
- List all the features of your mobile app or website – For a website, you should start with a list of the pages you want represented plus any actions you would like the user to be able to do. For eg. for an artist page your features would be Home, Bio, Music, Videos, Contact, About, Shop and the ability for users to purchase merch with on the site via a credit card. For a mobile app, list the pages you would like in the menu plus what actions the user should be able to perform.
- Specify the process flow if applicable – If your solution involves processes outside of the app or website such as a food delivery system that needs to also interact with a driver and a POS system, it’s a good idea to highlight this as clearly as possible. The absolute best way to do this is with a flowchart diagram. If you are unable to do this, you can detail the flow in bullet points.
- Reports – Indicate if reports will be required and detail what type of reports will be necessary. Additionally, the frequency of these reports are also important. Some people try to avoid mentioning reports till late into the project to avoid having to ‘pay’ for it. Trust us, that will end up costing you more in the long run. On the contrary, it’s better to introduce reports earlier because most times they can be integrated into the system at a cheaper cost. Instead of having to depend on the developer to send you weekly reports at a recurring maintenance cost, you can have one built and integrated into the admin that allows you to generate your own reports.
- Support & Maintenance terms – How many months of support you need and in which model – dedicated resource or fixed commitment of time & hours, etc.
- Desired time of completion – The length of time a project takes is directly related to the number of features that need to be built. In some cases, features may be moved to a later phase to satisfy a deadline. Either way, indicating this in the SOW is valuable to allow the agency to determine whether they are able to finish the solution in time and either choose to not take on the project, suggest an alternate deadline or suggest a reduction in features or alternate solution that can be completed quicker.
Finishing the SOW
After you create the SOW unfortunately, the document still isn’t finished yet. You will need the agency or developer to add some more items to the document:
- A Detailed Timeline – You would have added your desired timeline but this timeline will be a lot more concrete. It will break down the project life cycle into tasks with a time value attached to each one. On mobile app and website projects, time is very important because it is directly related to cost; development cost is calculated according to an hourly rate.
- Costing – Along with the timeline, a total cost will be provided. There are many costs that comprise this total. Generally, the type of costs are:
- Development costs – Charged according to an hourly rate
- Other professional costs – There may be a project manager or graphic designed also involved. These costs also typically have an hourly rate.
- Maintenance costs – Once a mobile app or website project is accepted by the client as being completed according to the scope, any additional development request is treated as a separate job and costed as such. This can get expensive, especially if the changes are small. One way to solve this problem is to agree to a maintenance contract which usually covers a certain number of hours of work for a limited period. This cost is typically charged by the period either monthly or yearly.
- Agreement – Usually there is a lot of back and forth after you submit your SOW. This is normal so don’t be impatient. It’s better to catch issues at this stage than after you’ve made your down payment. The developer or agency will probably request clarification on your concept, or you may want the cost reduced. After much discussion, you both will sign the agreement and soon after, development begins.
If you are seeking more information regarding creating a Scope of Work or you are interested in creating a website or mobile app, feel free to contact us.
