Teodora Lukač

01

Self-service knowledge system

EnablementDocumentationOnboarding

Built to scale beyond individual dependency.

+

80%

reduction in repeated support requests after self-service resources became the default path.

The problem

The toolset and process ecosystem expanded over time, and the same questions kept surfacing repeatedly across teams. In a large organization, people needed guidance on using templates, submitting work, following processes, and making routine changes. The signal was clear: the same questions were arriving simultaneously across messages, email, quick calls, and direct outreach. The deeper issue was that knowledge access was scaling linearly with headcount, and the existing approach was not designed to keep pace with that growth.

What I did

Rather than building a generic knowledge base, I mapped the ten questions that were consuming the most support time and built the system specifically around those. Scoping it that way was a deliberate choice. A comprehensive knowledge base would have taken longer to build and been less likely to get used, whereas a targeted one created immediate value and built credibility for the system early. This included step-by-step written guides, short video walkthroughs for visually complex actions, and clear instructions for using templates and following processes.
The key decision was to structure the content around tasks rather than tools alone. People did not want long manuals. They wanted a fast answer to a specific action. So instead of generic documentation, each resource focused on a particular task with short, practical guidance people could apply immediately. Driving adoption required persistence. Self-service resources needed to become the default before people turned to them instinctively. To reinforce usage, I consistently redirected questions to the exact guide, video, or template link while still keeping support approachable. The change became noticeable when people began telling me the resources had saved them time, without being asked.

Outcome

The reduction was visible across Teams messages, emails, quick calls, and repeated direct questions over a six-week period. Before the system, the same ten to fifteen questions were being answered manually every week. After adoption, most of those moved to self-service. Routine operational questions were handled independently, which freed up time for higher-priority work and moved knowledge out of individuals into a shared, reusable system that could scale beyond individual dependency.

My roleOwner of self-service enablement, documentation structure, templates, and adoption support.

StakeholdersAll teams organization-wide, primary users of the system

ToolsJira · Confluence · Adobe CC · Microsoft 365

SkillsInformation architecture · Content strategy · Enablement · Knowledge management

02

Managing risk in multi-stakeholder delivery

Timeline planningReview coordinationScope decisions

The kind of delivery that closes clean.

+

100%

sign-off on deliverables within 4 weeks.

The problem

The delivery date was fixed from the start, but the work could not simply move in a straight line toward it. Within a 4-week timeline, 12+ deliverables had to move through review, revision, approval, final preparation, and handoff, with some parts progressing in parallel and others depending on decisions that could not slip.
The real risk was not volume alone. It was losing time in the schedule through mistimed reviews, delayed sign-off, or late changes landing on work that was already close to handoff. That made the project less about keeping tasks moving and more about controlling the sequence of key decisions. If feedback arrived too late or priority calls were made too slowly, the final week would be spent recovering the schedule instead of closing the work cleanly.

What I did

Starting from the handoff date, I mapped the sequence backwards, set review and approval deadlines around it, and used RAG status tracking to keep project health visible across all active deliverables. That helped surface risk early and protect the parts of the schedule that were actually fragile instead of giving everything equal weight.
I also structured feedback into planned checkpoints with clear turnaround expectations so revisions stayed contained and usable. Rather than absorbing every late request in the same way, I assessed each one against delivery impact: what had to make the deadline, what could be accommodated without affecting sign-off, and what would need to move outside the current scope or timing. That judgment mattered because the role was not just to keep work moving. It was to protect delivery quality without pretending the schedule was more flexible than it was.
Before handoff, I ran a final readiness check across every deliverable to confirm approvals, final versions, file completeness, and packaging so the project closed on substance, not just on paper.

Outcome

All 12+ deliverables were completed, reviewed, approved, and handed off within the 4-week timeline, with no items missing final sign-off. Because the schedule was managed around key decisions and delivery risk, the final stretch was used to close and package the work rather than recover from preventable delays. The handoff landed as a complete, approved set of deliverables rather than a deadline met on paper with loose ends still open.

My roleOwner of schedule control, review planning, stakeholder coordination, scope calls, delivery management, and final handoff.

StakeholdersClient-side decision maker · Review stakeholders · Delivery contributors

ToolsExcel / Google Sheets · Email · Google Drive / OneDrive · Microsoft Teams · Project documentation

SkillsTimeline planning · Milestone management · Review coordination · Stakeholder alignment · Dependency management · Scope decisions · Risk management · Delivery readiness · Final handoff

03

Workflow standardization across teams

Process designChange managementCross-functional

Production time that kept shrinking.

+

50-70%

reduction in recurring production time after repeatable workflows replaced repeated rebuilds.

The problem

As volume grew, the same coordination effort was being repeated cycle after cycle. Recurring requests were moving through the process in slightly different ways each time, because without a shared structure, each team naturally developed its own approach. Over a few months it became clear this was not a one-off issue. Execution steps that could have been standardized were being rebuilt from scratch each time.

What I did

I reviewed how recurring work was actually moving across the process and identified where time was consistently being lost. The variation was concentrated in a small number of high-frequency request types that made up the majority of volume. Standardizing everything at once would have created too much disruption and stalled adoption, so I prioritized those high-frequency types first. Highest time savings, lowest resistance. Early results then made the case for broader rollout. I introduced a standardized workflow for those: shared templates, clearer handoff expectations between stages, and a structure that could be reused instead of rebuilt each time.
A key challenge was building consistent adoption across teams with different working rhythms. Shifting established habits required sustained effort, because familiar approaches felt faster in the short term, even when the new structure delivered better results over time. I stayed persistent with the system until the process became easier to follow than to bypass.

Outcome

Before standardization, the same tasks were repeated in full every cycle, consuming hours that should not have been spent. After, teams followed a consistent structure instead, eliminating repeated work on tasks with identical requirements. That capacity shifted to higher-complexity, higher-value requests that had previously been delayed or deprioritized due to volume. Measurable improvement was visible within approximately four weeks of rollout.

My roleOwner of workflow standardization across templates, handoffs, and recurring delivery patterns.

StakeholdersEngineering leads · Marketing managers · Senior leadership

ToolsJira · Confluence · Miro · Figma

SkillsProcess mapping · Requirements analysis · Change management · Documentation · Stakeholder alignment

04

Cross-team intake and prioritization system

OperationsIntake designPrioritization

One system, every request accounted for.

+

40%

reduction in status-chasing messages across Teams and email after full adoption.

The problem

Requests were arriving through multiple channels including messages, emails, conversations, and inconsistent tickets, with no reliable intake structure. With no central system in place, work was getting lost and visibility was limited across departments. The clearest sign that a more structured approach was needed came when previously completed work re-entered the process due to limited visibility, leading to unnecessary duplication. That kind of overlap is difficult to track until it becomes a pattern.

What I did

I built a structured intake and triage system to bring requests into one consistent flow. I defined the minimum fields a request needed before entering the queue, introduced categorization logic, documented SLA expectations and escalation paths, and set up a regular triage rhythm to surface blocked items, conflicts, and unrealistic timelines before they became execution problems.
A key change was shifting prioritization away from personal urgency and toward real business impact. That required more than applying the criteria. It meant making them visible and explained, so stakeholders understood why one request moved ahead of another. Without that transparency, the system would have been perceived as arbitrary rather than structured. Adoption required consistency across all teams over time, and that consistency was what made the system work.

Outcome

Before the system, follow-up meant chasing updates through messages, conversations, and meetings just to understand status or ownership. After adoption, teams had a single place to check progress without interrupting anyone. Requests that previously slipped through due to missing information were caught at intake instead, and prioritization became more visible and easier for stakeholders to understand. Tracked across all departments over approximately six weeks post-rollout.

My roleOwner of request intake, triage structure, prioritization logic, and ongoing workflow operations.

StakeholdersAll departments organization-wide

ToolsJira · Confluence · SharePoint · Microsoft Teams

SkillsIntake design · Prioritization frameworks · SLA definition · Escalation logic · Jira configuration · Documentation

05

From ambiguous brief to controlled execution

Requirements gatheringStakeholder managementDelivery

Delivery that held up under pressure.

+

2x

reduction in revision cycles across projects where the discovery process was applied.

The problem

Requests would often arrive before the brief was fully defined. Without a shared starting point, work risked progressing on unclear foundations toward a target that had not been properly agreed, producing rework that consumed time already allocated to other work. The problem only became visible once execution was already underway.

What I did

Before execution started, I made sure the request was properly understood. I ran focused discovery conversations to define the real problem, identify the audience and expected outcome, and learn what had already been tried. When the original request would not solve the underlying need, I raised the gap early, agreed on the actual objective with stakeholders, and proposed an adjusted approach before moving forward. The decision to push back on a brief rather than execute it as written was a deliberate risk. It slowed the start, but it protected the delivery from landing on the wrong target.
One challenge was building trust in the process. The natural instinct in fast-moving environments is to start executing immediately, and introducing a structured discovery step required demonstrating its value rather than just proposing it. When a project delivered on time but landed short of what was actually needed, it created a clear opening. I applied the discovery process on the next request, the outcome was stronger, and I showed the comparison between the two directly. That evidence made the case better than any formal proposal would have, and the approach became the standard from that point forward.

Outcome

Before the process, most projects moved through three to four rounds of significant revision. After, the majority required one round with minor adjustments. This was tracked across multiple projects over approximately three months through revision rounds logged in Jira, approval meeting frequency, and repeat feedback patterns. Improvements became visible within one to two weeks on most requests, with adoption compounding over time.

My roleEnd-to-end owner of scope, stakeholder alignment, execution, and delivery.

Stakeholders5+ across creative, technical, and leadership teams

ToolsJira · Confluence · Microsoft Teams · Microsoft 365

SkillsDiscovery · Requirements gathering · Scope definition · Stakeholder communication · Risk flagging · End-to-end execution

Teodora Lukač

Case studies

Impact

Approach

Testimonials

Tools and platforms

Let's
connect

Teodora Lukač

Expertise

Case studies

Impact

Approach

Testimonials

Tools and platforms

Let'sconnect

Let's
connect