successful utilization of essence at munich re€¦ · introducing essence has challenges...

Successful utilization of ESSENCE at Munich ReWith a grain of salt …

Burkhard Perkens-Golomb18th June 2015, SEMAT conference, Berlin

The characteristics of the business model, the IT applications and the AD Organisation

Business ModelBusiness Model

Well established since1880 ~ 11,000 employees ~ €28bn income in 2014 Pure B2B Not many customers, not

many contracts High diversity w.r.t.

geography & lines ofbusiness Big volume of money and

data per contract Complex contracts

Well established since1880 ~ 11,000 employees ~ €28bn income in 2014 Pure B2B Not many customers, not

many contracts High diversity w.r.t.

geography & lines ofbusiness Big volume of money and

data per contract Complex contracts

ApplicationsApplications

Transactional Systems Reporting Systems Mostly expert users High complexity in data

(data structures, datarelationships, data rules, heterogeneity, quality etc.)

Transactional Systems Reporting Systems Mostly expert users High complexity in data

(data structures, datarelationships, data rules, heterogeneity, quality etc.)

Appl. Dev. OrganisationAppl. Dev. Organisation

~ 1000 FTE int. + ext. Stove pipe organisation

(„Services“) with tendencyto silos Multisourcing & offshoring In the past:

• Way of working was strictly waterfallish & document-focused

• Weak end2end responsibility

Nowadays: Movingtowards iterativ-incremental

~ 1000 FTE int. + ext. Stove pipe organisation

(„Services“) with tendencyto silos Multisourcing & offshoring In the past:

• Way of working was strictly waterfallish & document-focused

• Weak end2end responsibility

Nowadays: Movingtowards iterativ-incremental

22.06.2015 2Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb

And so …


The old way of working: The discipline-oriented setup led to a strictly sequential &artefact-based approach

Sequential activities with formal artefact-based hand-over from one service to the next, ‘orchestrated’ by a Project Manager, each service with a

specific way-of-working focused on their own activities.

Service Team

Quality Gate

Service Team

Service Team

Service Team

Project Manager

Quality Gate

Quality Gate

Project

Specify Design Code Test

HandoverPlanInitiate

“Iteration”


Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb

Snapshot of a discussion in the SEMSO1) group …

No commonunderstanding ofparticular workproducts

Different levels ofdetail for workproducts in mind

Different workproducts can beused for the same purpose

22.06.2015 5

The Confusion of Tonguesby Gustave Doré (1865) [Wikipedia]

1) SEMSO = Software Engineering in a Multisourcing Organization

No commonlanguage for thediscussion of a way of working!

No commonlanguage for thediscussion of a way of working!

Elaboration

Inception

Transition

Construction

$$$$

Opportunity Requirements System TeamWork Way of Working

Solution Needed

Benefit Accrued

Identified

Bounded

Addressed

Demonstrable

Retired

Seeded

Adjourned

Initiated

Concluded

Prepared

Closed

Principles Established

RetiredOperational

Stakeholders

Represented

Satisfied in Use

Recognized

ValueEstablished

Conceived

Formed

Foundation Established

Started

Involved

Fulfilled

Approach Selected

Usable

Addressed Fulfilled Ready (Concluded) Working WellPerformingSatisfied for Deployment

UsableIn Agreement Viable

Coherent

UnderControl

Performing Working Well

In Use

Ready

Collaborating In Place

Standard

Acceptable

ESSENCE’s Benefit 1: Definition of LifecyclesA standard lifecycle

Successful utilization of ESSENCE at Munich Re – Burkhard Perkens-Golomb 22.06.2015 6

ESSENCE’s Benefit 1: Definition of LifecyclesA standard lifecycle

Elaboration

Inception

Transition

Construction

$$$$

Opportunity Requirements System TeamWork Way of Working

Solution Needed

Benefit Accrued

Identified

Bounded

Addressed

Demonstrable

Seeded

Adjourned

Initiated

Concluded

Prepared

Closed


RetiredOperational

Stakeholders

Represented

Satisfied in Use

Recognized

ValueEstablished

Conceived

Formed


Started

Involved

Fulfilled

Approach Selected

Usable

Addressed Fulfilled Ready (Concluded) Working WellPerformingSatisfied for Deployment

UsableIn Agreement Viable

Coherent

UnderControl

Performing Working Well

In Use

Ready

Collaborating In Place

Standard

Acceptable

ESSENCE’s Benefit 1: Definition of Lifecycles Variants of lifecycles


Exploratory Standard

Small Enhancements Support

ESSENCE’s Benefit 1: Definition of LifecyclesEnhancements for mandatory processes


ESSENCE’s Benefit 1: Definition of LifecyclesEnhancements for optional topics


ESSENCE’s Benefit 2: Giving more specific guidance with practices (activities, work products, etc.)


ESSENCE’s Benefit 3: Defining company-specific practices


ESSENCE’s Benefit 4: Combining practices to build a Way-of-Working


ESSENCE’s Benefit 5: Linking the way of working to the organization


Who‘s using all the stuff? Well …


Introducing ESSENCE has challenges

22.06.2015 16

1. Lack of self-improving culture

2. In some areas very basic software engineering issues revealed

3. „We’re too busy to improve“

4. No external driver for a more rigid approach

„I looked at the SEMAT website –I don‘t get the idea.“

„All methodology stuff is boring!“

„Not relevant for me – it’s too sophisticated“

„ ESSENCE makes projects look mechanical – but projects aren’t.“

„As an occasional user, using the toolsis hard.“

Adoptioner: Intrinsic/Extrinsic Motivation

Product: Relevance & Attractiveness


Who‘s using all the stuff? Well …

22.06.2015 17

1. Lack of self-improving culture

2. In some areas very basic software engineering issues revealed

3. „We’re too busy to improve“

4. No external driver for a more rigid approach

„I looked at the SEMAT website –I don‘t get it.“

„All methodology stuff is boring!“

„Not relevant for me – that’s too sophisticated“

„ESSENCE makes projects look mechanical – but projects aren’t.“

„As an occasional user, using the toolsis hard.“

Adoptioner: Intrinsic/Extrinsic Motivation

Product: Relevance & Attractiveness

Sales Big Picture?

People in the Big

Picture?

„ESSENCE from the

trenches“?

Stuff must be visuallypleasing!

HIGH usability of

tools


Thank You for Your Attention.

Do You have any Questions ?

Transition

Construction

Elaboration

Inception

PreparationThe aim of this phase is to identify the business need for the project, and secure funding to start it. For complex, risky, or novel projects, more detailed work may be need to be done for funding to be obtained.

A short phase (usually only one quick iteration) to get the delivery team up and running, and the initial plans in place. Ideally a proof-of-concept is produced to show understanding of the problem and technology.

The purpose of this phase is to address the technical risks facing the project and produce a baseline plan with committed dates and costs. To do this the project risks must be brought down to an acceptable level by increasing the understanding of the requirements and proving the architecture by implementing critical parts of the system. This may take many iterations.

The longest phase of the project where the system is built iteratively and incrementally, addressing the customer's requirements in whatever order the customer requires. A usable, production quality system is maintained at all times.

During this phase the system is accepted by the customer and goes live. Information critical to the running and maintenance of the system is handed over. Historical data and lessons learned are recorded to improve future projects.

Way of Working


In Use

In Place

(Working Well)

Customer Solution

Software System

Demonstrable

Ready

Operational

(Usable)

Architecture Selected

Work

Endeavor

Team

$$$$

Opportunity

Solution Needed

Viable

Addressed

(Benefit Accrued)

Value Established

Identified

Estimated

Confirmed

Closed

Approved

Sized

Funding Requirements

Acceptable

Addressed

Fulfilled

Bounded

Conceived

Usable

(Coherent) Seeded

(Collaborating)

Formed

(Adjourned)

(Performing)

Started

Concluded

Prepared

Closed

Under Control


MR Essentials:Standard Application Development Lifecycle – v 2.0

Fulfilled

Munich RE Essentials

Mandatory State

(Recommended State)

Legend:

Represented

Satisfiedfor Deployment

(Satisfied in Use)

Involved

Recognized

Stakeholders

Initiated

(Retired)

In Agreement

(Concluded)

Coherent

(Ready)

Version 2.0 – 28th Sep. 2014

(Investment Approval: authorizes any additional spend needed to complete the project)(Cost Sheet: reflects any revised estimates)

Investment Approval: provides approval to execute authorizing the spend for Construction and TransitionCost Sheet: replaces the need for budget with new estimate to complete

(Investment Approval: authorizes any additional spend needed to complete Elaboration)

Planning Baseline Executing Closing

OpportunityValue Established

OpportunityViable

OpportunityAddressed

OpportunityAddressed (Benefit Accrued)

Funding ApprovedFunding Confirmed Funding Confirmed

FundingClosed

Inception Elaboration Construction Transition

TeamFormed

TeamFormed (Performing)

TeamFormed (Performing

TeamFormed (Adjourned)

WorkUnder Control

last Elaboration Closed1st Construction Objectives AgreedIteration {1..n}

technical risks Addressedtop 10 AssessedRisk {n}

Schedule: timeline and dates updated to reflect actual progress and revised estimates

WorkUnder Control (Concluded)

last Construction Closed1st Transition Objectives AgreedIteration {1..n}

logistical risks Addressedtop 10 AssessedRisk {n}

Schedule: timeline and dates updated to reflect actual progress and revised estimates

WorkClosed

last Acceptance ClosedIteration {1..n}

customer acceptance risks Addressedremaining risks AssessedRisk {n}

Schedule: shows the history of the project

WorkStarted

last Inception Closed1st Elaboration Objectives AgreedIteration {1..n}

business risks Addressedtop 10 AssessedRisk {n}

Schedule: defines internal and customer-facing milestones, and outlines the phases and iterations

RequirementsFulfilled

Use-Case Model: complete for release

Supporting Information: complete for release

RequirementsFulfilled

(Use-Case Model: kept up to date)

(Supporting Information: kept up to date)

Software SystemArchitecture Selected

(critical componentsResponsibilities Assigned)Component {1..n}

(to prove the architecture Specifiedto test the proof of concept Evaluated)Test {1..n}

(for reused components Identified)Bug {n}

Design Model: clarifies the critical components to be developed / changed

(Use-Case Realization: to describe critical collaborations)

(Build: for a prototype or proof-of-concept)

Candidate Solution IdentifiedArchitecture

Software SystemDemonstrable (Usable)

key components’ critical operations VerifiedComponent {1..n}

those that prove the architecture EvaluatedTest {1..n}

all open defects Assessedthose compromising the architecture ClosedBug {n}

Design Model: describes “skinny” system

Use-Case Realization: describes the impact of the architecturally significant use-case slices

Build {n}: for the architectural spikes

EstablishedArchitecture

all affected by change Evaluatedthose for 3rd-part integration and acceptance Evaluated

Test {1..n}

This is the default lifecycle for projects in Application Development at Munich RE.

Project Com

mitm

ent Established / (Proof of Concept D

emonstrated)

Com

mitm

ent Confirm

ed / Solution Approach Proven

Business R

eady / Com

plete Useable Solution A

vailable

Solution Delivered / Solution In U

se

Business C

omm

itment Established / Solution C

onstraints Understood

A short phase (usually only one quick iteration) to getthe delivery team up and running, and the initial plansin place. Ideally a proof-of-concept is produced to showunderstanding of the problem and technology.

The longest phase of the project where the system isbuilt iteratively and incrementally, addressing thecustomer's requirements in whatever order thecustomer requires. A usable, production quality systemis maintained at all times.

During this phase the system is accepted by thecustomer and goes live. Information critical to therunning and maintenance of the system is handed over.Historical data and lessons learned are recorded toimprove future projects.

RequirementsBounded (Coherent)

Use-Case Model: shows the extent and value of the new system

Supporting Information: supports the use-case model in describing the system

RequirementsAcceptable

Use-Case Model: reflects the agreed scopeSupporting Information: reflects the agreed scope defining all terms used in the use cases

Backlog: demonstrates the release's scope (Backlog: kept up to date)Backlog: set up and bounded Backlog: tracks and prioritizes the release contents

Feature List: scopes the release Feature List: prioritizes the release's content Feature List: complete for release Feature List: complete for release

scope-related possibly Requested Change {n}all Assessed

those accepted Verified Change {n}all Assessed

those accepted Specified Change {n}all Assessed

those accepted VerifiedChange {n}

Project Evaluation Report: captures the achievements of the project, customer sign-off, historical data, and final costs

Human Resource Plan: identifies the roles and individuals Human Resource Plan: describes the team structure for the construction phase

Way of WorkingIn Use

Way of WorkingIn Place (Working Well)

Way of WorkingIn Place (Working Well)

Way of WorkingIn Place (Retired)

Project Management Plan: describes the recommended approach Project Management Plan: describes the approach to be used for Construction Project Management Plan: tuned to reflect lessons learned Project Management Plan: documents a successful approach

Human Resource Plan: describes the team structure for the transition phase (Human Resource Plan: shows the recent team structure)

Project Status Report {n}: updated to include all known technical risks Project Status Report {n}: provides snapshot of project health Project Status Report {n}: provides snapshot of project healthScope Statement: states agreed scope of the project

The purpose of this phase is to address the technicalrisks facing the project and produce a baseline plan withcommitted dates and costs. To do this the project risksmust be brought down to an acceptable level byincreasing the understanding of the requirements andproving the architecture by implementing critical parts ofthe system. This may take many iterations.

The aim of this phase is to identify the business needfor the project, and secure funding to start it. Forcomplex, risky, or novel projects, more detailed workmay be need to be done for funding to be obtained.

Application Development Lifecycle – v2.0

Software SystemReady

all VerifiedComponent {1..n}

all (incl. regression, integration and system tests) EvaluatedTest {1..n}

those compromising the release Closedall others AssessedBug {n}

Design Model: describes the entire system

Use-Case Realization: describe the impact of all in scope use cases

Build: for the complete solution

ValidatedArchitecture

Software SystemOperational

all ReleasedComponent {1..n}

those compromising the release Closedall others AssessedBug {n}

(Design Model: kept up tp date)

Use-Case Realization: describe the impact of all in scope use cases

(Build: kept up to date)

ValidatedArchitecture

PreparationEntry Criteria & Essential Inputs

Team

There is agreement of what the team is to achieve, andwhat structure would be suitable for that goal.

Human Resource Plan: outlines the desired team structure for the planning baseline phase (Inception and Elaboration)

Seeded

WorkInitiated

Project Charter: defines the desired outcomes

There is a shared understanding of the projectpurpose, and some of the key challenges facing it.

(Risk Register: initial project risks identified)

Software System

A candidate architecture has been selected from theinitial understanding of the requirements. Thisarchitecture will be tested and evolved through thewhole lifecycle.

Architecture Selected

(Design Model: identifies critical components to be developed / changed)

Candidate Solution IdentifiedArchitecture

Use-Case Slice {1..n} the most important Scoped

Use Case {1..n}Story Structure Understood

Use-Case Slice {1..n}architecturally significant Verified

all others Scoped

Use Case {1..n}architecturally significant Simplest Story Fulfilled

Use-Case Slice {1..n}all included in release Verified

Use Case {1..n}Sufficient Stories Fulfilled (All Stories Fulfilled)

Use-Case Slice {1..n}all included in release Verified

Use Case {1..n}Sufficient Stories Fulfilled (All Stories Fulfilled)

Investment Approval: authorizes the spend for the planning baseline phase (Inception and Elaboration)

Supporting Information: identifies architectural drivers and captures key concepts

The stakeholders have a common understanding ofthe scope of the proposed solution and its value to thebusiness.

RequirementsBounded (Coherent)

FundingApproved

The expected total cost of the project has beenestimated, and funding has been approved for theimplementation project.

Need for Budget: states the expected cost of the project

OpportunityValue Established

The value of addressing the opportunity has beenquantified either in absolute terms or in returns orsavings per time period (e.g. per annum).

Feature List: captures the capabilities, services or qualities that the customers most desire from this release of the systemUse-Case Model: shows the extent and value of the new system

Use Case {1..n} (important use cases Story Structure Understood) all others Goal Established

Statement of Feasibility: shows that the project is feasible from a resource and portfolio point of view

(Use-Case Narrative: outlines the most important use cases)

(Investment Approval: authorizes any additional spend needed to complete the project)(Cost Sheet: reflects any revised estimates)

Use-Case Narrative: describe the most important use cases Use-Case Narrative: describes architecturally significant use cases Use-Case Narrative: describe all in scope use cases Use-Case Narrative: describe all in scope use cases

(Test Case {n}: to verify the most important slices) Test Case {n}: prove the architectural aspects of the system Test Case {n}: prove the system meets the requirements Test Case {n}: prove the system meets the requirements

(Test Strategy: scopes the extent of testing)

(Test Strategy: scopes the extent of testing) (Test Strategy: describes the testing approach for the architectural aspects of the system) (Test Strategy: describes the testing approach for the complete solution) (Test Strategy: describes the testing approach for hotfixes and further

small enhancements during maintenance)

StakeholdersInvovlved

The stakeholders representatives are actively involvedin the work and fulfilling their responsibilities.

StakeholdersInvovlved

StakeholdersIn Agreement

StakeholdersSatisfied for Deployment

StakeholdersSatisfied for Deployment (Satisfied in Use)

Version 2.0 – 28th Sep. 2014

successful utilization of essence at munich re€¦ · introducing essence has challenges...

Documents