Quality Management System Concept

By James Hutchins

The paradigm change in the twenty-first century for project management needs to be addressed in a new concept of a Quality Management System (QMS). The current practices of project management as they relate to QMS do not adequately address customer concerns.  To satisfy these concerns, the creators must plan, execute and, most importantly, document what is necessary for the individual project within the program under the umbrella of the organization.  This is a twenty-first century customer conundrum.  This thesis addresses how those programs/projects can functionally integrate creators with customers.  By close collaboration, intimate communication and teaming cooperation, resolutions will come about for better customer understanding and requirements satisfaction.

• Language: English
• Publisher: James Hutchins
• Release date: Aug 17, 2019
• ISBN: 9781393007135

James Hutchins

James L. “Hutch” Hutchins was born 1950 at Bangor, Maine.  The family moved to Southern California.  He roamed the local mountains and deserts camping out several times alone.  An avid reader and watcher of adventure, history, philosophy and poetry all his life.  He joined the United States Marines in December, 1969 after three years of college.  He dreamed of following the career of his father a professional educator but after the marine corps enlistment in 1978 spent over 30 years working in Quality Assurance. While in the marines he travelled to Germany, Denmark, Scotland, Britain, Formosa, Japan, the Philippines and Thailand.  In Thailand he was stationed at the base named by the marines “MCAS Rose Garden, Nam Phong RTAFB, Thailand. With his career he moved across and back the United States for over 40 years.        A researcher of family heritage he writes of people he knew in his quality career.  His stories cover the areas of his own adventures.        He now lives in Korat, Thailand with his third wife.

Book preview

TABLE OF CONTENTS

LIST OF TABLES ............................................... p v

LIST OF FIGURES.............................................. p vi

ABSTRACT ........................................................ p vii

CHAPTER

1.INTRODUCTION ........................................... p 1

Background ...................................................... p 1

Statement of the Problem ................................. p 4

Purpose .............................................................  p 4

Theoretical Basis and Organization .................. p 6

Limitations ....................................................... p 12

Definitions ........................................................ p 14

.

2. REVIEW OF LITERATURE ...................... p 18

3. METHODOLOGY ....................................  p 35

4. DATA ANALYSIS ...................................  p 55

5. CONCLUSIONS .......................................  p 59

REFERENCES ................................................. p 62

LIST OF TABLES

Timeframe of Parallel Development ...................  p 23

Requirement Increase .........................................  p 56

RDW Decrease vs. Profit Increase .....................  p 57

LIST OF FIGURES

Difference Between DATA and ISO or CMMI® .. p 8

Software vs. Hardware Development .....................p 10

Image of Arsenale Management Structure ...........  p 19

Project Management Life Cycles ........................... p 37

Project or Program Samples ................................... p 38

How Traceability Works ......................................... p 49

Functional Relationship Across Project or Program Life Cycle Phases .......................................................... p 52

ABSTRACT

The paradigm change in the twenty-first century for project management needs to be addressed in a new concept of a Quality Management System (QMS). The current practices of project management as they relate to QMS do not adequately address customer concerns.  To satisfy these concerns, the creators must plan, execute and, most importantly, document what is necessary for the individual project within the program under the umbrella of the organization.  This is a twenty-first century customer conundrum.  This thesis addresses how those programs/projects can functionally integrate creators with customers.  By close collaboration, intimate communication and teaming cooperation, resolutions will come about for better customer understanding and requirements satisfaction. 

CHAPTER 1

INTRODUCTION

Background

With over twenty-five years of experience in various positions of Quality Control/Assurance the author has developed a strong belief in how projects are being or should be conducted.  Experience extends from Special Access Required (SAR) programs to commercial enterprises.  SAR programs are classified programs which can have impacts upon national security.  Employment in the SAR programs came with mandatory non-disclosure agreements.  Exposure of SAR specific supportive thesis information would create understandable legal issues.  Accommodation of those agreements and any request for substantiation would have required extensive negotiations between competing aerospace companies.  Violating the agreements could have serious ramifications for this nation, present and former employers, and the author.  This thesis shall use alpha characters for any company and double alpha characters for individual projects to distinguish each.

Dependence upon the literature for supportive, substantive information was necessary.  This material covered previous class texts, outside reading and discussion groups within the American Society for Quality (ASQ).  This literature reinforced the belief in what activity is needed to reduce anomalous project experience. Communication within a project by project management, both horizontally between team members and vertically with senior management, allows projects to survive (Hutton, 1994).

A Software Development Plan (SDP) is based upon a contractual line item.  Normally, this plan defines the relationship between the different functional members of a development team.  In the past, Department of Defense (DOD) defined these requirements in the contract by military or DOD standards.  Usually these requirement contractual documents were specific to either software or hardware.

An SDP based upon a hardware contractual line item requirement was necessary while working for Company A within Project AB.  Previously, the needed software for this project was developed in accordance with the specific software contractual line requirement.  Satisfaction of that software requirement was defined with a customer accepted Computer Program Development Plan (CPDP).  This first customer accepted plan covered only developed software which would be housed in Line Replaceable Units (LRUs).  The CPDP purposely excluded software used as a tool.  This tool software was to be used to test the CPDP developed software.  Contractually it had two restrictions.  The first restriction was the tool software could not interact with the LRU software, but it had to measure the internal LRU software performance.  The second restriction was on its development, control and pedigree of qualification.

The first restriction software engineering was solved with the creation of the SDP. The second restriction presented a unique problem for Project AB.  No such SDP for software development, control and pedigree existed.  The Project AB software engineering communities could not agree to create that needed plan.  Company A’s software engineering wanted to use the non-planned tool software even though the SDP did not exist.  The customer made it clear a planned