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 Organizationshttp://www.orgs-evolution-knowledge.net

Documentation and KM Systems Analyst (retired)Tenix Group Head Office, Williamstown, Vic.(retired July 2007)

National FellowAustralian Centre for Science, Innovation and SocietyMelbourne UniversityUni Office: ICT 5.59, 111 Barry St., CarltonPhone: +61 3 8344 1530 (Mon, Tue, Thurs only)Email: bhall-u@dis.unimelb.edu.au

TUTORIAL: 20 March 2009

Why is knowledge important to the enterprise?

Tech enterprises and engineering products are knowledge intensive– to design– to manufacture– to operate

Engineering processes and products are fallible!Organisations are complex dynamic systems

– Difference between complex and complicated• Organisations have minds of their own (my research area)• Cannot be predicted, can only be constrained

– Depend on "system of systems" to manage knowledge– System of systems components include

• People• Processes• Infrastructure technology

KM systems in the high-tech enterprise

PeopleProcessTechnology

infrastructure

Peop

le

Pro

cess

Infra

stru

ctu

re

Organizational knowledge

Leave one of the legs off, and the stool will fall over

Adequate performance on all issues depends on the quality of authoring, management and transfer of technical knowledge from supplier to operators

Organisational knowledge management imperatives

Capability when it is needed– Reliably does what it is supposed to– Available for service when needed– Maintainable - problems can be fixed when they arise – Supportable - critical needs available in supply chain – Operable within limits of human knowledge & capacity

Health, safety and operational knowledge issues– Heavy/complex engineered products can kill!

Life-cycle cost– Minimise acquisition cost– Minimise documentation, support & maintenance costs– Implement "lean maintenance" philosophy

Major quality issues in delivering product operational and support knowledge

Knowledge delivery goals (only people apply knowledge)– Correct

• Correct information• Consistent across the organisation

– Applicable/Effective• “Applicable” to the location of use• “Effective” for the time of use re engineering changes, etc.

– Available!• Accessible to those who need it, when and where it is needed

– Useable• Readily understandable by humans• Readily managed & processed in computer systems

Enterprise knowledge production and usage goals– Fast– High quality– Low cost

Objective knowledge development lifecycle for a large project

Project ADesign Study

Review, edit, signoff

Negotiate

Review, negotiate, amend

Project APrime Contract

RFT and Bid

Review, edit, signoff

Project ABid Documents

RFQs

BidsNegotiations

Project ASubcontracts

Review,negotiate, amend

Project AProcedures,Design Docs

Review,edit,

signoff

Project ASupport Documents

•20 - 50 year lifecycle

Project BDesign Study

Review, edit, signoff

Project BDesign Study

Review, edit, signoff

Project BDesign Study

Review, edit, signoff

Operationalexperience

PROCESS

PEOPLE

Implementing OODA system of systems in the organisation

CULTURE & PARADIGMS

INFRASTRUCTURE

“CORPORATE MEMORY”

INPUT

ANALYSIS SYNTHESIS

PEOPLEPEOPLE

GENETIC HERITAGE

DATA CONTENTLINKS

RELATIONSANNOTA-

TIONS

OBSERVE DECIDE, ACT

DOCS RECORDS

© William P. Hall

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.

"Living knowledge“: source of organisational knowledge

Organisational disciplines creating & using knowledge

research and development business development systems engineering logistics support analysis (lifecycle management) project management / project controls contracting & procurement design systems integration configuration management and eng. change control production management technical data and documentation management QA/QC test & trials lifecycle support and maintenance

Systems and applications infrastructure recording and transmitting knowledge

Tool areas– design & drawing tools– simulation and modelling tools– databases– authoring and content management systems– configuration and change management– cost and schedule control systems– knowledge retrieval– correspondence and action management– Integration environments

Enterprise resource planning/management– product/program lifecycle management– information and knowledge retrieval– process automation tools

Networking environments– portals– correspondence and action tracking

People issues

recruitment training and career development facilitation and incentives networking and community building registering and finding skills mapping and tracking knowledge sharing and transferring knowledge making decisions organisational culture etc.

ORGANISATIONAL CULTURE

“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.”

http://anon.nasa-global.speedera.net/anon.nasa-global/CAIB/CAIB_lowres_chapter5.pdf

Limits to knowledge and organisation

Rationality in making decisions (key part of OODA loop)“A decision making effort that exhausts all potentially relevant [knowledge] in order to make decisions in a transparently logical and objective fashion.” (Else 2004)

Organisations and people have limited capability (subsystem laws)

– Bounded rationality (Simon 1957). Models of Man Limits on decision making caused by limits on costs, human abilities, time, technology, and availability of [knowledge].

Boundaryless Careers - Arthur & Rousseau (1996)– People belonging to organisations are not owned by them– People have careers outside of any one organisation

Limits of Organisation - Arrow (1974 - see Else 2004)– As limited by bounded rationality of individual people– As limited by organisational structure, governance, etc

Process issues (all involve people)

overall project managementqualification and biddingsimulation and modellingdesign and stage reviewschange managementproblem managementdocument authoring, production and

publishingtest and trialtechnical regulatory frameworksetc.

Infrastructure issues

business analysispersonal productivity toolsproduct data, configuration and change

managementCAD, text authoring and simulation systemsworkflow enactmentplanning and controlproduction management and trackingauditproduct engineering and maintenance support

Learning from our mistakes

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

Why do engineers need to manage knowledge?

Sections from Westgate Bridge at Monash Uni's department of Civil Engineering, Clayton

What can go wrong? (most boil down to KM failures)– For example: (Wikipedia is a good place to start)

• 1984 Bhophal insecticide plant (India) - many thousands killed• 1986 Chernobyl nuclear power plant explosion - hundreds killed• 1988 Piper Alpha - 167 killed• 1981 Kansas City Hyatt Regency Hotel Walkway Collapse - 114 killed (see also)• 2001 Petrobras P36 Offshore Oil Platform Sinking - 11 killed• 2003 Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for

debris)

– Closer to home• 1970 Westgate Bridge - 35 killed, many injured• 1998 HMAS Westralia - 4 killed• 1998 Longford gas plant - 2 killed (see also)• 2005 Sea King Helo Nias Island - 9 killed

Why do engineers need to manage knowledge?

And then there are the economic failures!– Cost overruns– Schedule blowouts– Legal actions– Reputational damages– Again, most could be avoided by better KM

Auditor's reports provide good examples– Australian National Audit Office see especially:

• Management of the M113 APC Upgrade Project• Amphibious Transport Ship Project• Management of Major Equipment Acquisition Projects • New Submarine Project• Jindalee Operational Radar Network

The Challenger disaster

Challenger disintegrated during the boost phase on January 28, 1986

7 crew were killed when the shuttle assemblage disintegrated as the result of a flame leak in the right Solid Rocket Booster (SRB)

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.

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.

The Challenger Disaster

Rubber becomes stiffer the colder it gets. The launch was decided in the coldest weather ever. Engineers warned of the danger of leakage through cold seals,

but were bypassed.

The Challenger Disaster

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.

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.

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.

At about T+73 seconds, the plume burned away the lower strut that attached the SRB to the ET.

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

The Challenger Disaster

Primary reference - Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger Accident June 6th, 1986;

Brief on the physical failure; See also: Mahal, 1995 - The space shuttle Challenger accident

Primary reference - Report of the PRESIDENTIAL COMMISSION on the Space Shuttle Challenger Accident June 6th, 1986;

Brief on the physical failure; See also: Mahal, 1995 - The space shuttle Challenger accident

Challenger: crucial management decisions

Boisjoly, R.M. 1980. Ethical decisions – Morton Thiokol and the Space Shuttle Challenger disaster.

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, "We have to make a management decision.“…Erosion in an exhaust nozzle O-ring comparable to the field joint O-rings

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."

Challenger: summary of organisational issues

Source: http://www.tech.plym.ac.uk/sme/Interactive_Resources/tutorials/FailureCases/hs1.html The Group Decision Support System (GDSS) … had the following

failures: – 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.

– An agenda was never defined, hence NASA were surprised by the Thiokol O-ring presentation and ‘appalled’ by their decision not to launch.

– Conflict management was avoided by NASA’s domination of the meeting, and hence conflict was not satisfactorily resolved.

– 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.

– Thiokol should not have requested a 5 minute disconnection from the GDSS. This allowed other internal pressures to dominate their (undemocratic) decision.

– 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.

Design Failures: – 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.

– Lack of a safety culture which would put crew safety ahead of operational goals.

– A flawed ‘group decision support system’.

EPMO: engineering project management org

Successful $ 7 BN technologically complex and knowledge intense shipbuilding project – 10 similar ships for two customers– Fixed price contract negotiated 17½ years previously– Managed ~20 subcontracts worth more than $100 M ea– Finished

• On time• On budget (with escalation clauses to cover currency fluctuations, labour rates, raw

materials)• Happy customers

– Profitable “cash-cow” allowed company to acquire several new divisions

EPMO: Follow-on project

$ 500 M fixed price follow-on project– Three year project– Built to “commercial” standards– Seven ships constituting three quite different types for one customer– Finishing way over budget– First ship delivered 6 months late, others all behind schedule

Big losses led company owners to hold a “fire sale” auction– Multi-billion dollar order book– Pre auction estimate was that company was worth $A 1 BN– Sold in January 2008 for ~$A 775 M– Cost to owners thus on the order of $A 225 M!

EPMO Background

Company/management characteristics– Family owned– Distributed work– “Absentee” senior executives (different state from where work done)– Deep line management hierarchy– Command and control philosophy – don’t disagree with boss– Execs & line managers didn’t understand IT (i.e., pencil & paper

people)– Managers sacked for errors & “mistakes”– Hence, high turn-over of senior line managers (2-3 yr cycle)

Aspects of successful project– Stable, conscientious work force – many with 10 and 20 year pins– Long duration, with significant serial production facilitated org learning– Costly problems in design and early production stages

• Difficulties/delay getting IP and technical data for engineering and support • Engineering configuration management and change control• Difficulties delivering coherent technical data and documentation to client

– Cost-effective solutions found and built into processes and practices• Executives did not direct and were probably unaware of solutions• Solutions requiring investment often suffered inordinate approval delays• Some critical solutions funded by subterfuge from current operating

budgets– Solutions + effective IT significantly reduced costs.

EPMO Background – cont.

Finishing the successful project– Owners hired overseas “close-out” specialist as divisional EGM

• Bonus based on added profit squeezed from old project• Line managers only knew smooth running serial production• Implemented strict time-costing to the half hour• All time required to be allocated to project line item cost code• Costly staff quickly made redundant when no longer needed for project• EGM approval required for “outsiders” to meet project staff• Morale became very poor

Follow-on project– 3 year fixed-price project– Assumed to be “commercial” work– Limited opportunities for serial production– Costing assumed existing efficiencies would transfer to follow-on

with less technology & control– Started before successful project finished– New (cheaper) people were hired– Few had experience with naval projects– A security fence was built between the projects

EPMO failed to transfer organisational knowledge

Knowledge management expertise located in “rump” head office– R&D manager, Chief Engineer, Snr Systems Engineer, KM analyst, 2 PhD

students as KM Interns– Verbal support from GM Engineering who lacked enforcement power– KM funding only for analyst salary (i.e., no budget, no travel)– Advisory only (no power to implement anything)

As the new project was being negotiated– New hires knew theory but lacked experience in naval engineering programs– Methods for mapping knowledge in the old project were developed &

successfully prototyped by people in Group/Division Head Office• KM R&D Team: Analyst, KM Intern, Risk Manager/Project Controller, Jr Systems

Engineer, Special Projects Manager• Prototype proved old hands would happily share experience and “war stories”• Analysis and prototype validated and published as a peer reviewed paper

– Three formal attempts to implement knowledge mapping/transfer program• Pre-negotiation stage – first prototype by KM analyst & Risk Manager - knocked

back by Production Manager• 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

• Project mobilisation – proposal additionally adopted by Special Project Manager responsible for IT implementation – same result.

• Line management blocked access to both new hires and old hands as “time wasting”

EPMO: The importance of people and culture

Example: board spent $ M to implement corporate portal– Hired outside contractor to select system– Did not consult staff to understand what was needed– Would not pay for additional modules to make it work– Would not fund support staff

• To develop processes• To develop taxonomies• To provide more than minimal training

Fundamental issues for the technology organisation– Living knowledge is intangible and is produced and used by people– Old style engineers understand tangible technology well, processes

moderately well, people not at all• Can understand technology proposals and will pay to implement it• Do not understand people, cannot follow value arguments about people

and culture, and will not approve what they do not understand– Finance and admin people, can identify the cost of everything but

cannot compute the value of knowledge developed by people and processes.

Managing technological enterprises is mostly about managing people and knowledge

Failing to understand manage people and organisational culture can kill people & destroy organisations.

HMAS Westralia fire

Westralia is an RAN fleet oiler

Flexible fuel line burst spraying oil on hot engine manifold

Four Naval personnel died in fire

The entire ship was close to being lost

Out of commission for more than a year

HMAS Westralia fire – summary of findings

Westralia Board of Inquiry

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.

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.

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.

HMAS Westralia fire – summary of findings

The mistakes (Coroner’s Report)– No notice taken of manufacturer’s advice on appropriate

replacement for leaking metal fuel pipes– Application made in 1996 to replace leaking fuel pipes not

acted on– TM200 engineering change procedure used instead of

correct TM187– Lloyds certification requirements not complied with– Contract not adequately monitored– Warrant officer not adequately skilled to manage contract– Supplier not adequately trained– Support contractor failed to recognise that the TM200

request was a configuration change and did not take appropriate action to investigate

– Support contractor failed to monitor supplier or ensure compliance with Lloyds certification requirements

Discuss

Why do engineers need to manage knowledge?

Sections from Westgate Bridge at Monash Uni's department of Civil Engineering, Clayton

What can go wrong? (most boil down to KM failures)– For example: (Wikipedia is a good place to start)

• 1984 Bhophal insecticide plant (India) - many thousands killed• 1986 Chernobyl nuclear power plant explosion - hundreds killed• 1988 Piper Alpha - 167 killed• 1981 Kansas City Hyatt Regency Hotel Walkway Collapse - 114 killed (see also)• 2001 Petrobras P36 Offshore Oil Platform Sinking - 11 killed• 2003 Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for

debris)

– Closer to home• 1970 Westgate Bridge - 35 killed, many injured• 1998 HMAS Westralia - 4 killed• 1998 Longford gas plant - 2 killed (see also)• 2005 Sea King Helo Nias Island - 9 killed

What can go wrong? (most boil down to KM failures)– For example: (Wikipedia is a good place to start)

• 1984 Bhophal insecticide plant (India) - many thousands killed• 1986 Chernobyl nuclear power plant explosion - hundreds killed• 1988 Piper Alpha - 167 killed• 1981 Kansas City Hyatt Regency Hotel Walkway Collapse - 114 killed (see

also)• 2001 Petrobras P36 Offshore Oil Platform Sinking - 11 killed• 2003 Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for

debris)

– Closer to home• 1970 Westgate Bridge - 35 killed, many injured• 1998 HMAS Westralia - 4 killed• 1998 Longford gas plant - 2 killed (see also)• 2005 Sea King Helo Nias Island - 9 killed

Why do engineers need to manage knowledge?

And then there are the economic failures!– Cost overruns– Schedule blowouts– Legal actions– Reputational damages– Again, most could be avoided by better KM

Auditor's reports provide good examples– Australian National Audit Office see especially:

• Management of the M113 APC Upgrade Project• Amphibious Transport Ship Project• Management of Major Equipment Acquisition Projects • New Submarine Project• Jindalee Operational Radar Network