D  [C] [E[SPEM Top Page] [SPEM Index]

[Decision Making] [Delegation] [Deliverables] [Design] [Design Authority (DA)] [Design Constraints] [Design Drivers] [Design Reviews] [Design Tools] [Detailed Engineering Terms and Concepts] [Disposal] [Document/File Referencing] [Documentation] [The Drawing Office]

Decision Making

NOT YET AVAILABLE

[Press for File]

Decision making is something going on all the time. It varies from major project decisions involving hundreds of people over a long period of time, to individual personal decisions made without any real thought at all. As discussed in this chapter it could even be argued that every moment of the day we are in essence unconsciously making a decision, which is not to stop what we are doing and decide to do something else.

The figures given in the chapter focus upon structured project decisions, such as how to choose between a number of alternative 'solutions'. The methods of structured decision making are discussed including the methods/tools that can be used to support them.

Introduction

What is Decision Making?
The Decision Life-Cycle
A Structured Decision Process (for 'Hard' Decisions)
Notes on Related Activities
Variations
Key Features of Structured 'Hard' Decision Taking
Example Applications
'Soft' Decisions
Decision Method/Tool Support
Structure of Decision Support System
General Notes and Principles relating to Decision Making
Characteristics of a good decision
Decision Criteria
Expert Systems
Practical Notes about Expert Systems
Improving Decision Making within Organisations
Decision Makers are People
Note on Personal involvement in Decision Making


Delegation
[Press for File]

Delegation is one of the important, arguably the most important, skills of line management (ie. management responsible for tasks, with staff to aid in the carrying out of those tasks).  This chapter defines clearly what is mean by delegation, and gives guidance on how to carry it out effectively.  It also considers delegation from the viewpoint of the person being delegated to.

Introduction

What is meant by Responsibility, Authority, and Delegation
The Importance of Delegation
The benefits and drawbacks of delegation
What should be delegated
What should not be delegated
Delegating to the right person
Clear identification of delegated responsibilities
Delegating Authority as well as Responsibility
Controlling delegated activities
Motivating those carrying out delegated tasks
Checklist of Potential Problems, and how to overcome them
A note on Accountability
Optimum Delegation
Being Delegated to


Deliverables
[Press for File]

Deliverables are made against a contract. They are the major output from a contract against which final payment is made. A given contract may require a single deliverable, or a number of deliverables whose delivery may be distributed over time.  Deliverables include the system product itself, as well as much else besides, such as associated product documentation.  Deliverables will often also include project management related information such as progress reports.

Introduction

Types of deliverables
Linking Deliverables with Payment Plans


Design
[Press for File]

This chapter considers what is meant by design in general terms, and the different approaches to design.  It puts the term 'Systems Engineering' in the context of the term 'Design'.

Introduction

What is Design?
The Design Process
Systems Engineering and (General) Design Engineering for Complex Projects
Systems Engineering and Design Engineering for Simpler System/Equipment Projects
Systems Engineering and Design Engineering for Middling Complex System Projects
(General) Design Engineering
Worse Case Design
Statistical Design
Observations on Design generally


Design Authority (DA)
[Press for File]

A Design Authority is the person with authority for making decisions about a design and responsible for formally signing off the design. The DA must have authority over all technical aspects of the design, and thus provide a high level focus for all technical trade-off decisions.  The DA may or may not also have management responsibility for the the design activities.

A system project may have a number of hierarchical Design Authorities. The top level system DA will effectively delegate responsibility for the design of the component parts to other DAs. The system DA himself will only retain direct authority for requirement statements associated with the component parts and the interfaces.

Introduction

Typical DA Responsibilities
Design Authority terminology
Some Notes on Practical issues associated with placing DA responsibilities


Design Constraints
[Press for File]

Design Constraints are ways in which the solution to a requirement are constrained.  They are statements which are not related to the system purpose, but are imposed for reasons such as to reduce perceived risk.  Sometimes design constraints are introduced into the requirement as a result of poor systems engineering, where the customer is unable to specify what is wanted in terms of purpose, and specifies it in terms of what it is assumed the solution will be.  It is important that constraints are not confused with the operational requirement itself.

Introduction

Customer imposed constraints
Design to Meet weight and space Constraints


Design Drivers
[Press for File]

Design drivers are areas to which particular emphasis is given in the design process.  They are the areas which are believed to impact most significantly on the solution to the requirement, and to which some priority must be given during the design process.

Introduction

Reasons why emphasis on certain features of the design may be necessary
Ways of applying Resources on Design Drivers
List of Potential Design Drivers
Details on certain design drivers


Design Reviews
[Press for File]

Design Reviews are formal meetings at which progress of the design is reviewed. They usually take the form of presentations by those responsible for the day-to-day derivation of the design to persons independent of the design team.  Frequently design reviews are held at particular stages in the design when it is believed the design has reached some particular level of maturity.

Introduction

The objectives of Design Reviews
Outputs from Design Reviews
The Conduct of Design Reviews
Checklist of wider consideration often given at design reviews
Common Failings in Design Reviews
Principal Design Reviews
System/Sub-system/Equipment Design Reviews
Specialist Design reviews
Informal Design Reviews


Design Tools
[Press for File]

System Design Tools are computer based programs used in support of the design process.  They vary from general purpose data management tools through to mathematical modeling tools, through to expert systems.

Introduction

Benefits of using System Design Tools
Potential Disadvantages of using System Design Tools
Generic Issues Checklist:
Tool choice trade-offs
Current Availability of System Design Tools
Desirable features of a general purpose SDM Tool
In-house Development of Tools


Detailed Engineering Terms and Concepts
[Press for File]

This chapter gives a glossary of many engineering terms together with some additional classical engineering concepts.

Introduction

Specialist Scientific and Engineering Disciplines
General Engineering Terms
Comparison of systems for producing movement
Properties of Materials - General
Properties of certain Materials
Developments in Materials


Disposal
[Press for File]

Almost everything ultimately needs disposing of, or transforms into something that needs disposing of.  Disposal costs can be high, and become increasingly higher in the future as a result of environmental concerns.  Some consideration should therefore be given to disposal during the design phase as an aspect of keeping through-life costs down.  [Note disposal may relate to the whole of the system itself, to component parts of it as they are replaced, and to consumables used by or along with the system.]

Introduction

Origin of items/materials for disposal
Disposal as a System Life-Cycle Stage
Options for disposal (System and Components)
Design for Disposal
Disposal Management Plan


Document/File Referencing
[Press for File]

Putting in place a good document/file referencing system is important.  If it's done well people hardly notice it, except they have little difficulty deciding how to reference a document, and documents can be relatively easily found through their reference number.  If it's done poorly it is a sap on scarce resources.  A lot of time is wasted trying to decide on an appropriate reference for documents, and documents become much harder to find, leading to much wasted time.  Whilst this wasted time might be relatively small on any given occasion, it is multiplied many thousands and tens of thousands of times leading to a very large waste overall.  It can even lead to work being repeated since earlier work is not found when needed.

Introduction

The Structure of a Reference
Alternative Structures for References
Use of Talleys rather than initials


Documentation
[Press for File]

Documentation is used throughout the Systems Engineering and Project Management processes. This chapter is not concerned with the particular documentation itself but with issues and style associated with documentation in general.

Documentation is a vital part of the COMMUNICATION process. It is important both for communication at the time the documentation is produced and for communication with the future. Given its importance remarkably little attention is given to ensuring it is effective in its purpose. Frequently the producers of documentation see it as a chore, somehow subordinate to their primary objectives.  In the past there were 'Technical Authors' to put right poor documentation.  But in our electronic age this is less so, and what people write is often what gets 'published'.

The consequences of poor documentation range from inconvenience and wasted time to being very costly and even disastrous (e.g.. ambiguities in technical documentation).

Introduction

A The Structure of Documents
A1 The Big Idea
A2 Grouping and Ordering Ideas
A3 Hierarchical, Inductive, and Deductive Sequencing of Ideas
A4 More notes on Grouping and Ordering
A5 Introductory/Summary Text
A6 Action statements
A7 Recommending Action
A8 Stating Facts
A9 Examples
A10 Notes on Implementation
A11 Some misconceptions with respect to Documentation
B Grammar and Style
B1 Spelling
B2 Notes on Spelling Checkers
B3 Common typographical problems
B4 Word Meaning
B5 (Gramatical) Sentence Structures
B6 Grammatical Terms
B7 Punctuation
B8 Writing Style
B9 Contrast with Literary Style
B10 Breaking the Rules
C Physical Layouts and Document Formats
C1 Format Styles
D Miscellaneous Issues
D1 Some observations on the use of wordprocessors
D2 Additional Miscellaneous notes on Documentation
D3 Notes on the use of pictures, figures, etc. within documentation
D4 Miscellaneous Notes on: Equipment Manuals, Memos/letters, Forms
D5 Generic 'Contents' of Documents
D6 Organisational/Project Issues


The Drawing Office
[Press for File]

The term 'The Drawing Office' refers to the production of the detailed design in terms of detailed descriptions of layouts, components, and connections, in sufficient detail to allow the design to be manufactured.  In the past this was largely undertaken by draftsmen who literally drew the details.  Whilst today it is more usually done on the computer many of the concerns are the same.

Introduction

Materials and Components
Standards for Drawings
Drawing Sheets
Converting existing drawings to CAD
Configuration Control of Drawings
Engineering Drawings (Examples of types of)