Transcript 421-672 Management of Technological Enterprises

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 protected]
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
Organizational knowledge
 People
 Process
 Technology
infrastructure
Leave one of the legs off, and the stool
will fall over
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
Adequate performance on all issues depends on the quality of
authoring, management and transfer of technical knowledge from
supplier to operators
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 A
Design Study
Project A
Bid Documents
Project A
Prime Contract
RFT and Bid
Negotiate
Review, negotiate, amend
Review, edit, signoff
Review, edit, signoff
RFQs
Project A
Procedures,
Design Docs
Bids
Negotiations
Project B
Project
Design
StudyB
Project
Design
StudyB
Design Study
Project A
Support Documents
Review, edit, signoff
Review, edit, signoff
Review, edit, signoff
Operational
experience
Review,
edit,
signoff
Review,
negotiate,
amend
Project A
Subcontracts
• 20 - 50 year lifecycle
Implementing OODA system of systems in the
organisation
CULTURE &
PARADIGMS
GENETIC HERITAGE
PEOPLE
PEOPLE
PEOPLE
ANALYSIS
SYNTHESIS
OBSERVE
PROCESS
INPUT
DECIDE, ACT
INFRASTRUCTURE
DOCS
RECORDS
DATA
CONTENT
LINKS
RELATIONS
ANNOTATIONS
“CORPORATE MEMORY”
© William P. Hall
"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, 2324 October 2007.
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 management
qualification and bidding
simulation and modelling
design and stage reviews
change management
problem management
document authoring, production and publishing
test and trial
technical regulatory frameworks
etc.
Infrastructure issues
 business analysis
 personal productivity tools
 product data, configuration and change
management
 CAD, text authoring and simulation systems
 workflow enactment
 planning and control
 production management and tracking
 audit
 product 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?
 What can go wrong? (most boil down to KM failures)
– For example: (Wikipedia is a good place to start)
•
•
•
•
•
•
1984
1986
1988
1981
2001
2003
Bhophal insecticide plant (India) - many thousands killed
Chernobyl nuclear power plant explosion - hundreds killed
Piper Alpha - 167 killed
Kansas City Hyatt Regency Hotel Walkway Collapse - 114 killed (see also)
Petrobras P36 Offshore Oil Platform Sinking - 11 killed
Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for debris)
– Closer to home
•
•
•
•
1970
1998
1998
2005
Westgate Bridge - 35 killed, many injured
HMAS Westralia - 4 killed
Longford gas plant - 2 killed (see also)
Sea King Helo Nias Island - 9 killed
Sections from Westgate Bridge at Monash Uni's department of
Civil Engineering, Clayton
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
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
–
–
–
–
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!
 Big losses led company owners to hold a “fire sale” auction
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?
 What can go wrong? (most boil down to KM failures)
– For example: (Wikipedia is a good place to start)
•
•
•
•
•
•
1984
1986
1988
1981
2001
2003
Bhophal insecticide plant (India) - many thousands killed
Chernobyl nuclear power plant explosion - hundreds killed
Piper Alpha - 167 killed
Kansas City Hyatt Regency Hotel Walkway Collapse - 114 killed (see also)
Petrobras P36 Offshore Oil Platform Sinking - 11 killed
Space Shuttle Columbia – 9 killed (7 onboard, 2 in the search for debris)
– Closer to home
•
•
•
•
1970
1998
1998
2005
Westgate Bridge - 35 killed, many injured
HMAS Westralia - 4 killed
Longford gas plant - 2 killed (see also)
Sea King Helo Nias Island - 9 killed
Sections from Westgate Bridge at Monash Uni's department of
Civil Engineering, Clayton
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