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 [email protected] http://www.orgs-evolution-knowledge.net
Access my research papers from Google Citations
SIRF 2nd KM Roundtable 2015, South Melbourne, 26/5/2015
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
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
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 customers 4
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")
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
}
My involvement in the story
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 certification 8
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
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
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
One organization
—
three generations
two eras
1956 – 1988: Prelude
1989 – 2000: Mobilization & expansion
2001 – 2007: Closeout & failure
2008 - 2014: Extinction
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 EDI 13
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
1989 – 2000
— Mobilization & Expansion
“good times” in Marine while owners
& executives were occupied with family feuds and acquisitions
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
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-management 17
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 breaches 18
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&D 19
IT & KM successes & failures
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
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
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
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
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
CS 2
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
EBOM EBOM
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.
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
AMPSCOMPLETION
REPORT
CLIENT
MASTER
DATA FILES
MAINTAINER COMPLETING
MAINTENANCE ACTION
ASPMIS
TRANSFER
SHIP SPECIFIC
CONFIGURED
MAINTENANCE
ROUTINES
TENIX
CLIENT
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
Architectural overview for an integrated prime contractor-operator KM system ANZAC
28
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
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
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!
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
Single check-in/check-out/workflow interface via MatrixOne to all other applications
CMIS
MRP
CAD
RAM
Tech Pubs ACAD
CATIA
TeraText
SGML
Relex
Opus
Production
Procurement
2001 – 2007
—
ANZAC closeout & Project Protector failure
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 Systems 35
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
Why did Tenix fail?
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 imperatives 38
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 S
YS
TE
M B
SY
ST
EM
A
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
SU
MM
AR
Y
SY
ST
EM
C
SU
MM
AR
Y
SY
ST
EM
A
SY
ST
EM
B
SY
ST
EM
C
SY
ST
EM
D
SY
ST
EM
Y
SY
ST
EM
Z S
UM
MA
RY
S
YS
TE
M A
S
YS
TE
M B
S
YS
TE
M C
S
YS
TE
M D
S
YS
TE
M Y
S
YS
TE
M Z
SU
MM
AR
Y
SY
ST
EM
A
SY
ST
EM
B
SY
ST
EM
C
SY
ST
EM
D
SY
ST
EM
Y
SY
ST
EM
Z S
UM
MA
RY
S
YS
TE
M A
S
YS
TE
M B
S
YS
TE
M C
S
YS
TE
M D
S
YS
TE
M Y
S
YS
TE
M Z
SU
MM
AR
Y
SY
ST
EM
A
SY
ST
EM
B
SY
ST
EM
C
SY
ST
EM
D
SY
ST
EM
Y
SY
ST
EM
Z
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
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
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 & training 42
Why does Defence think Australians
can’t/shouldn’t build warships & submarines?
—
Open for discussion