Presents the history of the now defunct Australian defense contractor, Tenix Defence, as a case study in success and failure in managing large engineering projects. Over its 20 year history, (2) Tenix successfully completed Australia's largest defense ($7 bn) project to build 10 ANZAC Frigates for Australia and New Zealand on-time, on-budget, for a healthy company profit against a stringently fixed price contract; and customers that are still happy with their ships and support 7 years after the last ship was delivered; and (2) failed so miserably on the next largish project to build 7 simpler ships for New Zealand that Tenix's owners decided to auction all of their defence assets. Also, in the 21st Century and despite the ANZAC success, the $8 bn Air Warfare Destroyer (AWD) project to build 3 ships is years behind schedule and billions over budget. For more than 17 years of this history the author was a knowledge management systems analyst with access to most areas of company operations and thus able to observe sources of the successes and failures (including from the vantage point of Tenix's bid development for the AWD. The presentation shows that most successes and failures related to the ways in which Tenix managed their corporate and human knowledge, and attempts to infer some critical lessons that should be learned from this history.

1. Failing to learn from Australia’s
most successful defence project
William P. Hall
President
Kororoit Institute Proponents and Supporters
Assoc., Inc. - http://kororoit.org
Documentation & Knowledge Management
Systems Analyst (Ret.)
Tenix Defence
william-hall@bigpond.com
http://www.orgs-evolution-knowledge.net
Access my research papers from
Google Citations
SIRF 2nd KM Roundtable 2015, South Melbourne,
26/5/2015

2. After profitably
completing 10 ANZAC
Frigates on-time, on-
budget
3 Air Warfare
Destroyers are $2 Bn
over budget & 3 yrs
late
—
Why?
Greg Sheridan in the Australian 22 May 2015 -
Warships cost blows out to $9bn

3. Tenix Defence’s $7 BN ANZAC Ship Project was the
most successful Defence Project in Australian History
3
 Late 1989-2007 built & delivered 10 modern frigates
– 8 to the Royal Australian Navy
– 2 to the Royal New Zealand Navy
– Different customers, different languages, different systems
– Plethora of engineering changes affecting everything
– Stringently fixed price contract & delivery schedule
– Required to achieve 80% Australia/New Zealand content
– Fixed acceptance dates, major penalty/warranty clauses
 How is ANZAC’s success measured?
– Every ship on time
– No cost overruns
– Healthy company profit ! A success by any standard!
– Happy customers
– A project you probably never heard of (no bad press)
 Tenix auctioned its Defence assets in 2007 because it
could not complete a $500 M project for New Zealand

4. What did the “Marine Division” do?
 In the mid 1980’s, except for fishing boats & tugs the Australian
shipbuilding industry was effectively dead
– Two part completed Adelaide class (FFG Frigates) rusting on slipway
of the gov’t owned/managed Williamstown Naval Dockyard
– Labor productivity was close to zero
– Thuggery, theft and fraud were rampant in the dockyard
 Privatized by AMEC  AMECON  Transfield Defence Systems
 Tenix Defence Systems  Tenix Defence
– Bid for and won ANZAC Ship Project (ASP)
– Completed engineering design & production planning
– Negotiated $BNs of subcontracts from weapons systems to paint
– While successfully completing 2 rusting FFG hulks
– Mobilized an excellent team for ANZAC
– Completed design & engineering based on German MEKO 2
– Built & managed crew training facilities
– Began tech data/production of entire documentation suite
– Successfully completed 10 ANZAC Frigates on time, on budget,
healthy company profit, happy customers4

5. The ANZAC experience shows Australians can build
ships
5
 Hugely demanding project
– Complex/ever-changing engineering demands (engineering changes!)
– ANZIP requirements to use local industry
– Life-cycle costing
– Test, Evaluation and Validation requirements: 10 ship years
– Fixed price for everything - including crew training, operator
manuals, technical data/documentation, logistic support & spares
 Mistakes made, lessons learned
– Hard lessons in what didn't work led to solutions
– In-house R&D with innovation rescued bad situations and still showed
a profit
 Benefits maximized with locally developed solutions
– Reduced costs and risks
– Allowed guidance of IP development to meet our needs
– Informal and formal partnership opportunities (the "home team")

6. Neither the company nor Defence seem to have
learned anything from the ANZAC success
 Tenix failed to complete its next significant project
– $500 M to complete 7 simple ships for New Zealand
 A RO-RO transport
 2 offshore patrol vessels all to Lloyds commercial certification
 4 inshore vessels
– A year into the project it was clear the company was way over
budget and would finish years behind schedule.
– Owners auctioned all (~$1 BN) Defence assets in 2007 to escape
 Today: Government-owned ASC the lead shipbuilder for $8 BN
build of 3 Air Warfare Destroyers
– (Ex) Defence Minister David Johnston 25 Nov. 2014, “ASC couldn’t
build a canoe”
– AWD now ~ $2 billion over budget, 3 years behind schedule and
probably still sinking
– Australian shipbuilding headed for a “Valley of Death” around 2020
where there will be no active projects to maintain skills
 Government working to send future Defence work offshore
6
}

7. My involvement in the
story

8. Qualifications as an observer
 Background
– PhD Evolutionary Biology (Harvard 1973)
– Migrated to Australia
– 1980-1989
 Operated word processing bureau to pay for my own setup
 Became interested in impact of personal computers on people
 Computer literacy education & journalism
 Tech communicator & documentation manager software house
– Corp Services tech writer & doco mgr for Bank of Melbourne
 1990 – 2007 Tenix
 2001 started sporadic work on hypertext book
exploring co-evolution of human cognition & technology
 2010-2011 course dev’t with EA Principals incl. gaining
TOGAF® 9 enterprise architecture certification8

9. AMECON  Tenix Marine Division
 Shipbuilding specific - Jan 1990 to ~2000
– Documentation systems analyst-designer
 (Commercial) T&C flowdown from prime contract to subcontracts
 (Training) computer literacy, electronic file standards & retrieval
 (ILS – support engineering)
– Contract analysis for documentation delivery
– Contract amendment to replace paper deliveries with electronic
– Contract analysis for ship TE&V and Operational Availability Recording and
Reporting requirements
– Analysis & design of OAARSystem to prove Tenix met AO requirements
– Design of 3 generations of authoring & electronic delivery systems for
electronic tech data & documentation (e.g., knowledge of how to maintain
the ships usable by computers & people)
– ILS & Systems Engineering representative on Shipbuilding Systems Project to
implement enterprise resource planning system (failed)
– ILS & Systems Engineering rep on implementation of Product Lifecycle
Management system (partial failure)
– Bid team support (documentation controller / expert)
– Opportunity analyist (KM products / services)
9

10. Tenix Defence Head Office ~2000-2007
 Leader of Requirements and Contracts Engineering (RACE) Online
to promote XML standards for Defence tenders and contracts
 Designed state of the art PLM system for Tenix Land (M113 UP)
 Under GM Strategy & Development (soon disbanded)
– Co-leader audit of engineering software applications & requirements
– Team leader corporate knowledge management audit
 KM Analyst in Engineering Head Office under R&D Manager
– Heavy involvement in implementation of corporate KM Portal (LiveLink)
– KM policy development
– Involvement in developing content management proposals for Tenix’s
“shipbuilder” bid for the AWD project to cope with Defence’s proposed
consortium structure for the project
– Facilitated development of cross-divisional CoPs for engineering/ILS
– Sponsorship & guidance for two interns completing PhDs in KM areas
– Development & prototyping (with KM intern) a knowledge mapping and sharing
strategy for transferring critical personal knowledge from ANZAC Ship
Project to NZ Project Protector
10

11. Key papers describing lessons (not) learned
[click underlined title for full paper]
 [Document management] Hall, W.P. 2003. Managing maintenance knowledge in the
context of large engineering projects - Theory and case study. Journal of
Information and Knowledge Management, 2(3), 1-17.
 [Data] Sykes, M. Hall, W. P. 2003. Generating fleet support knowledge from data
and information. Australian Conference for Knowledge Management & Intelligent
Decision Support ACKMIDS 2003 Melbourne, Australia, 11 and 12 December 2.
 [Product Lifecycle Management] Hall, W.P. and Brouwers, P. 2004. The CMIS
solution for Tenix's M113 program. MatrixOne Innovation Summit. Shangri-La's
Rasa Sentosa Resort, Singapore, 12 - 14 August, 2004.
 [Project Management] 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.
 [Personal knowledge] 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.
 [KM failures] 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.11

12. One organization
—
three generations
two eras
1956 – 1988: Prelude
1989 – 2000: Mobilization & expansion
2001 – 2007: Closeout & failure
2008 - 2014:  Extinction

13. Three generations of
Sydney-based family companies
 Transfield Holdings 1988-1995 (private partnership)
– Founded 1956 Franco Belgiorno-Nettis & Carlo Saltieri
– Engineering projects (infrastructure & plant maintenance)
 1988 Transfield Defence Systems founded to bid on ANZAC
 1989 Sons, Paul Salteri & Franco Belgiorno-Zegna, MDs
 1996 Gen 2 family differences split company – Defence assets to
Salteri; remainder plus Transfield name to Belgiorno-Nettis
 1996-2001 Paul Salteri expanded from Marine
– Tenix Defence: + aerospace, + land, + electronic systems
– + civil infrastructure, + civil aviation, + computer
systems development, + local government data mgmt
 2001 Robert Salteri (3rd generation) appointed as CEO
– 2007 auctioned “some or all” Tenix assets, finalized sale of all
Defence assets to BAe Systems early 2008
– 2014 last infrastructure maintenance assets sold to Downer EDI13

14. Marine born in 1988 as an innovative new organization
soon acquired by the family company
 Eglo Engineering with Dr John White lobbied to start Submarine
project & joined a failed bid to win the Collins Class contract
 In 1986-7 Eglo formed AMEC as a publicly owned consortium with
ICAL, & (W) Australian Shipbuilding Industries to bid on pending
ANZAC Ship project
– Late 87 AMEC won bid to privatize dysfunctional Williamstown Naval
Dockyard in competition with private Transfield Defence Systems
 1988 Transfield acquired all AMEC stock and renamed company
to AMECON in early 88, retaining some staff from Eglo & Ical
 Under Dr John White AMECON closed Dockyard
– Terminated all Dockyard labor & management staff
– With ACTU agreement, replaced 23 unions, 30 awards & 390
classifications with 3 unions and 1 award and 2 classifications
– Rehired selected dockyard people of “good reputation” and many
years of living knowledge
– Recruited / contracted engineering talent needed to bid/design
ANZACs (other industry, Navy, overseas)
14

15. 1989 – 2000
—
Mobilization & Expansion
“good times” in Marine while owners
& executives were occupied with
family feuds and acquisitions

16. John White (from Eglo) turned dysfunctional WND into
internationally competitive shipyard on its 36 acre (14.5 ha) site
16
 Sheet steel & components in
 Completed ships & operating
knowledge out
 Modular construction
– Big components easy to
install in modules before
consolidation
– Module construction could
be subcontracted out

17. Defence systems started with the “Marine Division”
 High turnover (generally < 3 yrs) in Williamstown senior mgmt
– Hired to manage specific project phases
– No tolerance for “mistakes”
– No opportunity to learn corporate history or “on the job”
– Once the work was mobilized, senior management contributed little
to effective workings of the ANZAC Ship Project (“ASP”)
 Marine used as cash cow to support acquisitions
 Engineering, technical and production staff were the “heart”
– Plenty of 10 & 15 year pins (e.g., select staff from WND)
– Proud/excited to be designing, building & supporting Australian ships
– Major family turnouts to watch their ships being launched
– Worked and often socialized as teams
– Actively worked to understand what the Contract required
– Made mistakes, identified problems and solved them
– Worked very long hours to ensure project success
 Large component of self- and emergent-management17

18. Unique aspects of the ANZAC Ship Project Contract
helped to determine how the organization worked
 Client project authority was bi-national (nationally variant ships)
 Contract specified capabilities to be delivered not specific
products/systems
 80% Australia /New Zealand Industry Participation by value
 Foreign (German) design to be engineered & built in Australia
 Fixed price contract (1989 $ with escalation) / fixed schedule
– Ships & systems
– Shore based simulators, & complete ship crew training package
– Logistic support costs
 Initial consumables + supply chain/rotable pool/insurance spares
 Complete technical data / operational and maintenance documentation
deliverables
 Warranty requirement to prove over 10 ship-years that ships
were operationally available (AO) at least 90% of time
– Major test of design, engineering, training, maintenance knowledge
– Tenix required to develop acceptable methodology to prove this
 Major liquidated damages for schedule milestone breaches18

19. Problem areas requiring development & deployment of
specialist knowledge
 Solved major problems & issues largely unique to defence proj.
– Engineering subcontracts fully reflect prime contract obligations
– Acquisition of required IP from system subcontractors to build,
document & maintain ships
– Modular construction with dimensional control methods/technologies
– Welding technologies & training
– Contract amendment & subcontract management
– Cost & schedule control & reporting
– Inventory mgm’t & tracking (Project Authority takes ownership of
most stuff when delivered on site)
– Configuration management for tracking engineering change control
– “Issue 4” Safety critical documentation authoring & management
must track eng. changes throughout ship lifecycles
– Both human maintainers and computerized maintenance
management systems must understand safety-critical tech
data/documentation
 Problems identified and managed locally
– Internal solutions and innovation / Locally managed R&D19

20. IT & KM successes &
failures

21. Test, evaluation & validation of operational
availability (AO)
 Contractual requirement to prove that ~18 different critical
systems were each individually available for operations 80% of
time and all of the systems together were available 90% of time
– Major test of design and adequacy of design engineering, maintenance
planning & routines, maintainer training, ILS support and sparing philosophy
– Had to be proved from evidence collected from first 10 ship-years in service
(Ship 1 x 4 yrs, Ship 2 x 3 years, Ship 3 x 2 yrs, Ship 4 x 1 yr)
 In-house team designed and implemented OAARS system to
calculate down-times from data on component failures recorded
in ship-board maintenance management systems
– System had to work with Navy’s AMPS maintenance management system
– Calculation involved an availability tree hierarchy to determine impact of
individual component failure on availability of critical system(s) and ship
 Solution worked so well that Navy adopted AMPS and OAARS
for all ships except submarines (that had another maintenance
management system)
21

22. Shipbuilding Systems Project (from ~1996)
 Problem: costly nugatory work and rework in production
– Management solution focused on better bean counting: implement
manufacturing resource planning system
– Hired outside IT project mgmt “consultants” to work with IS
 First try
– 1+ yr implementing BaaN system designed for continuous manufacturing and
auto industry that did not understand Defence tracking requirements
– Neither consultants nor vendor staff experienced with defence projects
– Tenix rejected first implementation
 Second try
– Vendor returned with version implemented for Boeing in Seattle
– Consultant/vendor staff still didn’t understand new defence-related functions
– I was able to explain, but Tenix lost confidence in vendor
– Consultant/vendor told to get off the site and take their junk with them
 Cost
– 15-20 ~ staff full-time x 2 yrs each on both sides – time completely wasted
– ~ $10-20 million completely wasted with zero economic return!
 Shipyard work was efficient, the real problems were managing
engineering knowledge & change before steelwork began
– Area addressed by Product Data / Project Lifecycle Management (PDM/PLM)22

23. Product Data Management
 In-house PDM assessment group formed to select solution
– Staffed by systems, design, & support engineers
– Reviewed & ranked all viable systems, eMatrix ranked 1
 Finance and admin dithered for almost a year to approve project
– Last ranked system (Sherpa) presentation to management given by a
person who understood Defence contracting better than we did
 We already had a first generation Sherpa system & Navy used it
 Sherpa spaghetti code was very slow and unmaintainable with poor in-
country support
 GM Engineering forced decision against c’ty recommendations despite
presentation of evidence that Sherpa was failing
– IS began implementing system as Sherpa IP was being auctioned
 Sherpa never did what Tenix needed
 Engineering change management problem was solved with end-
user designed/managed systems implemented in-house (see Issue
4 and Crossbow, below)
23

24. Issue 4 (“documentaton quality”) – document &
content management was critical for whole project
 Contract assumed all documentation would be delivered on paper
– Navy decided to implement computerized maintenance management (AMPS)
– Tenix didn’t want the monstrous problems of keeping paper current
– Negotiated a zero cost amendment to deliver data + doco into AMPS
 All tech data & doco would have to parse in relational AMPS and be
usable by human maintainers as maintenance instructions
– 2000+ maintenance routines per ship x 10 ships (+ onshore subsets)
 All key codes must parse for relational system to work
 Impossible to provide by human authors using word processing systems
 3 different doco systems used/tested - none could deliver flawless data + doco
– Issue 4 crisis
 If data & documentation deliveries for Ship 4 milestone didn’t parse correctly ship 5
would not be accepted triggering ~$30 m liquidated damages, schedule slippage &
reputational damage
 SGML/content management R&D project evaluated technology & systems
– All credible overseas & local systems evaluated – best was RMIT’s SIM to be
implemented by Aspect Computing (product renamed TeraText).
– F&A did not understand problem or technology & never signed contract
– Operations manager diverted “time & materials” funds from operations
– Complete success – still in use today? reduced support doco costs 70-90%
on initial budget; half the solution to engineering change management
24

25. Established architecture integrating Tenix’s product
configuration and document content mgmt
25
Product data and
documents are
structured and
managed as content
Production data is
transactional and is
managed as records
and fields
MRP / PRODUCTION MGMT
• MBOM
• Production planning
• Production schedule
• Procurement
• Warehousing
• Establish & release workorders
Project
Schedule
HRM
Accounting
CS2
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
Omega PS
LSAR Database
EBOMEBOM
Catalogue
Drawings
ENGINEERING
CHANGE
See eMatrix, Windchill, TeamCenter
Contract
Implementing this architecture for the
ANZAC Ships reduced time for engineering
changes from months to more than a year to
weeks or even a day or two if needed.

26. Maintenance knowledge improvement cycle in practice
for ANZAC Ships
 Developed OARRS in-house to test
if contracted availability
thresholds were met over 10 ship-
years of operational experience
– Hired programmers to complete
coding and implement
– Met requirement with complete
success
 Management decided not to patent
and market
 Project taken over by outside
contractors working for Navy and
renamed Class Systems Analysis
and Reporting System (CSARS)
– Adopted by RAN for all naval ships
except submarines
 Provided a closed & continuous
feedback loop to validate &
improve maintenance routines/
documentation
26
CONTRACTS
TECHNICAL
MAINTENANCE
PLANS
SUPPLIER SOURCE
DOCUMENTS
SAFETY
CORRESPONDENCE
ENGINEERING
CHANGES
AUDIT AND LOGISTICS
ANALYSIS
TECH AUTHOR
MAINT. ENGINEER
ILS DB / LSAR DB
• Line item details
• Config details
• Eng. Changes
CLASS SYSTEM ANALYSIS AND
REPORTING SOFTWARE
MAINTENANCE AUDIT FUNCTION
TERATEXT
DB
CSARS
ONBOARD
ASSET MAINTENANCE
PLANNING SYSTEM
AMPSCOMPLETION
REPORT
CLIENT
MASTER
DATA FILES
MAINTAINER COMPLETING
MAINTENANCE ACTION
ASPMIS
TRANSFER
SHIP SPECIFIC
CONFIGURED
MAINTENANCE
ROUTINES
TENIX
CLIENT

27. Crossbow – rationalized and consolidated key eng data
replicated across 15 separate systems
27
 Critical information on ship/
system parts found on up to
15 different databases
– Spreadsheets, …, RDB
– Different ID systems used
in different DBs
– Typos & transcription errors
 In house support engineer recruited from RAAF developed data
rationalization/ warehouse called Crossbow
– Matched similar/identical items across DBs & managed coms to
synchronize on a single identifier for each part
– Recorded current & historical states of all DBs
– Provided point in time tracking of all changes & corrections
– Single user interface allowed easy navigation across all databases
– Client deliveries and access to Tenix data provided via Crossbow
 Tenix belatedly tried and failed to commercialize product

28. Architectural overview for an integrated prime
contractor-operator KM system ANZAC
28

29. Tenix Land implemented fully integrated Configuration
Management Information System for M113 UP
29
CMIS
MRP
Production
Procurement
RAM
Relex
Opus
LSA
TeraText SGML
TECHNICAL
PUBLICATIONS
CAD
ACAD
CATIA
LORA
CMIS
MRP
Production
Procurement
RAM
Relex
Opus
LSALSA
TeraText SGML
TECHNICAL
PUBLICATIONS
CAD
ACAD
CATIA
LORALORA
MRP = Mfg. Resource Planning
CAD = Computer Aided Design
LORA = Level of Repair Analysis
RAM = Reliability & Maintainability
LSA = Logistic Support Analysis
System implemented to
manage all project
related documentation
through entire product
lifecycle
Executives never
understood what
CMIS could do, and
middle managers who
did all left Tenix in
frustration
Travel not authorized
for effective liaison
between Land &
Marine

30. Background
 Contract: All configuration management in M113
Project according to
– TRAMM (Technical Regulation Army Maint Mgmt)
– MIL-STD-973 (Configuration management)
 Other standards
– Naming follows H6 (US Fed Item Name Directory)
– NATO Commodity Codes forms part type
– Final development based on S1000D XML standard
for documentation
 Rule: CMIS manages all tech data for all projects
– Engineering data
– Source documents
– Technical Publication content
 No part released until all metadata correct

31. CMIS was conceived as an "umbrella" system
 Integration of MatrixOne and TeraText
 Single user interface via MatrixOne
 Data normalization applies to all project data and
document components from the start
 MatrixOne provided common workflow management
environment for entire project
 Single point:
– electronic signoff (no paper chases!)
– engineering change management and tracking at light speed
– cost and schedule control prior to signoff
 The umbrella covers everything!

32. CMIS recognized that engineering knowledge was
Tenix’s most important asset
 Data and documentation are the most important
assets to the company
 CMIS is the custodian AND guardian of the Company’s
data and documents
– Secure Vaults and Stores
– Encrypted
– Access control
 CM II compliant
– Only recognized commercial CM doctrine
– Qualified by Institute of CM
– CM Manager was only CM II qualified certifier in Australia
 Understood how everything went together to deliver
the capabilities the client wanted

33. Single check-in/check-out/workflow interface via
MatrixOne to all other applications
CMIS
MRP
CAD
RAM
Tech
PubsACAD
CATIA
TeraText
SGML
Relex
Opus
Production
Procurement

34. 2001 – 2007
—
ANZAC closeout &
Project Protector failure

35. Serial production & closeout of ANZACs
 Specialist “close-out” GM blocked transfer of living knowledge
by isolating ASP serial production from other activities
– Staff required to account for every half hour against cost code in
work breakdown structure
– ASP behind security fence with swipe card access only
– Non ASP staff required GM signature to visit ASP staff
– Chatting around water cooler & coffee breaks seen as time wasting
 Costly engineers/senior staff outsourced or given redundancy
 ASP IS decided to replace the working Crossbow “kludge”
– Navy selected TeamCenter as their PDM system for ships in service
 Land’s MatrixOne solution was offered
 Suspect selection – key Navy selectors became TeamCenter employees
– ASP chose TeamCenter because Navy was going to use it rather than
Matrixone CMIS system that was fully operational in Adelaide
– ASP and IS spent millions trying to implement TeamCenter as
shipbuilder system for ANZAC Ships
 Could not manage complexity of ASP
 Still wasn’t fully working when Tenix Defence taken over by BAe Systems35

36. Mobilizing Project Protector to build 7 new ships for
New Zealand
 Anticipating Protector, I established an R&D project in Head Office to
develop & prototype strategy to map and facilitate transfer of lessons
learned from ASP to Protector
– IS spec. projects analyst, sr C&S controller, KM intern, programmer
– Identified major areas of project risk
– Knowledge map used to guide interviews
– Narratives, nuggets, metadata gathered in Crossbow to facilitate navigation
& exploration for possible solutions
– Proposed to introduce people experienced in risk areas in Q&A sessions
 New engineering staff hired “off the street” at low salaries
– Engineering graduates or industrial qualifications
– Few had defence, mobilization, shipbuilding, or CM experience
 Knowledge transfer activities blocked three times by line managers
– Too busy
– Time wasted against “critical activities” in work breakdown items
 Chose not to implement working CMIS system from Land in Adelaide
– IS chose to implement cheap & simple Croatian shipyard management system
– 3+ months into project still didn’t know how to set up configuration IDs
– Would not pay air fare for CM expert in Adelaide to help
36

37. Why did Tenix fail?

38. Executives never seemed to understand organizational
imperatives for their own company
 What are “organizational imperatives”? (my usage differs)
Things the organization must do successfully in order to continue its
existence and flourish in its real world physical, environmental, and economic
circumstances.
– Imperatives depend on the nature of the organization and its environment
– Imperatives exist independently of management beliefs, strategies, goals and
mission statements – physics always trumps belief
– Organizations failing to satisfy their imperatives in one way or another will
not thrive and may fail
 Imperatives for an engineering project manager (e.g., Tenix)
– Qualify and win suitable contracts (find customers)
– Successfully complete contracts won (satisfy customers)
– Ensure overall operational profitability
– Maintain workforce able to address imperatives
– Comply with health, safety and environmental standards
– Comply with governmental regulations
– Satisfy all of the above imperatives
 Don’t divert effort/resources to activities that don’t address
imperatives38

39. Never learned how to reliably win contracts
 Never understood the power/dangers of electronic documents
– Put MS Word in hands of contract engineers and typists who used
wordprocessor like a typewriter
– Multiple authors worked on same electronic files
 Internal R&D project proposed to replace MS Word authoring
environment with authoring & configuration management
environment used in-house for ANZAC documentation
– Would have reduced bid cost/hours by more than 50% allowing
resources to be applied to more/better crafted bids
– Support engineering (but not IS) had expertise to implement it
– Payoff time a year or less or immediately an “extra” bid is won
 Executives / F&A did not believe or understand concepts
 Only 3 bids won (including Protector) in 17 years after ANZAC
 Should have won Air Warfare Destroyer bid
– Tenix lost to ASC on a “value for money” basis
– Scuttlebutt said that F&A had costed work not required in RFT
 Tenix unable to successfully complete $500 M Protector
– Won $ 2 BN LHD project as company was being auctioned
39

40. 40
SYSTEMB
SYSTEMA
50+ ENGINEERS & ANALYSTS ENTERING OWN WORK
APPROXIMATELY 600+ INDIVIDUAL WORD PROCESSED DOCUMENTS INCLUDED IN TENDER
EACH INDIVIDUAL ELECTRONIC DOCUMENT FILE WILL BE WORKED ON BY MANY AUTHORS
ENGINEERS & ANALYSTS CREATE AND TYPE, LOCATE AND AMALGAMATE DATA & OBJECTS
PRINT? - REVIEW & EDIT / RETURN FOR CHANGE, PRINT? - REVIEW & EDIT AGAIN
1000’S OF SOURCE DATA ITEMS - MAY BE WP DOCUMENTS PRODUCED IN-HOUSE,
PREVIOUS TENDERS, DDS DOCS, SUPPLIER SOURCE DATA IN UNKNOWN FORMAT,
STANDARDS, GRAPHICS, SPREADSHEETS, DRAWINGS, CLIENT DOCUMENTS, ETC
COORDINATOR AND DOCO PRODUCTION TEAM PRINT 600+ FILES & ASSEMBLE REVIEW VOLUMES
SUMMARY
SYSTEMC
SUMMARY
SYSTEMA
SYSTEMB
SYSTEMC
SYSTEMD
SYSTEMY
SYSTEMZ
SUMMARY
SYSTEMA
SYSTEMB
SYSTEMC
SYSTEMD
SYSTEMY
SYSTEMZ
SUMMARY
SYSTEMA
SYSTEMB
SYSTEMC
SYSTEMD
SYSTEMY
SYSTEMZ
SUMMARY
SYSTEMA
SYSTEMB
SYSTEMC
SYSTEMD
SYSTEMY
SYSTEMZ
SUMMARY
SYSTEMA
SYSTEMB
SYSTEMC
SYSTEMD
SYSTEMY
SYSTEMZ
   
COORDINATOR & DOCO PRODUCTION TEAM VALIDATE 900+ ELECTRONIC FILES AGAINST DID CONTENTS
DOCO PRODUCTION
TEAM PRINT MASTER
COPY FROM CD
DIRECTORY
DATA CONTROL PRINTS COPIES
DOCO PRODUCTION
TEAM TRANSFER
VALIDATED
SUBDIRECTORIES TO
CD DIRECTORY -
BURN CD ROM
SENIOR MANAGERS REVIEW & EDIT CONTENT / STYLE ETC.
To win a bid you
have to draft it
• Tenix’s bid authoring
and doco management
systems didn’t work
– Time tightly limited
– Paper procedures applied
to electronic documents
– 50% of bid engineers’
work lost/nugatory
– Could not standardise doco
– No traceability/tracking
– Revision control not
enforced
– Final stage crises
– Chaos
• Resulting bids
– Costly in time & personnel
resources
– Poor costing of work bid
– Sloppy presentation
– Late
– Incomplete
– Full of errors
DOCO PRODUCTION TEAM ASSEMBLES 900+ FILES INTO SUB-DIRECTORIES
TECHNICAL SUPERVISORS AND MANAGERS REVIEW & EDIT TECH CONTENT
TEXT EDITOR PROOFS FOR READABILITY AND ENGLISH USAGE

41. Problems inherent(?) in the family business led to its
demise in the third generation
 All major ANZAC problems solved by 2001 acceptance of Ship 5
– In 2001 strict command and control hierarchy was instituted under
closeout GM to squeeze last cent out of “serial production”
– Most engineers “outsourced” to labor hire companies, hived off
to other divisions, or made redundant asap.
 Construction industry bean counting mentality
– Used to hiring/contracting standardized management & trade skills
on a project by project basis
– Management bonuses based on retrospective “Tenix Added Value”
 What they did in the past, not what they were doing for the future
– Little thought or understanding of the value of unique personal
knowledge, org. continuity & meeting organizational imperatives
– Staff not allowed to do anything not booked directly to a
contractual work item code
– Every half hour had to be accounted in time management system
41

42. The dead hand of absentee owners and Finance and
Administration mentality killed the company
 Owners & senior execs worked from Tenix Tower in Sydney
– Isolated from all operating divisions (closest was Pukapunyal)
– Minimal provision for interstate travel between divisions & HO
 Centralized command & control hierarchy
– North Sydney was a “black hole”: information in – nothing out
– Long chain of command with poor formal delegation of decisions
– Prior to 2001 many important decisions towards successful solutions
were made locally in default of / or even despite central authority.
 Execs did not understand how to manage or value knowledge
– Ignored findings of contracted KM audit, several consultants & CIO
– Did not understand value of tacit or explicit knowledge
 Finance & Administration mentality
– Knew cost of everything, value of nothing
– Sr mgmt bonuses based on retrospective “Tenix Added Value”
– Information Systems a department under F&A
 IS had little understanding/consideration of end-user requirements
 F&A would pay millions for hardware & software but little for
analysis & training42

43. Why does Defence think
Australians
can’t/shouldn’t build
warships & submarines?
—
Open for discussion