, I hope
you find this site beneficial and register soon by buying a book !!!
This article provides guidance and proposes a common solution of
"what-is" required to 'Manage and Control large and complex
technical systems' from their concept to de-commissioning. This article
provides direction and guidance of how these aims can be realized and it is
hoped that the philosophies, concepts, and principles contained will assist
those responsible for projects/programs meet their commitments effectively,
efficiently, and economically.
Copyright (c) by Ken Rigby
1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003
All rights reserved
VIRTUAL
REAL WORLDS Defines a new way
of perceiving the world.
However, all rights are reserved by the author.
State of
Play 2002 Brief summary on the latest view on system/software managing
processes and a proposed "Program/project
Standard".
Documents are available in
.pdf format: See PDFDOCUMENTS.
A hard copy publication which contains information based on the following
WWW pages entitled
"Technical
Management - a pragmatic approach" 2nd Edition now
available – published by Rigby Publishing Limited for Ken Rigby;
ISBN 1-904504-01-9.
For description at AMAZON CLICK HERE
'Technical
Management - documentation standard'.
ISBN 1-904504-00-0.
For
description at AMAZON CLICK HERE
For
description at AMAZON CLICK HERE.
For
description at AMAZON CLICK HERE.
For
description at AMAZON CLICK HERE.
For
description at AMAZON CLICK HERE.
Registration
to this web page will be automatic on purchase of the books (registration
number contained inside); so if you have found this site useful obtain a copy
for yourself, your company, or request via library.
Electronic
copies of the documents are also available (.pdf) Click here for link.
The target audience is for practitioners to define and
plan the technical effort, serve as a guideline for acquirers,
developers/subcontractors, program/project managers/engineers, and as a
reference textbook for undergraduate or graduate courses in systems and general
engineering technical management.
A copy
of the latest 'MANAGING STANDARDS' WWW site and some of the referenced
standards (public domain only) will also be available on a CDROM.
It has been specially adapted for off-line use with all common browsers.
Help to keep this page freely
available (i.e., no password) by ordering/obtaining the books!.
For Orders (Ordering
details, etc.) or e-mail
for further information to:
Click on INDEX above
for a fast access route to detailed information.
·
The purpose and intent of this article is to provide a starting point
and act as a "Rosetta stone" for the subject 'Management
and Control of Large and complex technical systems'. It attempts to provide
an understanding of what-is-required with reference to the major management
system components. This article has been prepared at the widest-level
consistent with meeting the needs of all interested parties. Having worked in
this area (mainly software development) for more years than I would care to
remember and, as there is so little information actually available and
documented I decided to use this method to provide an understanding and
enlightenment. The objective is to initiate standardization of 'Technical
Management' using results gained from engineering, technology, and experience;
to propose and promote an optimized Project Management System (PMS) using
existing and recently cancelled standards. Participation in the form of
comments or queries would be welcomed. It is intended that this article will be
updated, modified, and expanded at regular intervals with unfolding events and
available time.
This
seems to be evolving into integrated process environment that is a return to
the '60s prior to the specialization 'bang'- the circle has turned full circle
fusing them back together!
It is
widely recognized that large and complex technical systems need to be designed,
developed, produced and maintained using a unified system of engineering
concepts, polices, principles, processes, and terminology which will be usable
and understood by all those involved. These tenets are at present defined in a
multitude of standards, guide-lines, practices, directives, etc., provided by
various organizations such as; Governments, agencies, standards institutions,
universities, companies, etc., in a variety of countries. What needs to be done
is to unify, delineate, and categorize these requirements into the functional
areas and provide the necessary instructions and guidance for their
interpretation and use.
This
article intends to provide an introduction, purpose, and establish or propose
eclectic requirements for a 'Project Management System' (PMS) and detail
examples of 'what-needs-to-be-done'. The PMS shall provide practitioners of
'what-is' necessary to manage and control these systems and provide links to
where further guidance, assistance, or information can be obtained. An
additional aim is to show the usefulness and flexibility of a mark-up language
(HTML) and information flow via "the net" in this application and
general project use.
The
objective is also to provide an insight and act as a guide or aid for
practitioners or acquirers involved in the management and control of large and
complex technical systems.
It can
also act as the stem from which technical engineering effort can be identified,
analyzed, and specified. It is my intention to develop this idea incrementally
and evolutionary as more information becomes available and time permits.
Since
the DoD are planning or have planned not to support any further development of
existing (MIL/DOD) 'management' Standards; there is an urgent need to produce a
usable model or standard for Engineering
Management as defined in ISO/IEC 15288, MIL-STD-499A/B, ISO/IEC
12207, ISO 9001, DEF STAN 05-91 and associated documents to be created
which will represent a universal and strategic way forward to control and
manage large and complex technical systems and projects.
Recent work has been to produce
framework standards such as ISO/IEC 12207 and ISO/IEC 15288 these embody the
same principles and concepts implemented by this article. All the processes and procedures
referenced are required by these ISO standards. CMMI provides an integration framework for process
improvement of these defined processes, etc.
Reference
to detailed organizational structures, methods, and tools have been avoided to
allow flexibility regarding organizational methods to satisfy the principles
expressed in this article. The quality functions have been integrated into the
project tasks and provision shall be taken to ensure their functional
(technical authority) independence.
Disclaimer
The
preparation of this page is in no way associated with A-I-R (Server), my
employers, standardization organizations referenced, etc. I can make no
guarantee that it is complete or correct but every effort is being been made to
ensure conformity to the stated sources in the time available. Copies of the
referenced documents can be obtained from the identified organization(s) all
are unclassified and the majority are approved for public release; distribution
unlimited. Interpretations are personal or provided by people on a personal
basis. Known source and supplemental URLs will be provided in the Sources section and will be added to as and when prudent
and necessary.
Note:
this article only provides a guide in the use of the stated source documents
and does not supersede or replace any requirement(s) stated therein.
The
information, and data at this site, home.btconnect.com/managingstandard/, are
provided for your use. The information and data are presented "as is"
without warranty of any kind. All warranties, either expressed or implied,
including the warranties of merchantability and fitness for a particular
purpose. In no event shall I be liable for any damages whatsoever including
direct, indirect, incidental, consequential, loss of business profits or
special damages.
If you
have any beneficial comments, questions, ideas, or discover typos or errors,
please send me an e-mail and I shall endeavor to consider or fix it.
Contributions or support will be welcome.
Note
about the author: Ken has spent the majority of his career in the
pursuit of establishing a standardized system for controlling and managing a
variety of complex technical projects. Efforts to establish a universal
approach with the constraints of company and project commitments have proved
difficult. Efforts to promote the idea through a publications path also proved
difficult. This led to publication on the internet as an independent
initiative. Ken has been involved in both commercial and military (development
and production) environments on national and international technical projects.
As a senior software standards engineer Ken has been instrumental in advancing
standardization of system and software development processes in line within
international standards on a project basis. Consultations, sponsorship, or
advice welcomed.
For Authors brief
resume click here.
Click here to
send comments to: kenr@wysywig.airtime.co.uk
(Ken Rigby)
Copyright (c) by Ken Rigby - 1995, 1996, 1997,
1998, 1999, 2000, 2001, 2002
All rights reserved
This article establishes the concept and proposes a standardized method
and process necessary to manage the specification, design, development,
manufacture, maintenance and support of large and complex technical systems. It
utilizes inputs from a variety of existing standards (MIL, DOD, DEF STAN, JSP,
STANAG, ISO, etc., created primarily in the USA and UK defining engineering
management requirements) and proposes an eclectic and universal solution to the
fundamental problems necessary for managing and controlling the origination,
specification, design, development, productionization, and maintenance of large
and complex technical systems.
The
PMS shall establish the life cycle phases and basic engineering processes. The
PMS shall define the polices, activities, and define tasks necessary for the
concept, design, manufacture, maintenance, and retirement of modern large and
complex technical systems.
The
total management process is referred to as 'Technical Management' and includes
the following concepts and terms 'Quality Management', 'Quality system',
'Project Management', 'Quality Plan', 'Quality Control Plan', 'Program
Management', 'Quality Assurance', Total Quality Management (TQM), Continuous
Quality Initiative (CQI), etc., used by various national/international
institutions, agencies and associations. These terms will to all intent and
purpose mean the same (synonymous); i.e., define, describe and/or improve the
necessary system and documentation to facilitate the management and control of
large and complex technical systems.
The
Project (Quality) Management System shall be used to establish, document, and
maintain the requirement for demonstrating the contractors and his suppliers
capability of ensuring the conformity of the product designed and supplied to
contractual requirements and for furnishing the objective evidence of
performance of the technical effort.
The
main purpose of the PMS is to allow the supplier (contractor) the maximum
latitude in the management, design, development, and manufacture of the
technical systems while standardizing on what-is required (framework) and
documentation to be prepared without dictating how-to.
The
value of having a pre-defined and stable Project Management System that will
allow controlled management of the specification, design, development, and
manufacture on a variety of topics will permit the designer the freedom of
creativity without it affecting or impacting the work of others.
It is
generally accepted that human creative enterprise has behavioral
characteristics more like a living organism than a machine, with each cell
having a certain freedom of action and unless they are all kept informed of the
objective or direction then concerted technical engineering effort cannot be
expected. Systems need to be designed using adaptive processes at the 'threshold of
possibility' to enable the most recent technology concepts to be built-in
and not bolted-to. Education and direction in this concept and availability of
written requirements will enable acceptance to be effective and lasting.
The
primary function of the PMS is to inform and be the focus for this objective.
This
article deals with the management of the design, development, manufacture, and
maintenance rather than the system that is being designed.
It
is not how the system works or how business management operates (Drucker
style), etc. It concentrates solely on the approach to be taken in establishing
a system to manage a program of technical effort to conceive, develop,
manufacture, and support large and complex technical systems and is the real
process of Technical Program (project) Management.
This
web page has over 200 supporting allegiance pages linked by URLs connected by
this page.
The increasing complexity and protracted time-scales of modern systems
design and development have made working to a standardized project management
system both essential and mandatory. It shall provide direction, and act as a
"signpost" for reference and terminology of the system life cycle
processes.

FIGURE 1. Project
hierarchy levels.
Project
Management (sometimes referred to as Program, Quality or Engineering Management
in other circles) - just like the technical systems it manages and controls -
is a process with its own organizational structure (defined in the
“Organizational Program Management Plan/Process” document) and activities
containing internal subsystems or agents of Configuration Management, Systems
Engineering Management, Risk Management, Data Management, Safety, Security,
etc. The process is mandated by a 'Program (Project) Plan' which will identify
the overall project requirements (executive view) which will include
engineering effort contractual documents such as Statements of Work (SOW),
Request for Proposal (RFP), Invitations to Tender (ITT), and/or
System/subsystem Specifications (SSS).
For
details of Program
Plan discussion and model text.
The
Project Management System (PMS) is initiated by a 'Program Plan' which will
identify and establish the required documents detailing policy, organizations,
engineering tasks, processes and the necessary documentation to be prepared.
An
effective Program (Project) Manager uses the above as project engineering
management tools or agents to ensure achievement of required performance, life
cycle costs, and scheduled maintenance. Each management function shall be
documented in a tailored to suit specific program plan:
Each document shall be prepared to strict format, content, and intended
use with the rules defined in the approved referenced standards. They shall be
initially prepared and agreed prior to contract let or at least at the first
formal life cycle review (System Requirements Review) with the acquirer (customer);
acquisition streamlining guide-lines should be followed to meet the specific
project needs (tailoring) and to minimize cost and time-scales prior to
contract let. Every effort should be taken to keep them unclassified to enable
wide circulation and availability. Documents shall be prepared to be
electronically viewable with the facility to print when necessary. Networking
systems should allow for comments, reviews, etc., to be conducted with on/off
line capabilities.
The
necessity for these documents to be prepared, agreed, and authorized early in a
project cannot be over-stated as it is essential to establish a fully
integrated top-down project management system that will define project policy,
process, terminology, identify technical tasks, and promote direction. It is
usual for the acquirer (customer) to assume the responsibility for ensuring
that a realistic, workable 'Program/Project Management System' is in place and
being used prior to a contract being let or as soon as possible thereafter.
Adherence
to these standardization documents will ensure that the same process and
control for procuring end-items (deliverables such as ships, land vehicles,
aircraft, equipment, test equipment, simulation, and support items, etc.,) and
non-deliverable items will use the same standardized methodology and processes
and that the same document types will be prepared and terminology used. This
has obvious advantages in that only one project management system will be
necessary for whatever is being procured.
The
project management system is also a high-level requirement of DEF STAN 05-91
(Quality systems) and DEF STAN 05-67 in association with ISO 9000
which demands top-down fully integrated plans and procedures with quality
"built in" rather than "bolted to" for all processes
employed by suppliers.
The
PMS requirements are gained from the referenced documents
identified at the end of this article. The PMS requirements shall contain the
eclectic and melded requirements that are defined within the referenced
standardization and procedures documentation. The following provides a brief
summary of the contents of each of the PMS controlling documents; any supporting
or specialization documentation will be identified from within these documents.
The
PMS should not contain any "how-to" directives for technical
solutions to the technical problems posed by the projected technical system.
It is
the intention of this article (WWW page) to provide an example via URL links
from which projects can utilize or model a PMS and documentation set for their
specific project or program.
The Systems Engineering Management Plan (SEMP) establishes the plan for
the Systems Engineering management required to define the system performance
parameters and preferred system configuration to satisfy the technical
requirement, the planning and control of technical program tasks, integration
of the engineering specialities, and the management of a totally integrated
effort of design engineering, computer software engineering, specialty
engineering, test engineering, logistics engineering, quality evaluation, and
production engineering to meet cost, technical performance, quality, and
schedule objectives for a specific project or program.
The
purpose of the SEMP is to identify and describe the overall tasks (as defined
in a "Statement
of Work" (SOW)), principles and objectives for Systems Engineering
Management (SEM) during the total system life cycle of the System and its
comprising subsystems, and its developing Computer
Software Configuration Items (CSCIs), Hardware
Configuration Items (HWCIs), Manual operations, and supporting equipment
for the project.
The
Technical (Project) Management Program requires the implementation of a Systems
Engineering Management Plan (SEMP) that provides or establishes the technical,
managerial direction, and surveillance in accordance with contractual needs
(SOW) for the project.
The
project starts at the concept exploration (formulation and feasibility of
possibilities) stage followed by a Demonstration and Validation (proof of
possibilities) Phase leading to start of the Engineering and Manufacturing
development phase - realization of possibilities (see figure 1) the product
shall be accepted and certified at the end of this phase. The SEMP shall also
extend to the production and deployment (in-service) of the system life cycle
phases. Iterations of the development life cycles for individual HWCIs and
CSCIs may occur for complex systems. Each phase of a given life cycle can be
represented using a Basic Process Model.
This
document shall also meet the requirement for Quality Assurance or Management in
design (DEF STAN 05-67, ISO 9000, and DEF STAN 05-91) for specific
projects by defining principles, processes, and concepts necessary for the
design, development, and support tasks.

FIGURE 2. System
Support life cycle.
The
following primary functional areas shall be covered:
Technical program planning and control.
Details on
the following topics shall be included under this heading:
Systems engineering processes.
Details on
the following topics shall be included under this heading:
Integration and co-ordination of the project efforts.
Details of
control, monitoring, reporting, interfacing and coordination considerations
between the varied specialist
program efforts shall be defined. Concurrent engineering processes shall be
considered with the objectives of Continuous Acquisition and Life-cycle Support
(CALS) to enable a migration from paper intensive operation to an integrated
acquisition and support process. User-computer interfaces and diagnostic
testing when applicable shall be integrated into the development process for
system software and hardware.
Details
of the planning and scheduling of all the SEM activities that have been
identified as necessary shall be illustrated using PERT or similar critical
path scheduling and detailed in a Project Management
Plan.
Contractual
and non-contractual provisions and the review of the PMS will be indicated and
provided if necessary.
The
SEMP will be used in conjunction with the Configuration Management, Data
Management, Risk Management requirements and 'Documentation Standard'
requirements to meet the Technical Management need as required by the Project
Management System for the specific project; see FIGURE 3.
The
supporting specialist program/project plans (Software development, Maintainability,
Reliability, Safety, Security, etc.,) shall be prepared, when necessary, by the
relevant technical authority responsible for the specific engineering
discipline. These shall establish the organizations, facilities, methods, and
procedures necessary to manage and control the allocated tasks.
The
following lists some of the speciality plans which when identified as
applicable will be prepared:
The SEMP is based on and in accordance with the requirement for Systems
Engineering Management as required by Engineering Management defined in MIL-STD-499A
and B, ISO 15288, DEF STAN 05-67, DEF STAN 05-91 and outlines the necessary
tasks for Systems Engineering, Interface Control, Approval, and Certification
required by MIL-STD-973, DEF STAN 05-123/1, DEF STAN 05-57, DEF STAN 00-970,
RTCA/DO-178B, JSP 188, and MIL-STD-498 standards and procedures.
The
applicability of the SEMP to individual groups within the purchaser and
industry will be restricted (tailored) to tasks identified by a Statement of
Work (SOW), Invitations to Tender (IIT), and Request for Proposal (RFP), if
applicable.
Systems
Engineering can be applied in many ways and can be utilized to improve the
performance of industry by reducing risks and time to conceive, design,
develop, and manufacture large and complex technical systems.
Systems
Engineering Management concepts, when combined with common sense and technical
expertise, will constitute the basis of a sound systems engineering program.
New
standards for systems engineering require that the SEMP be the focus of the
integrated technical effort for systems and comprising subsystems. The above
requirements are still functionally applicable, however, changes to the SEMP
format will be necessary to emphasis the process. This page will be updated to
reflect the new approach as soon as sufficient analysis is complete.
New
approaches to SEM are in the formation of Integrated Product Teams (IPTs) where
functional disciplines are integrated together for a specific project. Also,
the SEMP may be called a 'Technical
Management Plan' to reflect the multidisciplinary nature of the
technical effort and tasks required.
Analysis
over the past few months has proved very rewarding 'Technical Management' will
include the Systems Engineering Process and additional activities as necessary,
IPT integration, tasks identification, and plans for transitioning/continuous
performance improvement.
I
intend to produce a publication that will contain the information provided by
this web page together with the latest thinking and direction. It will be
entitled "Technical
Management - a pragmatic approach"
to the management and control of large and complex systems. E-mail for further
information.
Development
of software requires a genuine systems engineering approach to the acquisition,
definition, design, and development of the projected technical system and its
comprising hardware and software. Direction and oversight stability reflected
in the planning maturity is vital at an early stage. What is to be done, when,
and by whom shall be defined.

FIGURE 3. Project
Management System Plans.
For
details of how to prepare an SEMP see SEMP model text.
The Data Management Plan (DMP) shall establish an overall plan for the
data management requirements for a specific project. The purpose of the DMP
shall be to provide the necessary management and control of the contractually
identified data items (management, financial, administrative, and technical).
The prime
functions are as follows:
NOTE: Data is essentially anything other than hardware, and software. It
includes but not limited to specifications, drawings, documents, source code,
and listings, etc.
Data Management can be combined with Configuration
Management; see MIL-STD-973.
For
details of how to prepare a DMP; see Data Management Plan
The Risk Management Plan (RMP) shall establish an overall plan for the
management of risks pertinent to the success of a specific project.
The
purpose of the RMP will be to identify the organization, and methods necessary
to provide management and control of the risks (management, administrative,
financial, technical, etc.) at project level.
This shall
include failure to meet contracted standards, cost, and schedule targets,
technical requirements, etc., at project level.
When risks
have been identified a 'Risk reduction program' will be scheduled to minimize
any possible impacts on the project.
For
details of Risk Management and how to prepare a RMP see Risk Management
discussion and example Plan
The purpose of the 'Documentation Standard' is to define general and
detailed requirements for documentation,
audience considerations, identify documentation types, sample texts, assurance
of data quality, and provide a brief overview of the documentation to be
prepared during the total life-cycle of projected systems, subsystems, and its
comprising hardware (HWCIs) and software (CSCIs). The documentation to be
prepared shall be compatible with the eclectic documentation requirements
contained in MIL-STD-499A, MIL-STD-961D, MIL-STD-962B, MIL-STD-970,
MIL-STD-490A, MIL-STD-498, DOD-STD-2168, DEF STAN 00-22, DEF STAN 05-28, DEF
STAN 05-57, JSP 188, BS 7649, RTCA/DO-178B, ISO 9000, and DEF STAN 00-31 or
whatever has been contractually agreed.
Documentation
example texts (relevant DIDs or 'model texts') shall contain or reference the
pertinent Codes of Practice, Project Standards, Work Instructions, as specified
so that uniform approaches and methods can be applied by the design and
associate personnel. This will ensure that the required activities are being
complied within the terms of the contract.
The
'Documentation Standard' shall define general and detail requirements for
documentation preparation, style, layout, content, format, etc., together with
the necessary procedures for change, revisions and amendments. An overview and
example text shall be provided as an example for each of the documents to be
prepared during the concept, design, development, support, production, and
maintenance phases of the system and its associated hardware (HWCI) and
software (CSCI) configuration items.
The
documentation shall plan, specify, direct, explain, detail, define, record, or
provide evidence of the performance of activities and processes during the
system, subsystem, CSCI, and HWCI life cycles and specialist program plans.
Documentation shall be capable of being viewed in its electronic form and be
printable whenever required. Networking systems shall allow for comments,
decisions taken, and reviews to be undertaken with on/off line capabilities.
The
information stored should be location, platform, and display independent; this
should enable any person on any system using a project documentation tool to
access and operate on the fundamental data e.g., analyze, review, comment, etc.
For
details of how to prepare a Documentation Standard see Documentation
Standard model text
A hard
copy of a documentation standard based on this web site will be available
see "Technical
Management - documentation standard"
The Configuration Management Plan (CMP) shall establish an overall plan
for Configuration Management requirements for the System/Subsystems, Computer
Software Configuration Items (CSCIs), Hardware Configuration Items (HWCIs) an
other designated equipment during total system life cycle of the project. For
CSCIs during the Engineering and Manufacturing Development phase, the criteria
identified in the Software Development Plan for the project will be observed.
The
purpose of the CMP is to identify and describe the overall policies and methods
for Configuration Management (CM) to be used during the total life cycle of the
System/subsystems, CSCIs, HWCIs and equipment for the project.
The
CMP shall establish and provide the basis for a uniform and concise
Configuration Management practice for the system/subsystems, CSCIs and HWCIs
during the total system life cycle of the project.
The
CMP shall be used in conjunction with the 'Systems Engineering Management Plan'
(SEMP), Data Management Plan, Risk Management Plan, and the 'Documentation
Standard' to meet the requirement for Technical Management defined by the
'Program Plan' by the Project Management System for the specific project. The
primary intention of the CMP is to provide information on the Configuration
Management policy, methods, and procedures to be adopted and implemented for
the specific project.
Starting
with the functional configuration identification defined and frozen at the
beginning of the Engineering and Manufacturing Development phase, the
configuration (baselines) will be protected from uncoordinated and unauthorized
change. This protection will be provided by formal Configuration Management
operated within the acquirer and supplier companies.
The
following outlines the contents of a typical Configuration Management Plan:
A typical System/breakdown structure identifying system, subsystem, RUs,
HWCIs and CSCIs is illustrated in figure 3.
The
'Configuration Management Plan' shall be prepared for specific project use and
conform to the requirements of MIL-STD-973, MIL-STD-483, MIL-STD-61, EIA-649,
ISO 10007, DEF STAN 05-57, as determined by contract order.

FIGURE 4. System
breakdown structure.
For
details of how to prepare a CMP see Configuration Management
Plan model text.
Or,
for a Up-to-date hardcopy see COPY
of SCMP Template

FIGURE 5. Hardware
and software life cycle.
Establishment of a Project Management System to a common standard is of
paramount importance (usually mandatory) as it sets the required level of
quality and management attitude for the rest of the project. However, its use
and principles are highly recommended for large commercial ventures in
providing a disciplined and structured approach to specifying requirements and
planning the program of tasks, events, terminology, activities, documentation,
etc. It is essential that the PMS is agreed and approved by the acquirer and
contractor (developer or producer) prior to any contract let. Above all the
principles of honesty and integrity when applying the PMS are essential to enable
genuine creativity in design and realism in management.
The
primary mission of the "Project Management System" is to establish a
well-planned, well-administered, and well-disciplined approach to the concept,
specification, design, development, manufacture, support and maintenance of
large and complex technical systems; at the same time as recognizing that the
aim is not to constrict creative thought but to capture, develop, and
manufacture its products.
A well
proven and universally accepted PMS will be an absolute necessity to control
and manage the next generation of very large complex technical systems being
conceived and designed to avoid excessive time-scales and costs, and increase
productivity and efficiency at National and International levels. Tools must be
created to allow pragmatic approaches to systems engineering and must conform
to the applicable standards to ensure a seamless process and common terminology
throughout industry.
The
use of a standardized PMS will allow more small and medium sized companies to
take advantage of the benefits of Technical Management standardization and thus
providing a more flexible, experienced and thoughtful "engineering"
workforce in the design,
development, and production of large and complex technical systems.
Consideration must be given to the composition of design teams; both for their
objectives and individual personality perceptions. This will enable focus on
the system being designed at the 'threshold of possibility' rather than
subjective or individual goals.
Changes
to management focus due to the advent of now available and fast electronic
communication Management
changes (discussion).
Up to now
management has been perceived as a tool for controlling people, resources, and
cost. Technical Management will define what-is-necessary to manage and control
the total technical effort required to produce, effective, economical, and
efficient technical systems alongside the personnel and business management
functions. It will not define or discuss personnel or business issues; these
will be assumed to be suitably defined in their specialist areas i.e.,
Personnel Management promotes staff motivation, recruitment, salaries, etc.,
and business management to promote financial, marketing, etc., expertise.
From comments received "Technical Management" is rarely
practiced due to education, time-scales, and cost; These practices need to be
inserted early and mandated contractually to improve quality and develop an
understanding management attitude toward engineering. Education will reduce
time-scales and costs, and produce more effective products; Academic
institutions must take the lead!
Establishment
of a universal and open standard for a PMS will be difficult and will only
succeed if promoted and accepted by the beneficiaries - which is everyone.
Emphasis should be on compliance rather than blind conformance.
A culture
change will cause clashes and building a new culture will require accepting the
eclectic and best with clear and open minds. Remember "He who rejects
change will be the architect of decay" and " Everybody hates change
but it is the only sure thing that has enabled progress".
Acquirers
and developers must resist all temptations to adopt 'silver bullet' and/or
'Emperors New Clothes' management techniques to satisfy time-scale/cost
reduction demands. History proves such techniques can end in embarrassment and
tears.
Program
Managers must give the 'thinkers and evaluators' time to establish
standardization methods before releasing the 'movers and shakers'.
Thinkers and evaluators should increase quality at the expense of cost and time.
Movers and
shakers generally compromise quality standards to gain reductions in cost and
time with sometimes long term consequences.
The following lists some of the advantages of using a PMS:
DISADVANTAGES
NOTE: Specific projects can "tailor"
the requirements prior to contract award or let and should be encouraged to do
so. See Pragmatic Principles article.
The main referenced documents are listed as follows:
DEF STAN 05-123, DEF STAN 05-57, DEF STAN 00-55, DEF
STAN 05-67 DEF STAN 05-28, DEF STAN 00-52, DEF STAN 00-31, DEF STAN 00-22, DEF
STAN 00-40, DEF STAN 00-41, DEF STAN 00-56, DEF STAN 05-91, DEF STAN 00-00, DEF
STAN 05-95, DEF STAN 00-970, JSP 188, JSP 184, MIL-HDBK-245, DOD-STD-2167,
DOD-STD-2167A, DOD-STD-2168,
MIL-STD-1521B,
MIL-STD-973,
MIL-STD-480B,
MIL-STD-961, MIL-STD-483A, MIL-STD-490A,
RTCA/DO-178B, MIL-STD-498, EIA IS-632, EIA/IEEE J-STD-016, EIA series on CM, MIL-STD-499A,
MIL-STD-499B, MIL-STD-680B, MIL-STD-882B,
MIL-STD-882C, MIL-STD-970,
MIL-STD-961D, MIL-STD-962B,
STANAG 4159, MIL-STD-1806, DO-178B, MIL-STD-1785, MIL-STD-7935A, MIL-STD-1700, MIL-STD-2165,
BS 7649, MIL-STD-1801A, AQAP-1, AQAP-13, ISO 9000, ISO 9001, ISO 9000-3
MIL-HDBK-248B, MIL-HDBK-761A, MIL-HDBK-59A, MIL-HDBK-271, MIL-HDBK-1785,
MIL-HDBK-61, ISO/IEC 12207 and amendment, ISO/IEC 10007, ISO/IEC 15288, CMMI, IEEE 1220, and their associated, guide-line, or allegiance documents/documentation.
Additional
reference to "SYSTEM ENGINEERING" (Epilogue section) by Harry Goode
& Robert Machol published in 1957 for visionary data.
A brief
summary of the above referenced documents is provided in referenced
documents brief summary.
PS: Due to the recent
change in attitude by the US DoD to specifications and standards (MIL) the
necessity of establishing a Project Management System as a universal
standard has become urgent and essential to keep the fundamentals of Technical
Management unified and cohesive. NOTE:
MIL-STD-499A and other 'MIL-STDs' for management have now been cancelled
without a replacement!
PPS: Main differences
between UK and US standardization documentation (Standards) are structural and
by implementation. US standards (MIL, DOD) are (if anybody has the time to
study) prescriptive, pragmatic, structured top-down and aimed at providing a
method for use in rigid contractual applications, requiring the acquirer to
approve baselines and participate in 'milestone' reviews.
The UK
standards generally define philosophies and guidance notes for those
responsible for projects to perform effectively, efficiently, and economically
without being to prescriptive on methods and the contents of the documentation.
Both
have good points and bad points and have been exploited by both parties in
contractual situations.
The
authors opinion is that a half-way house is probably the best solution with
predefined documentation and its proposed content agreed prior to a contract
being let for each project.
ISO
standards (9000, 12207, 15288, etc.,) seem to state that you must have a
standardized process(es) for a project without insisting on any specific
declared method or standardized prescription! (not a good idea - from
experience open to abuse and could lead to diversification in terminology and
document types (a 'vanilla' standard)!).
However,
its use with MIL-STD-498 does implement these standards, as both ISO/IEC 12207
and MIL-STD-498 are available they do provide a good basis. (ISO/IEC 15288 shortly). If
used with the SEI CMMI KPAs they will produce a universal process framework.
See "Program/project
Standards" for an example.
Known sites to date for information on referenced documentation are as
follows:
MIL-STD-498
and DIDs Assist
DEF
STAN home page DEF STAN Home page
Ada
pages ADA WWW pages
NASA
SATC Homepage SATC
Homepage
INCOSE
Home page INCOSE homepage
SE
Models and Standards: Systems Engineering
Models and standards compared.
Capability Overview paper: Systems Engineering.
Supplemental
links to information:
Software Management Software Management and System Engineering
Pragmatic Principles (systems engineering).
Management Tools and Techniques
Discovering System Requirements
News News
on standards reform.
System Architecture & Design Methodologies System Architecture
Process Tailoring for Software Project Plans SW Project Plans
Software Program Managers Network SPMN
SEI CMMI
CMM Models.
The address of sources are
provided here
Authors opinions and
recommendations.
Click on INDEX above
for a fast access route to detailed information.
Back to top of this page Click here.
For
Home page MANAGING
STANDARDS (http://home.btconnect.com/managingstandard/wysywig.htm) Home page
kenr@wysywig.airtime.co.uk
HTML Version originated (V1.0) on the 31st of May 1995.
This version is V4.6 2002 Authors
version notes and registration.
Copyright (c) by Ken Rigby 1995, 1996, 1997,
1998, 1999, 2000, 2001, 2002, 2003
All rights reserved
The author
reserves the right to amend, modify, or remove this page and any of its
allegiance pages i.e., (http://airtime.co.uk/users/wysywig/xxxx.htm) without
notice.
Please send any beneficial comments or identification of errors using
the following form to: kenr@wysywig.airtime.co.uk
Contributions
and support will be accepted.
Keywords:
Systems Engineering Management, Software Engineering, Engineering Management,
Technical Management, Maintainability, Reliability, Risk Management, Quality
Assurance, Environmental Engineering, Quality Control, Quality Assurance,
MIL-STD, DEF STAN, ISO 9000, ISO 9001, ISO 9000-3, ISO/IEC 12207, ISO/IEC
15288, Software Implementation, Documentation, Configuration Management,
Performance Management, Data Management, Design Reviews, Safety Critical
Systems, Security Critical Systems, Standardization program, Management Standards,
Program Plan, Project Plan, Quality Management, CMMI, CMM for Software.
"Technical
Management is a science not an art".
"A
Plan is nothing, planning is everything". - Dwight D Eisenhower.
“Physics has no
respect for politics”
An engineering approach to technical management has been long
overdue. The requirements of what-is-necessary to manage and control
large and complex technical systems has been ignored for too long. These
principles are only now being recognized and generally accepted throughout
industry and government. Why, then are we only now just beginning to
recognize their wide adoption.
The
answer, I suggest is the problem of technology development and the cultural
change necessary. As Technical Management is accepted the culture of the
past four decades will begin to change, and change always causes
problems. Even though most of us see the need for this change we will
always struggle against the deep rooted past customs and practices.
To
ease the change we need many things, up-to-the-line communications, easy access
to information, acceptance by those empowered to make decisions, support and
direction from higher level management (executives and directors) and
governments, and a very large dose of education and positive promotion with
clear direction and implementation. It is hoped that those involved will
rise to the challenge and will have the wisdom to create technical systems
which will improve the human condition efficiently, economically, and effectively.
By request from users the following clarification has
been added;
The
primary aim of the article is to improve the understanding and quality of the
technical management of large and complex systems.
I am introducing a licensing concept similar to shareware such that
persons/companies who register will be permitted (licensed) to use the
materials in a cut and paste fashion for documents for their private or
commercial use. If documentation is being prepared for a third-party, the
third-party must also register. When the third party is a government agency and
cannot register because of practical or statutory constraints, a waiver will be
granted provided the material is properly referenced.
I
shall require documents that contain any material to also contain either a
formal reference or acknowledgment of its source.
"This
document contains materials copied under license from the 'MANAGING STANDARDS'
site on the World Wide Web. (http://home.btconnect.com/managingstandard/)."
License: The holder of this license is granted a non-exclusive right to
copy materials from the home.btconnect.com/managingstandard/ site on the World
Wide Web for inclusion in documents intended for the sole use of the license
holder. Other uses are prohibited without the authorization of Ken Rigby.
Buying
the books which includes the license fee for registration will provide
'value' to the site and assist in its development and maintenance. Co-operation
in this would enhance the quality of site authors. Send E-mail for further
information.
TO
BUY “Technical Management – a pragmatic approach” FROM AMAZON CLICK HERE
TO
BUY “Technical Management – documentation standard” FROM AMAZON CLICK HERE
TO BUY “Software Configuration Management Plan -
Template” FROM AMAZON CLICK HERE
TO BUY “Software Development Plan - Template” FROM
AMAZON CLICK HERE
TO BUY “System/Software Safety Process” FROM AMAZON
CLICK HERE
TO BUY “Object-Oriented Software Engineering Process”
FROM AMAZON CLICK HERE
Documents are available in
.pdf format:
See PDFDOCUMENTS.
Copyright (c) by Ken Rigby 1995, 1996, 1997, 1998, 1999, 2000, 2001,
2002,
All rights reserved.
; The total number of visitors to
this site since the 15th of March 1998