Quality, Risk & Project Controls

Quality on a project has two faces, and confusing them is common. Quality assurance (QA) is about the process - the systems, standards, templates and checks a practice puts in place so that good work is produced reliably, by design rather than by luck. Quality control (QC) is about the product - the actual checking of the specific output, catching the errors in this drawing, this specification, this piece of built work. QA is building a machine that tends to produce good work; QC is inspecting what came off the machine. A good practice needs both: standards and systems so quality is the default, and rigorous checking because no system is perfect.

For a design practice, quality management is intensely practical. It means office standards - drawing conventions, specification templates, a checked and coordinated set of details - so that every project starts from a reliable baseline rather than reinventing everything. It means a checking discipline: no drawing leaves the office un-reviewed, coordination between disciplines is verified before issue, and someone other than the author looks at important output, because we are all blind to our own errors. And it means, in construction, the inspection of the works - the architect visiting site to check that what is built matches what was designed and specified, and that quality standards are met, within the scope of the appointed services.

The stakes are high because quality failures are expensive and they are a liability. An error that escapes into a construction drawing becomes a defect on site, a variation, a delay, a cost - and potentially a professional indemnity claim against the practice. The cheapest place to catch an error is at the desk, before issue; the most expensive is in the finished building. This is the whole economic argument for quality systems: they cost time up front and save far more down the line, and they protect the practice's reputation and its professional standing. Invest in the machine, and check what it makes.

One specific, high-value quality practice deserves its own discussion: the design review. This is the deliberate, structured examination of the design at key points by people other than its authors - a stepping-back to ask, before the design is frozen and built upon, whether it actually works. A good review looks across several dimensions at once: does it meet the brief; is it coordinated across disciplines (do the structure, services and architecture actually fit together); is it buildable; is it compliant with codes and regulations; is it within budget; and is it, still, good? Reviews are best held at stage transitions, precisely when a decision is about to be locked in and revisiting it later would be costly.

The value of a review comes from the outside eye and the structured questions. Designers fall in love with their solutions and go blind to their flaws; a fresh, senior, or peer perspective catches what the author cannot see. Structure helps too - a checklist or a set of standard questions ensures the review covers the unglamorous essentials (compliance, coordination, cost) and not just the exciting ones (does it look good). Crucially, a review is not a critique for its own sake; it produces actions - specific things to fix or verify, with owners and dates - and those actions are tracked to closure like any other task. A review whose findings evaporate is theatre.

Design review connects directly to risk, because many project risks are born in the design and are cheapest to kill there. A coordination clash caught in a review is a five-minute fix; the same clash discovered on site is a stoppage, a variation and an argument. A compliance issue caught before submission is a redraw; caught after construction it can be a catastrophe. This is why mature practices build reviews into their programme as non-negotiable gates, not optional extras squeezed out when time is tight - because the review is exactly the thing that prevents the crisis that would have cost far more time than the review ever did.

Risk management begins with a deceptively simple act: writing down, deliberately and early, what could go wrong. The tool for this is the risk register - a living list of the project's risks, each described, assessed and assigned an owner and a response. The discipline of actually naming risks is more powerful than it sounds, because most project disasters are not truly unforeseeable; they are foreseeable risks that nobody bothered to name, so nobody prepared for them. The difficult ground conditions, the slow approval, the client who might change their mind, the long-lead item that might not arrive - these are knowable in advance, and a register forces the team to say them out loud.

Each risk is assessed on two axes: how likely it is to happen (probability) and how bad it would be if it did (impact). Multiplying or combining these gives a sense of the risk's severity and lets you rank them - which is the whole point, because you cannot give equal attention to everything. A high-probability, high-impact risk demands a plan now; a low-probability, low-impact one can be noted and watched. Plotting risks on a simple matrix of probability against impact - the classic red/amber/green risk matrix - turns a long list into a picture that instantly shows where the real dangers are and where to spend your limited management attention.

A register is only alive if it is used. It should be created early, reviewed regularly (risks change - some pass, some grow, new ones appear), and owned - every significant risk needs a named person responsible for watching and managing it, or it will be watched by no one. On larger projects the register is a formal document, sometimes maintained by a dedicated PM or PMC; on smaller ones it can be a simple sheet the architect keeps. The size matters less than the habit. The practices that seem lucky - rarely blindsided, always somehow prepared - are almost never lucky; they are the ones who named the risks in advance and quietly did something about them.

Naming a risk is only half the job; the register must also say what you will do about each one, and there are essentially four responses to choose from. You can avoid the risk - change the plan so it cannot happen (redesign to remove a dangerous detail, choose a proven material over an experimental one, drop a scope that carries too much danger). You can reduce (mitigate) it - lower its probability or its impact (order the long-lead item early, do extra site investigation, add a design review). You can transfer it - shift it to someone better placed to carry it (insurance, a warranty, a contract clause that allocates it to the party who controls it). Or you can accept it - consciously decide to live with it, usually for low-severity risks, ideally with a contingency set aside if it bites.

The art is matching the response to the risk. It is wasteful to spend heavily avoiding a trivial risk, and reckless to merely accept a severe one. The register's probability-and-impact assessment guides this: the high-severity risks earn active avoidance or mitigation and a real plan; the minor ones are accepted and watched. Transfer deserves special care, because it is often misunderstood - insurance and contract clauses move the financial consequence of a risk, but they rarely remove the disruption, the delay or the reputational damage, and a risk transferred on paper to a party who cannot actually manage it is not really controlled at all.

Risk response also links straight to the money and the programme. Mitigations cost time and money now to save more later - ordering early, investigating the ground, adding reviews - and these costs belong in the budget and the programme, not as afterthoughts. Accepted risks are exactly what the contingency exists for. And the professional dimension matters in India as everywhere: some risks are managed through professional indemnity insurance and careful contracts, but the principle throughout is to explain the risk and its treatment plainly and, for the legal and insurance specifics, defer to a lawyer, an insurer and the current contract - never to assume. A risk response plan is where risk management stops being a list and becomes action.

Change is inevitable on every project - the client's needs evolve, the ground surprises you, the design develops, the authority requires something. Change is not the problem; uncontrolled change is. Change control is the formal process by which every proposed change is captured, assessed for its effect on scope, time and cost, decided upon by the right person, and recorded, before it is implemented. Without it, a project dies the death of a thousand cuts: dozens of small, unpriced, undocumented changes that each seemed trivial but that collectively blow the budget, wreck the programme and poison the relationship when the final account arrives full of surprises.

The process is not bureaucracy for its own sake; it is the mechanism that keeps the iron triangle honest. When a change is proposed - by anyone - it is written down, its impact on cost and programme is assessed, and it is put to the person with authority to decide (usually the client, for changes that affect their money or their building). Only when it is approved is it implemented and formally recorded, typically as a variation or change order under the building contract. The magic of the process is that it makes every change a conscious, visible, agreed decision rather than a silent drift, so the client is never surprised and the record is never in doubt. 'Yes, we can add that, and here is what it costs in money and time - shall we proceed?' is the whole of change control in one sentence.

The hardest part is discipline under pressure. On a busy site, with a client asking for 'just one small thing', the temptation to say yes informally and sort out the paperwork later is enormous - and it is exactly how projects lose control. The professional habit is to welcome the change but insist on the process: capture it, price it, get it agreed, record it, then do it. This protects everyone - the client from surprise bills, the contractor from unpaid work, the architect from disputes and claims. In contract terms these become variations with their own valuation and time implications, and administering them fairly is a core duty of the architect as contract administrator. A project with strong change control has no nasty surprises at the final account; a project without it has almost nothing else.

All the controls need a heartbeat - a regular rhythm of measuring where the project actually is against where it should be, and telling the people who need to know. Progress reporting is that heartbeat: a periodic, honest report showing status against programme, cost against budget, the open risks, the changes in train, and the decisions needed. Its cardinal virtue is honesty. A report that hides bad news to keep the client calm is worse than useless, because it removes the chance to act while there is still time; the report's whole job is to surface trouble early enough to do something about it. Good reports are concise, regular, and action-oriented - what is the status, what is off track, what will we do, what do we need from you.

A sharper way to measure progress is earned-value thinking. The trap in naive reporting is confusing spend with progress - having used half the budget does not mean half the work is done. Earned value compares three things: the value of work you planned to have done by now, the value of work actually done (the earned value), and what you have actually spent. Comparing planned to earned tells you if you are ahead or behind on schedule; comparing earned to spent tells you if you are over or under on cost. You do not need the full formal apparatus of earned value management to use the idea - simply asking 'how much have we actually earned, versus what we have spent and what we planned' cuts through the comforting fog of activity to the truth of progress.

Finally, controls close the loop with lessons learned. At the end of every project - and ideally at milestones along the way - the team should honestly review what went well, what went badly, and what they would do differently, and capture it so the next project benefits. This is the step almost everyone skips, because the project is over and everyone is exhausted and already on the next thing - and it is precisely why practices repeat the same mistakes for decades. A practice that genuinely runs post-project reviews and feeds the lessons back into its standards, its estimates and its risk registers gets steadily, compoundingly better; one that does not relearns the same painful lessons on every job. The final control is the discipline to learn.