421 672 Management Of Technological Enterprises(2008 Tutorial 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.
3.
4.
5.
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
8. "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.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
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."
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
Editor's Notes
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&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's failure to provide appropriate documentation & 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'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'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't exist for Longford.) Explicitly documented knowledge is useless if it sits on a shelf and isn't readily accessed when and where decisions need to be made. (Westralia?? Sensible procedural documentation existed . Why wasn'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'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. "Faster, better, cheaper" - 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.