Stakeholder Model

Purpose: The purpose of the Stakeholder Model template is to document internal and external individuals or groups who have a stake in for example an enterprise or a project. Below, you can see an example of a Stakeholder Model of Order Management:

StakeholderModel_1

Core concerns: Stakeholders can be grouped via Business Scope. Stakeholder relations are illustrated via the Interaction connection. Beyond this, you can enrich the Stakeholder Model with Capabilities, Business Processes, Information Systems, Initiatives, and Projects. Below, you can see several groupings of stakeholders:

StakeholderModel_2

Relation to other diagrams: The Interaction connections in the Stakeholder Model can be broken down into Requirement Models. The internal structure of the organization is modelled in an Organization Diagram while the interaction between the organization and its external environment can be modelled in a Business Ecosystem.

Properties and metadata: The Stakeholder Model can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Stakeholder Model’s properties dialogue window, where the properties can be viewed and edited:

Work Breakdown Structure

Purpose: The purpose of the Work Breakdown Structure template is to document the systematical structure of a project to define its organization or structural levels and plan resource allocation.

Core concerns: The Work Breakdown Structure diagram consists of Results, Notes, and their connections. It gives a simple overview of the structure of a projects phases and deliverables. In the illustration below, a Work Breakdown Structure for a project that is to define the requirement specifications for a new booking system:

Inside each Result, information about the estimated needed resources.

Relation to other templates: As a Work Breakdown Structure offers a detailed view of a project’s phases and deliverables and is as such, related to the Work Model. To determine the critical path of a project you should use the Critical Path Method Diagram.

Properties and metadata: The Work Breakdown Structure can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Work Breakdown Structure’s properties dialogue window, where the properties can be viewed and edited:

Deployment Diagram

Purpose: The purpose of the Deployment Diagram is to document the configuration of run-time processing nodes and the components they contain.

Core concerns: The Deployment Diagram template is structural UML diagram that enables you to model Packages, Components, Artifacts, Instance Specifications, Properties, Nodes, Devices, Execution Environments, Deployment Specifications, Objects, Classes, Interfaces, and Annotations. They can then be connected through Association, Dependency, Generalization, Deployment or Manifestation.

The Deployment Diagram models how the different hardware component and software components are connected. Below you can see an example of a Deployment Diagram for a booking service:

DeploymentDiagram_1

In the next example, you can see how Packages and Components would be included in a Deployment Diagram:

DeploymentDiagram_2

Relation to other templates: The Deployment Diagram is, as a component model, part of the application domain on the operational level. As such, it offers a complimentary view to those of the Application Architecture Diagram, Class Diagram, Component Diagram, Data Flow Diagram, Data Mapping Diagram, Data Replication Diagram, Sequence Diagram, State Event Diagram, Structure Chart, and Use Case Diagram.

Properties and metadata: The Deployment Diagram can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the diagram
  • Links to extensions such as Stereotypes and Constraints
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Deployment Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

 

 

 

 

Critical Path Method Diagram

Purpose: The Purpose of the Critical Path Method Diagram (CPM Diagram) is to reveal the critical path through a project, i.e. the list of activities that needs special attention since a delay in these activities will delay the whole project.

Core concerns: The CPM Diagram enables you to model Project Activities and connect them with Activity Paths. The Project Activities are then enriched with information about latest and earliest dates for start and finish as well as information about duration and slack for each Project Activity.

This makes it possible to calculate the probability of finishing the project within the planned timeframe, and to successively improve and detail the plan.

Below, you can see an example of a CPM Diagram about how to develop an organization to support a strategic change. It concerns the incoming and outgoing flow of employees as well as their training across several locations:

 

CPMDiagram_2

As you can see, the critical path is marked with red.

The following example is of a technology roadmap, where the critical path shows the three most critical project activities for on-time completion:

Other functionalities: A Calendar can be linked to the Property Dialog of the diagram showing holidays for the project.

Relation to other templates: The CPM Diagram template should be used after a project has been broken down into Project Activities. As such, it can be a decomposition of a Project Activity from a Business Canvas, Value Proposition, Work Model, Strategy Model or Innovation Canvas.

Properties and metadata: The CPM Diagram ­­­­can for example retain the following information:

  • A description of the diagram
  • Link to owner
  • Link to responsible
  • Link to calendar
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the CPM diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.