Managed or Co-Managed IT? Start With Who Does What

When your IT team needs more capacity, the first question is often whether to hire, outsource or share the work. A more useful starting point is to identify which work needs an owner. Otherwise, a support agreement can leave two teams expecting the other to act.

For Australian business owners, operations leaders and IT managers, the practical test is simple: could both teams explain who responds, who approves and who confirms the job is finished? Use that test to shape your support model before comparing proposals.

Choose the arrangement around your team

A managed IT arrangement can suit a business that wants an external team to handle an agreed range of ongoing technology operations. You still need someone inside the business to set priorities, approve expenditure and explain operational requirements. Outsourcing delivery does not remove those decisions.

Co-managed IT can suit an organisation with internal IT capability that needs additional capacity, specialist skills or coverage for particular functions. The internal team might retain business application knowledge and project leadership while a provider handles agreed infrastructure tasks. The division should reflect your people and systems; it is not a standard split that works everywhere.

If the pressure comes from one finite migration or upgrade, separate that project from ongoing support. If routine work repeatedly consumes the time intended for improvements, examine recurring responsibilities. The distinction helps avoid buying a continuing service to solve a temporary problem, or expecting a project budget to cover ongoing operations.

Build a one-page responsibility checklist

Take five recurring activities from your own environment and work through them with the people who currently do the work. Choose specific activities such as resolving a failed workstation update or escalating an accounting application outage. Broad labels such as “maintenance” hide too much.

• Scope: which devices, locations and applications are included, and which need another supplier?
• Trigger: what starts the work—a user request, an alert, a calendar date or an approved change?
• Delivery owner: which team takes the next action, and where does it record progress?
• Approval: who can authorise downtime, extra spend or a change affecting business operations?
• Coverage: when is the task monitored or worked on, and who covers absence?
• Completion: what evidence shows the task is finished, and who checks the business outcome?
• Escalation: who takes over if the first team cannot resolve it or a third-party vendor is needed?

Give each action one clear lead, even when several people contribute. For example, the provider might investigate a failed update, the internal IT lead might approve the next maintenance window, and an application owner might confirm the system works afterwards. This is an illustrative division to discuss, not a promised service inclusion.

Test the handover with a realistic scenario

Imagine your finance application becomes unavailable just before payroll processing. Ask both teams to describe the first three actions. Where is the issue logged? Who checks whether the problem sits with the device, network or application vendor? Who tells the finance team what is happening?

Then change one detail: the internal IT lead is on leave. If the answer becomes “we would call them anyway”, the arrangement needs a documented delegate. Repeat the discussion for an incident outside your normal operating hours. Do not assume that automated monitoring means a person will investigate every alert around the clock.

Read service measures and exclusions together

Ask what a response target actually measures: acknowledgement, technical investigation or another defined step. Ask separately how restoration and resolution are handled. A fast initial reply does not, by itself, describe when staff can return to work.

Check how priority is assigned, which support hours apply and what happens while a hardware or software vendor investigates. Compare the included work, project work, after-hours charges, licences and onboarding effort alongside the headline fee. For shared support, also account for the internal time needed to approve changes and maintain business context.

Make security responsibilities explicit

ASD’s guidance on engaging managed service providers recommends clear security expectations, controlled provider access, visibility of provider activity and incident notification arrangements. Use these as discussion points when defining the relationship.

Record which systems the provider can administer, how that access is protected and reviewed, and who receives security notifications. Agree how the teams will communicate if normal channels are unavailable. For cloud services, check the platform’s own responsibilities too: ASD’s shared responsibility guidance explains why customers still have security tasks to fulfil. Adding an IT provider should clarify who performs those tasks.

Review the arrangement after real work

Set an initial review date and bring examples: a ticket that crossed team boundaries, a change awaiting approval and a recurring issue. Check whether the written responsibilities matched what happened. Update the scope when locations, applications or staffing change, and agree how documentation and access will be handed over if the arrangement ends.

Bring your support gaps to the conversation

Zarbtech’s view is that an effective support model gives people clear work and clear handovers. Our Managed IT services support ongoing technology operations, while Co-Managed IT services work alongside an existing IT team. Bring your responsibility checklist and the tasks that keep slipping. We can discuss an appropriate scope, including what stays with your team and where additional support would help.