A full operational diagnostic across five broken delivery systems — and the roadmap to fix them.
I joined a web delivery program through Bridge Partners, serving a large enterprise B2B technology client with a flagship website spanning markets across North America, Europe, and Asia. Five external vendor teams — content, design, strategy and research, analytics, and development — were collaborating across a segmented Microsoft Teams environment with carefully controlled channel access and confidentiality requirements. The program was active. Pages were being built. Deadlines were being tracked.
The delivery infrastructure underneath all of it was fragile — not because of negligence, but because of inherited gaps. The previous vendor had not left workable processes in place, and the incoming team had not had the runway to build them before delivery pressure was already on. Reasonable workarounds, each one made at a point when it was the fastest path forward, had layered on top of each other into a system with no slack left and no single person who had mapped the whole picture.
Mapping it became my first job. What I found was not three problems. It was five.
I was the sole PM on this engagement. I owned the master project schedule, managed cross-vendor handoffs, ran partner-facing milestone reviews, and served as the connective tissue between teams who couldn't always see each other's work. That was the formal role. The work I did alongside it was the operational diagnostic — understanding what was actually broken across the full delivery system and designing the path out.
Authority to implement process changes sat with broader delivery leadership rather than with me. That shaped how I designed the remediation work from the start: thorough enough to be understood and acted on by people who hadn't mapped it themselves, phased in a way the program could actually absorb, and documented to be useful whether the timing for implementation was immediate or not.
I also owned something less formal but equally important: the relationship between the web team and a design vendor that had started the engagement with significant tension. One of my first moves was to set up a standing weekly meeting specifically to rebuild that working relationship. By the time I left, that vendor wrote a generous public endorsement on my LinkedIn.
After mapping the current state across all five workflows, the structural picture was consistent: every system had a single point of failure, no audit trail, and a manual dependency that would break under pressure. This was the kind of fragility that's invisible on a good day and catastrophic on a bad one.
Schedule management
Master schedule maintained in MS Project internally, then manually re-created in separate Excel workback documents for each partner team. Three versions of the truth, no sync, growing risk that partners were planning against outdated timelines with no way to know it.
Copy handoffs
Manual compare-and-merge between two Teams environments, tracked through color-coded Word document highlights. Yellow meant changed copy. Red meant delete. Red font meant placeholder. One missed post, one out-of-office, one wrong version opened — and the system failed silently.
Image and asset management
Cross-team permissions gaps meant assets couldn't be shared directly. Workaround: PM screenshots the image, enters it manually into an Asset Matrix spreadsheet, maintains metadata by hand. The PM was the system. That's not a workflow — it's a single point of failure with extra steps.
QA tracking — immediate risk
Twenty people were about to share a single Excel QA tracker at launch. No row locking, no audit history, no recovery path. This was the most immediate structural risk in the program — one overwrite event away from losing launch-critical defect records.
MS Project and Teams integration
Schedule data lived in MS Project. Stakeholder communication lived in Teams. No connection between them. Status updates required the PM to manually translate schedule state into Teams posts — creating lag, interpretation risk, and confidentiality exposure when the wrong information reached the wrong channel.
I didn't propose a full rebuild. The program had commitments and timelines that didn't have room for that. Instead I designed a phased remediation roadmap: three horizons, each one building on the last, each one scoped to what the program could actually absorb at that point.
Immediate — proof of concept
QA intake via Forms + SharePoint
Designed and piloted a QA intake workflow using Microsoft Forms feeding into a SharePoint-backed tracker. Replaced the shared Excel sheet with structured intake — every submission gets a timestamp, an owner, and a record that can't be overwritten. Estimated to eliminate 80–90% of the most likely failure modes at launch.
Short-term — systems replacement
SharePoint Lists + Power BI visibility model
Designed a SharePoint Asset Library to replace the screenshot-based Excel asset matrix — centralizing image metadata, version control, and partner access permissions. Paired with a milestone visibility model in Teams, SharePoint, and Power BI that gave executive stakeholders live readiness views without exposing the confidential internal schedule.
Medium-term — automation
Power Automate + integrated schedule view
Roadmapped a Power Automate-connected model that would eliminate manual status translation between MS Project and Teams — live schedule data surfaced to the right audiences through role-filtered channel views, reducing PM overhead and confidentiality risk simultaneously.
Documentation
Plain-language current-state map
Documented all five workflow areas in plain language — what the process was, what the risks were, what a pragmatic improvement path looked like. Not a complaint document. A map with a route marked on it, written to hand off cleanly to whoever came next.
The technical fixes were the easier half of this work. The harder half was organizational: getting a team operating under deadline pressure to hold two things at once — meeting immediate delivery commitments and making the structural changes that would make the next deadline less brutal.
That's the tension process improvement work almost always runs into. Short-term pain is visible and immediate. Long-term risk is abstract until it isn't. The organizations that get better at delivery are the ones willing to protect time for both threads simultaneously — to flex, reprioritize, and do the structural work while the delivery work is still in motion.
My original design was collaborative: run current-state/future-state sessions with each affected team, build the remediation plan together, and make adoption something the team chose rather than something that happened to them. That approach required organizational willingness to surface friction as information rather than treat it as a threat. That willingness wasn't fully there, and I respected that while continuing to document and design — because the work would be needed whether the timing was immediate or not.
The QA intake proof-of-concept was approved by delivery leadership the day before the contract ended — designed, tested, and ready to pilot. Just out of time.
Each workflow area had a dedicated current-state/future-state document that made the problem legible to people who hadn't mapped it themselves.
The remediation roadmap was structured for a formal team presentation — the delivery manager had asked me to run that session, and it was ready when the engagement ended.
The design vendor relationship — which had started with real friction — ended with that vendor writing a generous public endorsement on my LinkedIn. Relationship repair is change management too.
The engagement ended before the full remediation plan was implemented. That was consistent with the contract risk I had flagged from week one — the timeline was ambitious and the structural vulnerabilities needed time to address properly.
What I carry from this engagement: process improvement done in parallel with active delivery only compounds when the organization is willing to flex — to protect time for both the immediate deadline and the structural work that makes the next one easier. When that willingness is there, the gains stack. When it isn't, the documentation still matters. It's there for the next person, or the next moment when the organization is ready.
What I left behind was a complete diagnostic, a phased roadmap across all five systems, a proof-of-concept approved and ready to pilot, plain-language documentation the next person could actually use, and a change management framework that was ready to be presented. The work was done. The implementation was the next chapter.
This is some of the most honest PM work in my portfolio — not a triumphant launch story, but a real account of what it looks like to walk into a fragile system, map it carefully, design the way out, and hand the next person a better starting position than you had.