One of the main questions to answer when setting up a quality program is whether to centralize or decentralize the team, tools, and systems. J.L. Ashford’s book, The Management of Quality in Construction, clearly establishes the difference between each.
Regarding centralized quality programs, from pages 55 to 56:
“Under a centralized system, these operations [quality assurance and quality control] will be the responsibility of a quality control department with its own management hierarchy independent of production departments. […] Such centralized programs can be very powerful. […] The disadvantage is that quality control departments tend to grow into separate empires working in parallel with but in isolation from those responsible for production.
The disadvantage stated above doesn’t allow quality programs to scale with economic and business cycles. I’ll share more of my thoughts on centralized systems in a moment.
Regarding decentralized programs, from page 56:
“The difference between centralized and de-centralized systems is that in the latter the responsibility for controlling quality is placed firmly on the shoulders of those actually doing the work.”
Further on page 57:
“The role of the management representative will depend on the type of quality system adopted. The manager of a de-centralized system is likely to have a smaller permanent staff at his disposal and his operations will therefore be less expensive than those of a manager of a centralized system. Also his activities reinforce the responsibilities of the production team rather than detract from them. They thus serve to encourage a more serious and constructive attitude towards quality.”
We’re about to enter sensitive territory. Before I state my own thoughts, know that
These concepts apply to any program: safety, scheduling, or other concentrated subject or expertise. In my own work, I did not recommend hiring dedicated quality managers for specific regions or product types, roaming from project to project to help carry out the quality activities on projects. (This does not apply to government or data center work where dedicated quality managers are contractually required as part of project team staff.) I’m a proponent of the decentralized system for two reasons. First, pitching a centralized group requires a large upfront cost associated with salaries for more full-time employees, and it doesn’t scale very well. (As business grows, you need to hire more people. When business shrinks, you’ve over-hired.) Second, the time management friction that teams feel forces the team to work together and distribute workload appropriately. Everyone learns about other roles and responsibilities. This friction serves as a motivator for constant process simplification and improvement for all processes – not just quality (setting aside the fact that quality should be integrated anyway and not separate).
The balance we are all attempting to strike is that centralized systems work when there are immature labor markets or inexperienced or unskilled teams, as well as in more robust or stricter process-oriented business cultures. Decentralized works where leadership is spread out across the company and there are lesser requirements for adhering to strict processes and when there is a greater percentage of higher performers. However, this isn’t always a possibility or reality, given we work in a high-risk industry where compliance will make or break a project (or an organization).
You may not be able to pick one type of system over another. Perhaps a blend of the two will give you the balance you need. There is no right or wrong approach, as each organization must take into account their business culture and strategy and decide what system will work best for them.
Leave a Reply