Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Failing to learn from Australia’s most successful defence project

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.

  • Login to see the comments

  • Be the first to like this

Failing to learn from Australia’s most successful defence project

  1. 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. 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. 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. 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. 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. 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. 7. My involvement in the story
  8. 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. 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. 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. 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. 12. One organization — three generations two eras 1956 – 1988: Prelude 1989 – 2000: Mobilization & expansion 2001 – 2007: Closeout & failure 2008 - 2014:  Extinction
  13. 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. 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. 15. 1989 – 2000 — Mobilization & Expansion “good times” in Marine while owners & executives were occupied with family feuds and acquisitions
  16. 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. 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. 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. 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. 20. IT & KM successes & failures
  21. 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. 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. 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. 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. 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. 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. 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. 28. Architectural overview for an integrated prime contractor-operator KM system ANZAC 28
  29. 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. 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. 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. 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. 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. 34. 2001 – 2007 — ANZAC closeout & Project Protector failure
  35. 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. 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. 37. Why did Tenix fail?
  38. 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. 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. 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. 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. 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. 43. Why does Defence think Australians can’t/shouldn’t build warships & submarines? — Open for discussion

×