421-672 Management of Technological Enterprises Managing Knowledge in Technological Enterprises (Tutorial 1): Knowledge en...
Why is knowledge important to the enterprise? <ul><li>Tech enterprises and engineering products are  knowledge intensive <...
KM systems in the high-tech enterprise <ul><li>People </li></ul><ul><li>Process </li></ul><ul><li>Technology infrastructur...
Organisational knowledge management imperatives <ul><li>Capability when it is needed </li></ul><ul><ul><li>Reliably  does ...
Major quality issues in delivering product operational and  support  knowledge <ul><li>Knowledge delivery goals (only peop...
Objective knowledge development lifecycle for a large project • 20 - 50 year lifecycle Project A Design Study Review, edit...
Implementing OODA system of systems in the organisation PROCESS  PEOPLE CULTURE & PARADIGMS INFRASTRUCTURE “ CORPORATE MEM...
&quot;Living knowledge“ : source of organisational knowledge Vines, R., Hall, W.P., Naismith L. 2007.  Exploring the found...
Organisational disciplines creating & using knowledge <ul><li>research and development </li></ul><ul><li>business developm...
Systems and applications infrastructure recording and transmitting knowledge <ul><li>Tool areas </li></ul><ul><ul><li>desi...
People issues <ul><li>recruitment </li></ul><ul><li>training and career development </li></ul><ul><li>facilitation and inc...
Limits to knowledge and organisation <ul><li>Rationality in making  decisions  (key part of OODA loop) </li></ul><ul><ul><...
Process issues (all involve people) <ul><li>overall project management </li></ul><ul><li>qualification and bidding </li></...
Infrastructure issues <ul><li>business analysis </li></ul><ul><li>personal productivity tools </li></ul><ul><li>product da...
Learning from our mistakes <ul><li>Introduction to Part II of the Columbia Accident Investigation Board Report: “ Many acc...
Why do engineers need to manage knowledge? <ul><li>What can go wrong? (most boil down to KM failures) </li></ul><ul><ul><l...
Why do engineers need to manage knowledge? <ul><li>And then there are the economic failures! </li></ul><ul><ul><li>Cost ov...
The Challenger disaster <ul><li>Challenger disintegrated during the boost phase on January 28, 1986  </li></ul><ul><li>7 c...
The Challenger Disaster <ul><li>Rubber becomes stiffer the colder it gets.  </li></ul><ul><li>The launch was decided in th...
The Challenger Disaster <ul><li>On launch, the cold, stiff O-rings to failed to seal in the lower joint of the right SRB. ...
The Challenger Disaster <ul><li>Primary reference -  Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger...
Challenger: crucial management decisions <ul><li>Boisjoly, R.M. 1980.  Ethical decisions – Morton Thiokol and the Space Sh...
Challenger: crucial management decisions At the end of the discussion, Mason turned to Bob Lund, Vice President of Enginee...
Challenger: summary of organisational issues <ul><li>Source:  http://www.tech.plym.ac.uk/sme/Interactive_Resources/tutoria...
EPMO: engineering project management org <ul><li>Successful $ 7 BN technologically complex and knowledge intense shipbuild...
EPMO: Follow-on project <ul><li>$ 500 M fixed price follow-on project </li></ul><ul><ul><li>Three year project </li></ul><...
EPMO Background <ul><li>Company/management characteristics </li></ul><ul><ul><li>Family owned </li></ul></ul><ul><ul><li>D...
EPMO Background – cont. <ul><li>Finishing the successful project </li></ul><ul><ul><li>Owners hired overseas “close-out” s...
EPMO failed to transfer organisational knowledge <ul><li>Knowledge management expertise located in “rump” head office </li...
EPMO: The importance of people and culture <ul><li>Example: board spent $ M to implement corporate portal </li></ul><ul><u...
HMAS Westralia fire <ul><li>Westralia is an RAN fleet oiler </li></ul><ul><li>Flexible fuel line burst spraying oil on hot...
HMAS Westralia fire – summary of findings <ul><li>Westralia  Board of Inquiry </li></ul><ul><ul><li>71. The fire in HMAS W...
HMAS Westralia fire – summary of findings <ul><li>The mistakes ( Coroner’s Report ) </li></ul><ul><ul><li>No notice taken ...
Why do engineers need to manage knowledge? <ul><li>What can go wrong? (most boil down to KM failures) </li></ul><ul><ul><l...
Why do engineers need to manage knowledge? <ul><li>And then there are the economic failures! </li></ul><ul><ul><li>Cost ov...
Upcoming SlideShare
Loading in …5
×

421 672 Management Of Technological Enterprises(2008 Tutorial 1)

452 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
452
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • What does the fleet operator seek ? Meet capability requirements With minimal procurement delay That do the job when needed - supplier technical data/documentation must provide client with knowledge they need to operate product. Can easily be kept operational in the face of wear and damage Minimum downtimes Operational knowledge and H&amp;S issues Technical data/documentation must be sufficient, correct and available to enable safe operation and maintenance by personnel. A significant contributor to the fire on board the HMAS Westralia was the failure of key decision makers to follow existing documented engineering/configuration change procedures in the replacement of fuel lines . Why? Can better systems give people access to knowledge they need to avoid such disasters. A significant contributor to the Longford gas plant disaster was Esso&apos;s failure to provide appropriate documentation &amp; training to cover the dangers of working with frozen vessels. Why? Can better systems give people access to knowledge they need to avoid such disasters. Problems locating and using manuals (which may or may not be up to date) sitting on someone&apos;s dusty bookshelf at some distance where decisions are being made. Life-cycle cost Fleets cannot operate without adequate documentation and technical data, but these costs don&apos;t provide the capability. Must be reduced to a minimum
  • What are the overriding goals for the delivery of operational knowledge to fleet managers and operators? Correct and consistent - use same words to describe the same actions wherever they occur. Applicable and Effective Availability of the documentation - this is an important issue. (It didn&apos;t exist for Longford.) Explicitly documented knowledge is useless if it sits on a shelf and isn&apos;t readily accessed when and where decisions need to be made. (Westralia?? Sensible procedural documentation existed . Why wasn&apos;t it followed?) Usable - discoverable, understandable and relevant to the end user (e.g., an operator or maintainer) and manageable in whatever kind of knowledge management environment the fleet operator uses. (Library shelves full of paper manuals is one form of knowledge management - a bad one) Capturing, managing and delivering knowledge is a cost and risk burden Minimise cycle times - new information and changes must be deployed to the end-users when and where they need it Maximise quality - knowledge capture, production processes must deliver a high quality product or the product won&apos;t be used or will cause more problems than it solves. Minimise costs - data/documentation is a cost against the needed capability to be minimised wherever possible - but not at the expense of increasing risk. &amp;quot;Faster, better, cheaper&amp;quot; - but not at the risk of catastrophe. Up front saving is worthless if the project fails - e.g., the Mars Lander.
  • Explicit knowledge for a long lived project is expressed in its documentation. Project documentation is developed through a number of phases, and at least for defence engineering projects the same information and knowledge is often contained in many different documents, in both similar contexts and in different contexts. A major issue is to manage this redundant content consistently over the life-cycle in relation to changing product configurations and to reflect project experience. The remainder of the presentation discusses architectures and tools we have implemented in Tenix to do these things.
  • 421 672 Management Of Technological Enterprises(2008 Tutorial 1)

    1. 1. 421-672 Management of Technological Enterprises Managing Knowledge in Technological Enterprises (Tutorial 1): Knowledge engineering in the engineering organisation William P. (Bill) Hall (PhD) Evolutionary Biology of Species and Organizations http://www.orgs-evolution-knowledge.net Documentation and KM Systems Analyst (retired) Tenix Group Head Office, Williamstown, Vic. (retired July 2007) National Fellow Australian Centre for Science, Innovation and Society Melbourne University Uni Office: ICT 5.59, 111 Barry St., Carlton Phone: +61 3 8344 1530 (Mon, Tue, Thurs only) Email: [email_address] TUTORIAL: 20 March 2009
    2. 2. Why is knowledge important to the enterprise? <ul><li>Tech enterprises and engineering products are knowledge intensive </li></ul><ul><ul><li>to design </li></ul></ul><ul><ul><li>to manufacture </li></ul></ul><ul><ul><li>to operate </li></ul></ul><ul><li>Engineering processes and products are fallible! </li></ul><ul><li>Organisations are complex dynamic systems </li></ul><ul><ul><li>Difference between complex and complicated </li></ul></ul><ul><ul><ul><li>Organisations have minds of their own (my research area) </li></ul></ul></ul><ul><ul><ul><li>Cannot be predicted, can only be constrained </li></ul></ul></ul><ul><ul><li>Depend on &quot;system of systems&quot; to manage knowledge </li></ul></ul><ul><ul><li>System of systems components include </li></ul></ul><ul><ul><ul><li>People </li></ul></ul></ul><ul><ul><ul><li>Processes </li></ul></ul></ul><ul><ul><ul><li>Infrastructure technology </li></ul></ul></ul>
    3. 3. KM systems in the high-tech enterprise <ul><li>People </li></ul><ul><li>Process </li></ul><ul><li>Technology infrastructure </li></ul>People Process Infrastructure Organizational knowledge Leave one of the legs off, and the stool will fall over
    4. 4. Organisational knowledge management imperatives <ul><li>Capability when it is needed </li></ul><ul><ul><li>Reliably does what it is supposed to </li></ul></ul><ul><ul><li>Available for service when needed </li></ul></ul><ul><ul><li>Maintainable - problems can be fixed when they arise </li></ul></ul><ul><ul><li>Supportable - critical needs available in supply chain </li></ul></ul><ul><ul><li>Operable within limits of human knowledge & capacity </li></ul></ul><ul><li>Health, safety and operational knowledge issues </li></ul><ul><ul><li>Heavy/complex engineered products can kill! </li></ul></ul><ul><li>Life-cycle cost </li></ul><ul><ul><li>Minimise acquisition cost </li></ul></ul><ul><ul><li>Minimise documentation, support & maintenance costs </li></ul></ul><ul><ul><li>Implement &quot;lean maintenance&quot; philosophy </li></ul></ul>Adequate performance on all issues depends on the quality of authoring, management and transfer of technical knowledge from supplier to operators
    5. 5. Major quality issues in delivering product operational and support knowledge <ul><li>Knowledge delivery goals (only people apply knowledge) </li></ul><ul><ul><li>Correct </li></ul></ul><ul><ul><ul><li>Correct information </li></ul></ul></ul><ul><ul><ul><li>Consistent across the organisation </li></ul></ul></ul><ul><ul><li>Applicable/Effective </li></ul></ul><ul><ul><ul><li>“ Applicable” to the location of use </li></ul></ul></ul><ul><ul><ul><li>“ Effective” for the time of use re engineering changes, etc. </li></ul></ul></ul><ul><ul><li>Available! </li></ul></ul><ul><ul><ul><li>Accessible to those who need it, when and where it is needed </li></ul></ul></ul><ul><ul><li>Useable </li></ul></ul><ul><ul><ul><li>Readily understandable by humans </li></ul></ul></ul><ul><ul><ul><li>Readily managed & processed in computer systems </li></ul></ul></ul><ul><li>Enterprise knowledge production and usage goals </li></ul><ul><ul><li>Fast </li></ul></ul><ul><ul><li>High quality </li></ul></ul><ul><ul><li>Low cost </li></ul></ul>
    6. 6. Objective knowledge development lifecycle for a large project • 20 - 50 year lifecycle Project A Design Study Review, edit, signoff Negotiate Review, negotiate, amend Project A Prime Contract RFT and Bid Review, edit, signoff Project A Bid Documents RFQs Bids Negotiations Project A Subcontracts Review, negotiate, amend Project A Procedures, Design Docs Review, edit, signoff Project A Support Documents Project B Design Study Review, edit, signoff Project B Design Study Review, edit, signoff Project B Design Study Review, edit, signoff Operational experience
    7. 7. Implementing OODA system of systems in the organisation PROCESS PEOPLE CULTURE & PARADIGMS INFRASTRUCTURE “ CORPORATE MEMORY” INPUT ANALYSIS SYNTHESIS PEOPLE PEOPLE GENETIC HERITAGE DATA CONTENT LINKS RELATIONS ANNOTA- TIONS OBSERVE DECIDE, ACT DOCS RECORDS © William P. Hall
    8. 8. &quot;Living knowledge“ : source of organisational knowledge Vines, R., Hall, W.P., Naismith L. 2007. Exploring the foundations of organisational knowledge: An emergent synthesis grounded in thinking related to evolutionary biology . actKM Conference, Australian National University, Canberra, 23-24 October 2007.
    9. 9. Organisational disciplines creating & using knowledge <ul><li>research and development </li></ul><ul><li>business development </li></ul><ul><li>systems engineering </li></ul><ul><li>logistics support analysis (lifecycle management) </li></ul><ul><li>project management / project controls </li></ul><ul><li>contracting & procurement </li></ul><ul><li>design </li></ul><ul><li>systems integration </li></ul><ul><li>configuration management and eng. change control </li></ul><ul><li>production management </li></ul><ul><li>technical data and documentation management </li></ul><ul><li>QA/QC </li></ul><ul><li>test & trials </li></ul><ul><li>lifecycle support and maintenance </li></ul>
    10. 10. Systems and applications infrastructure recording and transmitting knowledge <ul><li>Tool areas </li></ul><ul><ul><li>design & drawing tools </li></ul></ul><ul><ul><li>simulation and modelling tools </li></ul></ul><ul><ul><li>databases </li></ul></ul><ul><ul><li>authoring and content management systems </li></ul></ul><ul><ul><li>configuration and change management </li></ul></ul><ul><ul><li>cost and schedule control systems </li></ul></ul><ul><ul><li>knowledge retrieval </li></ul></ul><ul><ul><li>correspondence and action management </li></ul></ul><ul><ul><li>Integration environments </li></ul></ul><ul><li>Enterprise resource planning/management </li></ul><ul><ul><li>product/program lifecycle management </li></ul></ul><ul><ul><li>information and knowledge retrieval </li></ul></ul><ul><ul><li>process automation tools </li></ul></ul><ul><li>Networking environments </li></ul><ul><ul><li>portals </li></ul></ul><ul><ul><li>correspondence and action tracking </li></ul></ul>
    11. 11. People issues <ul><li>recruitment </li></ul><ul><li>training and career development </li></ul><ul><li>facilitation and incentives </li></ul><ul><li>networking and community building </li></ul><ul><li>registering and finding skills </li></ul><ul><li>mapping and tracking knowledge </li></ul><ul><li>sharing and transferring knowledge </li></ul><ul><li>making decisions </li></ul><ul><li>organisational culture </li></ul><ul><li>etc. </li></ul><ul><li>ORGANISATIONAL CULTURE </li></ul><ul><li>“ Organizational culture refers to the basic values, norms, beliefs, and practices that characterize the functioning of a particular institution. At the most basic level, organizational culture defines the assumptions that employees make as they carry out their work; it defines ‘the way we do things here.’ An organization’s culture is a powerful force that persists through reorganizations and the departure of key personnel.” </li></ul><ul><li>http://anon.nasa-global.speedera.net/anon.nasa-global/CAIB/CAIB_lowres_chapter5.pdf </li></ul>
    12. 12. Limits to knowledge and organisation <ul><li>Rationality in making decisions (key part of OODA loop) </li></ul><ul><ul><li>“ A decision making effort that exhausts all potentially relevant [knowledge] in order to make decisions in a transparently logical and objective fashion .” ( Else 2004 ) </li></ul></ul><ul><li>Organisations and people have limited capability (subsystem laws) </li></ul><ul><ul><li>Bounded rationality ( Simon 1957). Models of Man </li></ul></ul><ul><ul><li>Limits on decision making caused by limits on costs, human abilities, time, technology, and availability of [knowledge]. </li></ul></ul><ul><li>Boundaryless Careers - Arthur & Rousseau (1996) </li></ul><ul><ul><li>People belonging to organisations are not owned by them </li></ul></ul><ul><ul><li>People have careers outside of any one organisation </li></ul></ul><ul><li>Limits of Organisation - Arrow (1974 - see Else 2004 ) </li></ul><ul><ul><li>As limited by bounded rationality of individual people </li></ul></ul><ul><ul><li>As limited by organisational structure, governance, etc </li></ul></ul>
    13. 13. Process issues (all involve people) <ul><li>overall project management </li></ul><ul><li>qualification and bidding </li></ul><ul><li>simulation and modelling </li></ul><ul><li>design and stage reviews </li></ul><ul><li>change management </li></ul><ul><li>problem management </li></ul><ul><li>document authoring, production and publishing </li></ul><ul><li>test and trial </li></ul><ul><li>technical regulatory frameworks </li></ul><ul><li>etc. </li></ul>
    14. 14. Infrastructure issues <ul><li>business analysis </li></ul><ul><li>personal productivity tools </li></ul><ul><li>product data, configuration and change management </li></ul><ul><li>CAD, text authoring and simulation systems </li></ul><ul><li>workflow enactment </li></ul><ul><li>planning and control </li></ul><ul><li>production management and tracking </li></ul><ul><li>audit </li></ul><ul><li>product engineering and maintenance support </li></ul>
    15. 15. Learning from our mistakes <ul><li>Introduction to Part II of the Columbia Accident Investigation Board Report: “ Many accident investigations do not go far enough. They identify the technical cause of the accident, and then connect it to a variant of “operator error” – the line worker who forgot to insert the bolt, the engineer who miscalculated the stress, or the manager who made the wrong decision. But this is seldom the entire issue . When the determinations of the causal chain are limited to the technical flaw and individual failure, typically the actions taken to prevent a similar event in the future are also limited: fix the technical problem and replace or retrain the individual responsible. Putting these corrections in place leads to another mistake – the belief that the problem is solved.” http://history.nasa.gov/columbia/CAIB.html </li></ul>
    16. 16. Why do engineers need to manage knowledge? <ul><li>What can go wrong? (most boil down to KM failures) </li></ul><ul><ul><li>For example: (Wikipedia is a good place to start) </li></ul></ul><ul><ul><ul><li>1984 Bhophal insecticide plant (India) - many thousands killed </li></ul></ul></ul><ul><ul><ul><li>1986 Chernobyl nuclear power plant explosion - hundreds killed </li></ul></ul></ul><ul><ul><ul><li>1988 Piper Alpha - 167 killed </li></ul></ul></ul><ul><ul><ul><li>1981 Kansas City Hyatt Regency Hotel Walkway Collapse - 114 killed ( see also ) </li></ul></ul></ul><ul><ul><ul><li>2001 Petrobras P36 Offshore Oil Platform Sinking - 11 killed </li></ul></ul></ul><ul><ul><ul><li>2003 Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for debris) </li></ul></ul></ul><ul><ul><li>Closer to home </li></ul></ul><ul><ul><ul><li>1970 Westgate Bridge - 35 killed, many injured </li></ul></ul></ul><ul><ul><ul><li>1998 HMAS Westralia - 4 killed </li></ul></ul></ul><ul><ul><ul><li>1998 Longford gas plant - 2 killed ( see also ) </li></ul></ul></ul><ul><ul><ul><li>2005 Sea King Helo Nias Island - 9 killed </li></ul></ul></ul>Sections from Westgate Bridge at Monash Uni's department of Civil Engineering, Clayton
    17. 17. Why do engineers need to manage knowledge? <ul><li>And then there are the economic failures! </li></ul><ul><ul><li>Cost overruns </li></ul></ul><ul><ul><li>Schedule blowouts </li></ul></ul><ul><ul><li>Legal actions </li></ul></ul><ul><ul><li>Reputational damages </li></ul></ul><ul><ul><li>Again, most could be avoided by better KM </li></ul></ul><ul><li>Auditor's reports provide good examples </li></ul><ul><ul><li>Australian National Audit Office see especially: </li></ul></ul><ul><ul><ul><li>Management of the M113 APC Upgrade Project </li></ul></ul></ul><ul><ul><ul><li>Amphibious Transport Ship Project </li></ul></ul></ul><ul><ul><ul><li>Management of Major Equipment Acquisition Projects </li></ul></ul></ul><ul><ul><ul><li>New Submarine Project </li></ul></ul></ul><ul><ul><ul><li>Jindalee Operational Radar Network </li></ul></ul></ul>
    18. 18. The Challenger disaster <ul><li>Challenger disintegrated during the boost phase on January 28, 1986 </li></ul><ul><li>7 crew were killed when the shuttle assemblage disintegrated as the result of a flame leak in the right Solid Rocket Booster (SRB) </li></ul><ul><li>SRBs are 149 feet long and formed by joining 4 main sections. Two rubber O-rings in the SRB joints are supposed to stop leakage of hot gasses. </li></ul><ul><li>It was known for several years that the O-rings were suffering burn damage, but managers believed that the second O-ring would stop fire leakage. </li></ul>
    19. 19. The Challenger Disaster <ul><li>Rubber becomes stiffer the colder it gets. </li></ul><ul><li>The launch was decided in the coldest weather ever. </li></ul><ul><li>Engineers warned of the danger of leakage through cold seals, but were bypassed. </li></ul>
    20. 20. The Challenger Disaster <ul><li>On launch, the cold, stiff O-rings to failed to seal in the lower joint of the right SRB. At liftoff, black smoke escaped from the joint, suggesting the O-rings were burning. The smoke stopped after about 2 seconds into the flight, when aluminium soot from the burning fuel apparently blocked the leak. </li></ul><ul><li>At T+40 seconds, the shuttle was hit by strong wind shear. This was no danger to the shuttle itself, but stresses may have broken the soot blockage. </li></ul><ul><li>By T+59 seconds, a plume of flame from the leak burned a hole in the external fuel tank (ET), storing liquid hydrogen and oxygen. </li></ul><ul><li>At about T+73 seconds, the plume burned away the lower strut that attached the SRB to the ET. </li></ul><ul><li>The SRB swung around and the nose slammed into the ET, causing liquid oxygen to spill out. Then the plume caused the dome on the bottom of the external tank to fail. This released thousands of gallons of liquid hydrogen. The ET is pressurized so the fuel will flow into the orbiter's main engines, so the fuel acted like a rocket motor, adding nearly 3 million pounds of thrust to the shuttle. This extra thrust was more than the ET could stand, and it broke apart. Aerodynamic stresses caused the shuttle itself to break up </li></ul>
    21. 21. The Challenger Disaster <ul><li>Primary reference - Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger Accident June 6th, 1986; </li></ul><ul><li>Brief on the physical failure ; </li></ul><ul><li>See also: Mahal, 1995 - The space shuttle Challenger accident </li></ul><ul><li>Primary reference - Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger Accident June 6th, 1986; </li></ul><ul><li>Brief on the physical failure ; </li></ul><ul><li>See also: Mahal, 1995 - The space shuttle Challenger accident </li></ul>
    22. 22. Challenger: crucial management decisions <ul><li>Boisjoly, R.M. 1980. Ethical decisions – Morton Thiokol and the Space Shuttle Challenger disaster . </li></ul>When Joe Kilminster of MTI was asked by Larry Mulloy of NASA for his launch decision. Jue responded the he did not recommend launching based upon the engineering position just presented. Then Larry Mulloy asked George Hardy of NASA for his launch decision. George responded that he was appalled at Thiokol's recommendation but said he would not launch over the contractor's objection. Then Larry Mulloy spent some time giving his views and interpretation of the data that was presented with his conclusion that the data presented was inconclusive. … NASA'S very nature since early space flight was to force contractors and themselves to prove that it was safe to fly. The statement by Larry MulIoy about our data being inconclusive should have been enough all by itself to stop the launch according to NASA'S own rules, but we all know that was not the case. Just as Larry Mulloy gave his conclusion, Joe Kilminster asked for a five-minute, off-line caucus to re-evaluate the data and as soon as the mute button was pushed, our General Manager, Jerry Mason, said in a soft voice, &quot;We have to make a management decision.“… Erosion in an exhaust nozzle O-ring comparable to the field joint O-rings
    23. 23. Challenger: crucial management decisions At the end of the discussion, Mason turned to Bob Lund, Vice President of Engineering at MTI, and told him to take off his engineering hat and to put on his management hat. The vote poll was taken by only the four senior executives present since the engineers were excluded from both the final discussion with management and the vote poll …. What is everyone's professional responsibility and ethical conduct code which should be practiced in the work place? The following advice was given by Mr. Adolph J. Ackerman in June, 1967, in an article published by the IEEE. I firmly believe that his advice is timeless and applies to all generations in engineering. Mr. Ackerman said, 'Engineers have a responsibility that goes far beyond the building of machines and systems. We cannot leave it to the technical illiterates, or even to literate and overloaded technical administrators to decide what is safe and for the public good. We must tell what we know, first through normal administrative channels, but when these fail, through whatever avenues we can find. Many claim that it is disloyal to protest. Sometimes the penalty disapproval, loss of status, even vilification--can be severe. Today we need more critical pronouncements and published declarations by engineers in high professional responsibilities. In some instances, such criticism must be severe if we are properly to serve mankind and preserve our freedom. Hence it is of the utmost importance that we maintain our freedom of communication in the engineering profession and to the public. The decades ahead are bound to be a critical and difficult period and there will be occasions for sharp dissent and strong words if we are to meet our responsibilities.&quot;
    24. 24. Challenger: summary of organisational issues <ul><li>Source: http://www.tech.plym.ac.uk/sme/Interactive_Resources/tutorials/FailureCases/hs1.html </li></ul><ul><li>The Group Decision Support System (GDSS) … had the following failures: </li></ul><ul><ul><li>The seal ring database was known to be flawed. Ideas, suggestions and objections were solicited, but not anonymously. Individuals who departed from ‘accepted wisdom’ were flagged as unwelcome members of the GDSS. </li></ul></ul><ul><ul><li>An agenda was never defined, hence NASA were surprised by the Thiokol O-ring presentation and ‘appalled’ by their decision not to launch. </li></ul></ul><ul><ul><li>Conflict management was avoided by NASA’s domination of the meeting, and hence conflict was not satisfactorily resolved. </li></ul></ul><ul><ul><li>The GDSS setting was inappropriate for such an important decision. A face-face meeting would have allowed visual signals to play a role and the unhappiness of the Thiokol engineering representatives would have been apparent. </li></ul></ul><ul><ul><li>Thiokol should not have requested a 5 minute disconnection from the GDSS. This allowed other internal pressures to dominate their (undemocratic) decision. </li></ul></ul><ul><ul><li>The GDSS put safety last and operational goals first. Note that shuttle crew were not represented at the meeting, although they had the most to lose. </li></ul></ul><ul><li>Design Failures: </li></ul><ul><ul><li>The design of the solid booster joint was insufficiently robust to cope with the effects of re-usability, low temperature O-ring compression response, and movement during acceleration and wing turbulence. </li></ul></ul><ul><ul><li>Lack of a safety culture which would put crew safety ahead of operational goals. </li></ul></ul><ul><ul><li>A flawed ‘group decision support system’. </li></ul></ul>
    25. 25. EPMO: engineering project management org <ul><li>Successful $ 7 BN technologically complex and knowledge intense shipbuilding project </li></ul><ul><ul><li>10 similar ships for two customers </li></ul></ul><ul><ul><li>Fixed price contract negotiated 17½ years previously </li></ul></ul><ul><ul><li>Managed ~20 subcontracts worth more than $100 M ea </li></ul></ul><ul><ul><li>Finished </li></ul></ul><ul><ul><ul><li>On time </li></ul></ul></ul><ul><ul><ul><li>On budget (with escalation clauses to cover currency fluctuations, labour rates, raw materials) </li></ul></ul></ul><ul><ul><ul><li>Happy customers </li></ul></ul></ul><ul><ul><li>Profitable “cash-cow” allowed company to acquire several new divisions </li></ul></ul>
    26. 26. EPMO: Follow-on project <ul><li>$ 500 M fixed price follow-on project </li></ul><ul><ul><li>Three year project </li></ul></ul><ul><ul><li>Built to “commercial” standards </li></ul></ul><ul><ul><li>Seven ships constituting three quite different types for one customer </li></ul></ul><ul><ul><li>Finishing way over budget </li></ul></ul><ul><ul><li>First ship delivered 6 months late, others all behind schedule </li></ul></ul><ul><li>Big losses led company owners to hold a “fire sale” auction </li></ul><ul><ul><li>Multi-billion dollar order book </li></ul></ul><ul><ul><li>Pre auction estimate was that company was worth $A 1 BN </li></ul></ul><ul><ul><li>Sold in January 2008 for ~$A 775 M </li></ul></ul><ul><ul><li>Cost to owners thus on the order of $A 225 M! </li></ul></ul>
    27. 27. EPMO Background <ul><li>Company/management characteristics </li></ul><ul><ul><li>Family owned </li></ul></ul><ul><ul><li>Distributed work </li></ul></ul><ul><ul><li>“ Absentee” senior executives (different state from where work done) </li></ul></ul><ul><ul><li>Deep line management hierarchy </li></ul></ul><ul><ul><li>Command and control philosophy – don’t disagree with boss </li></ul></ul><ul><ul><li>Execs & line managers didn’t understand IT (i.e., pencil & paper people) </li></ul></ul><ul><ul><li>Managers sacked for errors & “mistakes” </li></ul></ul><ul><ul><li>Hence, high turn-over of senior line managers (2-3 yr cycle) </li></ul></ul><ul><li>Aspects of successful project </li></ul><ul><ul><li>Stable, conscientious work force – many with 10 and 20 year pins </li></ul></ul><ul><ul><li>Long duration, with significant serial production facilitated org learning </li></ul></ul><ul><ul><li>Costly problems in design and early production stages </li></ul></ul><ul><ul><ul><li>Difficulties/delay getting IP and technical data for engineering and support </li></ul></ul></ul><ul><ul><ul><li>Engineering configuration management and change control </li></ul></ul></ul><ul><ul><ul><li>Difficulties delivering coherent technical data and documentation to client </li></ul></ul></ul><ul><ul><li>Cost-effective solutions found and built into processes and practices </li></ul></ul><ul><ul><ul><li>Executives did not direct and were probably unaware of solutions </li></ul></ul></ul><ul><ul><ul><li>Solutions requiring investment often suffered inordinate approval delays </li></ul></ul></ul><ul><ul><ul><li>Some critical solutions funded by subterfuge from current operating budgets </li></ul></ul></ul><ul><ul><li>Solutions + effective IT significantly reduced costs. </li></ul></ul>
    28. 28. EPMO Background – cont. <ul><li>Finishing the successful project </li></ul><ul><ul><li>Owners hired overseas “close-out” specialist as divisional EGM </li></ul></ul><ul><ul><ul><li>Bonus based on added profit squeezed from old project </li></ul></ul></ul><ul><ul><ul><li>Line managers only knew smooth running serial production </li></ul></ul></ul><ul><ul><ul><li>Implemented strict time-costing to the half hour </li></ul></ul></ul><ul><ul><ul><li>All time required to be allocated to project line item cost code </li></ul></ul></ul><ul><ul><ul><li>Costly staff quickly made redundant when no longer needed for project </li></ul></ul></ul><ul><ul><ul><li>EGM approval required for “outsiders” to meet project staff </li></ul></ul></ul><ul><ul><ul><li>Morale became very poor </li></ul></ul></ul><ul><li>Follow-on project </li></ul><ul><ul><li>3 year fixed-price project </li></ul></ul><ul><ul><li>Assumed to be “commercial” work </li></ul></ul><ul><ul><li>Limited opportunities for serial production </li></ul></ul><ul><ul><li>Costing assumed existing efficiencies would transfer to follow-on with less technology & control </li></ul></ul><ul><ul><li>Started before successful project finished </li></ul></ul><ul><ul><li>New (cheaper) people were hired </li></ul></ul><ul><ul><li>Few had experience with naval projects </li></ul></ul><ul><ul><li>A security fence was built between the projects </li></ul></ul>
    29. 29. EPMO failed to transfer organisational knowledge <ul><li>Knowledge management expertise located in “rump” head office </li></ul><ul><ul><li>R&D manager, Chief Engineer, Snr Systems Engineer, KM analyst, 2 PhD students as KM Interns </li></ul></ul><ul><ul><li>Verbal support from GM Engineering who lacked enforcement power </li></ul></ul><ul><ul><li>KM funding only for analyst salary (i.e., no budget, no travel) </li></ul></ul><ul><ul><li>Advisory only (no power to implement anything) </li></ul></ul><ul><li>As the new project was being negotiated </li></ul><ul><ul><li>New hires knew theory but lacked experience in naval engineering programs </li></ul></ul><ul><ul><li>Methods for mapping knowledge in the old project were developed & successfully prototyped by people in Group/Division Head Office </li></ul></ul><ul><ul><ul><li>KM R&D Team: Analyst, KM Intern, Risk Manager/Project Controller, Jr Systems Engineer, Special Projects Manager </li></ul></ul></ul><ul><ul><ul><li>Prototype proved old hands would happily share experience and “war stories” </li></ul></ul></ul><ul><ul><ul><li>Analysis and prototype validated and published as a peer reviewed paper </li></ul></ul></ul><ul><ul><li>Three formal attempts to implement knowledge mapping/transfer program </li></ul></ul><ul><ul><ul><li>Pre-negotiation stage – first prototype by KM analyst & Risk Manager - knocked back by Production Manager </li></ul></ul></ul><ul><ul><ul><li>Early negotiations – proposal additionally supported by availability of PhD student to manage interview & mapping process & systems engineer to develop software – knocked back by line managers </li></ul></ul></ul><ul><ul><ul><li>Project mobilisation – proposal additionally adopted by Special Project Manager responsible for IT implementation – same result. </li></ul></ul></ul><ul><ul><ul><li>Line management blocked access to both new hires and old hands as “time wasting” </li></ul></ul></ul>
    30. 30. EPMO: The importance of people and culture <ul><li>Example: board spent $ M to implement corporate portal </li></ul><ul><ul><li>Hired outside contractor to select system </li></ul></ul><ul><ul><li>Did not consult staff to understand what was needed </li></ul></ul><ul><ul><li>Would not pay for additional modules to make it work </li></ul></ul><ul><ul><li>Would not fund support staff </li></ul></ul><ul><ul><ul><li>To develop processes </li></ul></ul></ul><ul><ul><ul><li>To develop taxonomies </li></ul></ul></ul><ul><ul><ul><li>To provide more than minimal training </li></ul></ul></ul><ul><li>Fundamental issues for the technology organisation </li></ul><ul><ul><li>Living knowledge is intangible and is produced and used by people </li></ul></ul><ul><ul><li>Old style engineers understand tangible technology well, processes moderately well, people not at all </li></ul></ul><ul><ul><ul><li>Can understand technology proposals and will pay to implement it </li></ul></ul></ul><ul><ul><ul><li>Do not understand people, cannot follow value arguments about people and culture, and will not approve what they do not understand </li></ul></ul></ul><ul><ul><li>Finance and admin people, can identify the cost of everything but cannot compute the value of knowledge developed by people and processes. </li></ul></ul><ul><li>Managing technological enterprises is mostly about managing people and knowledge </li></ul><ul><li>Failing to understand manage people and organisational culture can kill people & destroy organisations. </li></ul>
    31. 31. HMAS Westralia fire <ul><li>Westralia is an RAN fleet oiler </li></ul><ul><li>Flexible fuel line burst spraying oil on hot engine manifold </li></ul><ul><li>Four Naval personnel died in fire </li></ul><ul><li>The entire ship was close to being lost </li></ul><ul><li>Out of commission for more than a year </li></ul>
    32. 32. HMAS Westralia fire – summary of findings <ul><li>Westralia Board of Inquiry </li></ul><ul><ul><li>71. The fire in HMAS WESTRALIA on 5 May 1998 was caused by diesel fuel from a burst flexible hose spraying onto a hot engine component and then igniting. The hose was one of a number of new flexible hoses supplied by the ship’s support contractor, ADI Limited, to replace the original rigid pipes. In the Board’s view, the hoses were not properly designed and were unfit for the intended purpose. </li></ul></ul><ul><ul><li>72. A change of this type should have been processed through the RAN configuration change process as well as being approved by the ship’s classification society, Lloyds Register. Both processes were bypassed, largely as a result of ignorance and incompetence. Key personnel within the RAN, and more particularly ADI Limited, were not adequately trained or qualified for the responsibilities placed on them. Regardless of the scrutiny that was avoided by bypassing these approval processes, ADI Limited should have taken steps to ensure that a safe, properly engineered product was supplied for a demanding application; it demonstrably failed to do so. </li></ul></ul><ul><ul><li>73. The four personnel who died in the fire did so as a result of acute carbon monoxide toxicity consequent upon inhalation of fire fumes. </li></ul></ul>
    33. 33. HMAS Westralia fire – summary of findings <ul><li>The mistakes ( Coroner’s Report ) </li></ul><ul><ul><li>No notice taken of manufacturer’s advice on appropriate replacement for leaking metal fuel pipes </li></ul></ul><ul><ul><li>Application made in 1996 to replace leaking fuel pipes not acted on </li></ul></ul><ul><ul><li>TM200 engineering change procedure used instead of correct TM187 </li></ul></ul><ul><ul><li>Lloyds certification requirements not complied with </li></ul></ul><ul><ul><li>Contract not adequately monitored </li></ul></ul><ul><ul><li>Warrant officer not adequately skilled to manage contract </li></ul></ul><ul><ul><li>Supplier not adequately trained </li></ul></ul><ul><ul><li>Support contractor failed to recognise that the TM200 request was a configuration change and did not take appropriate action to investigate </li></ul></ul><ul><ul><li>Support contractor failed to monitor supplier or ensure compliance with Lloyds certification requirements </li></ul></ul><ul><li>Discuss </li></ul>
    34. 34. Why do engineers need to manage knowledge? <ul><li>What can go wrong? (most boil down to KM failures) </li></ul><ul><ul><li>For example: (Wikipedia is a good place to start) </li></ul></ul><ul><ul><ul><li>1984 Bhophal insecticide plant (India) - many thousands killed </li></ul></ul></ul><ul><ul><ul><li>1986 Chernobyl nuclear power plant explosion - hundreds killed </li></ul></ul></ul><ul><ul><ul><li>1988 Piper Alpha - 167 killed </li></ul></ul></ul><ul><ul><ul><li>1981 Kansas City Hyatt Regency Hotel Walkway Collapse - 114 killed ( see also ) </li></ul></ul></ul><ul><ul><ul><li>2001 Petrobras P36 Offshore Oil Platform Sinking - 11 killed </li></ul></ul></ul><ul><ul><ul><li>2003 Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for debris) </li></ul></ul></ul><ul><ul><li>Closer to home </li></ul></ul><ul><ul><ul><li>1970 Westgate Bridge - 35 killed, many injured </li></ul></ul></ul><ul><ul><ul><li>1998 HMAS Westralia - 4 killed </li></ul></ul></ul><ul><ul><ul><li>1998 Longford gas plant - 2 killed ( see also ) </li></ul></ul></ul><ul><ul><ul><li>2005 Sea King Helo Nias Island - 9 killed </li></ul></ul></ul>Sections from Westgate Bridge at Monash Uni's department of Civil Engineering, Clayton <ul><li>What can go wrong? (most boil down to KM failures) </li></ul><ul><ul><li>For example: (Wikipedia is a good place to start) </li></ul></ul><ul><ul><ul><li>1984 Bhophal insecticide plant (India) - many thousands killed </li></ul></ul></ul><ul><ul><ul><li>1986 Chernobyl nuclear power plant explosion - hundreds killed </li></ul></ul></ul><ul><ul><ul><li>1988 Piper Alpha - 167 killed </li></ul></ul></ul><ul><ul><ul><li>1981 Kansas City Hyatt Regency Hotel Walkway Collapse - 114 killed ( see also ) </li></ul></ul></ul><ul><ul><ul><li>2001 Petrobras P36 Offshore Oil Platform Sinking - 11 killed </li></ul></ul></ul><ul><ul><ul><li>2003 Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for debris) </li></ul></ul></ul><ul><ul><li>Closer to home </li></ul></ul><ul><ul><ul><li>1970 Westgate Bridge - 35 killed, many injured </li></ul></ul></ul><ul><ul><ul><li>1998 HMAS Westralia - 4 killed </li></ul></ul></ul><ul><ul><ul><li>1998 Longford gas plant - 2 killed ( see also ) </li></ul></ul></ul><ul><ul><ul><li>2005 Sea King Helo Nias Island - 9 killed </li></ul></ul></ul>
    35. 35. Why do engineers need to manage knowledge? <ul><li>And then there are the economic failures! </li></ul><ul><ul><li>Cost overruns </li></ul></ul><ul><ul><li>Schedule blowouts </li></ul></ul><ul><ul><li>Legal actions </li></ul></ul><ul><ul><li>Reputational damages </li></ul></ul><ul><ul><li>Again, most could be avoided by better KM </li></ul></ul><ul><li>Auditor's reports provide good examples </li></ul><ul><ul><li>Australian National Audit Office see especially: </li></ul></ul><ul><ul><ul><li>Management of the M113 APC Upgrade Project </li></ul></ul></ul><ul><ul><ul><li>Amphibious Transport Ship Project </li></ul></ul></ul><ul><ul><ul><li>Management of Major Equipment Acquisition Projects </li></ul></ul></ul><ul><ul><ul><li>New Submarine Project </li></ul></ul></ul><ul><ul><ul><li>Jindalee Operational Radar Network </li></ul></ul></ul>

    ×