Session 02: Gathering Data

Hey hey! Welcome to this session of the of the PM Standards project where I am creating a repository of project management best practices for Cryptiquest. The last session kicked off this project, resulting with goals, objectives and deliverables for the first phase (research) of this project. In this session I will gather the content to analyze.

Let’s begin.

I need to gather the following data:

1. The PM (project management) notes from the various retrospectives;
2. PM standards that I use that have not been yet documented; and,
3. PM standards that I am aware of but not yet created/implemented.

I’ll start with the PM notes. I’ll dump those below here as a list:

• Define what a project is and project terminology
• Include instructions for how to define the need, obstacle, solution, goal, objectives, and methods for success – and how they tie to Cryptiquest values and missions.
• Session instructions, including when to use recaps, how to use recaps, etc.
• All time estimates/actuals should be displayed in hours/days.
• All time estimates/actuals should account for developer time only.
• Time estimates should be presented as a min-max range.
• Each deliverable should always start as a session.
• A “New Action Items” segment must be included at the end of each session.
• Add “Limitations” section to each kick-off session.
• A step for “Assessing the Goal, Objectives and Deliverables” should be added any time the scope or direction of the project changes, noting that as long as the direction brings the project closer to solving the need, it is okay to update.
• To address ISSUE 1, add a research phase between objectives and project plan.
• To address ISSUE 2, there needs to be a need-analysis phase before the review phase where the product is scrutinized to answer the following questions:
  • What problem does this solve?
  • Who is the target audience?
  • Why are they the target audience?
• To address ISSUE 3, there needs to be a project naming convention that focuses on need rather than solution.
• The design process for new tools must include:A “collaboration assessment phase” to consider in what ways the new tool and old tools can collaborate and how they must change in order to do so.
• A “creator concept-to-launch assessment phase” to consider in what ways the new tool will guide creators from concept to launch.
• A “share and collaborate assessment phase” to consider in what ways the new tool will enable creators to share and/or collaborate on projects.
• A “accessibility assessment phase” to consider in what ways the new tool might abandon users based on ability.
• A “game format phase” to consider in what ways the new tool fits into all supported formats.
• A “engine integration phase” to consider in what ways content created by the new tool will come to life in the engine.
• The following types of feature requests will have equally high priority:
  • Tool collaboration
  • Process guidance
  • Collaboration and sharing
  • Accessibility
  • Game format
  • Game integration
• The design process for new media must include a “tool usage” phase to consider which tools should be used for the project.
• Perhaps the Retrospective should be generated at the start of each project and store all the project planning elements (need, goal, objective, etc.) and considerations?

Okay. Next I will take a look at the PM standards that I follow but haven’t documented:

• Scope (needs, goal, objectives, deliverables)
• Phases and life cycle
• Sessions
• Retrospective (Lessons Learned, Action Items)
• Project Queue

And here are the PM standards that I’m aware of but have not implemented:

• Drafting and versioning rules
• Branding and legal guidelines
• Tool usage
• Marketing guidelines

That’s everything that I can think of for now. In the next session, I will organize this in some categories and assess what is and is not part of this project.

See you there.

Action Items

N/A