Team Charter: Difference between revisions

From EDURange
Jump to navigationJump to search
added initial content
No edit summary
 
Line 1: Line 1:
change me!
== Scoping Outline: ==


What: provide a product that supports creating and delivering custom cybersecurity exercises
=== Challenges: ===


For whom: instructors and learners, anyone who wants to learn cybersecurity, especially instructors
* '''What:''' ''"Create ways to..." / "Redesign the..."''
** Provide a product that supports creating and delivering custom computer lab exercises.
* '''For Whom:''' ''"For <user>... (considering <other stakeholders>)..."''
** Anyone who wants to learn cybersecurity and other computer science topics, especially instructors administering labs for class.
* '''Context:''' ''"In a world where..." / "Keeping in mind that..."''
** It is difficult to set up a computer lab, it can be tedious and repetitive.


context: it is difficult to set up a cybersecurity lab, it can be tedious and repetitive
=== Considerations: ===


goals: we want to automate it as much as possible, and improve student outcomes, provide building blocks for others to create content
* '''Goals:''' ''"We aim to..."''
** Automate it [What is it? Orchestration? Authoring? Administration? Managing student interaction?].
** Improve student outcomes [In or outside our own system? Do we care?].
** Provide building blocks for others to create content.
* '''Crux:''' ''"We really need to..."''
** Understand how students learn.


crux: understand how students learn
== Framing Checklist: ==
We should discuss these qualities:


* You tried on some behaviors (like empathy and rapid prototyping) on a current project before launching a new one.
* Project is a human, subjective challenge (understanding people is key to the project success).
* Project is geared toward discovery (not optimization).
* Challenge can be solved with a product, service, or event, not a strategy or system (for your first project).
** ''Not our first project, and we can practice concrete solutions in more narrowly scoped projects to begin immediately.''
* Those most affected by the work are acknowledged as actors with agency, not simply receivers of outcomes.
* Framing doesn’t embed a solution.
* Framing doesn’t (unintentionally) assume the form of the solution.
* Framing doesn’t (unintentionally) presume people’s needs.
* Goal of the project work is clear without dictating the specific solution outcome.
* You and your team actually care about this challenge. (If not, why are you doing it?)


== Note: Teams/Products Are Long-Lived ==
Many of the links below, and the template used for this charter, are for project scoping. Projects have limited, definite lifecycles - the project ends when the goal is accomplished, and the result is handed off to an operational team to run it.


This top-level team charter has an indefinite lifespan. It's meant to be revisited and revised (though it can also be replaced). The team charter helps us have a shared understanding of not just what we're making, but what we're maintaining and providing to our "customer" (even if we aren't necessarily selling our product/service).


See https://www.pmi.org/learning/library/team-charter-development-5128 !
== External Resources ==
See https://dschool.sfo3.digitaloceanspaces.com/documents/Design-Project-Scoping-Guide_V7.pdf!


Also:
Also:


* https://www.pmi.org/learning/library/team-charter-development-5128
* https://www.atlassian.com/work-management/project-collaboration/team-charter
* https://www.atlassian.com/work-management/project-collaboration/team-charter
* https://dschool.stanford.edu/tools/design-project-scoping-guide
* https://dschool.stanford.edu/tools/design-project-scoping-guide
* https://ocw.mit.edu/courses/1-040-project-management-spring-2009/
* https://ocw.mit.edu/courses/1-040-project-management-spring-2009/
* https://www.nasa.gov/reference/4-1-stakeholder-expectations-definition/
* https://www.nasa.gov/reference/4-1-stakeholder-expectations-definition/

Latest revision as of 17:00, 27 April 2026

Scoping Outline:

Challenges:

  • What: "Create ways to..." / "Redesign the..."
    • Provide a product that supports creating and delivering custom computer lab exercises.
  • For Whom: "For <user>... (considering <other stakeholders>)..."
    • Anyone who wants to learn cybersecurity and other computer science topics, especially instructors administering labs for class.
  • Context: "In a world where..." / "Keeping in mind that..."
    • It is difficult to set up a computer lab, it can be tedious and repetitive.

Considerations:

  • Goals: "We aim to..."
    • Automate it [What is it? Orchestration? Authoring? Administration? Managing student interaction?].
    • Improve student outcomes [In or outside our own system? Do we care?].
    • Provide building blocks for others to create content.
  • Crux: "We really need to..."
    • Understand how students learn.

Framing Checklist:

We should discuss these qualities:

  • You tried on some behaviors (like empathy and rapid prototyping) on a current project before launching a new one.
  • Project is a human, subjective challenge (understanding people is key to the project success).
  • Project is geared toward discovery (not optimization).
  • Challenge can be solved with a product, service, or event, not a strategy or system (for your first project).
    • Not our first project, and we can practice concrete solutions in more narrowly scoped projects to begin immediately.
  • Those most affected by the work are acknowledged as actors with agency, not simply receivers of outcomes.
  • Framing doesn’t embed a solution.
  • Framing doesn’t (unintentionally) assume the form of the solution.
  • Framing doesn’t (unintentionally) presume people’s needs.
  • Goal of the project work is clear without dictating the specific solution outcome.
  • You and your team actually care about this challenge. (If not, why are you doing it?)

Note: Teams/Products Are Long-Lived

Many of the links below, and the template used for this charter, are for project scoping. Projects have limited, definite lifecycles - the project ends when the goal is accomplished, and the result is handed off to an operational team to run it.

This top-level team charter has an indefinite lifespan. It's meant to be revisited and revised (though it can also be replaced). The team charter helps us have a shared understanding of not just what we're making, but what we're maintaining and providing to our "customer" (even if we aren't necessarily selling our product/service).

External Resources

See https://dschool.sfo3.digitaloceanspaces.com/documents/Design-Project-Scoping-Guide_V7.pdf!

Also: