Session 06: Backing Up to Scope
Hi there. Hey. Hello. Welcome to this session of the “How to Make Guides” project where I am creating a guide to instruct users how to create guides of their own – from concept to release. In the previous session, I had drafted the “Planning Your Guide” section of the project. Since that session, I’ve conducted a session (or two) that helped reassess the direction of the project. In this session, I will take a step back and write the missing scope section for the “Planning Your Guide Project” section. I want to do that now so I can apply the instructions to this project.
I’ve recently identified that the goal of the newly created exploration phase is to identify the entire scope of the project and the goal of the project planning phase is to convert that scope to objectives.
I’ve determined that the process of scope identification could follow this order:
- Identify Constraints
- Sort Constraints
- Define Product Scope
- Define Project Scope
A question: If I have a project scope and a product scope – should I have project objectives and product objectives? It seems that if I split them then the project could strategically be considered successful when the product isn’t – especially if the goal is to plan for the product’s success. They should probably remain tied together.
Should I just start to write the final and see what happens? Lets do that.
Step 3: Explore the scope of the project.
Exploring the scope works to define what both, your product and project, are and are not. There are two main factors to keep in mind: your product is the guide you are building and the project is the process you will follow to ensure the guide is successful.
The first step when building out your scopes is to identify the things that limit your product and project (e.g. deadline, cost, format, etc.). These limiting items are called constraints. Here is a list of constraints typical for guide projects:
- Deadline: The date something is due (e.g. the day the project should be finished, the day the product should launch, etc.)
- Work Hours: The amount of hours that can be spent on the project; sometimes this is controlled by budget and sometimes this is controlled by deadline as the “total number of hours before the deadline” minus the “number of hours of unavailability” (e.g. holidays, other obligations, etc.)
- Costs: The expenses or purchases necessary to finish the guide. (e.g. printing costs, editing fees, etc.)
- Product Format: The medium and method in which the guide will be presented (e.g. printed handouts, digital document on a shared drive, etc.)
- Quality: The level of professionalism the content needs to meet (e.g. reading level, style of voice, etc.)
- Usability: How successful the guide is in teaching the topic (e.g. 100% of those who use the guide correctly will be able to complete the task, etc.)
- Subject Matter Expert: An authority in the topic used to pull information from (e.g. resource material, expert-in-the-field, etc.)
- Project Process: The tool used to manage the production of the guide (e.g. Cryptiquest Project Management Guide, Version controls, etc.)
This isn’t a comprehensive list. Every project is different. The goal is to think of the needs that have to be met for the project – really spend time to think through the limitations.
I’m going to stop there because I think I see a flaw – the constraints should be thought of in terms of product vs. project. I thought this would be easier to do it all in terms of constraints first but it’s not as easy to consider constraints for both the project and product simultaneously. Let me try this again.
Step 3: Explore the scope of the project.
Exploring the scope works to define what both, your product and project, are and are not. There are two main factors to keep in mind: your product is the guide you are building and the project is the process you will follow to ensure the guide is successful.
Both your product (the guide) and the project (the process for making the guide) will have separate scopes since both entities have different definitions. The product scope will highlight the “must haves” for the guide while the project scope will cover the “must haves” for the production of the guide.
Another way to think of scope is to consider the limitations or constraints that your project faces: Is there a deadline? Are there any branding considerations you have to abide by? Are there target audience requirements that need to be met? etc. These constraints define the scope of your product and project.
Exploring the Product Scope
The scope for guides typically come down to the following parameters:
- Format: The medium in which the guide will be created (e.g. printed handout, digital PDF, etc.)
- Repository: The facility where the guide will be stored (particularly if online, the website, drive, server, or app where will it be hosted)
- Breadth: The depth at which the guide coves the topic (e.g. “this guide will teach the fundamental rules of chess but not strategy”, etc.)
- Subject Matter Expert: An authority in the topic used to pull information from (e.g. resource material, expert-in-the-field, etc.)
- Target Audience: The people who will use your guide ()
- Usability:
I think I need to have a target audience scope somewhere. Figuring out who the target audience is and what needs/restrictions they should be a huge part of product design. This project is just getting bigger and bigger. Annoying.
I suppose I could move the Target Audience section from the review section to here.
Step 3: Identify your target audience and their needs.
Before you begin to scope out your guide and project, you should identify who you think the target audience is (and isn’t) for the project. You need to explicitly answer the following questions:
- Who is going to use this guide?
- Who isn’t going to use this guide?
- What limitations do these users have?
Even though you might not be reaching out to the target audience until a few steps later, performing the need-analysis now is crucial for several reasons:
- The guide should ensure the needs of the users are met.
- Whatever additional user considerations the guide needs to have need to be planned out.
- Knowing your target audience now helps with the review process in the future.
To identify your target audience, use the journal technique until you feel like you thoroughly understand the answers to the three questions above.
Step 4: Explore the scope.
Exploring the scope works to define what both, your product and project, are and are not. There are two main factors to keep in mind: your product is the guide you are building and the project is the process you will follow to ensure the guide is successful.
Both your product (the guide) and the project (the process for making the guide) will have separate scopes since both entities have different definitions. The product scope will highlight the “must haves” for the guide while the project scope will cover the “must haves” for the production of the guide.
Another way to think of scope is to consider the limitations or constraints that your project faces: Is there a deadline? Are there any branding considerations you have to abide by? Are there target audience requirements that need to be met? etc. These constraints define the scope of your product and project.
Exploring the Product Scope
The scope for guides typically come down to the following parameters:
- Format: The medium in which the guide will be created (e.g. printed handout, digital PDF, etc.)
- Repository: The facility where the guide will be stored (particularly if online, the website, drive, server, or app where will it be hosted)
- Breadth: The depth at which the guide coves the topic (e.g. “this guide will teach the fundamental rules of chess but not strategy”, etc.)
- Subject Matter Expert: An authority in the topic used to pull information from (e.g. resource material, expert-in-the-field, etc.)
- Target Audience: The users you identified in the previous step of this guide (e.g. my fellow students, creators of at least 6th grade reading level, etc.)
- Usability: How successful the guide is in teaching the topic (e.g. 100% of those who use the guide correctly will be able to complete the task, etc.)
Exploring the Project Scope
The scope for guide projects typically come down to the following parameters:
- TIME
- Deadline: The date something is due (e.g. the day the project should be finished, the day the product should launch, etc.)
- Hours: The amount of hours that can be spent on the project; sometimes this is controlled by budget and sometimes this is controlled by deadline as the “total number of hours before the deadline” minus the “number of hours of unavailability” (e.g. holidays, other obligations, etc.)
- COSTS
- Direct Expenses: Costs and fees for products or services needed to pay for this project (e.g. paper, professional editing, etc.)
- Indirect Expenses: Products or services that have costs or fees that may have already been paid for other projects (e.g. webhosting costs, ink, design software, etc.)
- RESOURCES
- People
- Direct Stakeholders: The people who are directly affected by the success of the product (e.g. you, your company, the users, etc.)
- Indirect Stakeholders: The people who are impacted by the project but not necessarily the product (e.g. designers, reviewers, editors, etc.)
- Invisible Stakeholders: The people who could be impacted by your involvement with the project (e.g. your family, your friends, etc.)
- Materials: The items used to complete the project and product (e.g. paper, writing utensils, rubber bands, etc.)
- People
I think that’s pretty good for a draft. I’ll add that to the project document.