SME Software Projects: Managing an Outside Team

SME owners can manage software projects without reading code. Agree testable outcomes, divide work into manageable stages and schedule regular demos. Tie payments to written acceptance conditions. Give each change an agreed cost and schedule impact. Settle code rights, account ownership and handover expectations at the start.

What should you agree before work starts?

Write the scope, or boundaries of the work, as outcomes you can observe and test. A feature name alone leaves too much open. “Customers can log in” does not explain how they do it or what happens when a login code fails to arrive.

For example, a returning customer signs in with a phone number and a one-time code (OTP). Agree the test conditions, including connectivity and waiting limits. Treat any example timing as something to verify with the vendor, rather than promise before checking the messaging provider.

A feature list can mean different things to an owner and a developer. Testable examples help expose that gap before implementation.

When should stage payments be released?

Divide the project into milestones: stages with a deliverable, deadline and acceptance criteria. Payments follow the contract and the agreed checks, rather than the calendar alone.

Two-to-four-week stages can be a starting point for an SME project. Adjust them to the work and the availability of testers. Set a review window, perhaps three to five working days, and record whether the result is accepted, needs corrections or awaits clarification.

What should the weekly demo show?

Ask the vendor to run a real workflow using safe sample data: create an order, complete a test payment and check the report. Include the staff who will use the system. They often notice steps that the proposal misses.

The official Scrum Guide describes reviewing results as a working session. The UK government’s delivery guidance also discusses showing work and talking through it. Both are useful references without requiring you to adopt every part of their methods.

Schedule the demo at a fixed weekly time. If it is cancelled, ask for the reason and a replacement date. “80% complete” does not tell you whether staff can run the process they need.

How should new requests be handled?

Changing needs are common. A 2018 global PMI survey reported scope expansion in 52% of projects, budget overruns in 43% and schedule overruns in 48%. Those figures span projects; they are not estimates for Indonesian SMEs.

Keep a change log with the date, request, cost impact, schedule impact and decision. Agree those effects in writing before adding work to a current stage. A small change can be included without an extra charge if both parties agree; record that decision too.

Who owns the code and controls the accounts?

Separate code rights from account control. Contracts should distinguish custom code, the vendor’s pre-existing components and third-party components. Obtain legal review under the law chosen for the contract, especially for cross-border work.

A US example shows why contract wording should not be copied blindly. Commissioned works made for hire are limited to nine statutory categories, explained by the U.S. Copyright Office. A US contract-practice discussion distinguishes a promise of later assignment from a present transfer. This is a US-law example; its wording is not an automatic rule for Indonesian contracts.

Register domains, hosting and analytics under your business’s control from the start, then grant the vendor appropriate access. Owning custom code does not remove other components’ obligations. Review open-source licenses in commercial software separately.

Which documents should an SME owner request?

Start with four documents people can use in everyday work:

1. A one-page record of outcomes, test conditions and boundaries.
2. A stage schedule with acceptance conditions and payments.
3. A change log with cost and schedule decisions.
4. Terms covering code rights, account ownership, support and handover.

Add risk documentation for payments, sensitive data or safety-critical work. Documentation follows risk as well as team size. In hotel management system development, stages help review each workflow in turn.

What does project research tell us?

These studies explain the background risk rather than forecast your SME project. Their samples and success definitions differ.

The stat everyone quotes is from the 1994 Standish Group CHAOS report: only 16.2% of projects hit time, budget, and scope. 52.7% were "challenged" and ran 189% over their cost estimate on average. 31.1% were cancelled outright.

That number got repeated for three decades with little scrutiny of how it was produced, until a peer-reviewed replication supplied that scrutiny. Eveleens and Verhoef applied Standish's own definitions to 5,457 real forecasts across 1,211 projects. They found the definitions "misleading, one-sided, pervert the estimation practice, and result in meaningless figures": an accurately forecasting organization scored only 35–59% "success" by Standish's method, while one that padded its budgets scored 67%. Pressed on this, Standish's chairman said the reports "should be considered Standish opinion and the reader bears all risk in the use of this opinion" — a line absent from the reports themselves.

That skepticism matters more once you look at the risk that's actually well documented. Flyvbjerg and Budzier's analysis of 1,471 IT projects found an average cost overrun of 27%. But one in six was a "Black Swan", running 200% over cost and nearly 70% over schedule. That's a fat-tailed, power-law pattern a follow-up study of 5,392 projects confirmed. Those terms describe a distribution with a small minority of projects suffering very large overruns.

Most projects finish close to plan. A minority blow up completely. Regular reviews and clear acceptance conditions can expose warning signs earlier; they do not guarantee that a severe overrun will be avoided.

What should you do next?

Before accepting a quote, choose one business process and ask the vendor how it will be tested. Compare that answer with the schedule, payments and handover documents. If the answer is still only a feature name, clarify the outcome first.

For a project already underway, start at the next demo. Record what staff can use, which corrections remain and which changes need a decision. You can assess progress without reading code.