Hands-On Activity: Create a scope of work

Activity overview

You have been learning about the role of a data analyst and how to manage, analyze, and visualize data. Now, you will consider a valuable tool to help you practice structured thinking and avoid mistakes: a scope-of-work (SOW).

In this activity, you’ll get practical experience developing an SOW document with the help of a handy template. You will then complete an example SOW for an imaginary project of your choosing and learn how analysts outline the work they are going to perform. By the time you complete this activity, you will be familiar with an essential, industry-standard tool, and gain comfort asking the right questions to develop an SOW.

Before you get started, take a minute to think about the main ideas, goals, and target audiences of SOW documents.

Scope of work: What you need to know

As a data analyst, it’s hard to overstate the importance of an SOW document. A well-defined SOW keeps you, your team, and everyone involved with a project on the same page. It ensures that all contributors, sponsors, and stakeholders share the same understanding of the relevant details.

Why do you need an SOW?

The point of data analysis projects is to complete business tasks that are useful to the stakeholders. Creating an SOW helps to make sure that everyone involved, from analysts and engineers to managers and stakeholders, shares the understanding of what those business goals are, and the plan for accomplishing them.

Clarifying requirements and setting expectations are two of the most important parts of a project. Recall the first phase of the Data Analysis Process—asking questions.

As you ask more and more questions to clarify requirements, goals, data sources, stakeholders, and any other relevant info, an SOW helps you formalize it all by recording all the answers and details. In this context, the word “ask” means two things. Preparing to write an SOW is about asking questions to learn the necessary information about the project, but it’s also about clarifying and defining what you’re being asked to accomplish, and what the limits or boundaries of the “ask” are. After all, if you can’t make a distinction between the business questions you are and aren’t responsible for answering, then it’s hard to know what success means!

What is a good SOW?

There’s no standard format for an SOW. They may differ significantly from one organization to another, or from project to project. However, they all have a few foundational pieces of content in common.

• Deliverables: What work is being done, and what things are being created as a result of this project? When the project is complete, what are you expected to deliver to the stakeholders? Be specific here. Will you collect data for this project? How much, or for how long?

Avoid vague statements. For example, “fixing traffic problems” doesn’t specify the scope. This could mean anything from filling in a few potholes to building a new overpass. Be specific! Use numbers and aim for hard, measurable goals and objectives. For example: “Identify top 10 issues with traffic patterns within the city limits, and identify the top 3 solutions that are most cost-effective for reducing traffic congestion.”

• Milestones: This is closely related to your timeline. What are the major milestones for progress in your project? How do you know when a given part of the project is considered complete?

Milestones can be identified by you, by stakeholders, or by other team members such as the Project Manager. Smaller examples might include incremental steps in a larger project like “Collect and process 50% of required data (100 survey responses)”, but may also be larger examples like ”complete initial data analysis report” or “deliver completed dashboard visualizations and analysis reports to stakeholders”.

• Timeline: Your timeline will be closely tied to the milestones you create for your project. The timeline is a way of mapping expectations for how long each step of the process should take. The timeline should be specific enough to help all involved decide if a project is on schedule. When will the deliverables be completed? How long do you expect the project will take to complete? If all goes as planned, how long do you expect each component of the project will take? When can we expect to reach each milestone?
• Reports: Good SOWs also set boundaries for how and when you’ll give status updates to stakeholders. How will you communicate progress with stakeholders and sponsors, and how often? Will progress be reported weekly? Monthly? When milestones are completed? What information will status reports contain?

At a minimum, any SOW should answer all the relevant questions in the above areas. Note that these areas may differ depending on the project. But at their core, the SOW document should always serve the same purpose by containing information that is specific, relevant, and accurate. If something changes in the project, your SOW should reflect those changes.

What is in and out of scope?

SOWs should also contain information specific to what is and isn’t considered part of the project. The scope of your project is everything that you are expected to complete or accomplish, defined to a level of detail that doesn’t leave any ambiguity or confusion about whether a given task or item is part of the project or not.

Notice how the previous example about studying traffic congestion defined its scope as the area within the city limits. This doesn’t leave any room for confusion — stakeholders need only to refer to a map to tell if a stretch of road or intersection is part of the project or not. Defining requirements can be trickier than it sounds, so it’s important to be as specific as possible in these documents, and to use quantitative statements whenever possible.

For example, assume that you’re assigned to a project that involves studying the environmental effects of climate change on the coastline of a city: How do you define what parts of the coastline you are responsible for studying, and which parts you are not?

In this case, it would be important to define the area you’re expected to study using GPS locations, or landmarks. Using specific, quantifiable statements will help ensure that everyone has a clear understanding of what’s expected.

Completing your own SOW

Now that you know the basics, you can practice creating your own mock SOW for a project of your choice. To get started, first access the scope-of-work template.

To use the template for this course item, click the link below and select “Use Template.”

Link to template: Data Analysis Project Scope-Of-Work (SOW) Template

OR

If you don’t have a Google account, you can download the template directly from the attachment below.

Fill the template in for an imaginary project

• Spend a few minutes thinking about a plausible data analysis project. Check out 5 Data Analytics Projects for Beginners if you need help coming up with ideas.
• Come up with a problem domain, and then make up the relevant details to help you fill out the template.
• Take some time to fill out the template. Treat this exercise as if you were writing your first SOW in your new career as a data analyst. Try to be thorough, specific, and concise!
• The specifics here aren’t important. The goal is to get comfortable identifying and formalizing requirements and using those requirements in a professional manner by creating SOWs.

Compare your work to a strong example

Once you’ve filled out your template, consider the strong example below and compare it to yours.

Link to the strong example: Data Analysis Project Scope-of-Work (SOW) Strong Example

OR

You can download the template directly from the attachment below.

Confirmation and reflection

Question 1

When you created a complete and thorough mock SOW, which foundational pieces of content did you include? Select all that apply.

• Deliverables
• Milestones
• Reports
• Budget
• Timeline

Explain: In your mock scope-of-work, you should have included four foundational pieces of content: the deliverables, milestones, timeline, and reports. Once these items are in place, the SOW will help keep you, your team, and your project stakeholders organized and on the same page. Going forward, you can use this industry-standard tool to clarify a project’s business goals and how to accomplish them—just like a professional data analyst!

Question 2

Now that you have put your scope-of-work knowledge into practice, take a moment to examine and reflect on your completed mock SOW. Then, review your work next to the strong example linked above. In the text box below, write 2-3 sentences (40-60 words) in response to each of the following questions:

• How did you identify and formalize the project’s requirements?
• What questions did you ask in order to update the foundational pieces of content?

Explain: Congratulations on completing this hands-on activity! Although SOWs do not have a set format, they do include common foundational pieces of content. A good response would include how this content answers questions, sets expectations, and organizes activities. Beyond that, consider the following:

Usually, projects don’t start until an SOW is approved with its key pieces of content: the deliverables, milestones, timeline, and reports. To collect and synthesize this information, analysts identify and formalize quantifiable project requirements. They use structured thinking to ask clarifying questions, define what to accomplish, and specify project boundaries.

The importance of context

Context is the condition in which something exists or happens. Context is important in data analytics because it helps you sift through huge amounts of disorganized data and turn it into something meaningful. The fact is, data has little value if it is not paired with context.

Understanding the context behind the data can help us make it more meaningful at every stage of the data analysis process. For example, you might be able to make a few guesses about what you're looking at in the following table, but you couldn't be certain without more context.

On the other hand, if the first column was labeled to represent the years when a survey was conducted, and the second column showed the number of people who responded to that survey, then the table would start to make a lot more sense. Take this a step further, and you might notice that the survey is conducted every 5 years. This added context helps you understand why there are five-year gaps in the table.

Years (Collected every 5 years)	Respondents
2010	28000
2005	18000
2000	23000
1995	10000

Context can turn raw data into meaningful information. It is very important for data analysts to contextualize their data. This means giving the data perspective by defining it. To do this, you need to identify:

• Who: The person or organization that created, collected, and/or funded the data collection
• What: The things in the world that data could have an impact on
• Where: The origin of the data
• When: The time when the data was created or collected
• Why: The motivation behind the creation or collection
• How: The method used to create or collect it

Understanding and including the context is important during each step of your analysis process, so it is a good idea to get comfortable with it early in your career. For example, when you collect data, you’ll also want to ask questions about the context to make sure that you understand the business and business process. During organization, the context is important for your naming conventions, how you choose to show relationships between variables, and what you choose to keep or leave out. And finally, when you present, it is important to include contextual information so that your stakeholders understand your analysis.

Learning Log: Define problems and ask questions with data

Overview

In a previous learning log, you reflected on what you learned from the SMART questions you asked during your real life data conversation. Now, you’ll complete an entry in your learning log using notes about your data conversation to explain your initial insights to potential stakeholders. By the time you complete this entry, you will have a stronger understanding of how you might use data to define problems and what information is useful for stakeholders at this stage. This will help you develop formal documents like a scope of work (SOW) as a data analyst in the future.

Summarize your findings

As a data analyst, part of your job is to communicate the data analysis process and your insights to stakeholders. This often involves defining the problem and summarizing key questions and available data early on. You might include this information in a formal document for stakeholders like a scope of work (SOW) at the beginning of a project. As a reminder, an SOW is an agreed-upon outline of the tasks to be performed during a project; it is important to ensure your stakeholders understand this key information at that stage.

Before you start your learning log entry, take a moment to review your notes and your reflection for Learning Log: Ask SMART questions about real life data. Imagine that you are going to design a data analysis project based on this data conversation.

In the learning log template linked below, you will create a summary of key information you think a stakeholder would need to know about this project. In this case, your stakeholder could be a member of the executive team, like a project manager. Here are some questions to help you get started:

• What is the problem?
• Can it be solved with data? If so, what data?
• Where is this data? Does it exist, or do you need to collect it?
• Are you using private data that someone will need to give you access to, or publicly available data?
• Who are the relevant sponsors and stakeholders for this project? Who is involved, and how?
• What are the boundaries for your project? What do you consider “in-scope?” What do you consider “out-of-scope?”
• Is there any other information you think is relevant to the project?
• Is there any information you need or questions you need answered before you can begin?

As you think about these questions, it’s likely you’ll discover that you don’t have all the information you need. This is part of the process!

When kicking off data analysis projects, expect to have a lot of conversations. By identifying what you know and what you don’t know, it makes it much easier to plan your next data conversation, so that you can get the answers you need.

Access your learning log

To use the learning log for this course item, click the link below and select “Use Template.”

Link to learning log template: Define problems and ask questions with data

OR

If you don’t have a Google account, you can download the template directly from the attachment below.

Test your knowledge on structured thinking

Question 1

What are the key elements of structured thinking? Select all that apply.

• Organizing available information
• Recognizing the current problem or situation
• Revealing gaps and opportunities in order to identify the options
• Implementing a solution

Explain: Structured thinking is the process of recognizing the current problem or situation, organizing available information, revealing gaps and opportunities, and identifying the options.

Question 2

Fill in the blank: A scope of work is an agreed-upon _____ of the work you’re going to perform on a project.

A. to-do list

B. outline

C. report

D. diagram

A scope of work is an agreed-upon outline of the work you’re going to perform on a project.

Question 3

What are some strategies to ensure your data is accurate and fair? Select all that apply.

• Think through the "who, what, where, when, how, and why" of your data
• Collect the data in an objective way
• Use data that is very personal to you
• Make sure you start with an accurate representation of the population in the sample

Explain: To ensure your data is accurate and fair, make sure you start with an accurate representation of the population in the sample; collect the data in an objective way; and ask questions about the data.