Developing Systems Engineering Capabilities within Businesses and Enterprises

initial copy and minor edit of relevant material from cahpter 7 of v0.25

Need to edit more, do citations and references and address comments etc.

Introduction

The pursuit of continuous improvement is a constant for many organsiaiton. See for Example (Morgan and liker, 2010) description of Toyota, (oppenheimer et al, 20010) lean principle of “pursue perfection”, and the Kotter principle of “don’t let up” drive a need for improvement. The ability to manage teams through their lifecycle - mobilize teams rapidly, establish and tailor an appropriate set of processes, metrics and systems engineering plans, support them to maintain a high level of performance, and capitalize acquired knowledge and redeploy the team members expeditiously as the team winds down - is a key organizational competence that has substantial leverage on project and organizational efficiency and effectiveness.

The business provides project teams with the necessary resource, background information, facilities, cash, support services, etc, and provides a physical, cultural and governance environment in which the projects and teams can be effective. So key functions of the parent organization include generating and maintaining relevant resources, allocating them to projects and teams, providing support and governance functions, maintaining expertise and knowledge (on process, application domain and solution technologies), securing the work in the first place, organizing finance, and maintaining the viability of the organization.

For improvements to really stick, they must reside in the organisation rather than the individuals, so the organsiaiton can endure and not depend on some specific “heroes”. This topic outlines the issues to be considered in organsiaitonal learning

Knowledge

There are two kinds of knowledge, explicit and tacit. Explicit knowledge can be written down or incorporated in computer codes, and can be treated as an asset. Much knowledge however is “tacit knowledge” that only exists within the heads of people, and in the context of relationships that people form with each other. So the ability of an organization to create value is critically dependent on the people it chooses to employ, what they know, how they work together, and how well they are organised and motivated to contribute to the organization’s purpose.

(Martin 2006) defines a “knowledge pyramid”, with signals at the bottom, then data, information, knowledge, and wisdom. In the knowledge pyramid, understanding increases as you ascend the pyramid. (Fasser & Brettner 2002) discuss knowledge management extensively, and emphasize the value of numerous mechanisms for informal knowledge transfer. They assert that “we may think that knowledge transfer is just an information technology issue, but in actuality, it is also a psychological, cultural, and managerial issue – in short a human issue”; ”without context, knowledge is just information”; and “only information in action can create knowledge”. This suggests that most so-called “knowledge management systems” actually just manage data and information. Knowledge management involves culture as well as technology.

A “learning organization” aims to absorb, diffuse, generate, and exploit knowledge (Sprenger and Have, 1996). Organizations need to manage formal information and facilitate the growth and exploitation of tacit knowledge. They should learn from experience and create a form of “corporate memory” – including process, problem domain and solution space knowledge, and information about existing products and services. (Fassner and Brettner 2002, pp 122-124) suggest that “shared mental models” are a key aspect of corporate knowledge and culture.

Organizations need to manage SE know-how, integration of SE with other organizational processes and activities, and knowledge of their business domain. Typical strategies include internal networks of SE leaders, experts, practitioners, reviewers, trainers, assessors; links from knowledge to organizational training and people development; and IT “Infostructure” to facilitate distributed working and cross-site collaboration. The INCOSE Intelligent Enterprise Working Group did a lot of work on knowledge management in an SE context, producing a “Concept of Operations for a Systems Engineering Educational Community” (Ring et al 2004)

Information has to be both shared and protected in complex organizations. Sharing is key to effective collaboration; it is constrained by the need to protect Intellectual Property, and commercially and nationally sensitive material. Different cultures and personal styles make best use of information presented in different ways and in different orders (i.e. in levels of abstraction, big picture first or detail, principles first or practical examples). (Sillitto, 2010 b) describes the knowledge management challenges for large multi-national organizations. Projects need to manage project information, and establish configuration control over formal contractual information and information that defines the product/service being developed, supplied or operated. A key role of systems engineers is to “language the project” (Ring et al 2004). Good data management and tool support will allow people to “document once, use many times”, and ensure consistency of information over time and between different teams.

System information needs to be maintained throughout the life of the system and made available to relevant stakeholders – including those designing new systems that have to interface to the system of interest - to allow system management, maintenance, reconfiguration, upgrade and disposal, and forensics after accidents and near-misses. (Elliot, B, et al 2008) suggest that information management is the dominant problem in systems engineering for in service systems, and that the cost and difficulty of establishing “current state” and legacy constraints before starting to implement a change is often underestimated.

Improvement and change of SE in organsiaiton

SE leaders (Directors, functional managers, team leaders and specialists) have responsibilities, and control levers to implement them, that vary depending on their organization’s business model and structure. A great deal of their time and energy is spent managing change in pursuit of short, medium and long term organizational goals: “doing everyday things better”; making change happen, embedding change and delivering the benefit; and coping with the effects of disruptions. Mergers, acquisitions and project start-ups, phase changes, transitions from “discovery” to “delivery” phase, transition to operation, sudden change in level of funding, can all impose abrupt changes on organizations that can destabilize teams, processes, culture and performance. The tqble below provides links to both the general management literature and specific systems engineering knowledge.

Add table from early draft of Chapter 7 (didn't make final edit)

Doing everyday things better

There is a wealth of sources / techniques, including Kaizen, Deming PDCA (Deming 1994), Lean (Womack 1998, Oppenheim et al. 2010), 6-Sigma (Harry 1997), and CMMI (SEI, 2010)

Planned change: standing up or formalizing SE in an organization

Planned change may include: introducing SE to a business (Farncombe et al, 2009); improvement/transformation; formalizing the way a business or project does SE; dealing with a merger/demerger/major re-organization; developing a new generation or disruptive product, system, service or product line (Christensen); entering a new market; and managing project lifecycle transitions: start-up, changing to the next phase of development, transition to manufacture/operation/support, wind down and decommissioning.

CMMI (SEI 2010) is widely used to provide a framework for planned change in a systems engineering context. Planned change needs to take a holistic approach considering people (knowledge, skills, culture, ability and motivation), process, measurement and tools as a coherent whole. It is now widely believed that tools and process are not a substitute for skills and experience but merely provide a framework in which skilled and motivated people can be more effective. So change should start with people not with tools. Before a change is started it is advisable to baseline the current business performance and systems engineering capability, and establish metrics that will show early on whether the change is achieving the desired effect and benefits.

Unforeseen disruption

Unforeseen disruptions may be externally or externally imposed. Externally imposed disruptions may be caused: by the customer - win/lose contract, mandated teaming or redirection; by competitors - current offering becomes less/more competitive, a disruptive innovation may be launched in market; or by Governance and regulatory changes - new processes, certification, safety or environmental standards. Internal or self-induced disruptions may include: a capability drop-out due to loss of people, facilities, financing; product or service failure in operation or disposal; strategy change e.g. new CEO, respond to market dynamics; or a priority over-ride.

Embedding change

In a Systems Engineering context, sustained effort is required to maintain improvements such as higher CMMI levels, Lean and Safety cultures, etc, once they are achieved. There are several useful change models, including Kotter’s 8 phases of change (Kotter 1995): establish a sense of urgency, create a coalition, develop a clear vision, share the vision, empower people to clear obstacles, secure short term wins, consolidate and keep moving, and anchor the change. The first six steps are the easy ones. The Chaos Model (Zuijderhoudt 1990, 2002) draws on complexity theory to show that regression is likely if the short term wins are not consolidated, institutionalized and anchored. This explains the oft-seen phenomenon of organizations indulging in numerous change initiatives, none of which sticks because attention moves on to the next before the previous one is anchored.

Article Discussion

[Go to discussion page]