Stakeholder

15. April 202028. April 2020 Oliver Schönfeld

Stakeholders are all persons and groups affected by a system, as well as all those directly interested or involved in the product. Stakeholders are invited to Review meetings at all levels and can optionally be invited to Backlog Refinement meetings to explain their requirements.

To identify stakeholders, the P4 framework uses two different life cycles as conceptual guidelines. These are:

the product life Cycle (from the idea to the end of product maintenance) and
the single item life Cycle (from purchase of raw material to recycling)

For each product or system, the different stakeholders (= interest groups) can be identified from these.

Product life cycle

Item life cycle

The P4 framework distinguishes between three groups of stakeholders, which are assigned to the three areas

Other stakeholders

In addition to the “direct” stakeholders, other, “more general” stakeholders are usually defined in requirements management. These are, for example

the society, consisting of public and government organizations
the environment (mostly affected by emissions and waste)
competitors

In the P4 framework, these stakeholders are not represented by Stakeholder Needs, but by specific goals (e.g. to describe the competitive situation) or they are represented by norms and standards in the area of Quality Attributes & Constraints (QA&C).

Stakeholder map

A Stakeholder map shows the various stakeholders with their needs and the strength of their influence on the team or system.

\r\n

Further suitable links:

Definition on Wikipedia: Stakeholder

Modelling the organization

28. March 202023. April 2020 Oliver Schönfeld

With organizational modeling, the specific organization is modeled by P4 elements, i.e. the teams, groups and Clusters are represented by their information and work flows.

The processes can now be represented within the organizational model, whereby this is done by defining and documenting the corresponding inputs, responsibilities, actions and outputs. Every organizational unit is described according to the SIPOC method (Supplier – Inputs – Process – Outputs – Customers).

Cluster Management Circle

8. February 20204. May 2020 Oliver Schönfeld

A Cluster within the product development Organization is managed by a group of managers. It consists of at least the following roles:

Other management roles complement the Management Circle depending on the type and orientation of the Cluster.

\r\n

Further suitable links:

Management Circle of the Organization

8. February 20204. May 2020 Oliver Schönfeld

The product development Organization is managed by a group of managers. It consists of at least the following roles:

Other management roles complement the Management Circle depending on the type and orientation of the organization. Often the CEO of the Organization is leading this Management Circle.

\r\n

Further suitable links:

Portfolio Architect (PFA)

29. December 20194. May 2020 Oliver Schönfeld

With the Cluster System Engineer Group at Portfolio and organizational level, the Portfolio architect is responsible for the technology and architecture side of the entire product development process.

The Portfolio architect forms the management of the entire Organization together with the Portfolio Owner and the Organization Scrum Master .

Cluster System Engineer (CSE)

29. December 20194. May 2020 Oliver Schönfeld

With the Team System Engineer Group at the Cluster / system level, the cluster System Engineer is responsible for the technology and architecture within the product creation process.

Portfolio Owner (PFO)

28. December 201915. May 2020 Oliver Schönfeld

The Portfolio Owner is the “Product Owner” the Organization and has, together with the Cluster Product Owner Group (CPOG) on the Portfolio- or Organizational level, overall responsibility for the Market and Business side of the product development process. (A general description of the Product Owner role can be found here …)

Cluster Product Owner (CPO)

28. December 201915. May 2020 Oliver Schönfeld

The Cluster Product Owner is part of the Team Product Owner Group (TPOG). They have the responsibility for the market and business side of the product development process at the Cluster and System level,. (A general description of the product owner role can be found here …)

Responsibility of Technology and Architecture by the System Engineers

26. October 201911. May 2020 Oliver Schönfeld

The P4 framework divides its organizational and management structure of product development into three areas:

Market and business
Organization, infrastructure and processes
Technology and architecture

Technology and Architecture

The technical roles of the different levels are responsible for the used and new technologies, as well as the architecture of the developed systems, i.e. the breakdown into Functions, Modules, Components and interfaces. They communicate with the stakeholders in this area: suppliers, the supply chain and production .

The role of the Team System Engineer

Within the Working Team , the Team System Engineer has the role of moderating and driving technical decisions and, when in doubt, making decisions. He is not “above” the Working Team, but is, so to speak, the “first among equals” (Primus inter paris).

The Team System Engineer of a team represents the technical expertise and responsibility of his team in groups and committees, as well as in the coordination between the teams. As a representative of its Working Team, it estimates, for example, the Cluster Backlog Items together with the Team System Engineers of the other teams in the cluster.

The role of the Cluster System Engineer

Within the Team System Engineer Group , the Cluster System Engineer has the role of moderating and driving technical decisions and making decisions when in doubt. He is not “above” the Team System Engineer Group, but is, so to speak, the “first among equals” (Primus inter paris).

The Cluster System Engineer of a Cluster represents the technical expertise and responsibility of its cluster, in groups and committees, as well as in the coordination between the Clusters. As a representative of its Team System Engineer Group, it estimates, for example, the Portfolio Backlog entries together with the Cluster System Engineers of the other Clusters.

The role of the Portfolio architect

Within the Cluster System Engineer Group , the Portfolio architect has the role of moderating and driving technical decisions and, when in doubt, making decisions. He is not “above” the Cluster System Engineer Group, but is, so to speak, the “first among equals” (Primus inter paris).

The Portfolio architect represents the technical expertise and responsibility of the organization in the organizational management group vis-à-vis the Portfolio Owner and the organizational Scrum Master in order to achieve a global balance between the topics.

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Team Planning

Team Sync

Team Backlog Refinement

Cluster Backlog Refinement

Cluster Review

Cluster Retrospective

Organisation Retrospective

Team Product Owner

System Engineer

Team Scrum Master

Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master

Portfolio Owner

Portfolio Architect

Organisation Scrum Master

Working Team

Community of Practice

Team Product Owner Group

Team System Engineer Group

Team Scrum Master Group

Cluster Management Circle

Cluster Product Owner Group

Cluster System Engineer Group

Cluster Scrum Master Group

Organisation Management Circle

Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog

Cluster Backlog

Usable Knowledge & System Increment

Cluster DoD

Cluster Improvement Backlog

Portfolio Backlog

Systems & Applications

System Platforms & Variants

Organisation DoD

Organisation Improvement Backlog

Team Product Owner

25. September 201927. April 2020 Oliver Schönfeld

The Team Product Owner prioritizes the Team Backlog and approves the results of the Working Team. The Team Backlog can contain several product developments or parts of them. (A general description of the Product Owner role can be found here …)

Depending on the type and area of responsibility of the Team (“team flavor”), the results of the teams vary greatly. Therefore, the Team Product Owners in P4 can have different names:

Service-Owner

Service owners are the technical leaders of teams who are responsible for an expertise or competence. Often members of such Service Teams are too specialized or too few to be able to work in interdisciplinary teams on a permanent basis. Another reason for a Service Team is that it operates a special infrastructure, e.g. a laboratory. These teams are often a kind of internal service provider within the organization and are usually visited or invited by other teams.

The Service Owner is responsible for prioritizing the service orders of her/his team. In the simplest case, the team uses a Kanban board with a first-come-first-serve principle (FIFO). However, the Service Owner can also divide the services offered by the team into service classes, for example, by means of different service level agreements at different costs.

To achieve an optimal flow of system development, the Service Owner adopts the priorities from the Portfolio Backlog or the Cluster Backlog in the simplest case. In addition, the Service Owner coordinates regularly with the other Team Product Owners within the Team Product Owner Group (TPOG).

Module-Owner

In the development of complex systems there will often be subsystems or Modules to make complexity more manageable (modules encapsulate complexity) or to enable the reuse of Modules and Components by means of a platform or modular concept.

A Module Owner is therefore the manager who ensures that the appropriate Modules are available for application and system development. On the other hand, She/he is responsible for ensuring that the Modules are reusable. Stable interfaces for a platform or modular system are particularly important.

Feature Owner and Application Owner

Feature Owners are the Team Product Owners of interdisciplinary teams who develop and are responsible for one or more Functions (Features) of a system variant (=applications) and make them available to users. Together with the other feature owners and the application owner, the feature owner is responsible for improving the customer value of his Application Team’s product. The application owner is the direct interface to the users of the application to decide on requirements and changes to the application.

Application Owners are the Team Product Owners of the interdisciplinary teams that develop and are responsible for marketable System Variants (=Applications) and make them available to users. The Application Owner is responsible for improving the customer value of the Application Team’s products. The Application Owner is the direct interface to the users and Stakeholders of the application to decide on requirements and changes.

The Application Team with the Application Owner are the internal clients of the Module and Service Teams. Application Teams integrate the Modules provided by the Module Teams with the help of the services provided by the Service Teams.

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Iteration Planning

Team Sync

Team Backlog Refinement

Team Review

Team Retrospective

Team System Engineer