Driving delivery across 28 Ericsson sites
Multi-site IT infrastructure and service work made easier to propose, approve, deliver, follow up, and close across approximately 1,200 users.
Project Executive · Sysnet Global Technologies · HPE-Ericsson Account · Jan 2015 - Sep 2018
The work
I supported IT infrastructure and service-delivery activity across the HPE-Ericsson account in India. On any given week that meant coordinating across 28 sites, approximately 1,200 users, and a mix of project managers, engineers, vendors, and customer stakeholders, each with their own view of what was urgent.
My role sat between the customer request and the completed work. A request came in, and I helped shape it into a proposal, line up the people and approvals needed to deliver it, keep its progress visible while it moved, follow up on anything blocking it, and confirm it was genuinely finished before it was closed.
It was not one technical programme with a single start and end. It was a steady stream of infrastructure and service work, each piece at a different stage, that had to move through the same delivery cycle without losing ownership, context, or momentum.
What made it complex
The challenge was rarely a single technical issue. It was the dependency chain around it. A straightforward-sounding request could touch customer stakeholders, project managers, engineers, vendors, site users, commercial approvals, scheduling constraints, and possible downtime before it was done.
With work spread across sites and owners, the real risk was not difficulty, it was drift: a task quietly waiting on an approval, a follow-up nobody picked up, an implementation marked done but never verified. Progress depended on always knowing where each piece stood, who needed to act next, and what could stop it from moving.
What I owned
Day to day, I owned the coordination layer. Keeping open work visible, chasing the next action, and confirming that activity was genuinely finished rather than just started: the trackers, the follow-ups, and the closure checks were mine to keep moving.
I supported the commercial side rather than owning it. I helped turn customer requests into proposals and move them toward approval, but the approvals themselves, and the commercial decisions behind them, sat with the customer and account leadership.
The technical work sat with the engineers and vendors. My job was to align them, sequence delivery around approvals and downtime, and make sure nothing fell between owners as a request moved through to closure.
Approach
I used a consistent delivery rhythm to turn customer requests into work that teams could understand, approve, execute, verify, and close. In practice it came down to a few habits applied every time: every piece of work had a clear owner and a clear next action, status was written down rather than remembered, decisions and approvals were captured where people could see them, and nothing was treated as finished until follow-up confirmed it. The aim was never more process for its own sake, it was to keep ownership, status, decisions, and follow-up visible so work did not stall in the gaps.
The questions that ran the day
These were the practical questions behind day-to-day delivery decisions.
How the work stayed moving
The delivery rhythm depended on simple operating discipline.
Trackers kept open work visible across sites, owners, approvals, delivery activity, and pending actions.
Standard operating procedures helped teams follow the same path from customer request through proposal, approval, implementation, follow-up, and closure.
Regular communication kept project managers, engineers, vendors, and customer-side stakeholders aligned on progress, blockers, decisions, and next steps.
Follow-up meetings confirmed whether the work had been implemented correctly, what remained open, and whether the project could be formally closed.
No -> standard plan
Yes -> align timing
No -> proceed
Yes -> workaround / escalate
Check implementation, open items, and closure status.
What the work enabled
My contribution was not to reinvent the account. It was to help the delivery system operate with greater consistency and visibility.
Clearer visibility across open work, ownership, and next steps.
More reliable follow-up across sites, engineers, vendors, and customer stakeholders.
Better coordination between customer requests, proposals, approvals, delivery, and closure.
Fewer loose ends as infrastructure and service activity moved from request to completed work.
Clearer communication for stakeholders who did not need every technical detail but did need an accurate view of progress.
What it taught me
Enterprise technology delivery depends on more than technical execution.
It depends on making the work visible, clarifying ownership, communicating at the right level, and following through until implementation and closure are confirmed.
That lesson still shapes how I approach product, transformation, and delivery work today: the system around the work matters as much as the work itself.
"Visibility, ownership, communication, and closure matter as much as the technical work itself."