Information Resources
Scoping a Project
Part III: Expectations
Expect this document to be revised several times before being officially adopted.
You’ve read earlier that the scope is a draft. As you’re vetting the ideas that were once in your mind, and are now on paper, the document will evolve and mature: A paragraph might turn into a list, a section might split into two, and what was once overlooked might suddenly become obvious and included. You’ll remember the first item you first typed in your first list, and it won’t take long before you have a fully outlined scope—one which you believe to be polished and perfect.
Next, you’ll share this document with project leads, who will review everything you’ve listed, and communicate cases where your wording or descriptions were unclear.
“Buyer is notified of a successful transaction.”
This item states.
“Is that via an on-screen message? An email? A text? What does the notification say?”
The project lead asks.
“Buyer is shown a success message on-screen, on successful transaction, and is sent an email containing all purchase details: quantity, item number, item name, price, subtotal & total.”
..this item has become.
Next, you may share this document with the full production team.
“Do you want a picture of the purchased item?”
The designer asks.
“We’ll need an HTML delivery option for system notifications with images, instead of text-only.”
The developer offers.
“If we go that route, we can design a full mailer template that matches the site design.”
The designer adds.
As new options are explored, you evaluate what you believe will the best direction to accommodate your project needs, and update the scope accordingly. Remember to stay away from words and phrases that could lead to confusion (e.g., including but not limited to, such as, for example, normal, regular, basic, etc.) replacing them with more exact ones (e.g., with the following, limited to these options, total number of, exactly, precisely, etc.).
Expect there to be many options to every task.
Your designer is going to be a very subjective thinker, as most creatives are. Their job isn’t to dispute your needs, but rather to find effective routes of communicating your needs, organizationally and aesthetically. The creative isn’t necessarily needed in your production scope, unless it falls into one of the following categories:
1. Design decisions might change the deliverables
Adding, for example, HTML emails (as depicted in the scenario above) will require mail templating, which should be included in the scope along with the existing text only versions. The design itself can be worked out during the Creative UI/UX phase of development, and isn’t needed in the production scope.
2. Design decisions might complicate the development
Consider a typical search bar or a product list. If your designer builds a storyboard where the search bar “suggests” a result, then your developer will need to accommodate for this additional functionality. If the storyboards show a window appearing each time an end user hovers over a product, wherein the product’s specifications are shown, then the developer will need to see this, too, in your scope. It’s your job to approve or decline the designer’s recommendations. If they’re approved, then you’ll need to update your scope to reflect them.
3. Design decisions might require additional resources
Image your project involves a user account system. A “Log-in” prompt is replaced with the name of the user account when a user logs into your application. Your designer might add, beside this username, the date of the last login. The design decision might seem minor, but it now requires the developer to add an additional column to the database to store/update the timestamp. This property should now be included in your scope, among the other properties of a user account, such as: username and password.
A quick note of caution for working with designers: A designer’s primary concerns are organization, usability and aesthetic, with budgetary constraints coming second. As recommended design updates to the scope may complicate or simplify the development, they’ll likely affect the estimate for the project, if one has already been provided. It’s the responsibility of all members of the production team to raise concern if recommended design changes will affect the budgeted cost and time required for the project.
Expect to not always have an immediate answer
Not every item in your scope is going to be a decision you’ve already made. Remember that you may be resolved on the bigger picture objectives, but these finer details don’t always require a firm commitment. It’s completely normal to put literal questions in your scope to be revisited later in the scoping process. Using our product purchase example, consider the following section of a hypothetical scope:
Shopping Cart: Shipping
- The buyer is taken to a shipping form, to enter their address details
- Fields: { Address 1, Address 2 (optional), city, state, postal code, country }
- Returning users will see form address values from their previous purchase
- Click “confirm address” to be taken to the purchase confirmation page
- Do shippers require a phone number? Should we include a field?
Including questions like these will be your reminder to revisit these during production calls, up until a production agreement is signed, to show that you’re considering this as an option, but aren’t necessarily including it in the production scope. You will get feedback from your production team and be better informed to make a decision in a later draft.
Expect to feel overwhelmed
Expect to be asked for a final scope
While this phase of your pre-production is absolutely critical, your production team will want to see a commitment from you, within reasonable time, so that they can actually begin the work. You shouldn’t feel like you’re being pressured to make a decision, but even if you’ve worked and reworked your scope several times, you may not feel like all of your bases are fully covered. And rightly so. There will always be something unforeseen, especially in the more involved scopes, which only arise after you’ve delivered your final scope, approved the production budget, and are well into production. These unanticipated details have little effect besides holding up production, and there’s rarely any “stop the presses!” moment to come of them. When they do arise, simply make a note of them, and continue through production. By the end, they are often worked out, or rendered superfluous. But if they’re not, you can always approve an overage for them prior to launch, or in a later phase. After all, a missing fax number on a contact form shouldn’t prevent you from moving forward the same way a door knob, missing from a blueprint, shouldn’t prevent you from breaking ground.
A whole separate article could be written about the art of project budgeting, including a section about incorporating a small contingency for unforeseen needs or pre-launch tweaking. You shouldn’t suffer for these oversights (in terms of cost), but neither should your production team (in terms of labor). At the end of production, you will return to the finalized, approved scope to verify that all the items have been addressed and satisfied, and ultimately award your sign-off. At that point, remember that the obligations of the scope have been met. Even if you want to add these unexpected adjustments, your team has completed what they were contracted to do. Which leads us to the last chapter of this article: Comfort.
Permalink: https://www.era404.com/info/scope/
