The top-level docs of a QMS

The Short Story - Examples

• QM (IMS): https://quality.critical.pt/QMS%20PT/HLP-high-level-processes/CPD-ims-manual/CSW-QMS-2004-CPD-0156-ims-manual.pdf#search=CPD%200156
• SDP: https://quality.critical.pt/qmsunified/HLP-high-level-processes/SDP1-software-development/CSW-QMS-2002-SDP-0909-software-development.pdf#search=software%20development
• Project Lyfe Cycles: https://quality.critical.pt/qmsunified/HLP-high-level-processes/PLC-project-life-cycles/CSW-QMS-2003-PCS-2296-project-life-cycles.pdf#search=project%20life%20cycles

The Long Story

Some typical top-level documents of a QMS include (documentation levels are described here):

• The Quality Manual (Sometimes titled "Quality Management System" document or "Integrated Manual System" if if handles more than "just" quality issues)
• The Software Development Process documentation (SDP and PLC). 

Here are some of the documentation levels and some examples of documents on each level:

Level 0:

• CSW-QMS-2004-CPD-0156 Quality Manual (or QMS, or IMS)

Level 1 (High-Level Processes):

• CSW-QMS-2002-PCS-1475: Quality Management Process
• CSW-QMS-2002-SDP-0909: Software Development Process
• CSW-QMS-2003-PCS-2296: Project Life Cycle Management Process
• CSW-QMS-2004-PCS-1608: Process Improvement Process
• CSW-QMS-2009-PCS-04341: Project Management Process
• (etc.)

Level 2: (etc.)

The Quality Manual

If the word quality means a thing for a certain organization it shall have a Quality Manual (QM), which states the company commitment to quality (and is required by most quality certifications).

The SDP (and its relation with the PLC)

If your company does software development, then it has a process (inputs: customer requirements, outputs: a working deployed solution). The typical name of this process is... Software Development Process or SDP. Typically this process will be written  (*).

Your company could have a single SDP document for all software development methodologies that it plans to use, or - a better idea - can have several documents, one for each methodology (Waterfall, Agile - SCRUM, etc.).

For waterfall methodology: Sometimes some project types (that need to be typified concretely) do not need all the phases (and its related "overhead").

So, a project type list shall be done, and an adjusted software life cycle must be defined for that specific project. Some companies will have the general phases described in one document (the [waterfall] SDP) and those details - of what should and what should't be simplified - in another which could be called "Project Life Cycles" (PLC).

In fact this constitutes a pre-tailoring of the QMS processes to be applied to these project types (more on tailoring later on), speeding up project start.

(*) Is it always like this? Maybe not. For small teams, small projects (read: startups), things could succeed without strict process definitions (or by using agile methodologies).

(2016-05-04: Added short story, long story layout)