Project Performance International

Project Performance International offer a series of presentations and tutorials of different lengths that can be presented to your organisation or professional society

If you are interested in PPI presenting at your organisation, please Contact Us

---

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 starting, 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 the alternative that 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 optimisation. 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 Managing Director and systems engineering guru Robert Halligan. The full text of this presentation, which challenges some conventional wisdoms, is not 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 as Robert prefers to call it, "Project Breakdown Structure - PBS", 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: System Breakdown Structure (SBS, Cost Breakdown Structure (CBS), Organissational Breakdown Structure (OBS), Specification Breakdown Structure (Specification Tree)

• application of WBS to costing, scheduling, definition, risk analysis, measurement, reporting, organisational 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 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.

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 illustrate clearly the flaws inherent in QFD and AHP in their standard forms, and explain effective modifications to each approach.

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

PPI also offer presentations under the following topics:

• 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
• Getting the Most from Integrated Product Teams
• Ten Don'ts in Engineering Decision Making
• Systems Engineering - The Next Ten Years