Reducing Project Timelines by 40%
STRIVR | Enterprise VR Technology | 2022–2024
What this is
STRIVR builds immersive VR training programs for Fortune 500 companies — organizations using virtual reality to train employees at scale in high-stakes environments. The work sits at the intersection of cutting-edge technology, creative production, and enterprise project management. The clients are large, the programs are complex, and delivery timelines carry real consequences.
When I joined, STRIVR already had processes. They already had timelines. The infrastructure existed — it just wasn't moving fast enough. Clients were saying it directly to leadership. It was showing up in renewal conversations, in accounts that had started to feel shaky, in the gap between what clients expected when they signed and what they were experiencing during delivery.
The problem wasn't broken processes. It was unexamined ones.
Why this approach — and not another one
The obvious response to a timeline problem in enterprise delivery is to add resources — more project managers, tighter oversight, more formal tracking. I didn't go that direction, because adding oversight to a slow system usually just makes the slowness more visible without changing the underlying cause.
I also didn't go the formal process audit route. Process audits tend to produce documentation that accurately describes what's happening without surfacing why. The knowledge about where things were actually slowing down didn't live in process maps — it lived in the people closest to the work, who had been navigating workarounds and unnecessary steps long enough that those things had started to feel normal.
So I started with conversations. Direct ones, with the internal teams doing the delivery work. Not "what's broken" — which tends to produce complaints — but more specific questions: does this review cycle need two rounds? Is this step creating value or just creating time? What would actually happen if we skipped this?
That approach was deliberate. The goal wasn't just to identify what to cut — it was to build the shared understanding needed to actually change how people worked. A top-down mandate to streamline processes would have gotten compliance. Doing the diagnostic work alongside the teams doing the work got commitment, which is what you need when you're asking people to change habits they've built their workflows around.
What surfaced was predictable in retrospect and invisible before we looked: review cycles that had doubled at some point without anyone formally deciding they should, handoffs that added days without adding quality, steps that existed because they'd always existed, not because anyone could explain what they protected against.
From there the work was straightforward — keep what genuinely served quality, eliminate what didn't, and standardize what remained so it held consistently across every program, regardless of who was staffed on it.
What would have broken
The relational diagnostic approach only works if the people you're talking to trust that the information they share won't be used against them. I was asking teams to tell me where the inefficiencies were, which in some organizational cultures is asking people to identify their own failures. If the environment had been more politically charged, or if leadership had been less aligned on the goal, those conversations would have gone very differently.
There was also a real risk in the cutting itself. Some steps that look redundant from the outside are actually load-bearing — they exist because something broke once without them, and that institutional memory lives in one person who never wrote it down. Moving fast through the streamlining phase without staying curious about why things existed in the first place could have introduced fragility into the process while reducing the timeline. I tried to stay slower in that phase than the outcome number might suggest.
The 40% figure also required holding the line on what we cut once we cut it. Process creep is real — steps come back because someone gets nervous, or a client makes a request that seems reasonable in isolation, or a new team member doesn't know why something was removed and reinstates it as a precaution. Standardizing what remained wasn't just efficiency work; it was protection against the drift that tends to undo this kind of work over time.
What I learned
The number that stuck with me wasn't the 40%. It was how much of the timeline reduction came from removing things rather than improving things. We didn't get faster by getting better at the steps that were there — we got faster by asking which steps needed to be there at all. That's a different kind of work, and it's harder to initiate because it requires questioning decisions that feel settled.
I also learned something about where this kind of work has to start. It starts with the people doing it, not the people overseeing it. The teams closest to the process knew where it was slow — they'd known for a while. What they hadn't had was someone asking the question without an agenda attached to the answer. That's a relatively small thing to provide and it tends to unlock a lot.
What I'd do differently: get to the standardization phase faster. The diagnostic work and the stakeholder alignment took the time they needed, but once the cuts were identified, I was more deliberate in the rollout than I needed to be. The teams were already bought in. I could have moved.
Outcomes: Total project time decreased by 40%. Client feedback on timelines improved. Renewal conversations became less complicated. The team had a consistent, shared delivery foundation that didn't depend on individual heroics to hold together.
"I really never had to worry about misalignment or missed details when Marissa was on one of my projects . . . It's rare to find someone who's so great at both managing projects and building strong relationships." — Hala Keilany, Customer Success | STRIVR
"She has a unique talent for finding alignment even in the most challenging situations, skillfully guiding discussions toward consensus and shared goals." — Kari Moran, Program & Project Management Leader | STRIVR
