Difference between revisions of "Determining Needed Systems Engineering Capabilities in Businesses and Enterprises"

Revision as of 18:47, 16 August 2011

A key part of Enabling Businesses and Enterprises to Perform Systems Engineering is deciding on the desired systems engineering capabilities within the business and/or enterprise. First, the Organizational Purpose must be understood, then the value that systems engineering can provide is determined. So understanding the value that Systems Engineering can provide within the organisation in support of Organizational Purpose is the starting point for deciding the desired SE capabilities. This topic summarizes the issues that drive the decisions about desired Systems Engineering capabilities for the business or enterprise. This has to take into account the factors that cause organisations to be different, so the topic also discusses the organizational “design” decisions and issues that may arise; and also how SE may interact with other functional areas in the organization, and what needs to be done to ensure that Systems Engineering delivers maximum value to the organization.

Once the systems engineering capabilities of the business and enterprise are determined, these capabilities are divided among organisations, teams and individuals. Determination of team SE capability is discussed in the topic Determining Needed Systems Engineering Capabilities in Teams, and the individual SE competencies are discussed in the topic Roles and Competencies.

The capability to perform systems engineering includes factors such as having competent personnel, adequate time, sufficient resources and equipment, and appropriate policies and procedures. The SE capability of a business or enterprise is dependent on all these factors. In addition, social dynamics at the team and organizational levels also influence the SE capability realized.

Relationship of this topic to Enterprise Systems Engineering

Enterprise Systems Engineering techniques can be used to establish needed SE capabilities. Architecture modeling and analysis enables better understanding of the dependencies between capabilities of nodes in the enterprise. At a high level of abstraction, here are basic steps to decide on the desired SE capabilities within the business and enterprise.

1. Understand the context, including the factors shown in Table 1

2. Determine the required SE roles

3. Determine the competencies and capabilities needed for each of the SE roles

4. Assess the ability and availability of the needed SE organizations, teams, and individuals

5. Make adjustments to the required SE roles based on the actual ability and availability

6. Organize the SE function in a manner that facilitates communication, coordination, and performance.

See the topic Organizing Business and Enterprises to Perform Systems Engineering for more information.

More information is provided below on context and required SE roles.

Contextual Drivers

The table below provides a comprehensive list of contextual factors and drivers to be considered when deciding on the desired SE capability for a business and enterprise.

**Table 1** - Environmental factors in organizing to perform SE in a business or enterprise
Environmental Factor	Examples
Where the SE activities are performed in the value chain: See the discussion on "Organizational contexts for SE" in Enabling Businesses and Enterprises to Perform Systems Engineering.	Whether the organization is: the “Problem owner”, system operator, prime contractor, subsystem/component developer or specialist service provider
Where the business or enterprise operates in the lifecycle	Concept, development, manufacturing, in-service, retired
Nature of responsibility to end users	Explicit - clear requirements, prescriptive legislation Implicit – “fitness for purpose”, product liability
Nature of responsibility to customers	Outcome: deliver the intended benefits the system is expected to provide Output: deliver or operate the system or part of it against agreed acceptance criteria Activity: perform specified processes Resource: provide specified resource.
Scale of systems	At which Hitchins level (Hitchins 2005) is the organization operating: Level 1: Subsystem and technical artefacts Level 2: Project systems Level 3: Business systems Level 4: Industry systems Level 5: Societal systems?
Complexity of systems integration task -Stupples levels, (Elliot et al, 2007; Sillitto, 2011)	Within a discipline (e.g. software, electronics) Multiple disciplines (software, hardware, optics, mechanical) Socio technical systems integration Environmental integration
Criticality of system and certification requirements	Safety, Security Ethics, Environment etc
Nature of contract	Fixed price or cost plus; Mandated work share arrangements
Nature and predictability of problem domain	Well defined and slowly changing “steady state” Poorly defined and rapidly changing, operators subject to unpredictable and evolving threats (e.g. defense)
Fundamental risks and design drivers in solution domain	Stable, low rate of technology evolution, systems use mature technology; Rapid technology evolution, pressure to bring new technologies rapidly to market/ into operational use Lead time expectations versus level of integrity/certification
competitive situation and business goals	Do existing business better Recover from a competitive shock or a shift in clients' expectations Develop a new generation product or service Enter a new market Reposition the business or enterprise in the value chain
Type of system or service	Product or "productised service" Bespoke solution (product or service) Tailored solution based on standard product and/or service elements

Different possible structures for an organization , and how the choice affects SE

Organizations manage SE resource in many different ways. A key driver is the extent to which they seek to optimize use of resources – people, knowledge, and assets – across teams, projects and businesses. There are four basic ways of organizing resources to support multiple projects: Project organization; Matrix organization; Functional organization; and Integrated organization (CM Guide 2009), (Handy 1985), (PMI 2008, section 2.4).

Project organization

A project organization is one extreme where projects are responsible for hiring, training and terminating staff and managing all assets required for delivery. In this model, systems engineers on a project report directly or indirectly to the project manager, and resources are optimized for the delivery the project. However, it does so at the expense of sub optimizing how staff are deployed across the larger enterprise, how technology choices are made across projects, etc. The (DAU 2001) SE Fundamentals gives a recent DoD view of good practice project organizations.

Functional Organization

A functional organization is the opposite extreme, where projects delegate almost all their work to functional groups. This is appropriate when the functional skill is fast-evolving and dependent on complex infrastructure and is often used for manufacturing, test engineering, software development, financial, purchasing, commercial and legal functions.

Matrix Organization

Very often a matrix organization is used to give functional specialists a “home” between project assignments. This is a common approach in systems engineering organizations where a SE functional lead is responsible for workforce development and may manage career development by giving individuals variety of development experience in different assignments.

Integrated Organization

In an integrated organization, people do assigned jobs without specific functional allegiance. Those who perform SE tasks primarily identify themselves as another type of engineer such as a civil or electrical engineer. They are knowledgeable of systems engineering and use it in their daily activities as required.

A Product Centered Organization

In accordance with the (Rechtin 1991, p. 132) heuristic that “the product and the process must match,” a common method for creating an organizational structure is to make it match the system breakdown structure (glossary) (SBS). According to (Browning 2009) at each element of the SBS there is an assigned integrated product team (IPT). Each IPT consists of members of the technical disciplines necessary to design the product system. The purpose of the IPT is to assure that the interactions among all the technical disciplines are accounted for in the design and that undesirable interactions are avoided.

Some disciplines, such as reliability and safety, may not fit into this hierarchical structure. Separate teams, sometimes called analysis and integration teams (AITs) are created for these disciplines. These teams are sometimes called functional IPTs. There should be an AIT (glossary) for each level of the IPT hierarchy.

At the program level there is a top-level IPT commonly called a systems engineering and integration team (SEIT). The purpose of the SEIT (glossary) is to oversee all the lower level IPTs.

The attached diagram shows how a program organization maps to the system breakdown structure. This diagram shows only two levels, but in practice there may be many levels.

Required SE Roles

Enterprise Systems Engineering techniques can be used to establish needed SE capabilities from first principles. The SEI Capability Maturity Models for Acquisition, Development and Services provide a framework for selecting systems engineering capabilities relevant to different types of business and enterprise.

After understanding the context for the business and/or enterprise, the next step is to determine the required SE roles. The SEI Capability Maturity Models for Acquisition, Development and Services provide a framework for selecting systems engineering capabilities relevant to different types of business and enterprise. In addition, existing SE competency models can be used to assist in determining the needed capabilities. An example is the INCOSE SE Competencies Framework (INCOSE 2010). See the Roles and Competencies topic for more information on competency models.

As shown in the figure below, management action on workforce development will be required if there are systemic mismatches between the competencies required to perform systems engineering roles and the actual competencies of individuals; and organizational culture may have a positive or negative effect on team performance and overall value added by the business or enterprise.

Interfaces with other functions in the business or enterprise

Systems engineering is relevant to and depends on other organizational functions. Some organizations see SE as purely about project delivery. Others see it as a key enabler for innovation for new and improved products and services. Typical relationships with other organizational functions are shown in the following table. These relationships should all add value to the business, and the need to service these relationships determines the level of SE capacity and capability that needs to be maintained at organizational as opposed to project level in the business or enterprise.

**Table 2** – **Systems Engineering relationships with other functions in businesses and enterprises**
SE contributes to other function	SE requires from other function	Areas where SE and other function should collaborate
Research and technology
Future client needs; architecture road maps; SE architectural framework for managing dependencies and information flows; maturity criteria.	Future technology capabilities; predictions of standards evolution; concept demonstrators; tools and models.	Future product architectures; novel system concepts; R&T pull-through; prioritize R&T to address capability gaps; tailored SE for R&T projects; SE research; innovation platforms; technology road mapping
Human Resources
Define SE competencies; report on staff performance; future SE staff needs; training requirements	Definition of grade structure and hiring/ promotion criteria; training budget; training provision	Develop SE training for practitioners and other functions; Managing team performance
Strategy and Business Development
Enterprise opportunity assessment; product line architecting; understanding trends and implications of future needs; model/analyze extended enterprise value stream; critical SE and architectural dependencies; competitor capabilities	Business case analysis; future markets; preferred partners; preferred suppliers; priorities for SE capability development; customer feedback	Enterprise opportunity identification and management; “Make, team or buy” decisions; product road mapping; crisis management; business development; alignment of goals across the enterprise; managing external relationships
Bid and Program
As above at project level; Systems engineering planning for whole system lifecycle; Architecture; Independent peer review; Technical metrics for SE process and system performance	As above at project level; task authorization and prioritization; Earned Value Mgt process.	Detailed project planning and control; risk identification and management; managing customer relationship; managing and controlling changes
Engineering Operations
Architecture constraints/ patterns; Competence requirements for SE roles; SE process, tools, models, methods, coaching, reviewers; Validation of plans and design, standards; SE metrics requirements; shortfall/excess in forward load; requirements for SE enabling systems	Metrics reports; Forward load estimate; Current SE issues in ops.	Risk assessment; “make team buy” decisions for subsystems and SE capabilities; load balancing and prioritization; anomaly resolution
Service delivery/Deployed operations (name TBC)
Change impact analysis Design and validation of upgrades and reconfiguration for new missions	Decommissioning; Refurbishment;	Changes to operational architecture, e.g. Force Realignment Anomaly resolution

Need for clarity of SE approach, and dangers in implementing SE

In any organization where activities and skills are shared there is always a danger of silos or duplication. One of the purposes of Systems Engineering is to reduce this risk – consider the interface or glue role (Sheard 1996), or the idea that “SE is good engineering with special areas of emphasis, … including interfaces between disciplines” (Blanchard and Fabrycky 2005).

It is important to have clarity on how the organization is doing its Systems Engineering. Typically, implementing SE may be part of an organisation improvement, so Kotter’s principles on creating a vision, communicating the vision and empowering the others to act on the vision are most relevant (Kotter 1995). The way an organization chooses to do Systems Engineering , should be part of the vision of the organization – and must be understood and accepted by all.

Many of the major obstacles in systems engineering deployment are cultural (see Culture)

Systems engineering will make a very powerful contribution to the organization’s quality goals. Embedding SE principles, processes and methods in the organization’s quality management system means that senior management and the quality system will help to embed systems engineering and make sure it is applied [(INCOSE 2010a), (ISO 2008) and cross ref part 1?].

One of the lean enablers for Systems Engineering (Oppenheim et al, 2010) is "Pursue perfection". The means of improvement at business or enterprise level is discussed in detail elsewhere, but the starting point has to be deciding the Systems Engineering capabilities the organisation wants.

A business or enterprise is a kind of system – and Systems Engineering is one of the functions the "system" may need to perform. The specific requirements for the Systems Engineering function can be derived from understanding what the overall system (the organisation) needs to do, and from the relationship between SE and other functions within the organisation at different levels. So there has to be a tailored solution to an organisation's SE requirements given the unique set of purpose / scope / context / capability / culture etc. of each organisation. Also, organisations change over time (learning, improving or losing capability etc.) and so the balancing of SE with everything else keeps changing.

It is also important to balance the need for a systematic and standardised approach to SE processes (as defined in the INCOSE SE handbook for example) with the capability for systemic thinking in order to understand problem situations and apply appropriate Systems Thinking to "dissolve" organisational barriers and blockers, and to make most of “technical capabilities” the organisation has that it wants to exploit (see, e.g. Beasley, 2011).

References

Citations

Beasley, R. 2011. The Three T's of Systems Engineering. Proceedings of the 2011 INCOSE International Symposium, Denver.
Blanchard, B. and W. Fabrycky. 2005. Systems Engineering and Analysis. 4th edition, Prentice-Hall International.
Browning, T. R. 2009. Using the Design Structure Matrix to Design Program Organizations. In: SAGE, A. P. & ROUSE, W. B. (eds.) Handbook of Systems Engineering and Management. Second ed. Hoboken, NJ: John Wiley & Sons.
CM Guide. 2009. Construction Management Guide. Project Organization Types. Available at, <http://cmguide.org/archives/319>.
Defense Acquistion University. 2001. Systems Engineering Fundamentals. Accessed at http://www.dau.mil/pubscats/PubsCats/SEFGuide%2001-01.pdf.
Handy, C.B. 1985. Understanding Organizations, Penguin Business, London.
Hitchins, D. 2005. Systems Engineering 5 layer model. Accessed at http://www.hitchins.net/5layer.html, last updated 2005.
INCOSE. 2005. Systems Engineering Leading Indicators Guide. INCOSE-TP-2005-001-02.
INCOSE. 2010. INCOSE Systems Engineering Handbook. Version 3.2.
ISO, 2008, ISO/IEC 15288:2008, Systems and Software Engineering - System Life Cycle Processes.
Kotter, John P. 1995. Leading Change: Why Transformation Efforts Fail. Harvard Business Review, March–April 1995.
Morgan, J. and J. Liker. 2006. The Toyota Product Development System: Integrating People, Process and Technology. Productivity Press.
Oppenheim et al. 2010, INCOSE Lean SE WG. Lean Enablers for Systems Engineering. Accessible at http://cse.lmu.edu/about/graduateeducation/systemsengineering/INCOSE.htm.
PMI. 2008. Project Management Body of Knowledge. 4th edition. ANSI/PMI 99-001-2008.
Rechtin, E. 1991. Systems Architecting: Creating and Building Complex Systems, Englewood Cliffs, NJ, CRC Press.
Sheard, S. 1996. 12 Systems Engineering Roles. 1996 INCOSE 6th Annual Symposium, Boston. Available at, http://www.incose.org/educationcareers/PDF/12-roles.pdf.

Primary References

None.

Additional References