Project Scopes
We write complete scopes for all new projects we work on. Writing out a scope helps to ensure that we fully understand the requirements for a project, and gives us an opportunity to review and critique the implementation plan before we do any major work.
Scope Format and Storage Location
All scopes will be written using Google Docs and stored in the Scopes folder in the shared Software drive. Use the templates found in the folder instead of creating your own.
Writing and Review Procedure
The process for writing a scope can vary. Most scopes should be written as a team in a continuous session or series of group sessions, with one primary writer. Small scopes can be written by a single person but should be reviewed by at least one other person in the same team (portal/automations) before being finalized.
Each scope defines who is responsible for reviewing the scope. All scopes must be reviewed internally before sharing with any PWI employee outside the software team. Generally, scopes must be reviewed by the Director of Technology. However, some very small and low-impact scopes may be approved by the team lead. All scopes shared with people from outside PWI must be reviewed and approved by the Director of Technology.
Basic Scope Elements
Here are the essential elements that every project scope must include. These lists are not exhaustive, and additional elements may be necessary for specific projects. However, all numbered elements are mandatory unless marked otherwise. If any element seems consistently extraneous, this document can be revised to remove it.
Project scopes look different based on the project type. We are currently defining the format based on two general types of projects: Software Projects and Automations Projects.
- Software Projects
Projects developed by the portal team, including those using no-code systems.
Custom software or plugins developed by anyone in the software department.
- Automations Projects
New design automations developed by the automations team.
Major changes to existing automations.
Software Projects
Problem Statement
List issues with current systems and workflows
Goals
Budget (hours)
Proposed timeline
Owners and Approvers
Requirements and Constraints
Existing policies and procedures
User roles and permissions
Workflows
Detail system automations as needed for complex automations
Note: define terms as you introduce them
User Interface (Screens, Modals, Forms, etc.)
Conditional visibility, required fields, etc.
Available actions (buttons, links, etc.)
Include sketches as needed (fully coded apps only)
(optional) Data model/structure
Outline format or diagram
Automations Projects
Problem Statement
List issues with current systems and workflows
Stated Goal
Budget (hours)
Proposed timeline
Owners and Approvers
Requirements and Constraints
limits of the model
sources of engineering data (spreadsheets, databases, etc.)
features that must be included
Drawings and Prints
Always detail customer drawing set, other drawing sets only need to be detail if there are unusual details or requirements to include
Include basic pages that will be included
Examples: cover page, shipping page, part detail pages, etc.
Only add details that are specifically required
No need to detail parts drawing set
Model Structure (assemblies and parts)
Outline format of parts and assemblies
Include details of which parts/assemblies utilize iLogic and model states
Workflows and triggers for changing parameters or model states
Forms
Field grouping, visibility, validation, etc.