Project Planning Phase

The Planning Phase confirms and validates how the project will be executed, monitored, controlled, and closed. While it begins once you're engaged with your Project, it is generally validated within the first 2 weeks and through the initial Discovery Sessions. Planning is when we re-iterate the impact of known risks to the Project scope and/or timeline as well as ensure our communication plans are effective.

1. Develop or Validate Project Management Plan

While we at GitLab have a preference to perform all planning within GitLab, we must adjust to customers needs. Delivery of a Plan can come in the form of a fleshed out timeline using GitLab Epics and Issues, it can be a Work Breakdown Structure based backlog, or it can be housed within a customer project management tool.

  • Review and incorporate impact of potential risks
  • Update comprehensive project plan according to new findings
  • Recommunicate scope, schedule, and cost baselines

inputs:

2. Validate & Agree on Scope Management

  • Communicate any changes to scope control & change management procedures
  • Confirm scope statement with acceptance criteria
  • Iterate WBS with work packages

3. Confirm Schedule Alignment

  • Reference Date Management Guidance for Kantata
  • Validate required activities (Definition of Done)
  • Establish activity relationships & owners
  • Iterate on schedule as critical paths evolve
  • Review Project Launch Plan strategy (timing, risks, etc.)
  • Update Milestone dates as needed

4. Iterate the Resource Plan & Management

  • Update roles and responsibilities as you learn more about the project
  • Iterate & Communicate RACI matrix
  • Determine if there are any new resource requirements

5. Evolve the Communications Management as Needed

A customer communication plan is to be developed and shared along with the Project Charter. The linked Communication Plan Template provides a starting point to create a communication plan that works for your stakeholders.

  • Update stakeholder communication needs as changes arise
  • Update communication matrix (ReadMe)
  • Confirm stakeholder management approach is visible
  • Ensure Communicate plan & schedule is updated and always visible

6. Risk Management

Mitigating Risk via RAID Board

  • The RAID, Risks, Actions, Issues, and Decisions dashboard is our way to ensure a single source of truth for project risk & resolution
  • It is where our internal project stakeholders and leadership can reference the latest project information when the project is trending or sitting in a Y/R health status
  • The RAID is automatically created when the PM creates the CP template. First step is to rename template “RAID - Customer - SOW/PO#
  • While the RAID is created, managed, and reported by the PM, the internal & Customer team is encouraged to update the RAID as we work through Project challenges and mitigations.
  • The Risk Management Process can be found here.