Most delivery problems begin before delivery.

What I Did

I recognized this as a program governance problem disguised as a technical disagreement. The answer wasn't to let teams debate hypothetically. It was to generate real evidence and let stakeholders make informed decisions.

I proposed a two-week feasibility spike:

• Design team would produce representative screens for both applications.
• Engineers would attempt to build them in LDS/Heroku.
• We'd evaluate what worked, what didn't, what the effort implications were, and where experience consistency/compromises would matter.

The spike was structured but fast. We didn't over-engineer it. We just needed enough evidence to convert speculation into reality.

With evidence in hand, I facilitated a cross-functional alignment session. Client IT, business stakeholders, engineering leads, design leadership, and the consulting team (BCG) all attended. The conversation shifted from 'which approach is better' to 'given these constraints and tradeoffs, what's the most feasible path to the business outcome?'

We evaluated trade-offs across user experience quality, time-to-market, cost, platform constraints, maintainability, and program objectives.

The group aligned on a hybrid strategy:

1. CTS and SFA would use LDS (internal staff-facing applications, lower customization risk).
2. Dealer, Retailer, Contractor, Partner apps would be custom builds (external user-facing, higher experience expectations).

Clear scope boundaries. Clear design direction. Clear resource planning.

As an additional outcome, design capacity freed up (LDS implementations didn’t need much design work). Rather than leave that capacity undefined, I proposed embedding UX validation into the UAT process. I framed it not as scope expansion but as risk mitigation: 'UX issues discovered in UAT are cheaper to fix than issues discovered after launch.' This secured alignment and integrated structured design outcome testing into QA, further protecting program KPIs.

What I Did

I took an evidence-based approach to justify the work strategically.

First, I conducted quick research: I had researchers on bench do heuristic analysis and usability testing on the Loyalty app. The findings were clear: benefit tier structures were unclear, point redemption flows were confusing, and the overall experience created friction that contradicted our engagement goals.

Next, I created a prototype of the point redemption flow: showing what good could look like with targeted improvements.

Then I framed the pitch strategically. Instead of walking into a "scope expansion" conversation, I walked JK Cement's business team through the prototype and explained how the loyalty app's current state was leaking value from the 7-app transformation. I positioned our work not as "designing another app" but as "protecting the outcomes you're investing in."

The business team bought it. They saw we understood their actual problem, not just our project scope. We got alignment and budget.

Finally, I embedded the loyalty app work seamlessly into the 7-app program. Same cadences, same team context, same stakeholder touchpoints. The client saw us as strategic partners who cared about outcomes, not just deliverables.

What I Did

I approached this as a portfolio-level prioritization problem, not a hiring problem.

First, I conducted a rapid portfolio-wide assessment: actual resource availability, utilisation, project timelines, upcoming milestones, and where flexibility existed.

Then I classified the portfolio by elasticity: which engagements could absorb schedule changes (elastic programs with timeline flexibility and risk management through re-sequencing), and which required protection (rigid programs with contractual commitments or critical approaching deadlines).

With this framework, I developed response scenarios for leadership:

• strategic resource reallocation +
• delivery re-sequencing +
• phased execution +
• temporal external capacity +
• hiring acceleration.

This wasn't choosing one solution, it was orchestrating a combination that balanced growth and stability. Following leadership alignment on a hybrid approach, I coordinated portfolio-wide adjustments.

I then facilitated stakeholder alignment. Every stakeholder understood the capacity constraint, the prioritization logic, and the staffing trade-offs. We moved from debate to a single operating plan the organization could execute confidently.

What I Did

I realized this wasn't a process problem; it was an operating model problem. Sales, PgM (me), Finance, and Delivery were operating in silos.

• Sales committed dates to clients without checking delivery capacity.
• Finance tracked commercial readiness without visibility into allocation readiness.
• PgM allocated resources without understanding commercial priorities.
• Nobody had a shared view of pipeline demand.

So I proposed a unified intake gate (not a new tool, but a mechanism where pipeline information flowed through a single, shared system). After discussing with Sales, we aligned on using a Sales-PgM pipeline tracker as the single source of truth. The tracker required details on what had to flow through it: project name, client, start date, confidence, SOW status, engagement type, effort estimates, resource requirements, and revenue size.

The key was adoption. Sales initially saw this as overhead. I established a simple principle: 'If it's not visible in the intake system, I won't consider it for allocation.' This created discipline. I initiated it, demonstrated the value (faster staffing decisions, fewer surprises), and over time, organically, it became the accepted way of working across nine Sales stakeholders.

What I Did

I introduced multiple feasibility checkpoints in the Design-Engg workflow, as mandates:

• Engineering would review IA and feature concepts before detailed design progressed.
• Before client presentations, Engineering would review wireframes and UI to flag feasibility concerns and complexity issues.
• Backend/interface definition checkpoints were established.
• Design QA gates required validating builds against designs.

Each gate was structured to surface constraints when redesign was still possible, not after lock-in.

I introduced a critical mindset shift: 'Handoff is not complete when Design shares files. Handoff is complete when Engineering accepts the handoff.' This changed accountability.

The approach was crucial: I didn't mandate all this immediately. I piloted across 4 projects, gathered feedback on what was working and what felt like overhead, and iterated. Only after demonstrating success (earlier risk discovery, faster delivery, better quality, improved relationships) did we run a studio-wide rollout. This mattered because change at this scale only happens when teams see value and choose adoption.

What I Did

I proposed a pod-based operating model where cross-functional teams (UX Lead, UI Lead, Designers, Project Managers, Researchers) would both shape the approach AND deliver it. The intent was radical simplicity: Same team from discovery through launch, eliminating handoff friction and preserving strategic context.

I introduced structured designer rotation between pods, with performance notes captured at each entry and exit from a pod. This meant performance reviews were grounded in observed work from leads who'd actually worked with designers on active projects, not secondhand impressions from Reporting Managers.

The pod model also created a mechanism to distribute strategic work (pitches, discovery, proposals) across leads rather than concentrating it with a few, improving organizational resilience.

What I Did

I recognized this as a knowledge management problem, not a tool problem. Someone could have said, 'Let's build a UX repository.' But that would miss the real challenge. A repository without governance becomes clutter. Without adoption incentives, it gets abandoned. The real problem was: how do you create a sustainable mechanism for capturing, organizing, and reusing knowledge as you scale?

I designed an operating model focused on three things:

1. making knowledge easy to discover,
2. keeping it organized and current over time, and
3. making reuse the natural behavior (not something required by mandate).

1. Making knowledge discoverable meant establishing a taxonomy: how do we organize patterns so designers can find them across domains? How do we annotate designs with rationale and context, not just artifacts?

2. Keeping knowledge healthy meant establishing governance. Who maintains the library? How do we prevent outdated patterns from becoming misleading? Regular audits. Content lifecycle management.

3. Making reuse natural meant embedding it into how teams work. Project kickoffs started with a library search: 'Let's see if we've solved this before.' New designers learned this during onboarding. Leadership visibly valued reusing proven patterns rather than reinventing.

What I Did

I designed a cascade of decision forums organized around three core governance principles:

• Signal Clarity (early risk visibility),
• Decision Alignment (who decided what & why at each layer), and
• Leadership Visibility (portfolio-level patterns).

I structured existing conversations into a predictable rhythm.

1. PM standup (twice a week, with PM team): surface what's happening this week, identify risks emerging, flag blockers before they become crises. This is early warning. We can see projects going off track in real-time, weeks in advance.
2. Project Recovery cadence (ad-hoc): go deeper on active problems (root cause, recovery approach, accountability).
3. Sales Pipeline Review (with Sales): review incoming pipeline projects, and staffing requests
4. Weekly Resource Allocation cadence (with design leads, sales and PMs): see where people are allocated, identify constraints, make allocation decisions. Structured in one meeting, to see the full picture and decide fast.
5. Weekly Utilisation Tracking (on Thursdays, with PMs): tracking of net billable utilisation across projects this week; summarised into weekly utilisation reporting to leadership
6. Capacity Planning (for design leads and PMs): forward looking weekly-bandwidth view in hours/week. 15-mins on-call review to ensure async updating isn’t ignored.
7. Fortnightly Finance sync: track invoicing milestones, margin risk, buffer status. Executive reviews (monthly and quarterly): portfolio-level insight, patterns, learning.
8. PM and Marketing team weekly cadence: for social collaboration initiatives with clients, case studies.
9. Scheduled PM 1:1s: coaching and accountability.
10. Monthly Business Reviews (with executive leadership): leadership visibility.

The architecture worked because each layer served a single question with the right stakeholders. Information flowed up (risks, constraints, data). Decisions flowed down (allocation commitments, hiring needs, strategic direction).

What I Did

I reframed escalation from failure to a management tool. Escalations are inevitable, the question is: how do we manage them systematically so they create learning, not just stress?

I built three mechanisms.

1. First, an escalation criteria framework: not everything that's hard needs to escalate. We defined what does and to whom, preventing noise.
2. Second, a structured escalation review (bi-weekly SOS call): when a project escalates, it enters with required information: What's the issue? Root cause? Impact? Recommended action? No vagueness. This became part of the governance rhythm, not a separate crisis process.
3. Third, escalations became a learning mechanism: we logged every escalation (what happened, why, how resolved, steps to avoid recurrence). Over six months, patterns became clear.