How to Manage a Software Development Project: A Nigerian Business Owner's Guide

Most failed custom software projects in Nigeria are not failures of coding. They fail because nobody on the business side owned the project. The developer waits three weeks for a decision about approval levels, the finance manager who understands the process is never in the meetings, and the first time anyone from the business opens the system properly is two days before go-live.

You do not need to understand databases or deployment pipelines to run a build well. You need a rhythm, a written record and the discipline to test things while they are still cheap to change. This guide sets out what that looks like for a Nigerian SME or mid-sized company commissioning a custom system: an inventory platform, a loan management system, a school portal, a logistics dispatch tool or an internal operations dashboard.

What "managing the project" actually means on your side

Your development partner manages the engineering. You manage the business side of the project, which covers five responsibilities that no developer can discharge for you:

• Deciding. Answering questions about how your business actually works, and doing it within days, not weeks.
• Defining. Confirming that what is being built matches the process you want, not the process the developer assumed.
• Verifying. Testing each delivered piece against real scenarios from your operation.
• Supplying. Providing data, content, account access, staff time and sign-offs on schedule.
• Controlling. Approving or rejecting changes with full knowledge of what they cost in money and time.

A useful way to think about it: the vendor is accountable for the system working as specified; you are accountable for the specification being right and for the business being ready to use it. Software projects go wrong at the seam between those two accountabilities, which is why governance matters more than technical oversight.

The six phases of a software development project

Whatever methodology your vendor uses, a custom build for a Nigerian SME moves through six recognisable phases. Knowing them lets you tell whether you are ahead or behind.

Discovery is the phase businesses most often try to shorten, and the one that most reliably saves money later. The build phase feels like the project, but testing, migration and training decide whether the software is adopted.

Who does what: roles you must fill before work starts

A project with unclear roles produces contradictory instructions, and contradictory instructions produce rework that you pay for. Fill these roles by name before the kick-off meeting.

• Project sponsor (you or a director). Approves budget and change requests above an agreed limit. Attends monthly, not weekly.
• Project owner / single point of contact. One person who answers the vendor's questions and consolidates internal opinions. This is the most important appointment you will make.
• Subject-matter experts. The storekeeper, the accountant, the dispatch officer — the people who know the exceptions. They join discovery and UAT, not every meeting.
• Tester(s). Staff who will run acceptance testing. Named early so their time is planned.
• IT or technical contact. Even if it is an external consultant, someone should hold your domain, hosting and account credentials.
• Vendor project manager. Your counterpart, who runs the delivery team.

The rule that prevents most confusion: all requests to the development team go through the project owner. When three managers WhatsApp the developer directly with different priorities, the developer builds whatever the loudest person asked for last.

How to set scope so it does not drift

Scope drift is the slow addition of features nobody costed. It is rarely one big request; it is fourteen small ones. Control it with three documents and one habit.

1. A requirements document or product backlog. Every feature written as something a user does: "A sales officer can create an invoice and send it to the customer on WhatsApp." Vague entries such as "reporting module" are where budgets die.

2. A written out-of-scope list. As valuable as the in-scope list. State plainly what is not included in this phase: mobile app, accounting integration, multi-branch stock transfer, customer self-service portal.

3. A phase plan. Agree what is Phase 1 (the system that replaces the current pain), and park the rest in Phase 2. Phasing is the single most effective cost-control tool available to a Nigerian SME, because it lets you get value from the first ₦3,000,000 before committing the next ₦3,000,000.

The habit: every new idea goes onto a change log, not into the build. Review the log fortnightly, and decide consciously what enters scope.

The weekly rhythm that keeps a build on track

You do not need daily oversight. You need a predictable, short, documented cycle.

1. Weekly review call, 30–45 minutes, same day and time. Attended by the project owner and the vendor project manager.
2. A working demonstration in every call after the design phase. Screens you can see and, ideally, click.
3. A written weekly update from the vendor covering: completed this week, planned next week, blocked and waiting on you, open risks.
4. A decisions log maintained by your project owner, recording what was decided, by whom and on what date.
5. A fortnightly change-request review with cost and time impact for each item.
6. A monthly sponsor review covering budget consumed, milestones reached and risks.

Keep everything that matters in email or a shared document. WhatsApp is how Nigerian project communication actually happens day to day, and that is fine for speed — but any decision that affects scope, cost or dates should be restated in writing the same day. "We discussed it on the call" is not a record.

How to measure progress you can verify

Percentage complete is the least reliable metric in software. A module that is "90% done" can stay 90% done for a month. Insist instead on evidence you can see:

• Demonstrable functionality. Can you open the staging link and create a record?
• Completed backlog items, marked done only after your project owner has seen them work.
• Test environment availability. You should have access to a staging system from the first build iteration, not at the end.
• Defect trend. Are open bugs falling week on week, or accumulating?
• Milestone acceptance. Each milestone accepted in writing against defined criteria.

Ask for a staging URL early. A vendor who cannot show you a working environment by the second or third sprint may not have started building in earnest.

Managing money, milestones and change requests

Tie payments to verifiable deliverables. A payment structure a Nigerian business can defend looks like this, as an indicative pattern rather than a fixed rule:

Indicative structures only; actual terms vary by vendor, project size and contract. Hold a retention of 5–10% released 30–60 days after go-live wherever the vendor will agree to it, because it keeps attention on you during stabilisation.

For change requests, require a standard one-page format: what is requested, why, what it affects, cost, time impact, and who approved it. Three questions to ask before approving any change:

• Does this block go-live, or can it wait for Phase 2?
• What does it push back, and by how long?
• Who is asking, and are they the person who will use it daily?

Budget 10–15% of the project value as a change contingency. Projects without contingency do not have fewer changes; they have unfunded ones, which become arguments.

Testing, data migration and rollout

User acceptance testing: the part only you can do

User acceptance testing (UAT) is where your staff use the system with realistic data and confirm it supports the real process, including the awkward exceptions. The vendor's QA finds technical defects; UAT finds business mismatches. Run it properly:

1. Write test scenarios from your operation, not from the feature list. "Customer pays part cash, part transfer, collects half the order today and half next week."
2. Use real, anonymised data, including the messy records.
3. Test on the devices staff actually use, including mid-range Android phones on mobile data.
4. Log every issue in one shared sheet: description, screen, severity, who reported it, status.
5. Classify severity as blocker, major or minor, and agree that only blockers and majors hold up go-live.
6. Re-test fixes before closing anything.
7. Sign off formally against the acceptance criteria in your contract.

Allow two to three weeks for UAT on a medium project, and protect that time. Compressing UAT to three days is how businesses end up discovering in month two of live operation that the system cannot handle credit customers.

Data migration, training and go-live

The transition is where adoption is won or lost.

• Clean your data before migration. Duplicate customers, inconsistent product names and missing phone numbers will be migrated faithfully into the new system. This is business work, not developer work.
• Do a trial migration into staging and have your accountant check totals against the old records.
• Choose a rollout approach. A parallel run (old and new systems together for two to four weeks) is safest for accounting-critical systems; a phased rollout by branch or department suits multi-site operations; a straight cutover is only sensible for simple systems.
• Train by role, not by feature. The storekeeper needs 40 minutes on receiving stock, not a two-hour tour.
• Record short screen-capture videos in the training session. Staff turnover means you will need them.
• Plan hypercare: a defined period, typically two to four weeks after go-live, with agreed vendor response times.

Example (hypothetical): managing a distributor's operations platform

Example (hypothetical). A building-materials distributor in Ogun State with a warehouse and two sales depots commissions a custom operations platform to replace a mix of spreadsheets and a paper waybill book. Indicative budget ₦6,500,000, indicative timeline 16 weeks.

How the owner manages it:

• Appoints the operations manager as project owner, with the accountant and the head storekeeper as subject-matter experts. All vendor questions route through the operations manager.
• Phases the scope: Phase 1 covers stock, sales orders, waybills, customer accounts and basic reports. Out of scope in writing: a customer-facing mobile app, integration with the accounting package, and route optimisation.
• Runs a 40-minute Tuesday review with a demonstration, and a fortnightly change review.
• After week six, a request to add a commission calculator for sales agents is logged. The vendor prices it at an indicative ₦450,000 and one week. The owner defers it to Phase 2 because it does not block go-live.
• Allocates two weeks for UAT. Three depot staff test with last month's real transactions. Eleven issues are logged; three are blockers, including a rounding error on part payments.
• Runs both systems in parallel for three weeks before retiring the waybill book.
• Holds back 10% of the fee until 45 days after go-live.

The result of that discipline is not a perfect project. It is a project where surprises appear in week six instead of week sixteen, and where the ₦450,000 decision was made deliberately rather than absorbed silently.

What changes for Nigerian businesses

Several local realities change how you should run the project.

• Staff time is the hidden cost. Your best people are already stretched. Put their project hours in writing at kick-off — for instance, "the accountant is available four hours per week from week two to week fourteen" — or they will be pulled into day-to-day work and the project will stall waiting for them.
• Power and connectivity affect testing. Schedule UAT sessions around your power reality, and test the system on mobile data, not only on office Wi-Fi. If staff will use it at a depot with weak signal, test it there.
• Payments and exchange rates. Cloud hosting, third-party APIs and some licences are priced in US dollars. Naira movements can change your recurring costs mid-project, so ask for recurring costs to be quoted separately and reviewed at go-live.
• Distributed teams are normal. Many Nigerian agencies work remotely with developers across cities. This is workable, but insist on a named project manager and a fixed meeting time rather than ad hoc contact.
• Verbal agreements are common and risky. Nigerian business relationships often run on trust and phone calls. Keep the warmth, but write down decisions. It protects both sides when memories differ.
• Regulatory context. If the system stores customer personal data, the Nigeria Data Protection Act 2023 applies and the Nigeria Data Protection Commission publishes the relevant guidance. Decide early who is responsible for consent capture, retention rules and data security, and record it in the contract. This is not legal advice — confirm your obligations with a qualified professional.
• Holiday and seasonal timing. Avoid planning go-live in late December, during peak trading season, or across major public holidays. Rollout needs your staff available and calm.

Mistakes to avoid

• No single decision-maker. Committees cannot answer daily questions. Appoint one project owner with authority.
• Skipping discovery to "save time". Undocumented assumptions become paid rework at three to five times the cost.
• Accepting progress reports without demonstrations. Ask to see it working, every week.
• Approving changes without pricing them. Every "small addition" has a cost; find out what it is before saying yes.
• Leaving testing to the vendor. Only your staff know the exceptions in your process.
• Paying in full before handover. Keep meaningful value attached to acceptance and stabilisation.
• No documented handover. Source code repository access, hosting credentials, deployment instructions and admin accounts should be in your company's name and transferred in writing.
• Treating go-live as the end. Budget for maintenance from day one; software has running costs for as long as it is used.

Your project management checklist

• Signed contract with scope, milestones, acceptance criteria and IP assignment
• Named project owner, sponsor, subject-matter experts and testers
• Requirements document or backlog reviewed by the people who do the work
• Written out-of-scope list and Phase 2 parking list
• Milestone payment schedule with a retention
• Change-request template and 10–15% contingency
• Weekly review slot fixed in diaries
• Staging environment access from the first build iteration
• Decisions log and issue log in shared documents
• UAT scenarios written from real operations
• Data cleaning task assigned with a deadline
• Rollout approach chosen (parallel, phased or cutover)
• Role-based training plan and recorded sessions
• Hypercare period and support response times agreed
• Handover pack: code repository, credentials, documentation, admin accounts

Conclusion

Managing a software development project is largely an exercise in structure. Appoint one decision-maker, write the scope and the out-of-scope list, hold a short weekly review with a working demonstration, log every change with its cost, attach payments to deliverables you have tested, and protect real time for UAT, data cleaning and training. None of that requires technical knowledge, and all of it reduces the two risks that matter most: paying for something that does not fit how you work, and building something your staff never adopt.

If you are planning a custom system and want the scope, phasing and milestone structure worked out before you commit to a build, Linestech can help you shape the project plan and requirements first, so the engagement starts with a clear specification rather than assumptions.

Frequently asked questions

Do I need a project manager on my side if the vendor has one?

You need a project owner, which is not the same as a full-time project manager. On a project below roughly ₦10,000,000, an operations or finance manager giving five to eight hours a week is usually enough. Above that, or where several departments are affected, consider a dedicated internal coordinator or an independent consultant who represents your interests.

How long should a custom software project take?

It depends on scope, but a focused departmental system commonly runs 10–20 weeks from kick-off to go-live, while a multi-module business platform can run six to twelve months. Be sceptical of very short timelines on complex scope: the time usually reappears later as defects, rework and delayed adoption.

What if the vendor is slower than agreed?

Raise it formally at the weekly review, in writing, the first week it slips — not the third. Ask for a recovery plan with revised dates and the reason for the delay. Withhold the milestone payment until the deliverable is accepted. If the pattern continues, your contract's remedy clauses and the retained balance are your leverage, which is why both belong in the agreement.

Should I use agile or fixed-scope for my project?

Fixed-scope suits well-understood requirements and a firm budget. Iterative delivery suits projects where the process will be refined as you see it working. Many Nigerian SMEs do best with a hybrid: a fixed total budget and phase plan, delivered in two-week iterations with demonstrations, and a change log for anything outside the agreed scope.

How much of my staff's time will the project consume?

Plan for the project owner to spend five to eight hours a week throughout, subject-matter experts to spend eight to twelve hours during discovery and again during UAT, and testers to give two to three days each during acceptance testing. Underestimating this is one of the most common causes of delay.

What should I do if my staff resist the new system?

Involve them early rather than announcing the system at launch. Resistance is usually a signal that the software makes someone's work harder or exposes performance that was previously invisible. Identify which it is, adjust the process where the objection is fair, and be explicit about what will not change.

When should I stop adding features and go live?

Go live when the system handles your core daily process end to end and any remaining issues are minor. Waiting for perfection delays the return on your spend and means staff learn the system months after they were trained. Ship Phase 1, gather real usage feedback for four to six weeks, then decide on Phase 2 with evidence.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Nigeria Data Protection Commission (NDPC)
• GitHub documentation
• OWASP Top 10