The Structure of Quality

Quality should not be constrained by or held within a structure.

What I mean by that is that, within an organisation, there should be no petty domain that controls quality in & of itself, & it should not manage all of the people involved in quality (control, assurance, etc). This is guaranteed to work against the basic premise that quality is everyone's responsibility. Quality should not be "someone else's problem", which is invariably what happens when one group within an organisation is labeled as the Quality Team (caps intentional).

In the same way that de Bono suggests that there should be a Chief Innovation Officer whose sole responsibility is to ensure that innovation across the organisation is encouraged & supported, a Quality Manager (it doesn't need to be an executive, but with executive sponsorship) should have organisation oversight (that is, be independent) to ensure that quality processes exist & are understood. Their role is to be the guardian of the quality aspect, covering the development of quality within each business unit (not imposing it on a unit), assisting with reviews (again, the reviews themselves happen within the unit) & review processes, education & culture (with input into how HR spread, or represent, the quality ethos), & the application of quality outcomes into modelling & budgeting (checking that quality is meaningful to the business success).
There will need to be people called in to help with the implementation - process re-engineering, change management, business analysis, etc. These people do not need to be a part of a quality structure. They should be either a floating group of company innovators, or else can be consultants. They could be a project team put together from elements of the organisation with a mission & a desire to work across teams, bringing together their expertise for a short burst of effectiveness - kind of like an agile scrum.

In a way, agile methodologies work very well with regards quality, &, even though it's usually a software development model, an appropriate business model can easily be defined with short-term goals, agreed-on outcomes, close stakeholder links, & process ownership. These are amongst the chief goals for applying agile, & amongst the chief benefits of a good quality process.

Quality is a whole-of-organisation approach to business improvement. Agile is a whole-of-team approach to project delivery. The two happily co-exist. The two complement. The two are flat in structure - there should be no egos, no ownership in one person. Everyone brings their experience & expertise in to the benefit of the team, with the hope that sharing same will also benefit everyone else in the team. Everyone grows as a consequnce of their involvement in the process.
Does it sound too idealistic? Perhaps. Maybe that's why very few are willing to take the risk to try something so radically different. So different that it might succeed.