When Safety Truly Defines Readiness

At my Project Management training programmes, students occasionally raise an interesting question: Why is Safety Management not specifically categorized as a separate Project Management Knowledge Area or Performance Domain?

My usual response is that safety management is not absent from project management rather, it is deeply embedded within almost every project management process itself. It is integrated into planning, scheduling, scope management, risk management, quality management, stakeholder coordination, and even day-to-day decision-making through expert judgment. Safety is not a standalone function operating in isolation; it is a foundational discipline woven throughout the entire project lifecycle.

Early in my career, I worked as a Site Engineer on an international joint venture in Sri Lanka. We were restoring one of the tallest buildings in the country after it had been badly damaged by a terrorist bomb  attack on a nearby hotel. The job involved replacing external cladding and windows, one floor at a time, in a building that was still partially occupied. Few tenants still had their belongings inside, so access was tightly controlled by a specialized security organization.

To enter any floor, three things had to happen: security approval, the presence of a tenant representative, and official clearance to begin work. Today, we’d call this a “Definition of Ready” a set of conditions that must be fully met before work starts. Back then, we just called it “the procedure.”

One morning, we were scheduled to replace windows on the 30th floor. A team of ten workers was ready, equipment was set, and the task was on the critical path—so any delay meant real consequences for both time and cost. We had asked security to open the floor at 8:00 AM.

Eight o’clock passed. Then 9;00. Then 10;00. No one showed up, and there was no response on the pager.

As a young engineer responsible for keeping things moving, I felt a lot of pressure. I looked through a small gap in the partition and the floor seemed empty.

I sent a message to security saying we would proceed. There was no reply. So I told the team to open the partition and start work. I even took photos, thinking that showed I was being responsible.

It didn’t.

The powerful  safety and security Manager and the team  arrived while the work was already underway. Everything stopped immediately. My site access permit was revoked on the spot. The situation escalated quickly to senior management and even the head office. The workers were upset, tensions rose, and for the first time in my career, I faced a serious setback.

A high-level meeting followed with project leaders, company directors, and security representatives. The message I received was clear and it stayed with me: safety is not  about what looks okay. It is  about what has been properly checked and officially approved.

The floor looked empty, but it hadn’t been cleared. I had bypassed the system. In today’s terms, I treated an incomplete Definition of Ready as if it were complete.

That distinction matters a lot.

While the “Definition of Ready” is often associated with Agile software teams, its principle applies just as strongly in construction. In this context, safety readiness is the Definition of Ready. It means confirming that an area is cleared, permits are issued, and all responsible parties have given their approval. Only when all of that is in place should work begin.