organizational change management incremental growth … · organizational change management &...

Renewing, Rebuilding, Reinvesting

Organizational Change Management&

Incremental Growth of System Engineering

Presented by:

Dale A. Brown M.Eng. P.Eng.

Director of Systems Engineering

June 24, 2015 – Salt Lake City, Utah

2015 Rail Conference

Renewing, Rebuilding, Reinvesting 2

MARTA at a glance

• MARTA was established in 1971

• 48 miles of track – 4 lines (2 N-S, 2 E-W)

• 38 stations

• 9th largest transit system in the US

• more than 4,500 employees

• average of more than 550,000 passengers a day

• Five Points Station sees 57,000 riders per day

• 350 modern electrically powered rail cars

• operating at speeds of up to 70mph

• more than 700 buses on 125 routes

• 120 buses that operate on CNG

• 75% of MARTA busses have wheelchair lifts


Today's Discussion

1. The Silo Effect vs. Systems Thinking

2. Organizational Change

3. MARTA’s Roadmap

3


Organizations grow from disciplines….

4

Quality AssuranceISO 9001

ASQ

DesignEngineering

CoreDisciplines

Project ManagementPMBoK

PMI

Asset ManagementISO 55001

MAP21

Legal / Financial Governance

SoX RulesDOT 49 CFR

Systems EngineeringISO 15288ISO 29110

INCOSE


Organizational Communication• MARTA evolved along lines of classical disciplines

• Over the years habits can generate “tunnel vision”

• This evolves into Silos and eventually Fiefdoms

• Result is “over the wall”, batch communications

5

The ability to “see the “Systems View” is not innate.

Many engineers do not evolve in their career this way.(e.g., many years doing electrical, software, mechanical, civil, etc.)


Our Biggest Challenge:The Resulting Silos

6

PurchasingContracts

Legal

ProjectManagement

(or CM)

EngineeringDrafting (CAD)

InformationTechnology

Quality Assurance

ExecutiveLeadership

Transit Operations

Transit Maintenance

Security & Transit Police

Public Relations

SafetyDiscipline

Engineering

Assurance Engineering

Inter-Silo communications is challenging and in some areas and can quickly get very political .


2 Quick Examples• Transit Police desired a new system. They

were convinced by an OEM. They wanted no interference from Engineering. But they are not QUALIFIED to consider dimensions of EMI, Lifecycle Support, Interfacing Systems, RAM…

• Transit IT believed that anything with software in it is under their “jurisdiction”. But almost everything you buy has software in it now! Again, Interfaces, Real Time Control loops, RAM are not within their capabilities.

7


Establishing Communications• One link at a time to build rapport and trust

8

PurchasingContracts

Legal

ProjectManagement

(or CM)

EngineeringDrafting (CAD)

InformationTechnology

Quality Assurance

ExecutiveLeadership

Transit Operations

Transit Maintenance

Security & Transit Police

Public Relations

SafetyDiscipline

Engineering

Assurance Engineering

Systems Engineering - Communicating


A Lot of Stakeholders to consider• No single group has enough competence to generate

contract documents for an AVIS – as an example.

9

Passenger Information System:

Railway/Bus Data InputOperator InputAudio OutputVisual Output

Mobile Data Output

Audio/Acoustic Engineering

Electrical/Electronic Engineering

Software/Network Engineering

Human Factors Engineering

Mechanical Engineering

Materials Engineering

Civil/Architectural Engineering

Environmental Engineering

Lifecycle Support Engineering

Reliability/Availability/Maintainability

Engineering

Safety Engineering

Security Engineering & Police

Operators, Dispatchers, Schedulers, Planners

Board of DirectorsExecutive Leadership

Finance, LegalTransit Patrons

Procurement

Quality Assurance

Drivers, Platform & Station Agents

Maintainers

FTA/DOT OSHA/DOLRegulatory Agencies


Cross-Functional Review & Sign-Off

• Systems Thinking demands review and sign off of Operations Concepts, Requirements, Interfaces, Architecture, etc. by all relevant stakeholders at various stage gates in the process - effectively adding more time & cost to a project!

….but who will pay for all this new activity?

10


Actual “Day in the Life” Studies

ENGINEER - CURRENT Week

Design Work 22.5

Review of Work Products 2.5

Meetings - All 10

Other (Admin, PD, V&V, social) 7.5

TOTAL 42.5

ENGINEER - SAFETY CULTURE Week

Design Work 5

Review of Work Products 17.5

Meetings - All 12.5

Other (Admin, PD, V&V, social) 7.5

TOTAL 42.5

Implementing new Peer Review Process to support a safety case.

In the example above, an electrical design engineer was

shifting from spending a few hours per week reviewing work

to nearly half their week reviewing the work of others.

Multiplied across 20 or more disciplines, this is a huge

organizational change and needs to be considered carefully!!


Workflow and daily practices will change

12

• How do you create a document?

• Where do you store a document?

• How do you review and approve a document?

• How is a drawing or document “Published”?

• Is this a valid requirement – who must approve?

• Who is in charge of a particular interface?

• How do you gather evidence of “competent review by practitioners of the art”?

• Who oversees all of this – makes sure it happens?


Motivation for increased Participation

• But where is the motivation for this? Who will pay for the peer review process and how do you enforce diligent participation by competent persons?

• The “Spend now to Save later” mentality is a difficult one to convince an agency to take on.

13


Organizational Change Management

14

“Change is the law of life. And those

who look only to the past or present

are certain to miss the future.” (John

F. Kennedy - Frankfurt 1963)

“Life is Flux” (Panta Rhei in Greek),

meaning “all things change “.

“the only constant IS change”

(Heraclitus of Ephesos c. 500 BCE)


Understanding Organizational Behavior

• Like people, organizations can become addicted to certain behaviors. It takes about 21 repetitions to form a human habit.

• At some point, people are repetitively going through the motions of their comfortable behavior – it becomes unconscious activity and results in stubbornness and complacency.

15


Not in our Nature

16

• Creative people, such as engineers, do not truly like discipline – it runs counter to innovative thinking and problem solving.

• Engineers, however, understand the benefits of discipline and can be convinced that sensible process is their ally and does not just represent some arbitrary bureaucracy.


Motivation & Reality

17

• People respond to their reward structure and related patterns – not posters.

• A PM is NOT rewarded for good ergonomic design or FTA Compliance - they are mainly rewarded for cost & schedule performance


MARTA Operational Change Management Approach

• Shown success with a few projects by including additional stakeholders (not all yet)

• Generated better requirements as a result and the projects conclude with ever-increasing levels of success (time, function, budget).

• Initial simple incentive is providing a charge code for time and gaining permission from managers

• Next step is to get this institutionalized across the wider stakeholder group……

18


Needed: Discipline & Accountability

• To generate motivation you must design the reward structures using a combination of enabling processes

• Then implement Engineering QA to provide feedback and consequences


Ignore Organizational Change considerations at your peril…

“It is not necessary to change; survival is not mandatory.”(W. Edwards Deming)


The Roadmap for SE at MARTA

Involve a few stakeholders – show

improvement with better requirements

Improve Enabling Processes such as Doc Control, CM, Change

Control, Peer Review –BUILD A FOUNDATION

Introduce more SE technical processes and

measure engineering process performance –

Engineering QA


Phase1 - Foundations Phase 2 – Requirements Management Phase 3 - Systems Integration Phase 4 – Lifecycle Support and AM

Change Control

Document Control

P01

3Q 2015

System Architecture & Modelling

P02 P03 P04

4Q 2015 1Q 2016 2Q 2016

NTP

2Q 2015

Requirements Structure

Core MARTA N.F. Requirements

Lifecycle Model

Foundation for FTA & GDOT Audits – gain control of MARTA configurations – mitigating risk

Prepare MARTA for Re-use and Standardization – eliminate

excessive RFP “hand-crafting” - reduce engineering costs

RationaleRationale

P05

4Q 2016

Peer ReviewControl

Risk Management

Decision Management

Engineering Quality Assurance

Interface Control

Transition Control

Build MARTA Interface Control system – Standardize Approach

– define Transition processes from CIP to MOW(example) -

preparation for V&V

Rationale

Infrastructure (tools) to aid

processes

……..

Human Factors

Safety

Reliability Availability

Security

Environmental

Organization Change

Ongoing V&V Maturity Ongoing V&V Maturity

Ongoing Training, Training Aids and Template Development Efforts

Roadmap Details


Audit MARTA Processes against 15288

PROJECT PROCESS CLASS

Project Planning

Decision Management

Configuration Management

ProjectMeasurement

Risk Management

Project Assessment

& Control

Information Management

TECHNICAL PROCESS CLASS

RequirementsDefinition

RequirementsAnalysis

Architectural Design

Implementation Integration Verification

Transition

Disposal

Validation Operation

Maintenance

PROJECT ENABLING (Organizational Management) PROCESS CLASS

ProjectPortfolio

InfrastructureLifecycle

Model

Human Resource

Quality

AGREEMENT PROCESS CLASS

Acquisition Supply

PARTIAL

OPERATING

NONEOBSERVED

Documented Process

Ad-Hoc Process or Partial Compliance

Process Missing

ISO / IEC 15288 Processes


Process Context

INPUTS PROCESS ACTIVITES

CONTROLS &

CONSTRAINTS

ENABLERS

OUTPUTS

Tendency is to gloss over the enablers – assume that they are there!


Enabling Requirements Management

Enabling Processes & Infrastructure


Requirements Management



RequirementsValidation

RequirementsElicitation

DocumentControl

Change Control

PeerReview

Engineering QA

Stakeholder NeedsAgency GoalsRequlations

Validated, Controlled

Requirements

RM Plan & Tool

DecisionManagement

Agency Policies and Regulations

Project Constraints

Risk Management

RequirementsTraning


Small bites of the elephant…

PROJECT PROCESS CLASS

Project Planning

Decision Management


ProjectMeasurement

Risk Management

Project Assessment

& Control

Information Management

TECHNICAL PROCESS CLASS



Architectural Design

Implementation Integration Verification

Transition

Disposal

Validation Operation

Maintenance

PROJECT ENABLING (Organizational Management) PROCESS CLASS

ProjectPortfolio

InfrastructureLifecycle

Model

Human Resource

Quality

AGREEMENT PROCESS CLASS

Acquisition Supply

MARTAINITIAL

PRIORITIES

ISO / IEC 15288 Processes


Why did MARTA choose these first?

1. Maintain the momentum of requirements elicitation started in earlier projects – but now build on this and improve the enabling processes

2. You will not succeed in requirements management if you do not have a validated peer review process.

3. You can’t perform Peer reviews without understanding & controlling the current baseline of your requirements

4. A change control system is necessary to agree changes after/during the peer review

5. Document control is necessary to avoid data-loss and ad-hoc access

6. Engineering QA is allows you to measure/improve/control the effectiveness of your process changes (DMAIC)

27


The Biggest Anticipated Impact….• Peer Review, combined with a Stage-Gated

project process is a silo killer!

Mobilization & Setup

Project Planning

M1

Concept Design

M2NTP

Preliminary Design

M3

Interim Design

M4

Final Design

M5 M6

Configuration Management Plan

Quality Assurance Plan

System Design Description

Document Tree

CDR Gate Review Report

Software Architecture Document

CDRL DESCRIPTION FIRST GATE STATUS at GATE LAST GATE CDRL ID OWNER ETC Current Remaining

(Milestone ID) (Milestone ID) (Milestone ID) (Doc ID)(Discipline

Lead)(hrs) (%) (hrs)CDR

M19


Some Next Steps…..• 3 Primary Repositories (Creating reuse)

– Process Library

– Design Standards

– Project Deliverables (subdivided into folders for each project)

Process Library

Design Standards

Project Specific

Deliverables

Project RequirementsSpecification

TemplatesProcesses

Procedures

Performance, ConstraintsMARTA Specific

Functionality

Project RFPFull Specification

Generates

REUSE


Thank You!

30

2012 Chaos Report: only 39% of 50,000 sampled projects succeeded.(delivered on time, on budget, with required features and functions)

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

% Locked-in Costs

% L

ifecy

cle

Co

sts

95% Locked-In

Operation/Support

Production

Design/Development

Concept/Feasibility

Product Life Cycle Costs

35%

50%

12%

3%

95% of total product life cycle costs is controlled by early engineering efforts!

organizational change management incremental growth … · organizational change management &...

Documents