What this experience taught me
Stepping into project leadership reinforced my belief that tools such as OKRs, Service Blueprints, and Stakeholder Value Maps are practical tools for communication and decision-making that naturally compliment project management. While traditional project management provided the structure for planning and delivery, design methods helped teams build shared understanding, align around outcomes, and navigate uncertainty together.
Applying these methods was experimental in itself. Shifting conversations from outputs to outcomes took time, and sometimes it simply isn't productive when dealing with an integration project. Service Blueprints and Stakeholder Value Maps helped some people see complexity more clearly, while others still preferred familiar documentation such as traditional SOPs.
One of the biggest surprises was how positively stakeholders responded to communicating progress through outcomes and OKRs. Framing the project this way encouraged broader discussions about opportunities to improve performance rather than simply completing the agreed scope. While that created stronger engagement, it also meant balancing new feedback against available capacity and the original objectives became an ongoing leadership responsibility.
Outcome Thinking & OKRs
Shifting the conversation from outputs to outcomes
Coming from UX leadership, I was used to measuring success by the impact created rather than the work completed. Bringing that mindset into project leadership encouraged conversations around business outcomes instead of milestone deliverables alone. OKRs provided a shared view of what success looked like and helped stakeholders understand why each workstream mattered, not just what was being delivered.
Outcomes are iterative
One lesson became clear very quickly: outcome-focused conversations naturally generate new ideas. While this created stronger engagement from stakeholders, it also required balancing emerging opportunities against available capacity and the agreed scope. The framework proved most valuable not as a reporting tool, but as a way to support better decisions throughout the project and influence how future initiatives are approached.
Service Blueprints
Making complex work visible
Service Blueprints have long been one of my favourite tools for understanding services that span multiple teams and systems. While often associated with customer experience, they are equally valuable for exposing operational complexity, dependencies, and ownership.
For this integration project, they became a shared visual language that helped stakeholders understand how work moved across teams, where handovers occurred, and which supporting systems enabled each step. The result wasn't simply better documentation—it created more productive conversations about responsibilities, bottlenecks, and opportunities for improvement.
Maps do not replace onversations
One lesson I quickly learned was that Service Blueprints are most valuable as conversation starters and alignment tools rather than standard operating procedures for individual operational work streams. Different stakeholders naturally focused on different layers of the blueprint depending on their role, making workshops and discussions far more effective than simply sharing the finished diagram.
Like any framework, the blueprint evolved alongside the project. It became less about creating a perfect map and more about building a shared understanding that helped teams make better decisions together.
Ecosystem Maps
Understanding relationships before decisions
Integration means constant evolution, creating a complex network of relationships across organizations, systems, and partners. We often discussed who was responsible for what, but the team struggled to keep sight of the wider context. Mapping the ecosystem made those relationships visible and gave everyone a shared understanding of how information, products, and financial flows connected across the integration.
Creating an Ecosystem Map made those relationships visible. Mapping the flow of information, finances, and goods, the project team could more easily identify dependencies, clarify ownership, and understand the broader impact of operational decisions.
The first map changed the solution
Rather than documenting an agreed approach, the first version became a tool for exploration. As relationships and dependencies became visible, it exposed complexity that hadn't been fully understood during earlier discussions. That insight led the team to simplify the proposed workflow and rethink how responsibilities should be distributed.
The second version reflects that evolution. The value wasn't in producing a perfect diagram, but in making assumptions visible early enough that the project could change direction before implementation.
As the project matured, the map shifted from describing a proposed workflow to describing the operational ecosystem itself.
