A Nairobi distributor invites three software firms to quote for a service portal. One offers a website with a request form. Another proposes a customer account, dispatch queue and accounting integration. A third includes mobile field reporting and support after launch. The prices are far apart, and every supplier can reasonably claim to have priced the portal described in the invitation. The buyer’s problem begins before the quotations arrive.
When purchasing software development services in Nairobi, define the decisions that the software must support before comparing project prices. A short discovery engagement can be valuable if it leaves the business with evidence, options, a delivery boundary and a brief another supplier could understand. It has little value if it ends in attractive screens with the hard questions postponed until after the build contract is signed.
This guide follows a fictional distributor planning a portal for customer service requests across a Nairobi head office, an industrial area dispatch desk and a branch outside the city. The business wants a fair procurement decision and an implementable first release. The example shows how to plan the workshop, challenge its findings and turn the outcome into comparable proposals.
Make the first meeting about a real transaction
Bring one recent request stripped of customer identifiers and sensitive material. It could involve a customer requesting a replacement, dispatch assigning a collection and finance reviewing a related charge. Include the documents and ordinary decisions that followed. A business process diagram prepared by management is helpful, but a real anonymised example often reveals the informal calls and manual checks that the diagram omits.
Ask the people who performed the work to describe it in sequence. The customer service officer knows what information first arrived. Dispatch knows why the requested slot changed. Finance knows which evidence was missing when it reviewed the charge. Each person may use a different word for the same request. Capture those words and define the record they refer to before agreeing on a list of software features.
Select a difficult request as well as a routine one. The ordinary request shows how work should flow. A request with a changed address, missing authorisation or rejected adjustment shows who owns the exception. If a supplier can describe only the easy path, the quote will probably omit much of the work needed in practice. Ask for the difficult path to appear in the discovery deliverables.
End the first meeting with an observable problem. For example, service officers cannot tell whether dispatch has accepted a revised address before promising the customer a new collection time. That statement identifies a person, decision and missing evidence. Improve customer experience is a worthwhile ambition but too broad for a supplier to price or for a buyer to accept at the end of development.
Invite the people who know the edges
A director can sponsor the project and approve its budget. The service supervisor understands policy. A frontline clerk understands which fields customers regularly leave blank. The dispatch coordinator knows what happens when requests arrive after the truck cutoff. Finance knows which references are needed for a charge. Invite representatives with those different perspectives and give them specific questions to resolve.
Use interviews where a full workshop would keep too many people away from work. A dispatcher may show more in twenty minutes at the desk than in two hours describing the process in a boardroom. Observe a safe fictional or suitably anonymised example. Record the decisions and obstacles rather than copying customer data into discovery notes. Agree how participants can correct the written account afterwards.
Include the branch that experiences the least convenient conditions. A process that works over the head office network may fail at a shared terminal on a busy receiving desk. A service employee who handles requests from a phone may have different information from a manager with access to the main system. Make those contexts part of the brief instead of treating them as exceptions discovered during training.
Name the person who can decide when departments disagree. Sales may want immediate confirmation while dispatch needs to check capacity. Finance may require a reference the customer does not have at first contact. The supplier can explain options and consequences, but the organisation must choose its operating policy. Record who owns the decision and when it must be made so discovery does not end with unresolved assumptions disguised as requirements.
Ask for outputs that another team can use
A discovery deliverable should describe the users, tasks, records, exceptions, interfaces and acceptance examples for the proposed work. It should identify the first release, future possibilities and unresolved dependencies. It need not be a large document. A clear account of a handful of consequential decisions is more valuable than dozens of pages repeating meeting notes.
Request a process map that distinguishes current practice from the proposed arrangement. The current map might show a telephone call from service to dispatch after every address change. The proposed map might replace the call with an amendment requiring acknowledgement. Write the trigger, information sent, receiving owner and expected evidence. A line between two boxes labelled integration tells a developer too little about what must actually happen.
Ask for a small data dictionary. Define customer, site, request, visit, charge and payment in your company’s terms. Identify stable references and the system or role that owns each one. Specify whether a customer can have several sites or a request can produce more than one visit. Those relationships affect design effort and report accuracy even when the screens themselves look simple.
Request a decision log. Each entry should describe the question, available choices, decision maker, chosen option and consequence for the first release. If an answer is pending, include the evidence needed and an owner. A discovery report that hides uncertainty may look polished while forcing the build team to guess. A visible unresolved item can be priced as investigation or excluded from a commitment until its dependency is understood.
Define the smallest release that completes the job
A useful first release lets a customer submit a service request, receive a reference, obtain a dispatch decision and learn the outcome. It may need an administrative role, status history and a support route. It may not initially need automated route optimisation, elaborate analytics or a mobile app. Choose scope according to what makes the journey usable from end to end.
Write down what remains manual. Finance might receive a controlled export during the first release while an integration is evaluated. Dispatch might assign drivers by hand while the portal records the decision. Manual steps are acceptable when someone owns them, the volume is manageable and the business can detect errors. A hidden manual step becomes a surprise staffing cost as soon as the portal attracts more requests.
Give each deferred feature a reason. A later accounting integration may depend on the existing system’s capabilities and access arrangements. An offline field application may require more evidence about branch connectivity. A route optimiser may add little value until dispatch records consistent site information. Recording the reason helps management distinguish prudent sequencing from a supplier pushing difficult work out of sight.
Test the proposed boundary with the awkward request. If the customer changes the address after dispatch accepts the job, can the first release record and resolve the amendment? If the answer requires somebody to telephone but nobody is assigned to record the result, the release is incomplete. Include the minimum workflow that closes the loop even if a later version automates more of it.
Price the interfaces honestly
An interface estimate should say which system connects, what events or records cross the boundary and how success is confirmed. Sending a service request to dispatch is different from synchronising every customer field in both directions. Ask the supplier to identify the external documentation, access, test environment and provider support it assumes. A promised connection can be unpriceable until someone confirms those dependencies.
Use a controlled export as a comparison. If the portal produces a daily file for finance, identify the fields, frequency, receiving owner, validation and correction route. The manual option may be suitable for a small volume or pilot. Its ongoing labour and risk should be included alongside the cost of a direct integration. A cheaper build that creates an hour of daily reconciliation may be expensive over its life.
Describe failure behaviour. An external system may reject an unknown customer, time out after accepting a request or receive the same message twice. The supplier should explain how the business detects each state and who takes action. A sentence promising seamless integration gives buyers little basis for acceptance. A test that sends one duplicate request and one genuine amendment exposes whether the design matches the business.
Clarify third party charges and rights. A supplier may need a paid provider account, an approved application, a particular service tier or assistance from the vendor of your current software. Confirm the actual arrangements before contracting for the result. Show which costs belong to the project, which recur and which remain uncertain. Avoid treating an indicative assumption as a verified external commitment.
Make prototypes answer a question
A prototype should test a decision that matters. The customer needs to distinguish a submitted request from a confirmed appointment. Dispatch needs to see whether an address change is acknowledged. Finance needs to review the source of a charge. Ask for a prototype covering those moments rather than just a polished home screen. The right level of fidelity depends on what the team needs to learn.
Give a staff member a realistic task without coaching. Ask them to find a request, identify its current state and decide what to tell the customer. Observe where they hesitate and what they think the labels mean. A prototype that looks professional may still lead a user to promise a collection before dispatch confirms capacity. Write down the misunderstanding and test a revised label or sequence.
Use different views for different roles. A customer should see the outcome and next step. A dispatcher should see operational detail and ownership. A director might see service performance by branch. Combining all information into one prototype can confuse the audience and expose details users do not need. Test each view with someone who performs the role, including staff who rarely use complex software.
Keep prototype limitations clear in the proposal. A clickable screen proves that the proposed interaction can be explored. It does not prove that authentication, integration, offline behaviour or reporting works. Identify the assumptions still requiring engineering investigation. A small technical trial may be appropriate where one dependency could materially change the project price. Define its question and completion evidence before commissioning it.
Compare local working arrangements on their merits
A Nairobi supplier may offer onsite discovery, remote delivery or a combination. Choose the arrangement around the work. Observing a dispatch desk or training a shift team may benefit from a visit. Reviewing a decision log or discussing a prototype may work well remotely. Clarify travel, scheduling, session preparation and which named roles will actually attend rather than assuming proximity guarantees access to the right people.
Ask who performs each part of delivery. The person presenting the proposal may not be the analyst who interviews staff or the developer who maintains the application. Request the proposed responsibilities, availability and handover arrangements. If work is subcontracted, understand who remains accountable and what access the subcontractor needs. A clear team structure matters more than the number of impressive titles on the proposal.
Set a practical rhythm for decisions. The supplier can provide a short working demonstration and list of open questions at agreed intervals. The buyer needs someone available to respond and a deputy for absences. A weekly meeting loses value if every item awaits an executive who attends once a month. Match the decision schedule to the authority available and price delays or changes transparently.
Test the communication arrangement before award. Send the same fictional change to the shortlisted teams through the agreed procurement process. Ask them to describe the effect on scope, price, dependencies and acceptance tests. Evaluate the clarity of the answer without rewarding speed alone. A thoughtful answer identifying a missing business decision may be more useful than an instant assurance that the change is easy.
Turn the workshop into comparable quotations
Give every supplier the same brief, sample workflow, expected volumes and assumptions. Ask them to separate discovery already completed, implementation, migration, integration, training, support and optional work. Specify whether prices include the equipment, hosting or third party services described. A quotation should let the buyer identify why one offer costs more before deciding whether the difference is worth paying.
Compare first year and ongoing costs under a defined operating scenario. A low initial build price can come with a high recurring licence or expensive routine changes. Another supplier may quote more upfront and hand over more operational responsibility to your team. Include your staff time under both arrangements. A proposal assuming the buyer will clean data, configure roles and train users still carries those costs.
Ask for a worked change request. The business adds a second dispatch branch with different opening hours. What can an administrator configure, what requires development and what tests must be repeated? The answer reveals how much future flexibility the proposal genuinely includes. It also exposes whether the supplier understands the difference between a local setting and a change that affects every customer request.
Distinguish fixed commitments from estimates. A fixed price requires sufficient definition of the outcome and assumptions. An estimate may be appropriate where discovery has identified a genuine unknown. Ask how the unknown will be resolved, who approves additional work and what happens if the external dependency cannot be obtained. A transparent uncertainty is easier to manage than a low fixed quote containing broad exclusions.
Tie milestones to evidence the buyer can see
Define the first milestone around a user journey. The customer submits a request and dispatch receives it once, including when the customer retries after a dropped connection. A second milestone might handle confirmation, amendment and cancellation. Another might complete the financial export and reconciliation. These outcomes connect payment decisions to working behaviour that operations can witness.
Avoid accepting a percentage based solely on developer effort. A project can consume most of its estimated hours while the crucial interface remains untested. Ask for working demonstrations in an appropriate environment using fictional data and documented expected results. Record which functionality exists, which is simulated and which remains dependent on third parties. A simulated payment or dispatch confirmation should be clearly identified.
Give the buyer a review window and an owner for acceptance. A service supervisor may confirm the request flow, finance may confirm the export and IT may confirm access and recovery arrangements. Agree how defects are recorded, what severity blocks acceptance and how retesting occurs. A deadline without reviewers available can turn acceptance into a paperwork event rather than a judgement about working software.
Keep the decision log alive during development. An initially reasonable assumption may change when a pilot branch reveals a different working pattern. Record the new evidence and its effect on scope. A request to correct behaviour that failed the agreed example is different from a request to add a new capability. Preserving that distinction prevents avoidable disagreements about whether a change is included.
Include deployment and handover in the purchase
A working demonstration on the supplier’s environment does not tell you who can operate the production service. Clarify ownership and access for the domain, hosting, source materials, database, communication providers and backups under the proposed arrangement. Identify who approves releases, who can restore service and where the organisation keeps its operating instructions. These are procurement deliverables, not tasks to discover after the project team leaves.
Ask for a deployment rehearsal. Use an agreed nonproduction environment and fictional records. Move a release through the proposed process, verify a service request and restore a backup into an isolated environment. Observe who can perform each step and which access depends on one individual. The project should leave enough documentation and authorised access for the organisation to continue operating through staff changes.
Train the people who own the exceptions. A general tour of the portal may show staff where buttons appear. It may not prepare dispatch to resolve a duplicated request or finance to reject an incorrect export. Give trainees the difficult case used in discovery and ask them to resolve it without the supplier directing every click. Record where instructions need improvement before launch.
Confirm the support boundary. A bug under the accepted scope, a configuration change, a new feature and a third party outage may require different responses. Define coverage hours, contact route, escalation, evidence needed and pricing. Ask what happens during the distributor’s busiest dispatch period. A support promise is meaningful when the buyer can explain who acts, within what agreed arrangement and how the incident eventually closes.
Give the workshop a budget and a stopping rule
Price discovery as a defined piece of work. Agree the number and purpose of interviews, the operational areas covered, the outputs expected and the review process. A supplier may offer a fixed workshop fee or propose a bounded period of investigation. Compare what the business will receive at the end. An inexpensive workshop that produces slides but leaves the vendor alone able to explain the scope creates a weak basis for competitive proposals.
Decide what would justify extending discovery. An unknown dependency in the accounting system may need a technical trial. A disagreement over dispatch authority may need an internal management decision rather than another supplier meeting. A new branch representative may reveal a material difference in the operating process. Give the project owner authority to distinguish those cases and approve additional investigation only when it resolves a question that changes the delivery decision.
Set a stopping rule for the first release. Once the buyer understands the core request, its exceptional paths, the systems involved and a credible acceptance method, further detail may offer diminishing value. Record open lower priority questions for later work. Discovery should reduce the buyer’s uncertainty enough to make a deliberate commitment, without consuming the budget needed to build and test the service.
Make time for the buyer’s contribution. Staff need to prepare examples, attend interviews, read the draft and resolve policy questions. An apparent delay by the supplier may reflect a missing internal decision or unavailable access to an existing system. Track those dependencies openly. A shared schedule with named owners helps both parties plan without turning normal discovery questions into blame about who is holding up the project.
Protect the examples supplied for discovery
An anonymised request should retain the shape of the problem while removing details that identify the actual customer or staff member. Replace names, telephone numbers, account references, addresses and attachments with fictional equivalents where appropriate. Check free text notes as carefully as structured fields. A comment describing a distinctive incident may reveal an identity even after the name has been removed.
Decide who may access the discovery materials and where they are stored. A supplier preparing a prototype may bring designers, analysts and developers into the work. Give each person the information necessary for their task under the agreed arrangement. Avoid sending a database export to demonstrate a workflow that a handful of fictional records can reproduce. Smaller examples are often easier to understand as well as easier to handle.
Use realistic relationships in the fictional data. Give one customer two service sites and two contacts with different responsibilities. Include an open request, a completed one and an amendment awaiting acknowledgement. Those relationships test the proposed design without exposing the company’s actual customer list. A random list of names and amounts may be anonymous yet still fail to represent the conditions that determine project effort.
Check prototypes for remnants of source material before circulating them to bidders. A screenshot pasted during a workshop may still contain a real account number or message preview. Assign a person to review the tender pack, remove unnecessary detail and confirm the materials are appropriate for the intended recipients. Establish the agreed handling of working notes and copies at the end of discovery. That small administrative step can save the buyer from losing control of materials long after a proposal has been declined.
Evaluate the supplier’s evidence with a short scorecard
Use criteria tied to the project rather than generic company prestige. Can the team explain the revised address case? Has it identified the dispatch handoff and finance dependency? Does its price make assumptions visible? Can the buyer operate the proposed system after handover? Give each criterion a definition and agree its relative importance before reading the final prices. This reduces the temptation to change the rules to fit the presentation everyone liked best.
Distinguish observed evidence from a future commitment. A working prototype demonstrates an interaction, an interface trial demonstrates a particular exchange, and a written implementation promise states an obligation to deliver later. Record which one supports each score. A supplier should receive credit for transparent limitations as well as proven capabilities. An unsupported assurance about a difficult connection deserves a different treatment from an honest estimate accompanied by a credible plan to verify access.
Check references using questions relevant to the work and the permission appropriate for contacting them. Ask how the team handled a changed requirement, a failed integration or a release that needed correction. Find out what the customer received at handover and who could operate the service afterwards. A general compliment about professionalism may be accurate while telling you little about the capabilities that matter to your distributor.
Let each reviewer score the evidence before the group discusses it. Operations may value the change acknowledgement more highly than a visual refinement. Finance may recognise that an inexpensive offer leaves reconciliation work to the buyer. IT may identify an ownership gap in hosting or backup arrangements. Discuss the reasons behind differences and preserve material reservations in the decision record. A numerical average alone can conceal an unresolved issue one department will have to live with.
Document what would change the decision. One bidder may become preferable if it verifies access to the existing accounting interface. Another may become preferable if it offers the required handover documents under acceptable terms. Ask for specific clarification against the same published criteria and keep the answer with the proposal. The buyer can then explain the award in terms of evidence and commitments rather than a vague impression left by the final meeting.
Return the result to the people who supplied the original example. Tell the service officer how a revised address will be handled, show dispatch how acceptance will be recorded and show finance where its first release export comes from. Their response is a final practical check. If frontline staff cannot recognise their work in the accepted brief, resolve the discrepancy before converting the document into a costly development commitment.
Decide whether the brief is ready to tender
Read the discovery output as though you were a developer who missed every workshop. Can you identify the users, records, difficult decisions, first release, dependencies and acceptance tests? Can you tell which integration is confirmed and which remains uncertain? Can you estimate the work without inventing the organisation’s policies? If key answers live only in meeting memories, the brief is not yet ready.
Then read it as a branch supervisor. Can you tell how a changed address reaches dispatch, who acknowledges it and what customer service may promise? A beautiful technical specification that cannot answer that operational question still misses the business need. Ask both readers to mark the paragraph that supports their answer. Their different perspectives often reveal one missing definition that affects the entire project.
Ask one final question about portability before the workshop ends. If the distributor chose a different team for implementation, which decisions, prototypes and examples could it reuse under the agreed terms? The answer should be clear enough for procurement to evaluate without assuming that discovery automatically commits the company to a build contract. Keep the approved brief in a place the company controls and identify the version issued to each shortlisted bidder. When a clarification changes scope, share the revised interpretation consistently through the agreed procurement process.
A good discovery engagement leaves the distributor able to compare software development services on a common problem and a visible result. Keep the anonymised request, scope decisions and acceptance examples with the tender documents. For further Kenyan guides on translating business work into software requirements, read the ZamaCore blog.