Session 03: Analyzing Data

Hi there and welcome to this session of the PM Standards project where I am creating a repository for project management standards. In the last session I compiled a list of project management standards based standards in use, standards from notes, and standards that are known but have not been implemented yet. In this session, I will categorize the standards and assess what is and what is not part of the scope of this project.

Here is the compiled 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?
• Practices in use
  • Scope (needs, goal, objectives, deliverables)
  • Phases and life cycle
  • Sessions
  • Retrospective (Lessons Learned, Action Items)
  • Project Queue
• Practices not in use yet
  • Drafting and versioning rules
  • Branding and legal guidelines
  • Tool usage
  • Marketing guidelines

I’m going to toss this list into a spreadsheet and attempt to categorize the items. I categorized the items by type which turned out to consist of the following labels: project anatomy, project specifics, process specifics, anatomy specifics, project-type specific, planning instructions, and session instructions.

Once the items were sorted by type I assessed whether they would be within or outside of scope. The criteria of whether the item was accepted or not was could the item change independently of project planning? For instance, tool usage has come up a lot – which refers to the objective that projects should use Cryptiquest crafting/planning tools as they are available. While this is important to Cryptiquest, it is not necessarily important to everyone. In addition, this rule may become more refined later. Instead of including it in this project, I think it makes more sense to reference company objectives while determining scope – and there (within the company objectives) you will find the caveat for using Cryptiquest tools.

Here is that list:

And now I will refine this list to its core elements:

• Project Anatomy
• Workflow (project-agnostic)
• Phases and Life Cycle
  • Need, Scope, and Your Compass Statements
  • Research and Analysis
  • Production
  • Review
  • Launch
  • Retrospective

I think that sums it up pretty well. In the next session, I will plot out how best to build and present this repository. See you there.

Action Items

N/A