Scoping a Software Project in Ethiopia: A Brief That Works

Why most software project briefs fail

In our experience receiving briefs from Ethiopian businesses, most have one of three problems:

1. Too vague: "We need a customer management system." (What kind? For what scale? Integrated with what?)
2. Too specific too early: "We need a React app with PostgreSQL backend deployed on AWS with these 47 features." (You haven't done discovery yet; you don't know your real requirements.)
3. Mixed authority: Brief written by one person reflecting one stakeholder; other stakeholders surface their conflicting requirements after work has started.

This article walks through what a useful brief looks like — written from the perspective of someone who receives them and quotes against them.

What to include

1. The business problem in plain language

Not "we need a CRM". "Our sales team is losing track of which leads have been called when, and we're missing follow-ups that we know would convert. We currently track in WhatsApp messages and a spreadsheet that's outdated by lunch."

The business problem makes the software requirement concrete. It tells the vendor what success actually looks like — not "we implemented a CRM" but "follow-ups happen on time".

2. Who the users are

Roles, daily routine, technical comfort, language preference, mobile vs desktop. "Five sales reps in their twenties, comfortable with phones, prefer Amharic for daily use, English for reports."

User detail changes everything. A system for technically savvy users looks different from a system for non-technical users.

3. What success looks like

A measurable outcome you can point to in 6 months and say "yes, this worked". Examples: "Follow-up rate above 85% on qualified leads." "Inventory variance below 0.5% on monthly counts." "Payroll processing time cut from 3 days to 4 hours."

Vendors who can't connect their work to your success metric should be a flag.

4. The integration landscape

What systems must this software talk to? NYLOS ERP? An external core banking system? Specific Ethiopian banks for payments? Biometric hardware? E-commerce platforms? Be honest about whether each integration is required, preferred or optional.

5. The constraints

• Budget envelope — even a rough range. "ETB 200–500K" tells the vendor whether they're scoping a small project or a large one. Vendors can work within a budget but not around an opaque one.
• Timeline — "needed by Q3 for board review" vs "no rush" produces different proposals.
• Compliance requirements — MOR, ERCA, IFRS, Labor Proclamation, NBE, donor-specific, ISO/SOC where relevant.
• Operational constraints — connectivity, on-premise requirement, language, multi-branch.

6. The questions you want answered

The brief should end with the questions the vendor must address in their proposal. Examples: "How will you handle data migration from our existing spreadsheets?" "What's your approach to user training?" "How is the work priced — fixed or T&M?" "Who maintains the system after go-live?"

Questions force vendors to engage with your reality rather than send a generic proposal.

What to leave out

1. The technical implementation

Don't specify the stack ("must be built in PHP", "must use MongoDB"). The technical choices are the vendor's job. Specifying them prematurely constrains good vendors and signals inexperience.

2. Feature lists pretending to be requirements

A list of 47 features is not a requirement. It's a sketch of what someone imagined the software would do. Real requirements come from discovery. Brief should reflect needs, not feature lists.

3. Mock-ups and designs

Unless you're highly confident in the visual direction, including mock-ups in the brief anchors vendors to your visual instinct rather than letting them design properly. Mock-ups produced during the design phase of the project, with stakeholder buy-in, are more valuable than ones included up-front.

4. Brand-naming the vendor before procurement

If the brief mentions a specific vendor by name as the chosen partner, the procurement process is for show. Be honest with yourself about whether you're doing real procurement or vendor-shopping.

What to demand in proposals

Once briefs go out to multiple vendors, the proposals you get back should answer:

1. What is the discovery phase? Any vendor proposing engineering without discovery is selling you risk.
2. What is the engineering process? Sprints? Demos? How often will you see the work?
3. What does the team look like? Names, roles, time commitment.
4. What is the pricing model? Fixed-price? Time-and-materials? Retainer? With what risk allocation?
5. What does ongoing support look like? After go-live.
6. What guarantees do you offer? Quality, timeline, scope.

Vendors who skirt these questions, or answer them vaguely, are flags.

Red flags in vendor responses

• "We can start next week" — if there's no discovery, they're guessing at scope.
• "Fixed price for everything" — no vendor can fix-price uncertain work without padding the price absurdly.
• "We use offshore engineers" — be honest about whether that suits your operating context.
• "Trust us" — trust is built, not asserted.
• No client references — every credible vendor has at least three.

How NYLOS handles project scoping

NYLOS treats discovery as a separate, fixed-price phase. We spend 1–2 weeks understanding your business before engineering. At the end of discovery, we produce a written specification with a fixed timeline and budget. You're not committed to the engineering phase until you've seen the spec.

This is slower than "we'll start next week" but much faster to a working system than "we'll figure it out as we go".

Read more

• [NYLOS Custom Software Development](/solutions/custom-software-development)
• [Build vs Buy Software in Ethiopia](/blog/build-vs-buy-software-ethiopia)
• [Software Vendor Management for Ethiopian Buyers](/blog/software-vendor-management-ethiopia)