Scoping, from a web development perspective, refers to the process of working out what is going to be built, and WHY it’s going to be built, and then writing this all down in a clear and easy-to-understand flowchart or document of some sort. For example, a VERY small scope might look something like this:
Right now we have 200 sales people out in the field. It is very difficult to tell who is doing what at any given time, and therefore we don’t know if our high performers are just in areas that have greater needs, or if our lower performers are slacking off. What we would like is an Android phone app that runs on Android 4.0 and higher. Sales associates would log into it where they could view their appointments (pulled from our SalesForce CRM) as well as log notes about their appointments. We would like these notes to be stored in SalesForce, as well as another management tool (probably a web application) that records their GPS location and time, so that we can monitor their routes. We would also like this app to generate reports, showing the time spent in commute, the sales that actually came from those visits, and the average visits per day ranked against the distance travelled.
The point is: you don’t have to write a technical document. Even if you are an engineer, or have had some programming experience, technical jargon laced verbiage is the sure fire way to confuse a programmer. I know that sounds unintuitive, but the more descriptive you can be, the better. Keep in mind that phrases like “End-to-end”, or “User-centric” can mean different things to different people (at best), or nothing at all (worse and probably more likely.) If you need to write something highly technical (like API documentation, or network infrastructure, etc.) put it in an appendix.
While this is a very basic (and not very detailed scope) it’s not terrible, considering I made it up on the spot. It details the important information:
• What we want to build
• Why we want to build it
• What it is going to do
• Who is going to be using it, and
• What platforms it is going to run on
The “Why” question there is actually more important than you think. While it might be obvious to someone building a house that “…four real people are going to sleep, shower, cook, and entertain in this house,” it might not be as obvious to someone who doesn’t know how your specific business functions nor who the software is going to be used for and why. Almost always, a developer and project manager can make better decisions if they have context. Programming is weird this way, in that most experts you hire have their expertise in something related to what you actually do, or want to do. Technology is a way of enabling business, and rarely is the business itself. That means that the developer you hire for your custom animal slippers business probably doesn’t know anything about fluffy rabbits as shoes, or may have never bought slippers. In fact, we have a developer here at Sourcetoad who’s had the same pair of shoes for over ten years… ONLY ONE PAIR!
Anyway, the take away is that getting the idea of what you want to do out of your head and into your developer’s is almost as important as the next part of scoping: Requirements Gathering.
For context, “Requirements Gathering” is just a term for “writing down all the stuff the application should do.” This means creating a feature list. Normally, you start with a laundry list of features, both obvious and non-obvious. Don’t leave it up to chance. Just because you think it might be obvious that a user has to create an account on your system to interact with it does not mean that a developer does. But we’ll leave that for another post. In fact, in the next post, we’re going to talk more in-depth about what a Management Portal is, and how having one in place can help you communicate with developers more cohesively during your next development project.
