William P. Hall, PhD

President Kororoit Institute Proponents and Supporters Assoc., Inc. - http://kororoit.org Associate EA Principals – http://eaprincipals.com william-hall@bigpond.com http://www.orgs-evolution-knowledge.net

Supporting business decisions in the technological enterprise

Access my research papers from Google Citations

Presentation for

MGMT20005 Business Decision Analysis

4/30/2014

Attribution CC BY

Overview

A bit of theory – Organizations are complex living systems

– Understanding organizational imperatives

– Herbert Simon and the limits to rationality

Some practical experiences – Tenix Defence – once a $ bn defence engineering project

management company now extinct

– Organizational imperative: successfully complete a $7 bn contract to build 10 warships for two national navies

– Contract analysis

– Operational Availability Assessment

– Feeding a relational database with documents written by fallible humans

– Why did the company fail

2

My background

Physics / evolutionary biology (PhD Harvard, 1973)

1981-1989: tech communicator/doc manager (computer literacy, software development, banking)

1990-2007: documentation and KM systems analyst/designer for Tenix Defence/$ 7 BN ANZAC Ship Project

2001: research focus on knowledge-based organizations

2011: TOGAF9 Certified Enterprise Architect

Currently finishing a book project, Application Holy Wars or a New Reformation - A fugue on the theory of knowledge

– Co-evolution & revolutions in human cognition and cognitive tools

– Theory of knowledge-based living systems (cells, organisms, organizations)

– How did savanna apes become human and conquer the world

– What’s next? Humano-technical cyborgs

Sociotechnical enterprises 3

A Peek at some theory

• Vines, R., Hall, W.P. 2011. Exploring the foundations of organizational knowledge. Kororoit Institute Working Papers No. 3: 1-39.

• Hall, W.P., Else, S., Martin, C., Philp, W. 2011. Time-based frameworks for valuing knowledge: maintaining strategic knowledge. Kororoit Institute Working Papers No. 1: 1-28.

• Hall, W.P. 2011. Physical basis for the emergence of autopoiesis, cognition and knowledge. Kororoit Institute Working Papers No. 2: 1-63.

What is an enterprise?

A coherently definable organized entity that may be: – Public or private sector organizations – Coherent military tactical unit – Ship and its crew

Exhibits some or all characteristics of hierarchical complexity, reactivity, adaptability, emergence, downward and upward causation, self-organization, non-linear / chaotic responses

An organized, notionally bounded socio-technical system, addressing its internal / external imperatives for success / survival (i.e., an “organic” entity), comprised of

– People (participants in the organization from time to time) – Processes (automated, documented, tacit routines, etc.) – Infrastructure (ICT, physical plant, etc.) – Defined by organizational knowledge (i.e., contributing to org.

structure/success) Members’ personal knowledge relating to their roles Knowledge as a deliverable product (e.g., technical documentation) Knowledge about and embodied in deliverable products Knowledge about and embodied in organizational processes

and infrastructure

Organizational knowledge

Leave one of the legs off, and the stool will fall over

Enterprises are living,complex systems of systems

Systems address the enterprise’s imperatives – Systems are comprised of interacting processes supported by applications and

infrastructure and involve people as well as technology – Knowledge determines how systems work

Enterprise architecture is a set of frameworks and methodologies for analyzing, understanding, and improving the systems structure

Working with living organizations

Imperatives: Living things have requisite inputs they must satisfy to avoid disintegration – Living people work together to make living

organizations

– Living organization containing living components must satisfy their components’ imperatives for life

Possibilities: Capabilities inherent in the organization

Constraints: The environment constrains possible actions, both positively and negatively

Enterprise management considerations

Focus on the situation of the enterprise – External situation

Dynamic environment – position relative to competitors – changing internal and environmental factors

Strategic context: challenges & advantages (how to protect and extend control over requisites for existence)

– Internal situation Organizational structure (functional subdivisions, etc.) Purpose, vision, values, mission People profile Systems & their capabilities Organizational assets (tangible, intangible) Product/service offerings Stakeholders (internal/external) Performance management/improvement system capabilities

– External must enable internal / Internal must satisfy external

Enterprise management considerations

Focus on making and supporting decisions – Provide the environment for effective decisions

Recognize the bounds of rationality: Manage delegation – provide adequate time (no decision is worse than a bad decision!)

– make important knowledge reliable and readily retrievable

– establish responsibility and authority

Provide & manage appropriate organizational resources and technologies to support decisions

– tacit and implicit personal knowledge

– valid and effective documentation and appropriate data

– effective training and decision procedures

– Audit and manage organizational performance (i.e., maintain effective feedback for continuous improvement) Measure

Analyze & review

Improve

Bounded rationality and limits to organisation: Herbert Simon and Steve Else

Steven Else (2004) Organization Theory and the Transformation of Large, Complex Organizations -- Donald H. Rumsfeld and the U.S. Department of Defense, 2001-04, PhD Thesis, Denver University

– people are limited - 'bounded rationality' (H. Simon 1955, 1957)

– best decision the organisation can strive for is 'just good enough', or 'satisficing' rather than optimising ; (K. Arrow 1974)

– Do your best and go on to the next (Amway sales training)

Some conclusions – Over centralization of decision making is a recipe for disaster

bounded rationality puts upper limit on observation

overloaded central decision maker loses touch with reality

– Orgs must delegate decisions to close to interfaces between problems and actions on those problems Need to balance between ability to observe and ability to make effective

decisions

The management style and management of knowledge both must change as the organisation grows in order to maintain balance

Putting theory into practice

Understanding how to manage organizational

knowledge flows naturally from the biological point of view

17 years in production

In service for 27 years

Integrated Logistic Support

Warranty

– 12 months for each ship

– 2 year latent defects period

10 ship years of Operational Availability Assessment Period – Ship to be available 80% of time

– Critical systems available 90% of time

– Develop system to prove to the Client that thresholds have been met

Deliver capabilities not hardware

8 ships RAN ( + 2 for RNZN)

2 Shore facilities (+1 for RNZN)

Design & systems integration

80% Australian & New Zealand Industry Participation

Fixed price/schedule contract!

Support engineering – Full fitouts & supply chain spares

– Crew training

– Operations manuals

– 2000+ maintenance procedures/ship

– Readable by relational database system!

The 17 year ANZAC Ship Project Contract

To survive enterprises must address imperatives in their contexts

Enterprises are living entities – Require cash flow & staff replacement

– Failure to satisfy imperatives leads to disintegration

No enterprise exists in isolation from its contexts – What are its imperatives for continued existence?

– Organizational systems satisfying imperatives must track continually changing contexts with observations, decisions and actions

Tenix’s primary imperatives – Win contract(s)

– Deliver on contract(s)

– Satisfy customer(s)

– Comply with regulatory requirements

– Perform profitably 13

14

ANZAC Ship Project What does an imperative look like?

10 ships must be accepted $A 7 Bn project value

Non acceptance = non-payment, project delay, liquidated damages + reputational damage

Make a profit - Satisfy customers

Case 1

Engineering a knowledge capture and transfer system

to support ships

• Hall, W.P. 2001. Writing and managing maintenance procedures for a class of warships: A case for structured authoring and content management. May 2001 issue of Technical Communication, the professional journal of the Society for Technical Communication.

• Hall, W.P., Richards, G., Sarelius, C., Kilpatrick, B. 2008. Organisational management of project and technical knowledge over fleet lifecycles. Australian Journal of Mechanical Engineering. 5(2):81-95.

Support engineering and operating knowledge

Contractual responsibility to provide training and documentation package as well as ships (i.e., a complete knowledge base) – Training facilities and simulators

– Crew training materials

– Complete operating manuals (captain and crew)

– Maintenance philosophy

– Maintenance procedures and documentation

Original concept – paper manuals

Cost neutral contract amendment – Feed everything into computerized maintenance

management system 16

Imperatives for delivering knowledge or using it in an engineering/production environment

Customer end user's knowledge imperatives – Correct

Correct information Consistent across the fleet / product range

– Applicable/Effective Applicable to the configuration of the individual product Effective for the point in time re engineering changes, etc.

– Available To who needs it, when and where it is needed

– Useable Readily understandable by those needing it Readily managed & processed in computer systems

Supplier's knowledge production and usage goals – Fast – High quality – Low cost

Knowledge development lifecycle for a large project

Project A Design Study

Review, edit, signoff

Negotiate

Review, agree, amend

Project A Prime Contract

RFT and Bid

Review, edit, signoff

Project A Bid Documents

RFQs

Bids Negotiations

Project A Subcontracts

Review, agree, amend

Project A Procedures, Design Docs

Review, edit,

signoff

Project A Support Documents

• 20 - 50 year lifecycle

Project B Design Study

Review, edit, signoff

Project B Design Study

Review, edit, signoff

Project B Design Study

Review, edit, signoff

Operational experience

Negotiate

MRP / PRODUCTION MGMT • MBOM • Production planning • Production schedule • Procurement • Warehousing • Establish & release workorders HRM

Accounting

CS 2

Contract Requirements

Capability requirements Documentation requirements

PRODUCT MANAGEMENT ( structured designs )

MODELS: • Component definitions • Component hierarchies

- System - Physical structural - Availability

OBJECTS MANAGED • Drawings • Parts lists • Configurations • Component specifications

and attributes

DOCUMENT CONTENT ( structured documents )

MODELS: • Element definitions

- Content - Attributes

• Element hierarchies • Element sequences

OUTPUT OBJECTS • Contract/subcontract

documents • Procedures/instructions • Deliverable documents • All other controlled

documents

COMMON REQUIREMENTS • Config control / Change mgmt

- Develop/Author - Release - Applicability, Effectivity

• Workflow management - Configuration changes - Document changes - Other business objects

• Track and control source data

Link element to component

Manage elements

LSAR database EBOM EBOM

Catalogue

Drawings

VAULT

Requirements tracking

DOCUMENT PROD MGMT • Author • Production schedule • Check out / check in • Track and review • Deliver • Manage configuration & change

Project Schedule

The full knowledge management environment for ship support

Tenix Navy

Tenix ANZAC’s measured improvements from KM solution

Tenix’s Ship 05 delivery challenge – For safe maintenance “documents” must be understood by human

maintainers and computerized maintenance management system

– Document & engineering change management issues

– Client threat to not accept 05 if still dissatisfied

Structured authoring solution resolved the issue – Condensed 8,000 procedures for 4 ships to class-set of less than 2,000

‘structured documents’ for 10 ships Routines delivered for Ship 5 CUT 80%

Subsequent content deliveries CUT 95%

Keyboard time for one change CUT more than 50%

Change cycle time CUT from 1 year to days

$ 7 Billion 17+ year long project completed successfully – Each ship delivered on time - every time

– For the stringently fixed price – no cost overruns!

– For a healthy company profit

– Today, the customers are still happy with the ships

The company failed and disintegrated on its next largish project because it did not transfer its learning from the old project

Case 2

Operational Availability Recording and Reporting

System

• Hall, W.P. Beer, J., & McFie, K. 2002. Managing maintenance to reduce life-cycle costs for a multi-national fleet of warships. Proceedings. International Maintenance Management Conference, 29-30 August, 2002, Gold Coast, Queensland

• Hall, W.P., Beer, J. & McCauley, B. 2002. Improving the quality of fleet/facility support knowledge. Proceedings of the Australian Conference for Knowledge Management & Intelligent Decision Support, ACKMIDS 2002 Melbourne, Australia, 9-10 December 2002.

TE&V Test, Evaluation, & Validation

Contract requirements: – Each ship in service is available to meet operational requirements

80% of time and each of ~20 “critical” systems available 90% of time.

– Contractor must bear all costs within fixed price to correct any/all shortfalls & changes required to meet OA thresholds

– Contract must prove to Client that contractor provided ship design and integrated logistic support package has met these requirements over first 10 years of operational experience (“Operational Availability Recording and Reporting”) 4 years for Ship 1

3 years for Ship 2

2 years for Ship 3

1 year for Ship 4

Covers on-board, base & supply chain spares, maintenance procedures (i.e., knowledge transfers via documentation & training), initial fitout.

23

CSARS: Class Systems Analysis And Reporting Software

Tenix's TE&V role with OARRS – Data collection completed 19 Oct 00

– ILS TE&V completion Dec 01

– Passed with complete customer satisfaction

Client wanted to extend our software tool for analysing ‘actual’ system & equipment performance across entire fleet

Means of conducting: – Reliability

– Availability

– Maintainability

– Sustainability

RAMS Analysis

Measures for RAMS

Reliability = MTBF = (op hrs / failures)

Availability = Ao = uptime / (uptime + downtime)

Maintainability = MTTR = avge (TTR)

Sustainability = MLDT = avge (job time - ADT - TTR)

Where does CSARS help?

Informed Decision Making − Determine existing capability

− Prioritise tasks for maintenance

− Manage repairables and materiel support

− Determine effectiveness of support

− Prioritise systems for cost analysis

Continuous Improvement − Data collection and reporting mechanisms

− Org, Intermediate & Depot level planned maintenance

− Estimating required inventory for "surge" capacity

− Input to life-cycle costing tools

CSARS: What does it look like?

Hierarchy

Failed

threshold

Search engine

Calculation

results

Ship

Calculation

Calculation

thresholds

Hierarchy:

CSARS: What does it look like?

Calculation

results

Redundant

equipment Non-critical

equipment

Zoom

Drill-down

block

Failed

threshold

Print

Calculation

thresholds

Availability Block Diagram:

Case 3

How some businesses can work hard to be stupid

• Nousala, S., Miles, A., Kilpatrick, B., Hall, W.P. 2005. Building knowledge sharing communities using team expertise access maps (TEAM). Proceedings, KMAP05 Knowledge Management in Asia Pacific Wellington, N.Z. 28-29 November 2005.

• Hall, W.P., Nousala, S., Kilpatrick B. 2009. One company – two outcomes: knowledge integration vs corporate disintegration in the absence of knowledge management. VINE: The journal of information and knowledge management systems 39(3), 242-258.

Why is knowledge important to the enterprise?

Tech enterprises and products are knowledge intensive

– to design – to manufacture – to operate

Processes and products are fallible! Organisations are complex dynamic systems

– Difference between complex and complicated Organisations have minds of their own (my research area) Cannot be predicted, can only be constrained

– Depend on "system of systems" to manage knowledge – System of systems components include

People Processes Infrastructure technology Structure embodies knowledge

KM systems in the high-tech enterprise

People Process

Technology infrastructure

Organizational knowledge

Leave one of the legs off, and the stool will fall over

Limits to knowledge and organisation

Rationality in making decisions (key part of OODA loop) “A decision making effort that exhausts all potentially relevant [knowledge] in order to make decisions in a transparently logical and objective fashion.” (Else 2004)

Organisations and people have limited capability (subsystem laws) – Bounded rationality (Simon 1957). Models of Man

Limits on decision making caused by limits on costs, human abilities, time, technology, and availability of [knowledge].

Boundaryless Careers - Arthur & Rousseau (1996) – People belonging to organisations are not owned by them

– People have careers outside of any one organisation

Limits of Organisation - Arrow (1974 - see Else 2004) – As limited by bounded rationality of individual people

– As limited by organisational structure, governance, etc

Tenix: an engineering project management org

Successfully completed $ 7 BN technologically complex and knowledge intense ANZAC shipbuilding project

– 10 similar (but not identical!) ships for two customers – Fixed price contract negotiated 17½ years previously – Managed ~20 subcontracts worth more than $100 M ea – Finished

On time On budget (with escalation clauses to cover currency fluctuations, labor rates, raw

materials) Happy customers

– Profitable “cash-cow” allowed company to acquire several new divisions

Tenix: Project Protector (RNZN)

$ 500 M fixed price project following ANZAC Ship Project – Seven ships constituting three different types for one customer – Build to “commercial” standards – Three year project – took many months to ramp up – Complete budget blow-out – First ship delivered 6 months late, others farther behind schedule

Company owners auctioned company at “fire sale” price – Multi-billion dollar order book – Pre auction estimate was that company was worth $A 1 BN – Sold in January 2008 for ~$A 775 M – Cost to owners thus on the order of $A 225 M!

1 transport 2 offshore PVs 4 inshore PVs

Background

Company/management characteristics – Family owned – Distributed work sites – “Absentee” senior executives (different state from where work done) – Deep line-management hierarchy – Command and control philosophy – don’t disagree with boss always knows best – Execs & line managers didn’t understand IT (i.e., pencil & paper people) – Senior managers sacked for errors & “mistakes” with high turn-over (2-3 yr) – Retrospective bonuses (Tenix value added)

Aspects of successful project – Stable, conscientious work force – many with 10 and 20 year pins – Long duration, with significant serial production facilitated org learning – Costly problems in design and early production stages

Difficulties/delay getting IP and technical data for engineering and support

Engineering configuration management and change control

Difficulties delivering coherent technical data and documentation to client

– Cost-effective solutions found and built into processes and practices, but… Executives did not direct and were probably unaware of solutions

Solutions requiring investment often suffered inordinate approval delays

Some critical solutions funded by subterfuge from current operating budgets

– Solutions + effective IT significantly reduced costs.

Background – cont.

Finishing the ANZAC Ship Project – Owners hired overseas “close-out” specialist as divisional EGM

His bonus based on added profit squeezed from old project Line managers only knew smooth running serial production Implemented strict time-costing to the half hour All time required to be allocated to project line item cost code Costly staff quickly made redundant when no longer needed for project EGM approval required for “outsiders” to meet project staff Morale became very poor

Follow-on project – 3 year fixed-price project – Assumed to be “commercial” work – Limited opportunities for serial production – Costing assumed existing efficiencies would transfer to Protector

with less technology & control – Started before ANZAC Project finished – New (cheaper) people were hired for Protector

Few had experience with naval or even defence projects

– A security fence was built between the projects

EPMO failed to recognize and transfer organisational knowledge

Knowledge management expertise located in “rump” head office – R&D manager, Chief Engineer, Snr Systems Engineer, KM analyst, 2 PhD

students as KM Interns – Verbal support from GM Engineering who lacked enforcement power – KM funding only for analyst salary (i.e., no budget, no travel) – Advisory only (no power to implement anything)

As the new project was being negotiated – New staff knew theory but lacked experience in naval engineering programs – KM group developed prototyped methods identify, map and transfer critical

knowledge & lessons learned by ANZAC project Prototype proved old hands would happily share experience and “war stories” Analysis and prototype validated and published as a peer reviewed paper

– Three formal attempts to implement knowledge mapping/transfer program Pre-negotiation stage – first prototype by KM analyst & Risk Manager - knocked

back by Production Manager Early negotiations – proposal additionally supported by availability of PhD student to

manage interview & mapping process & systems engineer to develop software – knocked back by line managers

Project mobilisation – proposal additionally adopted by Special Project Manager responsible for IT implementation – same result.

Line management blocked head office (KM group) access to both new hires and old hands as “time wasting”

The importance of people and culture

Example: board spent $ M to implement corporate portal – Hired outside contractor to select system – Did not consult staff to understand what was needed – Would not pay for additional modules to make it work – Would not fund support staff

To develop processes To develop taxonomies To provide more than minimal training

Fundamental issues for the technology organisation – Living knowledge is intangible and is produced and used by people – Executive’s bounded rationality

Understand some technology proposals and would pay to implement it Did not understand people, or follow value arguments about people and

culture, and will not approve what they do not understand – Finance and admin people, can identify the cost of everything but

cannot compute the value of knowledge developed by people and processes.

Managing technological enterprises is mostly about managing people and knowledge

Failing to understand manage people and organisational culture can kill people & destroy organisations.

The bottom line

Organizational processes, knowledge systems, and culture need to be organized to effectively support decisions critical to organizational survival

In the context of satisfying organizational imperatives, Enterprise Architecture provides tested methodologies for analysing organizational needs and designing appropriate processes and systems for meeting these needs

39

END