, I hope you find this site beneficial and register soon by buying a book !!!

MANAGING STANDARDS V4.6 

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.
 

This page and its allegiance pages may be copied for research/educational purposes only in their entirety with the copyright kept intact.

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

 

 

SCMP Template. 

 

 

 

                                                                           

 

 

 

ISBN  1-904504-03-5

For description at AMAZON CLICK HERE.

System/Software Safety Process

ISBN 1-904504-04-3

For description at AMAZON CLICK HERE.

Software Development Plan Template

For description at AMAZON CLICK HERE.

Object-Oriented Software Engineering Process

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:

kenr@wysywig.airtime.co.uk (Ken Rigby)

INDEX 

Click on INDEX above for a fast access route to detailed information.

CONTENTS 

·          

OBJECTIVE AND DISCLAIMER

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.

kenr@wysywig.airtime.co.uk 


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, 2003

All rights reserved.

FOREWORD

ABSTRACT

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.

Program/Project Management System 

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. Program hierarchy levels

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. 

SYSTEMS ENGINEERING MANAGEMENT PLAN 

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

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 Program Plans

FIGURE 3. Project Management System Plans.

For details of how to prepare an SEMP see SEMP model text.

Data Management Plan 

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

Risk 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

DOCUMENTATION STANDARD 

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"

CONFIGURATION MANAGEMENT PLAN 

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

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 Hardware and Software life cycle

FIGURE 5. Hardware and software life cycle. 

CONCLUSION

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.

ADVANTAGES 

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.

REFERENCED DOCUMENTS 

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.

SOURCES 

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. 

INDEX 

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”

Epilogue 

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,, 2003.

All rights reserved.

; The total number of visitors to this site since the 15th of March 1998


cover

 

 


LE FastCounter


LE FastCounter
In Association with Amazon.co.uk

cover