This template should be used whenever there is a need to define the scope and requirements of a project that the SPD team is involved in. For a Word Doc version of this template, follow this link.
Instructions:
| Assigned SPD PM: | |
| Document Created: | |
| Document Last Updated: | |
| Document Status: | [Draft, In Review, Approved] |
Describe the problem/capability gap that has been identified. This should be no more than a paragraph or two describing the current state of affairs and why it is a problem for a group of users. Please do not focus on any potential solutions here.
Please describe and/or link to any current documentation, code, current work, etc. that would give the reader of this document the context needed to better understand the problem description and the relevant domain knowledge needed to understand the problem
If this project is successful, what will change in the real world? Who or what will change because of it? If you have a theory of change already, this should be straightforward.
Who is currently running into this problem and who are we trying to help? Is this an issue that internal RMI-ers are encountering or is this a problem for external folks or both? How would you describe each potential type of user affected by this problem in one sentence?
Provide a short description for each major component that is needed to address the problem we are focused on.
What could be considered the MVP for this product? How could we break up the total product into achievable and realistic milestones? What budget/timeline/funder/etc. constraints do you have when it comes to addressing this problem?
How would one of the User Persona’s day to day activities be different if they now had access to our solution compared to their previous problem state? Can we walk through how the solution would assist them?
What actions or behaviors must be possible for our user(s) so that they no longer experience the problem? To be clear, this is still not focusing on a specific solution but rather focuses on what must be possible for a solution to be considered viable. These should also be prioritized, if possible, using the scale P0, P1, P2.
These requirements can also be further refined into sections. Either sections that help structure the overall product design (e.g. “Frontend requirements, backend requirements, etc.), or sections that delineate “Functional Requirements” (specific features or functions of the product) from “Non-Functional Requirements” (describe how the system performs and addresses qualities or constraints of the system).
P0 – This capability must be possible or else a solution would be considered incomplete and unacceptable.
P1 – This capability is highly desirable and would be noticeable if it wasn’t available; but if need be, it could be excluded from the solution.
P2 – This is a “nice to have”; this capability would be well received by users but it would not be sorely missed if it was not available.
What metrics do we think are important to track? What data do we need to understand if we were successful?
What would a roadmap of future improvements look like for this product if there was additional funding? Are there any additional capabilities that we might want to investigate and explore?
What is the maintenance plan for this project once primary work is completed? Is SPD expected to own any solution and just provide access to the tool? Is SPD expected to provide ongoing support if there are any bugs/future issues? What is the plan to sunset this project?