William P. Hall, PhD

PresidentKororoit Institute Proponents and Supporters Assoc., Inc. - http://kororoit.org

AssociateEA Principals – http://eaprincipals.com

william-hall@bigpond.comhttp://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

AttributionCC 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

Peop

le

Pro

cess

Infra

stru

ctu

re

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 ProjectWhat 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 ADesign Study

Review, edit, signoff

Negotiate

Review, agree, amend

Project APrime Contract

RFT and Bid

Review, edit, signoff

Project ABid Documents

RFQs

BidsNegotiations

Project ASubcontracts

Review,agree, amend

Project AProcedures,Design Docs

Review,edit,

signoff

Project ASupport Documents

•20 - 50 year lifecycle

Project BDesign Study

Review, edit, signoff

Project BDesign Study

Review, edit, signoff

Project BDesign Study

Review, edit, signoff

Operationalexperience

Negotiate

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

Accounting

CS2

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 specificationsand attributes

DOCUMENT CONTENT(structured documents )

MODELS:•Element definitions

-Content-Attributes

•Element hierarchies•Element sequences

OUTPUT OBJECTS•Contract/subcontractdocuments

•Procedures/instructions•Deliverable documents•All other controlleddocuments

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 databaseEBOMEBOM

Docu

ment

changes

Catalogue

Drawings

VAULT

Requirements tracking

DOCUMENT PROD MGMT• Author• Production schedule

• Check out / check in• Track and review• Deliver• Manage configuration & change

Prod

uctio

n ch

ang

es

ProjectSchedule

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&VTest, 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

Peop

le

Pro

cess

Infra

stru

ctu

re

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.

END