In his three-part blog series on building transformation capability in WHS teams, Will Mosenthal, our Director of Transformation & Delivery, unpacks the patterns we've observed in WHS functions navigating complex transformations, exploring the capabilities and structures we think leaders need to build to close the gap between strategy and delivery.
Each post stands alone, but together they trace a path from team-level realities through to the institutional structures to deliver change in WHS teams.
In Part 1 of this series, we set out the four patterns we see across WHS functions trying to deliver complex change. These are: safety professionals who are unfamiliar with project management being expected to drive strategic projects; teams operating beyond their capacity; digital and AI initiatives being a different kind of work; and the routine mis-framing of digital WHS initiatives.
In Part 2, we explore what works at the team level and the conditions around the team needed for transformation to be delivered effectively.
Design delivery practices that suit your WHS environment and team
For a lot of safety professionals, the world of project management – particularly when delivering new technology – can feel overwhelming. There is no shortage of methods, frameworks and templates available on the internet or from elsewhere in the organisation. Typically, there is a default to rehashing IT project methodologies and templates, which were designed with different expectations and for different users. They can quickly become laborious to use and disconnected from what the WHS team is trying to deliver and achieve.
Our observation is that the practices that work in a WHS team tend to be the ones that have been adapted to their specific WHS context. This usually means keeping delivery simple, clear and proportionate to the work at hand and using frameworks and templates that have been designed for delivering projects within that WHS team’s portfolio of change. Examples might be a shared delivery lifecycle and framework the team can describe in a sentence, a project charter document template that fits on a couple of pages or a project reporting template that uses simple language and is easy to update and understand. Reporting cadences need to align and connect with how the team already works and not add unnecessary meetings and overhead.
The ways of working and tools can be simple, but the expectations attached to them must be rigorous. Once a plan, scope and budget are agreed and baselined, project leads and executive sponsors need to manage to what has been committed.
Shared language matters just as much as shared tools. A good example is the way risks and issues are described in project delivery. On the surface, this should be familiar to WHS teams who are made up of risk management professionals, but the project vocabulary overlaps with terms safety people already use day-to-day. In safety, a hazard could cause harm, a risk is the likelihood and consequence of it being realised, and an incident is the hazard realised. In project delivery, a risk is something that might affect the project’s timelines, scope, budget or impact, and an issue is something that has already impacted one or more of these.
The instinct that serves safety professionals well in their technical work – surfacing a hazard early is good practice rather than failure – is the same needed in project delivery. Naming a risk or issue and its mitigation early is a sign of best practice and discipline, not a signal that the project is in trouble.
Finally, developing a rolled-up, end-to-end view across the projects in the function is critical. Rolling individual projects up into a single portfolio view enables senior leaders to see the real load on the team, make trade-offs on priority and allocate budget and resources where they’ll matter most. Without that view, leaders make project-by-project decisions that don’t add up at the function level, which can impact the value of the initiatives being delivered.
Uplifting project delivery capability looks different for different WHS teams
Transformation and project delivery skills and capability in WHS teams are rarely uniform. Some safety professionals have naturally strong planning instincts and well-established stakeholder practices, meaning that taking on new project management responsibilities isn’t a big shift or learning. Other safety professionals might be deep technical experts for whom structured planning, dependency management and upward communication are not natural strengths. As a result, uplifting the capability in the team with a one-size-fits-all approach doesn’t generally work.
We’ve seen several different approaches to uplifting this capability in WHS teams. Mentoring from peers inside the WHS team or from other functions (often IT) can be a low-overhead way to build capability and support a learn-by-doing approach. Formal project management training is another option, particularly for team members who might benefit from a structured grounding in the discipline.
The teams making the strongest progress tend to be the ones that acknowledge the spread of capability, surface the strongest practices in the team as examples for others and offer support and encouragement to the team members who need it most. The objective is to lift the baseline enough that the team can deliver strategic work with the same credibility that they bring to technical WHS work.
Engaged senior leaders who understand their role as sponsors
The team-level practices we’ve described above are important, but the critical enabler to delivering transformation – and in parallel uplifting delivery capability – is active engagement and support from senior leaders and project sponsors.
An effective sponsor has a very particular role as an agent for change and transformation leader. They make trade-offs visible when the team is being asked to do too much at once. They unblock cross-functional issues a project manager or team can’t resolve on its own. They give the team air cover when something needs to slip or change, and they model the escalation behaviour they want to see by responding to early warnings with support, ideas or coaching rather than over-scrutinising or blaming.
This is often a particular challenge in WHS. Senior WHS leaders usually have a similar professional pathway as their direct reports and may not have had best-practice project delivery and sponsorship modelled to them. They are now being asked to play a role they haven’t necessarily seen done well. This is amplified further with the demands of a modern safety leader being proficient and fluent in managing data and technology challenges and opportunities as well as the core safety practices.
Another challenge we see for both leaders and team members is making the transition from a mode of line manager and direct report to a mode of sponsor and delivery lead. This is particularly challenging when team members are managing project delivery as a part-time responsibility alongside their BAU day job. Lines can easily be blurred and confused, and the types of engagement, expectations and conversations between these modes are usually quite different. Our recommendation is for leaders and team members to set aside focused time for project updates and problem solving, which is a separate meeting or conversation from how they engage on BAU or career development topics.
Lastly, the way the work is talked about more broadly in an organisation by leaders sets a tone. How senior leaders describe safety projects in budget conversations, board updates and town halls determines what kind of resourcing, sponsorship and tolerance for disruption the team gets. As we discussed in Part 1, we see digital safety projects routinely under-framed as IT upgrades or over-framed as AI transformation, and both provide their own challenges for the team delivering the project.
How to bring this together
None of this is straightforward to solve, and the teams making the best progress are usually not doing it alone. They are drawing on capability from elsewhere in the organisation, including IT, HR, change management and specific program delivery functions.
Where the gap is too big to close from internal capability alone, they are supplementing with external support. The point here is that building delivery capability in a WHS team is rarely a purely internal exercise, and seeking support – either internally or externally – is how the strongest teams make progress.
Even where this is working at the team and immediate leadership level, we’ve seen large WHS functions running multiple concurrent transformation programmes hit a structural ceiling. Managing cross-functional dependencies with IT, operations, HR and finance needs a home that doesn’t exist in most organisations. In the next post, we share an idea we have been working through for managing these dependencies and the opportunity for WHS functions trying to deliver major transformation at scale.
