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.

Meta-Quality & the Onion

Hewitt-Gleeson talks of metacognition - thinking about thinking - as the start point for getting better at thinking. In the same way, applying quality to (proposed) quality procedures makes them better - more useful, more effective, more likely to be supported & implemented.

When the assessment of quality is applied to the concept of quality, you get a reviewable process, which is the basis for reviewing all process. This is not circular. To believe so is simplistic.

Like many things, quality has to be self-referential (note also Bertrand Russell's set of all sets). The quality of the quality initiative is more important than the output of the initiative, on the basis that if the initiative fails, then it has a direct (potentially negative) impact on all activity. As it is, the reason for applying a quality process is to have a positive effect (only). You have to be able to measure that effect before you can blithely apply it - thus, meta-quality.

Thinking about quality, & applying a critical quality eye on the initiative, is also a way of focusing attention & energy inwardly (on the process of setting up quality) before doing so outwardly (applying the quality initiative), before extending the effects to outside of the quality system (improving the quality of deliverables). This is an onion approach - building on the innermost layers.

If the core of the onion is rotten, then the outer-most layer will be tainted. That's the point where the organisation touches the customer, & is therefore where the organisation's key outcome lies. Any cosmetic change to the skin of the onion is a temporary mask of the fundamental problems in the organisation that need to be addressed first.

Like a real onion, the edible part is hidden behind a thin veneer that needs to be immediately peeled back before use - after purchase. It may be too late to realise that the onion won't deliver the expected flavour once you've bought it, but you'll know better than to return to that greengrocer next time.

That's metaphor stinks.

OPV & the Project kick-off

I had a lot of help with this one ...

I gave an introductory seminar on thinking, an introduction to de Bono's CoRT methodology. The object of doing so is usually to get people to start using the techniques in their daily lives - preferably after the seminar. However, one bright spark immediately came up with a suggestion that I felt was worthy of stealing - using an OPV in a project kick-off meeting.

"What is an OPV?" I hear you ask, because you know nothing about de Bono's work. Simply put, it's applying a focus of Other People's Views to the problem at hand. That is, think of things from the viewpoint of someone else, rather than limiting your thinking to your own perspective. In the kick-off meeting, with all of the project team gathered for the first time, everyone has to work out, collectively, each person's priorities & expectations.

This is not just an interesting intellectual exercise, this is a fantastic approach to getting the project off on the right foot. If the client or their liaison doesn't hear that the project team understands them, then they will assume that they are already understood, & blithely go away until the delivery, when they get upset at just how wrong everyone's interpretation was. Similarly, if the technical solution & functional priorities aren't understood (correctly), then the project will very quickly go off the rails (& this may not be noticed early enough).

Here's the approach. The client (or representative) sits back & listens while everyone tries to see the project from their perspective - outcomes, priorities, deliverables, cost, etc. The client then gets the chance to clarify - not correct - the possible misunderstandings. It has to be done right there in front of everyone, & it has to be documented, as each point of difference is effectively a point of interpretation in the project scope that was not obvious. That is, it depended on someone's perspective.

This process then goes on through the other key perspectives - project manager, analyst, solution architect, developer, deployer, tester, documenter. As a final check, you can simply each take a role & feed back to the group that person's perspective as understood after clarification. This is now an approach with its own level of quality, review, etc, that starts the project off with as much accuracy as is conceivable. What happens after everything gets underway is another problem.

This can also be done in post-mortem - each person's perspective on the success of the project needs to be understood & communicated. It makes sense for everyone to get that understanding through putting themselves in other people's shoes.

Through time, the habit of using OPV will cover the whole project, & every decision made will automatically make reference to a broader perspective than simply one person's - even without needing to refer to everyone. This is more efficient, & more effective from a management perspective, & more efficacious from a project perspective, leading to a higher likelihood of project success & fewer surprises.