Project management in systems integration and corporate IT. Led development teams building custom systems for clients — requirements, specification, scheduling, go-live and end-user training — then moved into managing consultants placed across more than ten client sites at once.
IT industry 2001 – 2020 · over ten years of it in project management
Career break 2009 – 2013 for childbirth and childcare; returned to project management in 2013 and went on to run a department.
The first five years were spent building, not managing. That decided how I ran projects afterwards: I know what a vague spec costs in rework, and how many places a late change touches, because I was the one making those changes.
One is finishing a project. The other is keeping a dozen projects from going wrong at the same time — and that one isn't about schedules, it's about people.
Both were already someone else's half-finished work, with the situation already happening. What makes inheriting harder than starting: you don't get to begin again.
Taken over mid-project: a national certification exam held over two days for 9,381 candidates.
This class of system has no second attempt. A failure on exam day isn't a delayed release — it is every candidate in the country. So the preparation wasn't about feature completeness; it was about having thought through and rehearsed every way it could break.
Zero incidents.
Inherited on the brink of never closing. Work kept shipping, but there was always one more item — the two sides had never agreed on what "finished" meant.
My first move wasn't a schedule. It was to renegotiate the definition of done with the client — turning it from a feeling into a written set of conditions both sides signed up to. Once that was settled, the rest was just execution.
The project closed.
That second one became the rule I've used ever since: a project that won't close usually isn't short of work — it's short of an agreed finish line.
IT Services at Qisda, planning, rolling out and maintaining systems across the group. The users were colleagues, which makes a rollout a question about people.
After this industry I opened a restaurant, ran digital operations for a brand, delivered a client project, and built an AI operating system for myself. It looks like a long jump. It was the same problem each time.
LTTC was "renegotiate the definition of done". Later: the client contract turned sign-off into a dated event; the booking system turned "who hasn't confirmed their order" into a database view; the AI agent turned "what needs doing today" into a line on a screen. All the same move:
turning "done"
from something you feel
into something you can see.
The only difference is that it used to take meetings and documents. Now I can build it into the system directly — and I can build it because the first five years of my career were spent building. That part didn't come from AI.