PPI Tutorials

A Journey Through Systems Engineering In An Hour And A Quarter

Using an amusing example from start to finish, Robert will have us performing Requirements Analysis, Physical Design, Logical Design, the conduct of Trade-Off Studies, Specification of system elements, System Integration, Verification, Validation, and Systems Engineering Management, all incorporating a strongly model-based approach (MBSE). In this interactive event, we can expect important principles to shine, and impediments to success to be highlighted.

Systems Engineering in the Next Decade

What are we presently achieving in systems engineering? With systems becoming increasingly complex and software intensive, what will the next decade bring? Will we see an improved success rate in engineering projects?

We propose a definition of ‘success’ as seen through the eyes of different stakeholders in a system, including, as applicable, users, customers, suppliers, developers, etc. The role of measures of effectiveness vis-à-vis Requirements is examined.

The paper assesses the current state of systems engineering practice against typical success criteria, using objective data to draw conclusions. We then put forward thoughts on how the next decade may be used to improve substantially the results of our projects. We prioritize the problem areas, and propose a remedy, a course of action, for each. In doing so, we address societal issues such as the impact on deep thinking of mobile devices, and the ongoing challenge to align engineering education outcomes with the needs of society, government and industry.

The Business Case for Systems Engineering

“Show me the evidence!” says the executive who is unconvinced about supporting systems engineering practices which all seem to involve additional up-front work at the expense of the project. The executive is skeptical, and so she should be! To permit major changes to the amount and balance of work without evidence of Return on Investment would be irresponsible.

The advocate of systems engineering, finding himself in this situation three years ago, was in serious trouble, because scientific quality, compelling evidence of ROI for systems engineering did not exist. How the world has changed in three years!

In this presentation and discussion, Robert will make the business case for systems engineering as a tool for reduced costs, shorter timescales and increased product value delivery, embracing the results of a number of recent, soundly-conducted studies on the subject.

A Systems Approach to Love, Life and Business

Robert will illustrate the application of systems thinking and systems engineering within a journey through life. He will commence with the real case of the application of systems engineering by Larry Khan, an American, to the selection of a lifetime partner. The approach and the result? – come and find out! He will then move to business systems, starting with his experience in applying systems engineering within his own consulting and training business. Topics touched upon, during Robert’s talk, will include enterprise transformation, business analysis and the BABOK. He will close with a project view, illustrating points and drawing lessons from the outcomes of projects across a diverse range of sectors.

Systems Engineering – the Boomerang Effect

The concept of this tutorial is “do certain things in systems engineering, and, just like the boomerang, they will come back and hit you in the head! Don’t do certain things in systems engineering, and the omission will, just like the boomerang, come back and hit you in the head.”

Upon his introduction, Robert will distribute a list of systems engineering principles, divide the attendees into teams of four or five, and invite each team to consider the validity of each principle. A team may conclude, for a given principle:

• yes, it is a valid principle
• yes, it is valid, but … (some qualification or exception), or
• no, it is not valid, because …

Teams will then present their conclusions. Robert will facilitate the ensuing discussion.

Functional Analysis – Why and How – Applications in the Problem and Solution Domains

Robert will describe, with credible examples, how to use functional analysis in the fundamentally different applications of, firstly, requirements capture and validation, and, secondly, design. He will address critical relationships between the logic and the physics, in both of these domains. He will explain and illustrate the importance of the two alternative functional views of control flow, and item flow, and how to use each. Robert will then compare and advise on functional modelling languages, including those incorporated in UML 2 and SysML. He will then provide pointers in the selection of software tools to support functional modelling.

Design Iteration Using Effectiveness Analysis

Conventional wisdom, as well as common sense, tell us that, faced with a design decision between acceptable alternatives, we should make that decision in the direction of the alternative which will be the most effective in the eyes of the stakeholder(s) whom the decision serves.

Experience tells us that, as engineers, we do not have infinite capacity to conceive the best of the design alternatives, the first time around.

Robert will expose, in an interactive format, the methods which he has used to capture and model the measures of effectiveness of interest to stakeholders, and their value relationships. He will discuss the validity of the resulting model, and show how the model can be used to assess the merits of design alternatives. Robert will then show how risk, opportunity, multiple stakeholders, multiple uses, and uncertain events can be factored into the effectiveness evaluation.

Having set the scene, he will then outline the principles of design optimization. Robert will describe a three-step method for iteratively driving up the effectiveness of an initial design, factoring into the approach the key question of “when to stop?”

Principles of the Engineering of Systems

Get the principles right, and the rest can follow. Get the principles wrong, and our chances of success are remote. In this presentation, Robert distils the engineering of systems to 14 basic principles (or for longer versions, 24 principles). Each principle is explained and discussed in an interactive format.

Twelve Issues in Systems Engineering

This presentation was delivered at the 2007 International Symposium of the International Council on Systems Engineering (INCOSE) in San Diego by PPI’s Managing Director and Systems Engineering guru Robert Halligan. The full text of this presentation, which challenges some conventional wisdoms, is now publicly available; this download contains the supporting graphics.

Getting the Most out of “Work” Breakdown Structure

Work Breakdown Structure (WBS) can be a powerful aid in effectively managing projects. But WBS (or “Project Breakdown Structure – PBS”, as Robert prefers to call it), is also easily misunderstood and misapplied. Robert’s coverage of the subject, in an interactive style, will include:

• why WBS must not be just a breakdown of work
• essential principles in adopting WBS as a management tool
• failsafe rules for constructing effective WBS
• relationships to other structures useful in project/engineering
• Management: Product Breakdown Structure (PBS), Cost Breakdown Structure (CBS), Organizational Breakdown Structure (OBS), Specification Breakdown Structure (Specification Tree)
• application of WBS to costing, scheduling, definition, risk analysis, measurement, reporting, organizational design, and control.

Is it beneficial to apply the “classic” systems engineering approach in the commercial/industrial systems engineering world?

Robert’s position to the subject question is that: it depends on what we mean by the classic systems engineering approach. If we mean a set of rules defined by the United States Department of Defense and forced on an unsuspecting population, to be applied unthinkingly, then we should plan to fail, both commercially and in other ways. If we mean a set of principles for the engineering of systems that have evolved over millenia, and a variety of methods which implement those principles, then Robert’s position is that, not only is it beneficial, but absolutely essential to commercial survival and prosperity.

A Schema for Types of Requirements

Robert will describe a schema for the types of requirements (states and modes, functional, performance, external interface, environmental, resource, physical, other qualities, and design), that he has used for many years, with considerable success. He will precisely define each type, and describe the significance of each type to each of the three roles of requirements analyst, requirements specification writer, and designer. Differences for physical systems, software and services will be discussed. Robert will then illustrate a proven-effective strategy for the automation of requirements specification production based on a six part classification scheme per requirement (actor primary and secondary, and for each actor, primary and secondary requirements types). He will then illustrate the unambiguous mapping into specification structure that is available.

How can we measure requirements quality, and why would we want to?

In this tutorial, Robert will explain why a requirements quality metric is one of the most valuable metrics in controlling and improving the outcomes of technical projects. He will go on to explain how to measure the quality of a set of specified requirements. The tutorial includes an interactive workshop in which you will exercise an effective method of measuring requirements quality. You are invited to bring your own requirements! Or you may select from Robert’s offerings.

Context and Design Requirements Analysis

Wouldn’t it be wonderful if, when we received a requirements specification, it was always of a suitable standard. No ambiguities, no omissions, requirements all verifiable, etc. Now to reality!

Robert will introduce, in turn, two techniques for transforming a hopelessly inadequate requirements spec (also one that is almost good enough, but not quite), into an adequate one.

For context analysis, he will describe the analysis technique (part of an overall methodology), then we will form into teams and perform the analysis. For design requirements analysis, we will conduct the analysis interactively with Robert.

Robert promises that both the analyses themselves and the wrap-ups will be both interesting and illuminating.

Building and Using a System Effectiveness Model

A sound principle of systems engineering is that, when faced with decisions between feasible solution alternatives, we always want to pick the best according to the values of the people we are serving. In this interactive session, Robert will illustrate how to build a system effectiveness model, then how to use the model to support decision-making between feasible design alternatives.

Why the leading technology-based enterprises of the world embrace Systems Engineering as a set of principles and methods

In this presentation, Mr Halligan will summarize the evolution of the practice of engineering over several centuries; what we have learned, and what we have yet to learn. He will discuss contemporary practices in engineering around the world, rapidly converging on a set of principles that seem to be associated with successful projects and enterprises, regardless of country, and regardless of application. He will illustrate the application of these principles with a basic and amusing example. Participants are encouraged to bring their own engineering principles and process issues to the event, for discussion.

Ten Don’ts in Engineering Decision-making

A sound principle of systems engineering is that, when faced with decisions between feasible solution alternatives, we always want to pick the best according to the values of the people we are serving. Usually, we will be making such decisions in the presence of uncertainties, often with multiple stakeholders involved, and sometimes the system will have multiple uses. Sound techniques to support such decision making exist in the field of decision analysis. Equally, a number of unsound techniques are promoted in various texts and practiced in unsuspecting enterprises, including the popular Quality Function Deployment (QFD) and Analytic Hierarchy Process (AHP) in their standard forms.

Robert will examine the issues, and provide ten don’ts covering the generality of engineering decision making. He will clearly illustrate the flaws inherent in QFD and AHP in their standard forms, and explain effective modifications to each approach.

A Framework of Knowledge, Skills and Attitudes Conducive to High Performance Engineering

Engineering projects are notoriously challenging, no more so that projects of the types widely represented at this conference – projects that are groundbreaking, complex and critically important. We are all trying to do these projects well, and to do them better. Which drives the topic of this presentation.

Engineering is a team sport. And like football, the performance of the team is governed by the the knowledge, the skills and the attitudes (KSAs) of the team members. The KSAs relate to the traditional engineering streams of technology, mathematics and physics, the systems engineering stream of knowing how to go about applying the technology, mathematics and physics in a way conducive to success, and soft skills such a communication and emotional intelligence that distinguish a team from just a group.

A variety of engineering competency frameworks exists. In this presentation, we overview existing systems engineering competency frameworks. We then present a new, recommended framework; new in terms of publication but old in that it has been the foundation of the systems engineering education of over 13,000 engineers worldwide. This recommended framework exhibits a strong alignment with, we believe, practical, in-the-trenches, efficient, value-driven, high-performance engineering.

Getting the Most from Multi-disciplinary Teams

The Integrated Product Team (IPT) is a multidisciplinary organizational unit, sometimes used in conjunction with a strategy of concurrent (or simultaneous) engineering, to improve the outcomes of technical projects. IPTs offer demonstrated benefits 20% and more over other types of structure in terms of capability, cost and schedule performance. IPTs reduce risk in projects which
involve significant development, or complex integration.

This tutorial places Integrated Product Teams in a business context. The briefing seeks to answer the question of an executive or manager with an interest in projects “Why should I be interested in Integrated Product Teams”?

Some Key Questions that are addressed:

• What is an Integrated Product Team? How does an IPT differ from other types of project organizational unit?
• What are the benefits of using Integrated Product Teams?
• What are the downsides in using Integrated Product Teams?
• What are the risk areas?
• Can Integrated Product Teams be beneficial in all types of project?
• What are the main pointers and pitfalls to realising value through IPTs?

PPI also offers presentations under the following topics:

• An Assessment of the Status of Systems Engineering in the World
• Knowing What Needs to be Done is Only a Small Start! – Systems Engineering Process Improvement
• SysML – Warts and All
• OCD and CONOPS – Two Very Different Beasts
• How to Prepare Great Requirements Specifications
• Requirements are Design
• A Systems Approach to Software Engineering
• Twenty Million Systems Engineers; Twenty Thousand Who Know They Are