Safety: The Next Criterion of Project Success

For decades, we have been taught that successful projects are measured by three things: cost, schedule, and quality.

Did we finish on time?

Did we stay within budget?

Did we deliver what we promised?

Three neat little boxes. Check, check, check. Project successful. Everybody go home.

Except perhaps we have been missing a rather important box.

Did we do it safely?

And I don't mean safety only in the traditional hard-hat, safety-glasses, don't-stand-under-the-crane sense. That absolutely matters, particularly in construction, manufacturing, energy, and other environments where people can be physically injured. But today's projects operate in a world where "safety" has become much bigger.

Safety can mean protecting people. It can mean protecting information. It can mean protecting systems, customers, vendors, communities, intellectual property, and sometimes even the organization itself.

Perhaps it is time to add safety as another criterion of project success.

A Project Can Succeed and Still Fail

Imagine a major project that finishes two weeks early and $500,000 under budget.

Champagne! Balloons! Someone gets a bonus!

Then we discover that employees were pressured into working unsafe hours to meet the schedule. A subcontractor bypassed required safety procedures. Sensitive project information was stored in an unsecured environment. An AI tool was quietly introduced without appropriate review. Or perhaps the finished product creates a risk nobody seriously considered because everyone was concentrating on getting across the finish line.

Is that project successful?

Technically, according to our traditional measures, perhaps it is.

Practically?

I am not so sure I want to stand too close to that champagne bottle.  After all someone may poke an eye out if the cork flies too hard.

Success cannot simply mean we got there. We also need to consider how we got there and what we left behind.

Safety Is Bigger Than the Safety Department

One of the problems with the word "safety" is that organizations sometimes put it into a very convenient box. Safety? That's Health and Safety's job. Cybersecurity? That's IT. Data privacy? Legal handles that. AI? Somebody somewhere is probably looking at it. Vendor risk? Procurement.

And suddenly everyone owns a tiny piece of safety, which can sometimes mean nobody sees the whole picture.

Projects do not respect organizational charts.

A single project can involve employees, contractors, subcontractors, technology providers, consultants, cloud environments, AI tools, confidential data, physical locations, equipment, customers, and third parties scattered across the world.

Each relationship introduces another place where something can go wrong.

That makes safety a project governance issue, not merely a departmental responsibility.

What Does "Safe" Actually Mean?

This is where project teams may need to broaden the conversation. When assessing whether a project is safe, consider several dimensions:

• Physical safety: Are employees, contractors, customers, and the public adequately protected?

• Cybersecurity: Are systems, networks, access credentials, and project information protected?

• Data privacy: Are we collecting, sharing, storing, and disposing of information appropriately?

• AI safety: Are AI tools being used responsibly, securely, transparently, and with appropriate human oversight?

• Vendor safety: Do third and fourth parties introduce risks we have not adequately evaluated?

• Operational safety: Could the project create instability, outages, process failures, or unintended consequences?

• Psychological safety: Can team members raise concerns, report mistakes, question decisions, and say, "I don't think this is safe," without fearing retaliation?  I use to deal with Mergers and Acquisitions work and it use to baffle my mind that many times an employee who has been handed their severance package has to train their replacement.  I am sure no one ever harbored resentment, right?

That last one deserves considerably more attention than it often receives.

You can have the greatest safety policy ever written, laminated, framed, and hanging beautifully on the wall. But if the person closest to the problem is afraid to speak, your policy may be little more than expensive wallpaper.

The Schedule Should Never Silence the Warning

Projects create pressure.

Deadlines approach. Budgets tighten. Executives want updates. Customers want delivery. Teams are tired. Someone inevitably says:

"We just need to get this over the line."

That sentence should occasionally make risk professionals nervous.

Because once getting over the line becomes the overriding objective, warning signs can start looking like inconveniences.

Testing gets shortened.

Reviews become informal.

Exceptions become "temporary."

Documentation can wait.

Someone decides a control is slowing everyone down.

A concern gets answered with, "We'll deal with that after go-live."

And sometimes "after go-live" is exactly when everyone discovers why the control existed in the first place.

Safety must have enough authority within project governance to challenge cost and schedule when necessary.

That doesn't mean stopping projects every time someone raises a concern. It means creating a disciplined way to evaluate the concern rather than allowing deadline pressure to automatically win the argument.

What Should Executives Be Asking?

If safety becomes a criterion of project success, executive reporting needs to evolve as well.

Instead of hearing only:

Budget: Green
Schedule: Green
Scope: Green

perhaps leadership should also be asking:

What could hurt someone?

What could compromise our information?

What could expose our customers?

What assumptions are we making about our vendors?

Has anything changed technologically since this project began?

Has anything changed from a regulatory perspective?

Are people comfortable raising concerns?

What risks are we accepting simply because fixing them might affect the schedule or budget?

And perhaps my favorite:

What are we not talking about?

That question can produce some very uncomfortable silence.

It can also save a project.

Auditors Have a Role Here Too

Auditors reviewing projects should resist the temptation to look only at whether project controls exist.

We should look at how decisions are actually being made.

Are safety concerns appearing in risk registers?

Are they discussed in steering committee meetings?

Are incidents and near misses analyzed?

Are vendor risks evaluated beyond the initial contract?

Are cybersecurity and AI risks reassessed as technology changes?

Can concerns be escalated outside the normal project hierarchy?

And importantly, what happens when safety conflicts with cost or schedule?

Because policies tell you what an organization says it values.

Trade-offs often tell you what it actually values.

Maybe the Triangle Needs Company

Cost matters.

Schedule matters.

Quality matters.

I am certainly not suggesting we toss decades of project management thinking out the window.

But perhaps our definition of success needs to grow up a little.

Projects today are more interconnected, digital, outsourced, automated, data-driven, and dependent upon technology than ever before. The risks surrounding them have evolved.

Our definition of success should evolve with them.

So the next time someone announces that a project was completed on time, under budget, and exactly to specification, celebrate it.

Then ask one more question.

Did we deliver it safely?

Because a project that reaches the finish line while leaving unnecessary harm, exposure, or unmanaged risk behind it didn't really win.

It just stopped the clock.

And maybe it is time we stop asking only:

"Was the project successful?"

and start asking:

"Successful for whom, and at what cost?"