Sign in or start a free trial to avail of this feature.
1. Building a Project Scope
Learn the basics of the scope; a project plan that applies a clear and easy to follow structure to guide us from abstract ideas to tangible solutions.
Lesson Goal (00:11)
Understand the importance of building a scope for a data project.
Abstract to Tangible (00:39)
A data project often starts with an abstract, if not ill-defined concept. Converting it into a tangible numbers-based analysis can seem like a daunting task at the outset, even for people with experience in working with data.
This is a problem for a few reasons. People don’t know where to start so they often start by looking at the data. This limits us to a very narrow view of the problem from the get-go. So how do we avoid this?
Why We Need a Scope (01:27)
We can avoid this problem by starting with a scope. We can consider a scope as a roadmap that guides us through the project from start to finish. It’s a crucial structure that keeps our work on track.
It keeps us from wandering into time-consuming work that’s not useful. As Shron says, “a scope provides structure you can think through, rather than working in a vacuum”.
Scope Layout (02:10)
This course is based on Max Shron’s book “Thinking with Data” where he lays down a scope with four parts: Context, Needs, Vision, Outcome.
The scope is iterative in its approach. We start with simple versions of each stage and revisit them multiple times to add detail. This helps create a more holistic view of our project.
We’ll run into problems if we dedicate a lot of time to one stage without a clear idea of what’s to come further down the road. For example, if we design a sophisticated model in the vision stage and then discover in the outcome stage that no one in the company has the expertise to use it.
How Iteration Brings us From Abstract to Tangible (03:55)
It starts with very rough story beats with vague references to data. It slowly makes more specific references to data until we eventually end up with a clear idea of what type of data we need to look for.
For example, a scope that starts with a concept of data like “distance to customers” would eventually end up with a very specific metric that may be described as “distance in kilometers from mean coordinates of the nearest cluster of customers.
The latter is complex and esoteric, but we have a clear idea of what it means because we previously defined it as a simple concept that fit into our narrative.
In this lesson, we'll understand the importance of building a scope for a data project.
When we think about a data-driven project, it's easy to imagine the final product. It might be an intuitive dashboard or a statistical model. It can even be a document or a book with references to charts and maps that illustrate how the data played its role in a clear manner that can be understood by anyone.
In other words, we have clear and tangible tools at our disposal. However, sometimes we only have a few abstract ideas and requests that are anything but tangible at the start of a project.
Converting that into tangible numbers based on analysis can seem like a daunting task at the outset, even for people with experience in working with data. If we don't meticulously plan our approach, we're bound to run into problems. Without a clear idea of where to begin, we'll likely start by looking at the data, but this would be putting the cart before the horse. It would limit us to a very narrow view of the project. We can avoid this by building a project scope.
This is a concept that's thoroughly discussed in Max Shron's book "Thinking with Data." Throughout this course, we'll touch on the fundamentals of the scope, as described by Shron.
For a more in-depth view, we recommend reading the book.
If our project can be considered as a journey, the scope is the roadmap that we prepare before setting off.
It contains a map that illustrates the roads and the terrain. It plots various waypoints along the way, and it even lays down an optimal route for getting from point to point.
We wouldn't dream of undertaking this journey by driving aimlessly into the night without trying to figure out where we're going or how we should get there.
In a similar sense, the scope guides our project from start to finish.
It'll provide a crucial structure that will keep our work on track and prevent us from wandering into time-consuming work that's not useful.
As Shron says, "A scope provides structure that you can think through, "rather than working in a vacuum." According to Shron, the scope has four major components, the context, needs, vision, and outcome.
The context is an understanding of the environment we're working in.
It's the who, what, and critically the why of the project, our partners, and stakeholders of the project.
The needs are the question that our data project is trying to answer. Often when starting a data project, we'll be given a rough set of requirements that can be understood as the needs.
However, these needs often need to be clarified, even if they're coming straight from our partners, boss, client, and so on.
In our needs investigation, we might even find that there are critical needs that were unstated or unknown.
The vision is a rough snapshot of what the project will look like. It's the dashboard, model, and document that we mentioned at the beginning of this lesson. Of course, in the beginning, we have no idea what they'll look like. We'll typically start with rough sketches written on paper with pencils.
They'll be made up of filler data, but they'll give us an idea of what kind of output we're working towards.
As the project progresses, they'll get more and more detailed until they eventually resemble the final product.
Finally, we have the outcome.
This is how our project is delivered.
If our partners are not data literate, we need to consider tools that take this into account.
If they need regular maintenance, we need to understand who we'll be passing the torch on to and what their skills and competencies are.
At the outset, we'll work through each of these stages.
We'll start with simple versions of each stage and revisit them multiple times to add detail. This helps create a more holistic view of our project.
We'll run into problems if we dedicate a lot of time to one stage without a clear idea of what's to come further down the road.
For example, it would be very problematic if we designed a sophisticated model in the vision stage and then discover in the outcome stage that no one in the company has the expertise to use or maintain it.
Sticking to just a high-level understanding of our data needs at the beginning of our project is important. It gives us a pretty good idea of where we're going, and that gives us the time and flexibility to think about our entire project.
If we start looking at very specific data from the beginning, we'll quickly find that we won't be able to see the forest from the trees.
We'll stop the lesson here.
In the next lesson, we'll explore the concept of the context in more detail.
We'll also introduce a case study that we'll use for the rest of this course.