[Introduction to Why Projects go Well or Badly]
[Making It Happen]
[What Goes Wrong]
[From an Individual's Perspective]
[Some Miscellaneous Issues]
[DGC Laws of Systems Engineering/Management]
[Systems Engineering and Management Checklist]
[Site Top Page] [User Top Page] [SPEM Top Page] [SPEM Index] [Part1] [Part2] [Part4]
| [Press for File] | [Next Ch] |
[Top] [Part 3 Chapters] [SPEM Top Page] [SPEM Index] |
This chapter gives a brief introduction as to what in practice frequently happens on projects, and thus why some go well and some badly. It also provides an introduction to the other chapters within this Part 3 of the Handbook.
| [Press for File] | [Previous Ch] [Next Ch] |
[Top] [Part 3 Chapters] [SPEM Top Page] [SPEM Index] |
This chapter identifies a number of key areas those responsible for setting up or running a project, or key parts of it, should pay particular attention to. They are about the overall approach that needs to be adopted with respect to a project.
Leadership
Clear Objectives
Give the Project Manager the Authority to get the job done
Getting the Right People into the Right Job
The importance of Planning
The importance of setting up an effective and robust infrastructure
The importance of having appropriate procedures
Effective subcontractor/supplier management
Being Result Oriented rather than Process Oriented
Encourage openness and truth
Project Identity
The need to plan for potential changes in requirement
To develop a culture of always looking for improvements
| [Press for File] | [Previous Ch] [Next Ch] |
[Top] [Part 3 Chapters] [SPEM Top Page] [SPEM Index] |
This chapter looks at some of the common ways in which projects go wrong in practice under the headings given below.
Higher Management Interference
Project split location
'Uninformed customer'
Changing Requirements
Lack of understanding of the customer requirement
Lack of System Approach by Customer
Inappropriate level of requirement specification
Lack of Understanding of Value/Quality
Poor Customer-Supplier contractual relationships
Lack of understanding of System Design contribution
Lack of clarity on design authority
Poor management of other own organisation sub-contractors
Over emphasis on specialist engineering groups
Lack of a System Design model
Use of an inappropriate System Design model
Poor Decision Making
Lack of/Inadequate Assessment of Risk
Sub-contractors being implicitly rewarded for doing things which might be damaging to the project as a whole
Underestimation of Learning Curve Difficulties
Failure to Adequately Manage Resource Build Up for Large Projects
Failure to Adequately Manage off-loading of Resources at key stages in Project
Failure to consider the full life-cycle during the earlier phases
Failure to consider tolerances and realistic production capabilities
Inadequate attention to practical operability issues
Lack of effective delegation
Individuals acting contrary to project interests
Poor organisational/project structures
Poor accounting structures
A Culture of Management by Fear
Over Management
Poor Process Improvement Management
Lack of up front investment
Those Responsible are not up to it
| [Press for File] | [Previous Ch] [Next Ch] |
[Top] [Part 3 Chapters] [SPEM Top Page] [SPEM Index] |
This chapter considers some of the characteristics we as individuals should or shouldn't have if we are to work effectively within a system project environment.
Be organised
Be open minded
Pay attention to good documentation and presentation skills
Interpersonal Communication
Negotiation Skills
Behaviour/attitudes to Avoid
| [Press for File] | [Previous Ch] [Next Ch] |
[Top] [Part 3 Chapters] [SPEM Top Page] [SPEM Index] |
This chapter considers a number of miscellaneous issues which could have been forced into one or other of the above categories but which sit as subjects which are probably best discussed in their own right. Namely:
Trading off low risk of no/limited change against greater benefits of significant change
'Professional Project Managers' or 'Engineers in Management'?
Internal Customers and Suppliers
Something imperfect is usually better than nothing at all
Introducing Systems Engineering concepts into Product Oriented Organisations
The Reality of Peter's Principle
Organisational learning issues
Single Suppliers
Imposing Constraints
Experience is a double edged sword
Design-Build Teams, Concurrent Engineering, etc.
The Need For and the Application of Tailoring
| [Press for File] | [Previous Ch] [Next Ch] |
[Top] [Part 3 Chapters] [SPEM Top Page] [SPEM Index] |
This chapter pulls together a number of principles to guide the system engineer and manager in his daily activities. These are points which have been discussed elsewhere within this Handbook. However it is useful to bring them together here as a means of helping remember them.
These are broken up into two categories:
General Principles:
The Future Uncertainty Principle
Principles of Uncertainty Reduction
Great things are achieved through a mix of idealism and pragmatism
It is important to know why.
There is usually a best time to make a decision or to take action
There is often a natural time in the project development at which certain issues/problems should be addressed.
Short term activities must always be seen in a long term context (It is better to look at everything a little bit and then focus on areas of specific concern within context, than leap into detail of something without understanding its wider context).
Treat symptoms AND causes
A low priority activity will become a crisis if ignored. It is thus necessary to manage low priority activities as well as high priority activities.
If you ask for something that is feasible, they will try to give you what you want. If you ask for something that is infeasible, they will give you what is in their own best interests.
Passing responsibility does not mean absolving oneself of consequences.
There are such things as right and wrong decisions.
A Decision Maker's span of interest is his own limit of responsibility
The actions for long term productivity/profits will never be taken if they conflict with short term productivity/profits unless they are budgeted for in a way that prevents the relevant budget being used for short term ends.
Everything is connected to everything else.
Always try to simplify, but only up to a point.
Just because there are different ways of doing things does not mean any given method is just as good as any other.
Just because something or someone has succeeded does not mean the means used is responsible for the success, though it might be.
Look to negotiate rather than impose or blindly accept.
Honest really is the best policy
Concepts of Chaos and Catastrophy are very real
'Optimal' solutions are usually Unstable
Risk is a matter of viewpoint.
It is often difficult to distinguish incompetence from conspiracy/strategy.
Those with the authority to make decisions do not necessarily make the best decisions
People act on the basis of their objectives and on what they believe to be true.
When managing people, recognise that they are not all the same.
People are more important than processes
Maintain a model or viewpoint of how things should be done, even where practical constraints mean they can't be done as they should.
Systems Engineering and Management Principles:
There is no such thing as a new design.
When conducting analysis activities of almost any sort the most significant gains usually result from doing the exercise rather than from getting the results.
A specification is never written without its sponsor having given thought to its feasibility, and concluding that it is feasible.
Never state a requirement without being sure: a) That the requirement can be met. b) Being sure that the statement of requirement is the best way of getting what you want.
Always look to clearly differentiate Operational Requirements/Needs from Design Requirements.
Constraints should not be imposed unless there is a good reason for imposing them.
Force the issue of addressing the consequences of future change.
The principles of a professional design
Every engineer talks a subtly different language when it comes to the principles of system engineering (or almost anything else for that matter).
Politics is a part of system design.
In general, people follow the path of least resistance.
It is often forgotten that the means to an end are just that, ie the means must not become more important than the end.
Many modern techniques and methods with their claims for significantly increased efficiencies and effectiveness are successful not as a result of the technique/method itself, but simply because it provides the opportunity for reassessing the processes being used.
Line management and Task management are not the same thing.
Managers who do not have a technical understanding of what they are managing are very dangerous in a system project environment.
Crisis are not a good thing
There is an optimal level of control: find it.
Life is not always fair
| [Press for File] | [Previous Ch] |
[Top] [Part 3 Chapters] [SPEM Top Page] [SPEM Index] |
This chapter provides a list of questions that system engineers and managers should ask of themselves and others at various appropriate stages of the system engineering and management process. Note that whilst the checklist can be used of auditors, it is most important that the checklist is used during early planning, asking questions such as 'How are we going to ensure ...', or 'Does the plan ensure ...'.
In answering the questions given below it is not sufficient to simply answer yes or no. Explanations and references should also be given such that the response to the questions can be audited/checked if appropriate.
[Abbreviations]
[Glossary]
[Bibliography]
[Special Purpose Index]
[Endnote]
[Site Top Page] [User Top Page] [SPEM Top Page] [SPEM Index] [Part1] [Part2] [Part3]
| [Press for File] |
[Top] [SPEM Top Page] [SPEM Index] [Part1] [Part2] [Part3] [Part4] |
The abbreviations given in this chapter are those which might not be immediately obvious to the reader.
Some more specialist abbreviations are given under:
| [Press for File] |
[Top] [SPEM Top Page] [SPEM Index] [Part1] [Part2] [Part3] [Part4] |
The glossary generally includes:
General terms which are often used, but for which many people only have a hazy notion of their precise meaning.
Terms which are sometimes used in an SPEM environment with a specific connotation which is subtly different to the everyday use of the term.
Terms which are sometimes used fairly loosely, but where this book has used them in a far more precise manner.
In addition to this glossary, more specialist glossaries are provided under the topics for:
The Special Purpose Index includes a list of all glossary terms allowing the reader to quickly find which, if any, of the glossaries a given term is in.
| [Press for File] |
[Top] [SPEM Top Page] [SPEM Index] [Part1] [Part2] [Part3] [Part4] |
Clearly for a handbook of this nature with such a wide coverage, a bibliography could very quickly run into many thousands of references; and the rest. And simply listing such a large number of references will not add a lot of value since:
It will not be possible for the reader to look up them all, and faced with a long list he is more likely not to read any than if presented with a smaller list and more explicit guidance on what the reference contains.
The reader can clearly find general titles for himself through libraries, in book shops, or on the Internet.
This bibliography is thus limited to:
In a small number of cases mention is made of references in the main body of the handbook.
Introduction
About Systems Engineering
Engineering Related
Management related
General Thinking and Skills
Specialist Engineering
| [Press for File] |
[Top] [SPEM Top Page] [SPEM Index] [Part1] [Part2] [Part3] [Part4] |
This chapter provides a means for the reader to find topics which are not obviously found from the context list. There are two types of index given:
Terminology Index, which provides a cross reference between terms the reader may be familiar with and the relevant section or sections which is the primary place the related topic is discussed, although possibly using different terminology.
Glossary Index. Noting that there are a number of glossaries given in this book, this shows which glossary given terms are defined in.
Introduction
Terminology Index
Glossary Index