Program Management Plan

From Yocto Project
Jump to: navigation, search



Overview of PMP


The purpose of this document is to identify and describe the overall program management processes and methods to be used during all phases of the open source Yocto Project. Derivate programs will follow their own program management processes and methods and document them accordingly.


This Program Management Plan (PMP) establishes the overall plan for the project management of the Yocto Project for versions 1.0 and later. The PMP is a living document and shall be modified as needed under configuration control.

Applicable Documents

The following documents may be referenced within:

Yocto Project PRD


For this document, the following terms and abbreviations apply:

BSP Board Support Package

CCB Change Control Board

PMP Program Management Plan

POR Plan of Record

PRD Product Requirements Document


Project Overview

Please see Yocto Project Feature List for a description of the specific features in any given release of Yocto Project.

Project Startup Checklist

Upon receiving consent to begin the Project, the Engineering Program Manager will conduct the tasks marked as applicable in the table below to begin the Project. Details on how to conduct these tasks are contained in this document. Completion status will be reported in the project wiki at

Task Required for this project?
Internal Team Kick-off meeting Required
Review staffing plan and roles with team. Required
Review proposal (Feature List, Assumptions, deliverables, design approach). Required
Discover and document additional requirements. Required
Review and update risk tracking list Required
Review and update project plan (schedule, milestones). Required
Review acceptance approach. Required
Prepare communication plan and flow. Required
Determine meeting types and schedule. Required
Determine report types and schedule. Required
Set up configuration management team Required
Set up any new e-mail aliases required Required
Formalize issue tracking and escalation plan. Required
Prepare initial status report. Required
Update Project Portal on wiki Required

Project Defined Processes and Tools

This section documents the project’s defined processes. Where a discrepancy is found between a process described in a linked document or website and this document, this document shall be considered to be the correct process.

Design and Development Process

Yocto Project Design and Development Process

Quality Management Process

The quality management process and test plan is documented in the following wiki page: --> Yocto Project v1.0

Overall Release Engineering Process

The process used for producing Yocto Project releases is documented on the following wiki page: and

Configuration Management Process

The configuration management tool for all software will be GIT. Current Configuration management practices regarding the rules for access and changes will be followed and are described in the following wiki page:

Change Management Process

Yocto Project will have a Change Control Board that will control changes to documents under change control, such as the Feature List or PRD. Changes to documents under change control must be proposed in writing to the Change Control Board via the public Change Control board email list. At least 50% of the CCB needs to respond with a two-thirds approval rate. If there are any disapprovals, the Yocto Project Architect needs to understand the reason for disapproval and agree that the change can proceed in spite of the disapproval.

The Change Control Board members shall be appointed by the Yocto Project Architect. Anyone in the community is welcome to apply to the CCB.

The Yocto Project code base will be considered under change control during the Test/Release phase of each Milestone. During this time, the CCB will approve any significant changes to the code base.

BSP Process

This project will use the Poky standard for BSP formats, documented in the BSP Development Guide:

Requirements Management Process

This project will manage features in a Feature List on the project wiki, which will be extruded into the project PRD. The Feature List for 1.0 is ratified as POR by the Yocto Project CCB. Any material changes to the Feature list after POR is set must be ratified by the CCB. Non-material changes may be made by a member of the Yocto Project community by notifying the CCB by email.

The feature list is created by the following process: Current release minus one month: Yocto Project Architect sends a solicitation for next release features. All comments are collected. Current release minus one week: Yocto Project Engineering Managers, Yocto Project Architect, and Yocto Project PM go through the feature request list. Yocto Project Architect prioritizes the features. Group agrees on a theme. PM begins the planning process around this. It is desirable to do this as a mini-conference so that additional people beyond Management, Architects, and PMs are invited.

Current release plus one week: Yocto Project Engineering Manager makes an announcement of the features and themes for the next release.

Maintainers take the finalized feature list and schedule it into different milestones and sprints. The PM will use this list to manage the project.

Project Tools

The following toolset will be used in the execution of this Project:

Function Tool
Schedule and Progress Tracking Yocto Project Wiki (ex.
Overall Milestone Tracking Via email to
Bug Tracking (pre-release) Bugzilla -
Bug Tracking (post-release) Bugzilla -
Requirement Tracking Yocto Project PRD
Software Configuration tool GIT
Document Repository Yocto Project Wiki (
Communication to Team Mailing lists:,
Feature Tracking Yocto Project Wiki (

Project Organization and Roles

Project Roles includes the processes required to make the most effective use of the people involved with the project.

Project Team Roles/Responsibilities

Generic Description of Roles and Responsibilities

Engineering Managers: An engineering manager is a manager at a company contributing to Yocto Project that has a team of Yocto Project engineers reporting to them. The engineering manager is responsible for managing the resources, schedule and requirements within their company for a particular feature area. Responsibilities include but are not limited to:

• Creating and maintaining a schedule for their particular feature group

• Reporting progress against the schedule

• Ensuring development within the feature group is on schedule and determining recovery plans when not on schedule

• Identifying and resolving any resource conflicts for staff reporting to them and/or working in their feature group or escalating problem if resolution not found

• Ensuring all committed requirements owned by feature group are met

• Preparing risk mitigation plan for feature group

• Escalating problems and issues to overall project manager Note that the managers may delegate any or all of their day-to-day responsibilities to an appropriate individual contributor but they still own the responsibilities above.

Engineering Program Manager

The Engineering Program Manager is responsible for the managing the overall project. Responsibilities include but are not limited to:

Creating and maintaining a schedule for the overall project

Reporting progress against the schedule

Reporting status of overall project

Ensuring project is on schedule and working with development managers to determine recovery plans when not on schedule

Determining overall staffing requirements for project and creating staffing plan

Identifying resource conflicts in consolidated schedule and working with development managers to resolve

Ensuring all committed requirements which are not assigned to a feature group are met

Preparing and executing risk mitigation plan for overall project

Escalating problems and issues to the project architect and the project Steering Group as a last resort

Running project meetings, recording minutes and tracking actions

Coordinating activities with groups external to the project

Publishing project information on project portal on the wiki

Scheduling and running program reviews


A Maintainer is an engineer who works on projects requiring advanced knowledge or technical expertise in a particular field of specialization and has been recognized as a responsible leader for this area. The Maintainer is responsible for:

• Technical direction for their area

• Ensuring all design documents are completed and all design reviews held

• Technical program oversight

o Of the program and other cross functional programs

o Deciding which patches or components for their area contributed by members of the community will be accepted or rejected

o Periodic review and tracking of progress toward design milestones

o Periodic review and tracking of implementation vs. High Level Design

o Identification of issues affecting the program or other cross functional areas

o Escalation point for implementation problems or critical defects

• Being the Point of Contact for technical questions and engineering impact assessment against the program of requirement changes

• Sign-off for IP review


The Architect for the project has overall ownership for the technical direction for the project. This includes, but is not limited to:

• Choice of major project components and how major components interact

• Final decision on which patches will be accepted in the project (which may be delegated to one or more Maintainer)

• Developing a long-term roadmap for the project and mapping functionality from the current release into the roadmap

• Ensuring that a proper sequence of steps are followed in releasing the project to maintain quality

Business Program Manager

The business program manager is a senior staff manager with significant technical and commercial experience in one or more specialized areas. The business program manager is the escalation point within the interest group and is responsible for scheduling and driving all marketing and sales related activates, including but not limited to:

• Branding

• Press announcements

• Conferences and trade shows

• Demos

• Design wins

Advisory Board Member

The Advisory Board is appointed by the Linux Foundation and is used as a last resort for making decisions on the Yocto Project. It is desirable that decisions for the Yocto Project are defined at the lowest reasonable level. Organizations can request participation at this level based on being LF members and acceptance by the Advisory Board.

A record of minutes from past meetings is on the Minutes page.

Staff Planning and Changes

The number of staff required will be determined between the Engineering Program Manager and the Development Managers.

Project Roll Off and Completion of Project Responsibilities

Prior to roll off, team members will need to check in all code modifications and documentation into GIT. Bugs that have been assigned to that team member will need to be resolved prior to roll off or transitioned to another team member.

Communications and Escalations

Day to Day Communication Path and escalation

The open source governance mechanism will govern the project. The Yocto Project website Governance page defines the Yocto Project governance model in additional detail:

Escalation Process

Issue resolution should be handled at the lowest possible level in the project, to avoid bottlenecking decision making. If a decision cannot be reached at the lowest level, then escalation should be made in this sequence:

• Maintainer

• Architect

• Steering Group (only as a last resort)

Project Planning and Tracking

This section is used to capture and summarize the results of project planning and to list the project tracking activities.

Program Management Oversight

A program manager has been assigned from both development and marketing to ensure effective management of the project. Responsibilities are as detailed in Section 6.1 commitments.

Project Scope Management

Scope Planning / Definition

The PRD will be used to define the scope of the project.

Scope Control

Any changes to the scope will be mutually agreed on by development and marketing and will be handled via the Change Management process, see section 5.5.


For Yocto 0.9 and Yocto 1.0, the project will be managed as a series of 6-week milestones. The milestones will be broken out as follows:

• 1 week – planning for this milestone

• 3 weeks – development

• 1 week – stabilization

• 1 week – release

The final project milestone is: 4 weeks of stabilization and release.

Project Time Management

Time management is at the discretion and using the processes of the respective group.

Risk Management

Risks will be recorded in the Engineering Sync meeting minutes.

Action Items and Major Issues Tracking

Action Items and Issues will be tracked on the Engineering Sync meeting minutes. Action Items and Issues will be reviewed and updated at a minimum of weekly.

Configuration Management

The software configuration management system used will be GIT. All electronic project documentation, including all schedules, will be stored in the Yocto Project Wiki at

Change Management

Any material changes to the commitments made in the PRD require an agreement by the Change Control Board.

Project Meetings and Reviews

The following project meetings and reviews will be held:

Meeting Participants Frequency
Engineering Sync Project maintainers and technical leads , Yocto Project Architect, Engineering Manager, Program Manager Weekly
F2F Milestone meetings Project maintainers and technical leads , Yocto Project Architect, Engineering Manager, Program Manager Every quarter (~3 months)
Steering Group See section 6.1.2 Bi-weekly (on IRC)
Yocto Project CCB Appointed by Yocto Project Architect As needed

Project Reporting

The status of the Yocto Project will be reported through the weekly Engineering Sync meeting.

Personal tools