Delivery
IT Project Management
Someone senior owning the plan, the vendors and the deadline — so the project actually lands.
You might need this if
- A rollout that was supposed to take six weeks is in month five.
- Three vendors are each waiting on one of the others, and nobody is chasing it.
- The person running the project also has a full-time job doing something else.
- You are being asked to approve decisions you have no way to evaluate.
What usually goes wrong
Small-business IT projects rarely fail on the technology. They fail because nobody owns them. The office manager is coordinating a phone system cutover between calls, the vendor is answering questions but not driving, and the decisions that need a technical opinion get deferred until they become emergencies.
The result is predictable: schedules slip quietly, scope creeps in through informal requests, and the go-live happens on a Friday with no rollback plan. Then the invoices arrive for work nobody remembers approving.
How I run a project
I take ownership of the delivery, not just the advice. That means a written scope before anything starts, a schedule with real dependencies rather than wishful dates, and a single point of contact who chases vendors so your staff do not have to.
You get a status update every week — what moved, what is blocked, what it has cost so far against the estimate. No surprises at invoice time. If the project needs to change direction, you hear it while there is still time to decide.
Cutovers get a runbook and a rollback plan, and they get scheduled when a failure would be survivable. Every project ends with documentation your team or your next provider can actually use.
Projects I take on
Office moves and new-site buildouts. Phone system and internet circuit replacements. ERP, practice-management and line-of-business system implementations. Server decommissioning and cloud cutovers. Vendor transitions, including replacing an incumbent managed service provider without a coverage gap.
What you get
- Written scope and success criteria, agreed before work begins
- Project schedule with dependencies, owners and decision deadlines
- Single-owner vendor coordination — you stop being the middleman
- Weekly written status with hours logged against estimate
- Cutover runbook with a tested rollback plan
- Closeout documentation package and handoff walkthrough
A good fit when
You have a defined project with a real deadline and no one internally with the time or technical standing to run it.
Not a fit when
You need day-to-day helpdesk coverage or someone on call. That is a managed service provider, and I am happy to help you pick a good one.
Common questions
Do you replace our existing IT provider?
No. I work alongside whoever supports you day to day. I represent your interests in the project and hold vendors — including your MSP — to the schedule and the scope.
How many hours does a project like this take?
Most projects run 4–10 hours a week during active delivery, less during vendor lead times. You get an estimate with a range before anything starts, and weekly hour reporting against it.
What if the project stalls on the vendor side?
That is precisely the work. Chasing vendors, escalating when responses stop, and documenting delays so you have leverage in the contract conversation.
Have a project you need to get right?
Book a free 15-minute call. No pitch, no jargon — just a straight read on whether I can help and what it would take.
Or email ryan@rmitcs.com

