IT Services Scope Checklist in Nigeria

Scope the problem before comparing providers

"We need IT support" can mean fixing staff laptops, moving company email, building a customer portal, securing cloud infrastructure, or managing several vendors. Those are different capabilities, risks, and engagement models.

A scope of work helps a Nigerian business describe what must improve, who owns each responsibility, and how both sides will know the engagement is working. It also helps a provider say clearly which services fit its team and which belong with another specialist.

Use this checklist before requesting proposals for IT services in Nigeria. It is suitable for a new engagement, a vendor change, or a defined improvement project.

1. Record the current environment

Start with an inventory, not a solution.

| Area | Questions to answer | |------|---------------------| | People | How many staff, contractors, branches, and remote workers need support? | | Devices | Which laptops, desktops, phones, routers, printers, and shared devices are in use? | | Identity | Which email provider, directories, admin accounts, and multi-factor authentication controls exist? | | Applications | Which SaaS tools, websites, custom systems, and spreadsheets are business-critical? | | Infrastructure | Where are domains, DNS, cloud workloads, backups, and source-code repositories managed? | | Data | What customer, employee, payment, health, or other sensitive data is handled? | | Vendors | Which third parties currently manage internet, hardware, software, hosting, and security? |

Mark unknown items rather than guessing. Finding missing ownership or undocumented systems may be one of the first engagement outputs.

Do not send passwords, API keys, or customer records with the initial request. A serious provider can estimate discovery from an inventory without receiving production access.

2. Define outcomes in business language

Each requested service should connect to an observable result.

Weak scope:

Improve our IT and make systems reliable.

Useful scope:

Establish company-owned administration for our domain and email, enable multi-factor authentication for staff, document account recovery, and test that authorised administrators can restore access.

Other outcome examples:

• New employees receive approved accounts and devices through a documented onboarding process.
• A branch can continue its essential workflow during an internet outage.
• Website enquiries reach the correct sales team and can be traced from submission to response.
• Business-critical files are backed up and a sample restore is tested.
• Management can see the owner, renewal date, and cost centre for each technology subscription.

Outcomes make proposals comparable even when vendors recommend different tools.

3. Separate the work into service lanes

IT services often span several lanes. State which ones are in scope:

Workplace and support

• Staff onboarding and offboarding.
• Device setup, patching, and inventory.
• Email, calendar, shared drive, and collaboration support.
• Help requests and escalation.

Cloud and infrastructure

• Domain and DNS administration.
• Hosting, deployment, monitoring, and backups.
• Network or branch connectivity coordination.
• Cloud cost and access reviews.

Security

• Multi-factor authentication and privileged-account review.
• Endpoint protection and patch baselines.
• Backup and restore testing.
• Incident contacts and response coordination.

Websites and digital channels

• Website maintenance and content workflows.
• Forms, analytics, CRM, and WhatsApp handoff.
• Performance, availability, and security updates.

Business applications

• SaaS selection and configuration.
• Custom software maintenance or integration.
• Data migration and reporting.
• Process automation.

Technology planning

• Current-state assessment.
• Prioritised roadmap and budget inputs.
• Vendor evaluation and architecture review.
• Documentation and governance.

One provider may cover several lanes, but the scope should not assume every IT company is a hardware reseller, managed service provider, web studio, software team, and cybersecurity specialist at once.

4. Define inclusions, exclusions, and boundaries

For every lane, write:

• Systems and locations included.
• Users and operating hours covered.
• Specific deliverables.
• Work explicitly excluded.
• Dependencies on another vendor or your internal team.
• Whether the activity is one-time, recurring, or triggered by request.

Example:

Included: administration and security configuration for Microsoft 365 accounts used by 35 staff. Excluded: procurement of laptops, internet-provider outages, and support for personal email accounts. The client supplies an approved employee list and names two authorised requesters.

Boundaries prevent support expectations from expanding through informal messages after the contract begins.

5. Assign responsibilities on both sides

A provider cannot maintain systems if the client delays approvals, withholds access, or allows anyone to request high-risk changes.

Create a simple responsibility table:

| Activity | Client | Provider | |----------|--------|----------| | Approve account creation or removal | Accountable | Executes approved request | | Maintain employee and role list | Owns source of truth | Reviews for technical gaps | | Recommend security settings | Reviews business impact | Proposes and documents | | Approve production change window | Approves | Plans, executes, and records | | Escalate suspected incident | Names decision contact | Follows agreed response path | | Pay software licences | Confirms budget owner | Identifies required licences |

Name roles, not only individual people, so the process survives staff changes. Define who may approve access, spending, downtime, and data movement.

6. Set a secure access process

The scope should require:

• Named accounts rather than shared administrator passwords.
• Least-privilege access for each assigned task.
• Multi-factor authentication for privileged systems.
• An approved method for sharing credentials and recovery codes.
• Change records for production systems.
• Access removal when provider staff leave the engagement.
• A final access review at handover.

If temporary elevated access is possible, state how it is granted and removed. Ask where operational notes and configuration records will live so your company can retrieve them without relying on one person's inbox.

For personal or regulated data, involve qualified privacy, security, and legal advisers in deciding access, retention, contractual, and incident obligations. A technical scope can implement decisions, but it should not invent the organisation's legal basis.

7. Make service levels measurable

Do not copy a 24-hour support promise into a contract if the provider is only engaged during business hours. Define:

• Support channel and operating hours.
• Who may raise a request.
• Severity levels with examples.
• Response target for each severity.
• Update frequency during a serious incident.
• Resolution target only where the provider controls the dependency.
• Escalation contacts.

An internet outage owned by a telecom provider and a broken deployment controlled by your software vendor cannot have the same resolution commitment. The IT partner may coordinate both, but the contract should distinguish response from guaranteed resolution.

Example severity definitions:

• Critical: A business-critical system is unavailable to most users, or there is a suspected active security incident.
• High: A major function is unavailable with no reasonable workaround.
• Normal: One user or non-critical function is affected and a workaround exists.
• Request: Planned access, configuration, advice, or enhancement.

8. Specify deliverables and evidence

Common deliverables include:

• Current-state inventory and ownership register.
• Prioritised remediation plan.
• Configured systems with change records.
• Network, cloud, or application diagrams.
• Administrator and end-user instructions.
• Backup report and restore-test record.
• Access and licence register.
• Monthly service summary with open risks and decisions.
• Handover pack at completion.

"Configured successfully" is not enough. State what evidence confirms acceptance, such as a test account signing in with multi-factor authentication or an authorised administrator restoring a sample file.

For digital work, click the provider's proof and ask what was actually delivered. Techzoid publishes client work for UNNAD, Garment Sparkle, and Cleanxpressions on our websites page. A website portfolio supports website-delivery experience, but it does not by itself prove device support, cybersecurity operations, or every other service lane.

9. Plan transition from the current provider

A transition scope should identify:

• Contract notice dates.
• Company-owned accounts and vendor-owned accounts.
• Domain, DNS, email, cloud, source code, and backup access.
• Open incidents and unfinished projects.
• Licence renewals due during transition.
• Documentation to export.
• Joint handover sessions.
• Date and owner for removing former-provider access.

Keep the current provider active until critical access and backups are verified where the contract allows. Avoid changing several systems at once merely to mark a new start.

If ownership is disputed, use company records and contractual channels. Do not attempt unauthorised access or ask a new provider to bypass controls.

10. Ask for transparent pricing assumptions

The scope should request pricing by lane or deliverable and identify:

• One-time discovery or setup.
• Recurring service fee.
• Included support volume or capacity.
• Out-of-scope rates and approval method.
• Third-party licences and taxes.
• Travel or on-site assumptions.
• Emergency or after-hours terms.
• Renewal and termination conditions.

The lowest monthly figure may exclude onboarding, documentation, on-site work, cloud fees, or project changes. Compare the total defined scope and the assumptions behind it.

11. Compare proposals consistently

Score each response against the same criteria:

1. Understanding of the current environment and risks.
2. Fit for the service lanes requested.
3. Clarity of inclusions, exclusions, and client responsibilities.
4. Security and access approach.
5. Relevant, verifiable proof.
6. Deliverables and acceptance evidence.
7. Service-level realism.
8. Handover and exit terms.
9. Total cost and pricing assumptions.

Ask finalists to explain one risk they would investigate first and one part of the scope they would not accept without discovery. Specific pushback is often more useful than a proposal that agrees with every line.

Copyable scope-of-work outline

Use these headings:

1. Company, locations, and users
2. Current technology inventory
3. Business outcomes
4. Service lanes included
5. Systems, users, and hours covered
6. Explicit exclusions
7. Client and provider responsibilities
8. Security and access process
9. Service levels and escalation
10. Deliverables and acceptance evidence
11. Transition and handover
12. Pricing format
13. Proposal evaluation criteria

Keep the first request focused. If the inventory is incomplete or several service lanes are changing, make discovery the first deliverable rather than demanding a fixed answer from uncertain inputs.

Your next step

A clear scope does not lock you into one technology. It gives providers enough context to recommend an approach while making hidden exclusions visible.

If you want help turning an inventory into a prioritised scope, contact Techzoid Innovation. We will identify which lanes fit our team and state clearly when a hardware, connectivity, legal, or other specialist should lead.