Project Estimation for Nepali IT Firms: Stop Promising Dates You Cannot Keep

Every Nepali software firm has the same meeting. A client from abroad wants a portal. The sensible timeline is five months. The client asks for three. The sales person nods, the developer sighs, and the project starts already behind schedule.

I have watched this scene play out dozens of times in Kathmandu. The blame lands on the developers, then on the client, then on the weather. Nobody says the real problem out loud. The real problem is project estimation that never happened, because an honest estimate would have lost the deal.

This guide is about fixing that. You can keep winning bids and still estimate honestly. You need three things: historical data, a written scope, and a buffer you can defend. Here is what matters for each.

Why Project Estimation Fails in Nepali IT Firms

Start with the numbers. A 2023 survey of software projects in South Asia found that more than half finished late, and the average delay was close to 40 percent. Nepal has no national study, but I see the same pattern on every project I review here.

The first cause is pricing pressure. Nepali firms bid against vendors in India and Bangladesh, and the rate for a junior developer in Kathmandu is a fraction of the rate in Bengaluru. To win, firms cut the timeline instead of the scope. Cutting the timeline does not make the work faster. It only moves the missed deadline onto a calendar the client controls.

The second cause is missing data. Most firms estimate from memory. A senior developer remembers that the last report module took two weeks, so the next one gets two weeks. The memory leaves out the weekend debugging, the client rewrites, and the week the power gave trouble. Memory is a bad ledger.

The third cause is the silent scope change. The client sends a small request by message. The developer does it as a favor. Three favors later the project is a month behind, and nobody remembers the request that started it. Project estimation fails in the same three ways at almost every firm in Nepal, and all three are fixable.

Project Estimation Needs Real Data, Not Hope

Here is the fix that costs nothing: keep an estimate ledger. For every task, write down the hours you planned and the hours you spent. One spreadsheet column for the plan, one for the actual, one for the difference. That is the entire system.

After three projects you have a personal inflation rate. You plan six hours for a screen and spend nine. That ratio, say 1.5, becomes your default multiplier. Apply it before you quote, not after the project runs late.

The ledger works because it replaces opinion with evidence. When a client asks why a module takes ten days, you can point to nine similar modules from last year. The data does the arguing, so you do not have to.

Team members matter too. A new graduate and a person who has done this for ten years do not produce at the same speed. Keep the ledger per person if you can. That sounds like office politics, but it is just arithmetic. You are estimating human effort, and human effort varies.

Project Estimation and the Scope Trap

Scope is the word every client misunderstands. The client hears a price and assumes the price covers everything they can imagine. The developer hears the price and assumes it covers what was written in the email. The gap between the two is where projects die.

Write the scope before you estimate. List the pages, the forms, the reports, the user roles. List what you will not build: a mobile app, a payment gateway, a dashboard with live charts. Most firms skip this list because it feels like paperwork. It is the cheapest insurance you will ever buy.

Nepal has an extra twist. Much of the work happens through messages: Viber, WhatsApp, Messenger. A client writes a request at 9pm, the developer answers at 10pm, and by morning the request has become a promise. The written scope does not stop these requests. It gives you a place to put them: the change log. Every request goes in the log with a number. Every change gets a new estimate and a new price. You do not say no. You say yes, and here is the cost.

The discipline is boring and it works. Clients respect a team that tracks changes, because it means the team respects its own numbers.

Project Estimation for Fixed Price Contracts

Fixed price is the most common contract in Nepali outsourcing, and the most dangerous one. The client pays one number. The firm carries every risk: sick developers, slow servers, new government rules, a client who keeps changing the design. The estimate is not a prediction. It is a bet.

When you take a fixed price project, write the assumptions into the contract. Assume response time, assume two rounds of revision per page, assume the client provides content within five working days. Each assumption is a door. If the assumption breaks, the door opens, and you can renegotiate the timeline without shame.

Change orders are how a fixed price contract stays alive. Many Nepali firms refuse to charge for changes because they fear losing the client. That fear is expensive. A change that takes two weeks and is never billed will be repeated ten times on the next project. Bill the first change and the ninth change becomes rare.

One more rule: never accept a fixed price project without a written scope and a buffer. If the client refuses both, walk away. There is always another client. There is no way to recover a project that started with a lie.

Project Estimation Without a Buffer Is Guesswork

A buffer is the time you add because you know you are wrong. You are always wrong. The only question is by how much. A buffer of 20 percent is common. Some firms use 30 percent for projects with new technology.

Most firms fear the buffer because it makes the price higher. They hide it in the numbers, and then they eat it when a delay hits, and the project runs at a loss. The better move is to show the buffer honestly. Tell the client: the core work is ten weeks, and we add two weeks because we know reality is messier than a plan. Clients accept this more often than you expect, because most clients have already been burned by a firm with no buffer and a missed date.

The buffer is not slack. It is a rain fund. You spend it when the estimate was wrong, not when the week was quiet. If the project finishes early with buffer left, you give the client the week back. That gesture is worth more than a thousand marketing messages.

A Simple Project Estimation Review Routine

An estimate is a living document. Review it every week with the team. Take one hour, open the ledger, compare planned hours with spent hours, and answer one question: are we still on the path to the date we promised?

If the answer is no, tell the client that week. Not at the monthly meeting, not when the delay is certain. Early warning is the only power you have. A client can absorb a change in week two. A client cannot absorb a surprise in week nine.

The review also feeds the next estimate. Every project ends with a short note: what we missed, what took longer, what the client changed. That note is the seed of your next estimate. Firms that keep these notes stop repeating their own mistakes, which is the cheapest speedup available in project work.

Project Estimation Tools That Cost Nothing

You do not need expensive software to estimate well. A spreadsheet is enough. Put the task list in rows, hours in columns, and color the cells that exceed their plan. Free tools like Google Sheets work fine, and a shared sheet keeps the client and the vendor looking at the same numbers.

For time tracking, ask the team to log hours at the end of each day. A rough log beats a perfect memory. Fifteen minutes a day from each developer gives you the data that makes every future estimate honest.

If you want one upgrade, track velocity on fixed teams: the amount of finished work per week. Velocity turns estimation from a guessing game into a number you can measure. It is the closest thing project management has to a crystal ball.

What to Do About Project Estimation Before You Bid

Run this checklist before every bid. One: pull the estimate ledger and apply the inflation multiplier. Two: write the scope list and the exclusion list. Three: pick the buffer and show it. Four: write the assumptions into the contract. Five: decide how changes are billed. Six: name the person who owns the numbers.

Do all six and you will still miss some dates. Estimation is a practice, not a formula. But you will miss fewer, you will lose less money, and the clients who stay will be the ones who respect honest numbers.

Here is the shift that matters. Most Nepali firms treat the estimate as a sales tool. The good ones treat it as a contract with reality. Choose the second group. Your team will sleep better at night, and your clients will stop dreading the status call.

1. How do I estimate a project when I have no past projects to learn from? Start with small pilots. Bid a fixed price on a small first phase, track the hours closely, and use that data for the full project. A paid pilot beats a guessed giant project every time.

2. What is a fair buffer for a software project in Nepal? Start at 20 percent for work you know and 30 percent for new technology. Raise the buffer when the scope is vague. Lower it only when you have data from three similar projects.

3. Why do Nepali firms keep winning bids with timelines that are too short? Because buyers compare price first and expertise second. The fix is not to bid higher. It is to bid the same price with a smaller scope, then grow the scope through change orders that are priced fairly. That keeps project estimation honest without losing the deal.

4. How do I tell a client their project will take longer than they want? Show the data. Walk through similar past projects with their actual durations, then explain what is different in this one. A client argues with opinions. A client accepts evidence.

5. Should I track hours per developer or per task? Both, but per task matters more for future estimates. Per developer hours feed the ledger too, and they expose who consistently underestimates. Keep two columns, one row per task.

Take the Next Step

Project estimation improves when the numbers are visible, and the same is true for the rest of your business. At Synergy Digital, we help Nepali firms set up delivery tracking, cloud tools, and AI systems that make work measurable. If you want an honest look at how your team estimates, send us one of your recent project plans and we will show you where the risk sits. Start the conversation at https://www.synergy.com.np.