Requirement Management for Software Outsourcing Projects
Most outsourcing projects don't blow up because of code. They blow up on the sentence "isn't that supposed to be included?"
You quoted 300k, you're 60% done, and the client asks for something nobody wrote down. Now you're arguing about a contract clause and a message from last Tuesday.
Here's what actually holds up.
One door for requirements
The killer scenario: the client's boss mentions something over dinner to your salesperson. Sales says "sure." Nobody tells the dev team. At acceptance it becomes "you promised."
Two rules:
- One contact person. Everything reaches the PM first, and the PM decides before it goes downstream.
- One place to record it. A tracker, a spreadsheet, a system — doesn't matter, as long as it's the same one. Group chats don't count.
Put it in the group announcement: "Log requests in X. Verbal requests aren't delivery commitments." Awkward up front beats a fight at the end.
What one requirement needs
Not a 40-page spec nobody reads. Six fields:
| Field | Why it matters |
|---|---|
| ID | REQ-001 — changes, hours and acceptance all hang off it |
| One-line description | Whose problem, what problem |
| Acceptance criteria | How you know it's done — must be verifiable |
| Priority | P0 blocks launch / P1 this release / P2 later |
| Requester + date | So you know who to go back to |
| Module | Needed for quoting and scheduling |
Acceptance criteria is the field people skip, and the one worth the most money. "Clean UI, smooth UX" is nothing. "Export to Excel with order ID, customer name and amount; under 5 seconds for 1,000 rows" is something you can point at. The client may find it fussy at signing. They'll thank you at acceptance.
Clarify before you quote
The most dangerous structure in outsourcing: fixed price plus fuzzy scope.
If you can't answer these in the clarification meeting, don't quote yet:
- Who uses it? How many users? What's peak concurrency?
- Which existing systems does it integrate with? Do they have API docs? Who's on their side?
- Is historical data migrating? How dirty is it? Who cleans it?
- On-premise or cloud? Any security or compliance requirements?
- Who runs it after launch? Is that inside the contract?
Then produce a requirement list and get the client's project owner to sign it. That list is your boundary. Every later "can we also…" starts from there.
Change requests aren't the problem. Free changes are.
No outsourcing project ships without changes. What decides whether you make money is how you handle them.
A change request needs four things: what changes, how many extra days, how much extra cost, which milestone it hits. Reply within 24 hours. Drag it out for three days and the client concludes you're slow — and that it wasn't a big deal anyway.
Set the rule early. Put it in the contract: three small changes free before acceptance, anything beyond that billed per person-day. Waiving the first one is goodwill; charging from the second is just business. The key is saying it up front instead of getting angry later.
Requirements have to match the hours
If you bill by person-day and requirements live in one place while timesheets live in another, settlement day will be a fight.
Simple fix: attach hours to each requirement — who worked, how long. Pull a report at each milestone. Overruns show up immediately.
Then ask why. Badly written requirement causing rework, or a guess that was never grounded? Two projects of that data and your next quote stops being a gut feeling.
Let the client see progress
Half the friction comes from information asymmetry. The client can't see what you're doing, so they chase. You get annoyed. They think you're stalling.
One page a week is enough: what shipped last week (with IDs), what's planned this week, and which requirements are waiting on the client — and for how many days.
That last item does the most work. "REQ-017 waiting on your API docs, day 6" makes ownership obvious without anyone raising their voice.
Traps I keep seeing
- The PM keeps requirements in their head. The moment they leave, the project loses its memory. Write it down, even in the ugliest spreadsheet.
- No prioritization in the backlog. Everything is P0, which means nothing is. Everything ends up half done.
- The people in review meetings can't decide anything. Three meetings, three different attendees, three conclusions. Confirm who signs off before the meeting.
- Acceptance criteria written last. By then everyone's tired and it gets fudged.
You can run all this on spreadsheets and chat groups — until you have five projects and twenty people, and it falls apart. In Stepwise, requirements, change records, timesheets and the client portal sit on the same line, so changing one requirement shows you which iteration it hits and how many hours it adds. If you've got a project running now, try it on a small one for two weeks.
