Instantiate Project

(Activity) for Tier: Product

PURPOSE

Once a contract is awarded a project must be instantiated in order to define the purpose, scope, summary approach, initial budget, and a core team. This activity is re-assessed and executed upon and in preparation for major updates to the project such as a new period of performance (POP) or task order. The outcome of the activity is a draft project plan and shared understand of the summary approach to develop the project. The plan and approach evolve over time and with subsequent activities. Initially many aspects and roles for the project may be unclear.The goal is to clarify the project and team over time. Consider involving other roles such as the Scrum Master, Solution Architect when executing for subsequent task orders.

WHEN

At contract award, executive decision to initiate, and at each award or major revision of the contract, statement of work, task order, or period of performance.

PARTICIPATING ROLES

• ACCOUNTABLE

  • Project Lead

• RESPONSIBLE

  • Project Manager
  • Business Unit Leader
  • Product Owner
  • Development Manager
  • Chief Operations Officer
  • Chief Financial Officer
  • Finance Team Lead

INPUTS

• InnovaSystems Proposal
• Contract Documents (e.g., Contract, Statement of Work (SOW), Performance Work Statement (PWS) and/or Task Order)

ENTRY CRITERIA

• The contract has been awarded
• The executive staff has approved the project
• Priorities of proposal objectives have been revised by contract team

SUB-ACTIVITIES

1. Hold Project Kickoff Meeting

   • Hold a kick off discussion including finance and other key stakeholders from the proposal team.
   • Review the budget based on the task order to gain a shared understanding of the financial scope of the project.
   • Determine contract deliverables scope and their minimum delivery cadence.

   Note

   The proposal and budget are company sensitive information.

2. Describe the Project

   • Create a Project Plan to record and maintain decisions about the project. This plan will be elaborated in subsequent activities.
   • Provide a brief project description that describes the reason for the business case for the project and what place it has in the sponsor’s project portfolio. Describe and outline other systems, projects and programs that the project is related to, dependent upon or is a dependency of.
   • Radiate the project plan by storing it in a place that is easily noticeable and accessible to all team members. For instance, the front page of a SharePoint site or the root of Azure DevOps wiki.

3. Outline the Project Budget

   • For new projects and renewals

     • Ensure employees used within the proposal are included in the inital budget.

   • Work with the Business Unit Leader (BUL) to establish an initial budget.

   • Define budgetary milestones within the budget section of the Project Plan.

     • Approximate dates of budget reviews both internal to the organization and customer driven reviews.
     • Approximate dates of critical funding decision points such as decisions to execute Option Years or new Task Orders.

4. Form Core Team and Ensure Toolset

   • For new projects

     • Ensure the team has a Product Owner, Development Team, and a Scrum Master. The Development Team may start out as a single technical representative with a focus on architecture so the team can begin planning implementation of the InnovaSystems Proposal.
     • Ensure a suitable Azure DevOps Project is established using the ISI Agile Process template.
     • Begin to analyze the knowledge and skills necessary for project success and develop learning and mitigation strategies.
     • Plan for proactive team level continuous learning by obtaining buy-in from team members on the best approach. Revisit this continuously as the team learns and changes. This includes leveraging organizational training resources.
     • Draft the required, available, and gapped skills within the Knowledge and Skills section of the project plan. This may be refined in subsequent activities.

5. Define the Period of Performance or Task Order Objectives

   • Analyze the period of performance or task order and work with the Product Owner to decompose and schedule these objectives in Azure DevOps.

6. Establish Project Process

   • Brainstorm a list of potential tailoring to the process that may be needed to support any unique circumstance.
   • Collaborate with the process group to determine which activities may require tailoring.
   • Establish a set of baselines procedures for following the process.

7. Determine an Operational Transition and Release Strategy

   • Analyze the contract requirements and Product Backlog to determine how the project will transition product and deliverables from the development environment to an operational one.
   • Work with the team to plan the delivery approach. For new projects, a continuous delivery (CD) capability is preferred.
   • Determine whether the project will use dedicated operations or a liaison from an ops pool.
   • Develop a baseline strategy for how releases will be managed. The team determines if releases are scope-based or time-boxed.
   • Develop objectives for initial releases (minimum viable) in order to develop momentum for product management and architecture. This ensures the product design and architecture take deployment and release into consideration from the beginning.
   • Elaborate the release strategy with any other methods the team is considering. For instance, the team may want to leverage canary releases in order to collect User Research or early telemetry data.
   • Document the release strategy and justification within the Release Strategy section of the Project Plan.

8. Establish Customer Acceptance Approach

   • Work with the project sponsors/customers, BUL, technical leadership, and other relevant stakeholders to establish a release acceptance approach. This is a shared understanding of the following:

     • The method and stakholders required to approve (sign off) a release during the Close Release Plan activity.
     • The update methods and content of the release plan prior, during, and post-mortem for the release cycle.
     • The method and stakeholders to approve shipment and release of the product to government managed and production environments.

   • Obtain approval for the approach from the Cheif Operations Officer (COO).

   • Document the approach within the Release Strategy section of the Project Plan and update relevant plans to accommodate. A summary in the project plan is adequate if enough detail is provided elsewhere.

9. Review and Approve the Draft Project Plan with Stakeholders

   • Review the draft plan with project stakeholders and collect feedback.
   • Based on feedback, make necessary corrections or additions to the Project Plan.
   • Conduct a final review with the COO and BUL to approve the draft Project Plan
   • Inform the team of the location and updates to the draft project plan. The team should have access to review the plan.

OUTPUTS

• Draft Project Plan

EXIT CRITERIA

• The draft project plan is has been approved by the Chief Operations Officer, Business Unit Leader, and Team.
• The team is provided access to and status of the draft project plan.

NEXT ACTIVITY

• Plan Project

Process Guidance Version: 10.4