Lecture for Business Systems Analysis. Explores some aspects of organization theory and bounded rationality as these have been applied over the 17+ year history of a major shipbuilding contract in the context of a large defense engineering and project management enterprise. Cases include (1) proving to the Client that contractual operational availability targets were met over 10 ship-years in service, (2) analyzing and designing a system to capture, manage, and deliver to both crew and a relationally based computerized management system all technical data and procedural knowledge required to maintain the ships through a 27 year life-span, (3) understanding how the company failed through its failure to complete a smaller, simpler shipbuilding project following on from the successful and profitable completion of the much larger and more complex project

1. 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

2. 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
2

3. 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 enterprises3

4. 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.

5. 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)
 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
 Members‟ personal knowledge relating to their organizational
roles
Organizational knowledge
Leave one of the
legs off, and the
stool will fall over

6. 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 designs and develops frameworks and methodologies
for analyzing, understanding, and improving the systems structure

7. 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 things that contain 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

8. Enterprise management considerations
 Focus on the situation of the enterprise
– External situation
 Dynamic environment
– position relative to competitors
– changing 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
 Organizational assets (tangible, intangible)
 Product/service offerings
 Stakeholders (internal/external)
 Performance management/improvement system capabilities
– External must enable internal / Internal must satisfy
external

9. 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

10. 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
– Overcentralization 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 periphery as they grow
 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

11. Putting theory into
practice
Understanding how to manage organizational
knowledge flows naturally from the
biological point of view

12.  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
 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

13. 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 profitably13

14. 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

15. 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.

16. 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.
– Contract requirement: 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.
 Contractor must bear all costs of correcting any/all shortfalls &
changes required to meet OA thresholds
16

17. 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

18. Measures for RAMS
 Reliability = MTBF = (op hrs / failures)
 Availability = Ao = uptime / (uptime + downtime)
 Maintainability = MTTR = avge (TTR)
 Sustainability = MLDT = avge (job time - ADT -
TTR)

19. 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, Intermed & Depot level planned maintenance
− Estimating required inventory for "surge" capacity
− Input to life-cycle costing tools

20. CSARS: What does it look like?
Hierarchy
Failed
threshold
Search engine
Calculation
results
Ship
Calculation
Calculation
thresholds
Hierarchy:

21. 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:

22. 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.

23. 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 system23

24. 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

25. 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

26. 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 databaseEBOMEBOM
Catalogue
Drawings
VAULT
Requirements
tracking
DOCUMENT PROD MGMT
• Author
• Production schedule
• Check out / check in
• Track and review
• Deliver
• Manage configuration & change
Project
Schedule

27. The full knowledge management environment for
ship support
Tenix Navy

28. 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

29. Some businesses 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.

30. 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

31. 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

32. 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

33. Tenix: 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

34. Tenix: Project Protector (RNZN)
 $ 500 M fixed price follow-on project
– Three year project
– Build to “commercial” standards
– Seven ships constituting three different types for one customer
– 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 2 4

35. 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.

36. Background – cont.
 Finishing the successful 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

37. 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 access to both new hires and old hands as
“time wasting”

38. 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.

39. END