Organizational Change Management & Incremental Growth of System Engineering

Transcription

1 Organizational Change Management & Incremental Growth of System Presented by: Dale A. Brown M.Eng. P.Eng. Director of Systems June 24, 2015 Salt Lake City, Utah 2015 Rail Conference

2 MARTA at a glance MARTA was established in miles of track 4 lines (2 N-S, 2 E-W) 38 stations 9 th 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 2

3 Today's Discussion 1. The Silo Effect vs. Systems Thinking 2. Organizational Change 3. MARTA s Roadmap 3

4 Organizations grow from disciplines. Legal / Financial Governance SoX Rules DOT 49 CFR Design Core Disciplines Quality Assurance ISO 9001 ASQ Systems ISO ISO INCOSE Project Management PMBoK PMI Asset Management ISO MAP21 4

5 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 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.) 5

6 Our Biggest Challenge: The Resulting Silos Executive Leadership Purchasing Contracts Legal Project Management (or CM) Drafting (CAD) Safety Inter-Silo communications is challenging and in some areas and can quickly get very political. Discipline Quality Assurance Assurance Transit Operations Transit Maintenance Information Technology Security & Transit Police Public Relations 6

7 2 Quick Examples Transit Police desired a new system. They were convinced by an OEM. They wanted no interference from. 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

8 Establishing Communications One link at a time to build rapport and trust Executive Leadership Purchasing Contracts Legal Project Management (or CM) Drafting (CAD) Safety Discipline Systems - Communicating Quality Assurance Assurance Transit Operations Transit Maintenance Information Technology Security & Transit Police Public Relations 8

9 A Lot of Stakeholders to consider No single group has enough competence to generate contract documents for an AVIS as an example. Quality Assurance Safety Lifecycle Support Reliability/Availability/ Maintainability Materials Environmental Passenger Information System: Civil/Architectural Security & Police Procurement Mechanical Railway/Bus Data Input Operator Input Audio Output Visual Output Mobile Data Output Human Factors Maintainers FTA/DOT OSHA/DOL Regulatory Agencies Drivers, Platform & Station Agents Audio/Acoustic Transit Patrons Electrical/Electronic Software/Network Board of Directors Executive Leadership Finance, Legal Operators, Dispatchers, Schedulers, Planners 9

10 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

11 Actual Day in the Life Studies Implementing new Peer Review Process to support a safety case. 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 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!! 11

12 Workflow and daily practices will change 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? 12

13 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

14 Organizational Change Management 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) 14

15 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

16 Not in our Nature 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. 16

17 Motivation & Reality 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 17

18 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

19 Needed: Discipline & Accountability To generate motivation you must design the reward structures using a combination of enabling processes Then implement QA to provide feedback and consequences 19

20 Ignore Organizational Change considerations at your peril It is not necessary to change; survival is not mandatory. (W. Edwards Deming) 20

21 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 QA 21

22 Roadmap Details Ongoing Training, Training Aids and Template Development Efforts 2Q Q Q Q Q 2016 Ongoing V&V Maturity Ongoing V&V Maturity Phase1 - Foundations Phase 2 Requirements Management Phase 3 - Systems Integration Phase 4 Lifecycle Support and AM System Architecture & Modelling 4Q NTP P01 P02 P03 P04 P05 Document Control Requirements Structure Interface Control Change Control Lifecycle Model Transition Control Peer Review Control Core MARTA N.F. Requirements Rationale Risk Management Decision Management Quality Assurance Infrastructure (tools) to aid processes Safety Human Factors Reliability Availability Security Environmental Organization Change Build MARTA Interface Control system Standardize Approach define Transition processes from CIP to MOW(example) - preparation for V&V Rationale Foundation for FTA & GDOT Audits gain control of MARTA configurations mitigating risk Rationale Prepare MARTA for Re-use and Standardization eliminate excessive RFP hand-crafting - reduce engineering costs 22

23 Audit MARTA Processes against AGREEMENT PROCESS CLASS ISO / IEC Processes Acquisition Supply TECHNICAL PROCESS CLASS PROJECT ENABLING (Organizational Management) PROCESS CLASS Requirements Definition Requirements Analysis Architectural Design Project Portfolio Infrastructure Lifecycle Model Implementation Integration Verification Human Resource Quality Transition Validation Operation PROJECT PROCESS CLASS Maintenance Disposal Project Planning Decision Management Configuration Management Project Measurement Project Assessment & Control PARTIAL Ad-Hoc Process or Partial Compliance Risk Management Information Management OPERATING Documented Process NONE OBSERVED Process Missing 23

24 Process Context CONTROLS & CONSTRAINTS INPUTS PROCESS ACTIVITES OUTPUTS ENABLERS Tendency is to gloss over the enablers assume that they are there! 24

25 Enabling Requirements Management Agency Policies and Regulations Project Constraints Requirements Management Stakeholder Needs Agency Goals Requlations Requirements Elicitation Requirements Definition Requirements Analysis Requirements Validation Validated, Controlled Requirements Enabling Processes & Infrastructure Configuration Management Change Control Document Control Peer Review Decision Management QA RM Plan & Tool Risk Management Requirements Traning 25

26 Small bites of the elephant AGREEMENT PROCESS CLASS ISO / IEC Processes Acquisition Supply TECHNICAL PROCESS CLASS PROJECT ENABLING (Organizational Management) PROCESS CLASS Requirements Definition Requirements Analysis Architectural Design Project Portfolio Infrastructure Lifecycle Model Implementation Integration Verification Human Resource Quality Transition Validation Operation PROJECT PROCESS CLASS Maintenance Disposal Project Planning Decision Management Configuration Management Project Measurement Risk Management Project Assessment & Control Information Management MARTA INITIAL PRIORITIES 26

27 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. QA is allows you to measure/improve/control the effectiveness of your process changes (DMAIC) 27

28 The Biggest Anticipated Impact. Peer Review, combined with a Stage-Gated project process is a silo killer! Mobilization & Setup Project Planning Concept Design Preliminary Design Interim Design Final Design NTP M1 M2 M3 M4 M5 M6 M19 CDR (Milestone ID) (Milestone ID) (Milestone ID) (Doc ID) (Discipline Lead) (hrs) (%) (hrs) CDRL DESCRIPTION FIRST GATE STATUS at GATE LAST GATE CDRL ID OWNER ETC Current Remaining Configuration Management Plan Quality Assurance Plan Document Tree System Design Description Software Architecture Document CDR Gate Review Report 28

29 Some Next Steps.. 3 Primary Repositories (Creating reuse) Process Library Design Standards Project Deliverables (subdivided into folders for each project) Process Library Design Standards Templates Processes Procedures REUSE Performance, Constraints MARTA Specific Functionality Project Specific Deliverables Project Requirements Specification Project RFP Full Specification Generates 29

30 Thank You! 100% 90% 80% % Locked-in Costs 95% Locked-In % Lifecycle Costs 70% 60% 50% 40% 30% 35% Production 50% Operation/Support 20% 10% 3% Concept/Feasibility 12% Design/Development Product Life Cycle Costs 95% of total product life cycle costs is controlled by early engineering efforts! 2012 Chaos Report: only 39% of 50,000 sampled projects succeeded. (delivered on time, on budget, with required features and functions) 30