Work Model

Purpose: The purpose of the Work Model template is to document development methods or project models.

Core concerns: The Work Model template enables you to model Project Activities, Milestones, Results, Quality Controls, Document Structures and Business Scopes. These objects are joined by Connections indicating a flow.

The Work Model template can, for example, be used by Enterprise Architects to document the Enterprise Architecture process from start to finish while covering all the project activities, milestones, and results. The Work Model helps ensure a standardized approach.

Below, you can see a few examples of Work Models utilizing a variety of the available objects:

 

The above model shows a simple project flow enriched with mile stones, results and a quality control.

The above model illustrates another generic model for a software development project – this example has more milestones inserted as well as added document structures containing project deliverable templates.

Relation to other templates: The Work Model template should be used to document project activities – to document business processes and workflows should be documented in Business Process Networks, Workflow Diagrams or Business Process Diagrams.

For a more detailed view of the structure of a project’s results and resources, a Work Breakdown Structure template should be used.

 

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

  • A description of the diagram
  • Link to the owner of the model
  • Link to the one responsible for the model
  • 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 Work Model, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

Workflow Diagram

Purpose: The purpose of the Workflow Diagram template is to document the Business Processes of an enterprise at the activity level.

Concerns: The Workflow Diagram template should be used to document the Activities, Roles, Business Events, Activity Paths and Workflow Conditions of a Business Process. Available in the default modeling syntax are also Business Objects, External Objects, Information Systems, Database, Inventory, Information Flow and Logistical Flow. The syntax can be easily extended to include more objects such as Requirements, Business Rules and Goals. Below you can see an example of a Workflow Diagram with multiple Roles that are modelled vertically:

WorkFlowDiagram_2

Relation to other templates: The Workflow Diagram does not support BPMN, if using that notation, you should model in the Business Process Diagram template. The Workflow Diagram can link to other Workflow Diagrams and are typically linked to by Business Process Networks. In the picture below, you can see another example of a Workflow Diagram. Here the Roles are modelled horizontally and you can see the links to and from other diagrams at two Business Events (‘ECR completed’ and ‘Rework’):WorkFlowDiagram_1

Other functionalities: In QLM, you can control which buttons related to risk management are shown below activities. You can choose to hide or show Risks, Controls and Key Controls. Both Controls and Key Controls are a type of Activity. From the Risk related toolbars (available via the “Actions” tab on the right-hand side of the Canvas in QLM) choose the following button to control what button panels appear on the Activity objects:

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

  • A description of the diagram
  • Information on cost and duration of the process
  • 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 Workflow Diagram’s properties dialogue window, where the diagram’s properties can be viewed and edited:

Product Variant Master

Purpose: The purpose of the Product Variant Master template is to provide an overall view of a product’s variants and can be modelled from the viewpoints of the Customer, Engineer, Part, or Production.

Core concerns: The Product Variant Master template enables you to model product variants by mapping their parts and part variants. The template includes the following objects: Product, Product Rule, Product Attribute, External Document and General Concept. These objects can then be connected as being Part of Product, Kind of Product, or by a “View Connection”.

The abstraction level that defines whether the model is from the viewpoint of the Customer, Engineer, Part or Production is chosen in the model’s property window.

The model below is a Product Variant Master of a balcony:

ProductVariantMaster_1

Relation to other templates: The Product Variant Master is a decomposition of a Product. As such it is related to the Product Canvas and Product Architecture. It can contain a Product Rule Table and could also be linked to from a Product Roadmap.

Properties and metadata: The Product Variant Master can for example retain the following information:

  • A description of the model
  • Choice of the Kind of Notations Graphics
  • Choice of Abstraction Level
  • 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 Product Variant Master where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: You can learn more about the Product Variant Master model by reading the following article (page 1-7):

Mortensen, Niels Henrik; Hvam, Lars; Haug, Anders: Modelling Product Families for Product Configuration Systems with Product Variant Master. (p. 1-7) In: Wotawa, Franz & Pill, Ingo. (2010). On Classification and Modeling Issues in Distributed Model-based Diagnosis.

 

Product Rule Table

Purpose: The purpose of the Product Rule Table template is to document the rules pertaining to a specific product.

Core concerns: The Product Rule Table is used as an auxiliary template and functions like a matrix that contains Product Rules.

Below, you can see an example of a Product Rule Table for a balcony:

ProductRuleTable_1

Relation to other templates: The Product Rule Table is related to templates such as Manufacturing Routing Network, Product Architecture, and Product Variant Master.

Properties and metadata: The Product Rule Table can for example retain the following information:

  • A description of the table
  • Audits (auto generated information regarding its current state and access rights)
  • Matrix Behavior

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

Product Roadmap

Purpose: The purpose of the Product Roadmap is to visualize the lifecycles of the projects, within a specific scope and timeframe, in your product portfolio.

Core concerns: The Product Roadmap template enables you to model Products, Markets, Projects and Personae within a Timeframe. Additionally, you can add objects representing Equipment and Work Centers. This allows you to map the lifecycle of product releases within different markets for different customer segments.

Below, you can see two examples of Product Roadmaps. The first showing the timeframe and markets for the release of different apps with multiple versions:

ProductRoadmap_1

The second figure spans over several years to provide a high-level view of a products expected lifecycle spanning over several projects. It also illustrates how you can model markets with multiple customer segments, in this case based on gender:

ProductRoadmap_2

Relation to other templates: The Product Roadmap Template is inherently related to the Product Architecture, Product Canvas and Product Variant Master, in the sense that all these models focus on different aspects of the lifecycle of a product. Another view on projects and initiatives are provided from the Enterprise Investment Portfolio. There, the reasoning behind the investment in the project is visualized by connecting the initiative (in this case a new product) to the specific goals of the enterprise that it contributes to.

Properties and metadata: The Product Roadmap can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the model
  • Link to the one responsible for the model
  • 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 Product Roadmap where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

Product Canvas

Purpose: The purpose of the Product Canvas template is to present the relevant information related to a specific product.

Core concerns: The Product Canvas template enables you to gather relevant Business Charts and model Personae, Product Demands, Markets, Locations and Products. Additionally, you can model a SWOT analysis that details the Strengths, Weaknesses, Opportunities and Threats the product is affected by.

Below, you can see two Product Canvases. The first has its focus on a product within two markets, showing the expectations two different customer segments have to the product.

ProductCanvas_2

The second example shows information related to a specific market, Poland, including product architecture and business assessment:

ProductCanvas_1

Relation to other templates:

The Product Canvas Template is inherently related to the Product Architecture, Product Roadmap and Product Variant Master, in the sense that all these models focus on different aspects of the lifecycle of a product. Furthermore, you can create additional Business Charts for the Product Canvas by using the dedicated template. Another view on projects and initiatives are provided from the Enterprise Investment Portfolio. There, the reasoning behind the investment in the project is visualized by connecting the initiative (in this case a new product) to the specific goals of the enterprise that it contributes to. Another view on how the product meets customer needs can be documented in the Value Proposition Canvas.

Properties and metadata: The Product Canvas can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the canvas
  • Link to the one responsible for the canvas
  • 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 Product Canvas where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Product Architecture

Purpose: The purpose of the Product Architecture template is to document the building blocks of a product. Below is an example of a product architecture:

ProductArchitecture_1

Core concerns: The Product Architecture template enables you to model a Product and connect different parts of it with three different connection types: Part of Product, Kind of Product, and Product Interface. See below for an example of a Product Architecture where each Product object is represented graphically:

 ProductArchitecture_2

Relation to other templates: Depending on whether the product is in production or in its development phase, it could be further described in a Product Viewpoint template, have a Product Variant Master, Product Rule Table or be represented in a Product Canvas. It may also be illustrated along with other products in a Product Roadmap, just as its production may be detailed in a Manufacturing Routing Network.

Properties and metadata: The Product Architecture 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 Product Architecture’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:

Customer Journey Map

Purpose: The Purpose of the Customer Journey Map template is to document the customer’s journey from awareness to the end of their interaction with an organization, covering possible touch points from the customer’s perspective.

Core Concerns: The Customer Journey Map template allows you to model connections between different Personas, Customer Journey Phases, Touch Points, Goals, Roles, Locations, Channels, Technology and the aspects from a SWOT analysis.

You can choose to model both a current state and a desired future state of the customer journey and use the documentation for process improvement. Below is an example of a current state model and a future state model:

Current state model:

CustomerJourneyMap_2

Desired future model:

CustomerJourneyMap_1

Other functionalities: The customer’s touchpoints can be elaborated upon with four scores for Customer Satisfaction, Customer Importance, Customer Effort and Net Promoter Score. Particularly vital touchpoints can be designated as a Moment of Truth.

Relation to other templates: The Customer Journey Map can be used as a groundwork for a strategic change, which for example can be modelled in a Work Model, a Business Capability Model and/or a Strategy Model.

Properties and metadata: The Customer Journey Map 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.

The above picture shows the properties dialogue window for the Customer Journey Map, where you can view and edit the diagram’s properties.

For more information: on Customer Journey Mapping, please view our webinar Experience Mapping – Customer Obsession for IT and Digital Professionals with Milan Guenther and Katharina Weber.

 

 

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.