Plan Project

(Activity) for Tier: Product

PURPOSE

Planning the project is a continuous activity to maintain the health of the project primarily regarding people, skills, resources, schedule, scope, and budget. Execute the sub-activities in the order and frequency that best serves the project while obtaining buy-in from stakeholders along the way.

InnovaSystems uses an integrated project planning approach to ensure the various aspects of the project are working well together. The project plan is an online information radiator which means it’s easy to find for all project personnel. Sub-plans may optionally be broken out and graduated into their own plans if they are referenced from the project plan. The project plan references items already defined in other areas such as Azure DevOps, Wikis, etc. instead of parroting them in a document.

The scope of this activity covers multiple releases with a focus toward customer and contract important milestones such as the period of performance, initial operating capability, and final operating capability. The duration the project plan, known as the plan scope, is up to what works best for the project team in order to maximize on-time delivery, quality, and reduce risk.

WHEN

Continuously to reduce risk and ensure a healthy plan.

ENTRY CRITERIA

  • A release strategy is documented within the Project Plan

SUB-ACTIVITIES

  1. Plan Project Objectives

    • Outline the period of performance or task order objectives and include contract deliverable documentation within the plan scope and begin planning the critical path (including critical dependencies) to ensure the most important objectives are achievable.
    • Add specific technical objectives to improve security, mitigate technical obsolescence, and reduce technical debt in order to reduce maintenance and ensure the system can support continued growth.
    • Identify risks such as bottlenecks, architectural or technical complexities, and resource availability for further analysis and response. Some bottlenecks are systemic and must be addressed early such as achieving an Authority to Operate (ATO) or Interim ATO.

    Note

    Some solutions may be technical or architectural and the involvement of the team is critical when conducting this planning.

    • Work with the Product Owner to develop and prioritize the product backlog. Many objectives will relate to the delivery of Features within a Product. There must be alignment between these two constituencies to ensure smooth delivery of objectives.

  2. Plan the Team’s Knowledge and Skills

    • Determine the necessary knowledge and skills to achieve the period of performance or task order objectives.
    • Derive any knowledge or skill gaps by comparing the list of objectives and contract deliverables with the current teams.
    • Document the required, available, and gapped skills within the Knowledge and Skills section of the project plan. A matrix may be helpful to maintain this data.
    • For each gapped skill, develop and document a mitigation approach. This may include staffing to also mitigate under execution.

    Note

    Teams should consider using the product backlog or Risk and Opportunity Management. The intent is to document it in a way that is visible and tracked.

  3. Plan the Team Resources

    • Ensure the project team is staffed to enable maximum capacity in order to achieve the objectives of the project and execute the budget. Continuously monitor this and work with business unit leadership to ensure staffing gaps are mitigated.
    • Work with HR and create RIDs when necessary.
    • Develop a shared resource plan for temporary personnel that may benefit the project. This may include technical, domain, and project knowledge sharing.

  4. Plan the Team’s Working Environment

    • Work with each project team member to review the ISI Work Environment Standards and determine any further needs outside of existing standards. Take note of systemic needs that others will have and provide feedback to IT when the standards are outdated.
    • Assess other environmental needs such as security considerations, facility access, clearance, and disabilities. Coordinate with human resources regarding ADA considerations as necessary.
    • Estimate the shared physical, hardware, software, and facilities required by the project team based on period of performance or task order objectives. Work with the Project Lead and Business Unit Lead (BUL) to determine and document actions to fulfill these needs. IT related requests are submitted via InnovaHelp on the InnovaNet homepage.
    • Document (or link other plans) to any resources (facilities, tools, etc.) necessary beyond ISI Work Environment Standards within the Resources section of the Project Plan.

  5. Schedule Project Objectives

    • Forecast the delivery of new and major updates to Features

      • Use average Feature cycle/lead time as a starting point while considering what work remains and partial updates to Features. If small enough, the lead/cycle time of child user stories may be preferred.
      • The forecast can be augmented by estimating the count of user stories and average cycle/lead time or average story points.

    • Forecast the delivery of smaller updates to Features

      • Use the count of user stories and average cycle/lead time or average story points.

    • The project may determine it’s forecast method for non-Feature objectives and describe it within the project plan. E.g. The team may need to forecast a data quality review, table top exercise, or interop test.

    Note

    For Features, using average Feature Lead Time while reducing Feature size variance is an example of a well-supported method.

    • Document the forecast in terms of a schedule and notional releases and critical dependencies within Azure DevOps. This will help drive release planning and ensure the team remains focused on the most important period of performance or task order objectives. Continuously revisit this to keep it from becoming stale. This is the project schedule.

    Note

    Objectives, especially features, are planned in accordance with the release strategy. The release strategy determines whether releases are scope-based or time-boxed.

  6. Plan Contract Deliverable Documentation

    • Assign responsibility to develop and maintain contract deliverable documentation to individuals and teams that have both the authority and knowledge. The team may use user stories or tasks to manage these documents.

    Note

    Using user stories may affect cycle/lead time metrics and subsequently estimates for delivering functionality. A project may designate these types of stories under a separate team if this is a concern. This does not apply to end-user documentation which should be part of the definition of done for a user story that delivers functional value.

    • Establish an optimal periodicity for updating and delivering the contract deliverable documentation. Estimate the level of effort based on historical data.
    • Iteratively plan concrete delivery dates or iterations (sprint or release) based on project promises and estimated level of effort for each contract deliverable documentation in the plan scope. Ensure the schedule is apparent to and monitored by the team. The contract deliverable documentation are managed as a part of sprints, releases, and the project schedule.

  7. Plan Stakeholder Involvement

    • Review the forecasted objectives and determine the necessary external stakeholders to ensure a smooth delivery.
    • Derive project specific meeting cadences with stakeholders beyond what’s specified in the process to ensure communication between stakeholders remains healthy. Work with sponsors, users, and the team to determine the right balance of meetings and focus time. For example, the customer may want regular status updates beyond what is provided in the Sprint Review.
    • Determine the role and influence of each external stakeholders. It may be useful to track whether a stakeholder is supportive, neutral, or a detractor in order move them toward a supportive posture.
    • Determine the value and information stakeholders seek and the planned methods to provide the value and information beyond what is described in the process.
    • Document the above within Stakeholder Involvement section of the Project Plan.

  8. Review and Obtain Buy-in

    • Review the project plan with the project team to collect feedback and update until they buy-in.
    • Review the project plan with external stakeholders as stated within the Stakeholder Involvement section of the plan. Work with customers/sponsors to achieve the level of approval they require.

    Note

    Consider review of the project plan with other Innova Project Managers for consistency.

    • Conduct a final review with the Chief Operations Officer and BUL to approve the Project Plan.
    • Pay particular attention and escalate any risks relating to a mismatch between contract derived objectives and expectations from customers or sponsors.
    • Circle back and update the project team if any significant changes are required by external stakeholders.
    • Record the plan buy-in.

OUTPUTS

Project Plan

EXIT CRITERIA

  • The Project Plan has been reviewed and approved by the project team and external stakeholders