A full operational diagnostic across five broken delivery systems — and the roadmap to fix them.
I joined a web delivery program managed through a consulting firm, serving a large enterprise technology client. Multiple vendor teams — web, design, content, 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.
But the delivery infrastructure underneath all of it was fragile. Not because of negligence — because of accumulated workarounds. Reasonable solutions, each one made at a point in time when it was the fastest path forward, had layered on top of each other into a system with no slack left in it 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 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.
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 one of the most generous professional references I have received.
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.
A remediation plan that lives in a document and never gets adopted is just documentation. I knew from the start that the technical fixes were the easier half of this work — the harder half was getting a team that had been operating a certain way for months to change how it operated, without disrupting the delivery timeline they were already behind on.
I built a formal change management framework alongside the technical roadmap: a structured brainstorming process that walked each affected team through the current-state pain points, the proposed future state, and what the transition would require from them specifically. The goal was not to announce a new process. It was to make the team part of designing it, so that adoption wasn't something that happened to them.
The QA intake proof-of-concept was piloted with the team before it was proposed as the standard — designed to be tested, not announced.
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 designed to be presented formally to the broader delivery team — the delivery manager had asked me to run that session before the engagement ended.
The design vendor relationship — which had started with real friction — ended with that vendor writing one of the strongest professional references I have received. 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 left behind was a complete diagnostic, a phased roadmap across all five systems, a tested proof-of-concept on the most immediate risk, 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.