The London Borough of Hounslow was carrying out an enforcement review to redesign how enforcement-related activity— such as engagement with or responses to fly-tipping, anti-social behaviour, parking offences, etc —was organised across the council. Responsibility for these areas sat across seven teams, alongside external contractors, leading to fragmentation, duplication, and unclear ownership. In practice, this meant cases could “pinball” between teams, residents did not know who to contact, and in some cases duplicate penalties could be issued because systems did not align.

The review was driven by both operational and political pressures. Enforcement issues were highly visible, costly to resolve, and important to elected members and residents. There was a need to improve clarity, reduce fragmentation, make better use of data, and rethink how contracts were structured. Data analysis—such as fly-tipping hotspots and antisocial behaviour patterns—reinforced the urgency and helped frame enforcement as a borough-wide system issue rather than isolated problems.

The borough wanted to improve clarity, coordination, and performance, while also considering how contracts and services could be better aligned. The overall ambition was to develop a stronger operating model for enforcement that could perform more effectively in a financially constrained context.

This review took place alongside two other major change programmes. One Programme had already brought together services in the enforcement and community safety space and had left teams adjusting to new roles and changed responsibilities. The second was an organisation-wide digital transformation programme intended to create a more joined-up front door for the council. Together, these meant that the Enforcement Review was happening in a live and changing environment, where structures, systems, and responsibilities were shifting.

A key priority in the early discovery phase was to build a shared understanding of how the system currently worked, before attempting to redesign it.

I used  Responsibility mapping to make a fragmented and partially understood system known and concrete enough to work with. At that stage, discovery had already begun, but understanding remained distributed across teams, and no single view of the system existed.

The method took the form of a simple table mapping enforcement functions against land types. This was a deliberate choice. Land ownership and jurisdiction were key drivers of confusion in practice, and mapping along those lines revealed how responsibility shifted depending on context.

The artefact itself was intentionally simple. What mattered was the discussion it enabled. As stakeholders worked through the table, differences in interpretation emerged. Responsibilities that had been assumed to be clear were revealed to be conditional, overlapping, or inconsistently applied. The exercise also helped identify gaps.

The method created a space where multiple partial understandings could be surfaced at once. It did not attempt to resolve contradictions immediately, but made them visible and discussable. This was critical in a system where fragmentation was structural rather than accidental. A key learning was that the effectiveness of mapping depends on choosing categories that reflect operational reality. Mapping by team alone would not have revealed the same issues. Mapping by land type and function exposed the lived complexity of the services.

This practice supported the work by creating a shared frame for understanding a system that no single person fully grasped. It helped move the project from individual perspectives to collective visibility. It enabled stakeholders to see how responsibilities overlapped, conflicted, or were missing altogether.

It also helped move the conversation from general frustration to specific, actionable issues. Instead of saying “the system is fragmented,” teams could point to real examples—cases being passed between teams, duplicate enforcement actions, or unclear ownership of land-based issues.

It also grounded the conversation. Instead of describing problems in general terms, the stakeholders could point to specific scenarios where responsibility was unclear or duplicated. This made subsequent design discussions more focused and actionable.

• Shared understanding had to be actively constructed: No single person held a complete view of the system. The method worked because it brought together multiple partial perspectives rather than trying to replace them with one authoritative version. 
• Simplicity enabled participation: The basic format of the table made it easier for stakeholders to engage. A more complex artefact might have created distance or slowed the conversation.  
• The ‘current state’ was not stable: Because restructuring and digital transformation were happening in parallel, the system being mapped was itself evolving. This meant the output was necessarily provisional.  
• Visibility does not equal resolution: The method surfaced structural issues, but did not resolve them. Alignment required further negotiation and design work beyond the mapping itself.  
• Working with incomplete information was unavoidable: The scale of the system meant that discovery could not be exhaustive. The method became part of how discovery continued, rather than a final step after it.