The Love/Need for the Buffer
By Rustam Khadka – Project Manager in Nepal
As humans, we don’t always like extra.
Extra instructions? Nope. Extra meetings? Please no.
Extra toppings on Pizza? on the same price? Yes, please! Let’s be Nepali here and say, Extra Gheeu (Clarified Butter) on Thakali Plate? Big yes.
There’s a strange happiness in getting more than what you paid for. It feels like you’re winning at life. Like you somehow hacked the system without even trying.
And when you’re in a space where you control that “extra”, when you’re not just taking the order but shaping it?
That’s a whole different high. That’s the be your own boss moment.
Now, let’s bring this energy into a project. Because in the world of project management, the word extra shows up too. Not in cheese or toppings, but in something just as valuable, buffer time.
And oh, what a journey buffer time takes.
Let’s walk through it.
Why Project Managers in Nepal Add Buffer Time
If you’re a Project Manager in Nepal (or anywhere else, really), you’ve likely lived through this cycle.
The burning question is why Project Manager loves buffer time? The simple answer is, because surprises are always RSVP’d in IT.
A developer estimates 8 hours for a task, adds 2 hours extra just in case. It is now 10
You, the Project Manager, add a safe 2-hour buffer, because you’ve seen things. Now it’s 12 hours.
You forward it to your Delivery Supervisor. They add another 2 hours. “Just in case,” they say. Now we’re at 14 hours.
It goes to Chief Tech Leadership. They’ve seen things too: clients changing their minds, blockers appearing out of thin air, weekend deploys going rogue. Another 2 hours are added. Now it’s 16.
Finally, it lands on the Chief Business Head’s desk. They pause. They blink. They cut it back to 8 hours.
Why? (I will come back to this later)
Buffer Time: The Hero We Hide in the Background
Most people think buffer time is “extra”. Some think it’s laziness. A few say it’s over cautiousness.
But for me? Buffer is insurance.
It’s the raincoat I carry even when the sky looks clear. Because in IT, storms don’t send a warning. They just arrive. And they come RSVP’d.
The Logic Behind Buffer Time
Let’s clear this up first: buffer time isn’t about distrust. It’s about being prepared.
As a Project Manager in Nepal, I’ve seen beautifully estimated projects turn chaotic within hours. Not because people failed, but because life happened. Or should we say, because project happened 😊?
Here’s what buffer time covers:
- That “quick” bug that took half a day
- Sudden sick leaves of your team member
- A design that needs one or more revisions
- The client suddenly remembering something “important”
- Random server downtime
- Internet glitches (yes, even in today’s time)
Buffer is not a luxury. It’s a necessity.
Why Everyone Adds a Bit More Except One!!!
Each person in the chain sees the same task through a different lens.
- The developer thinks: “If I get everything I need, I can wrap this in 8 hours, but I will have 2 more extra just in case”
- The Project Manager adds buffer for task clashes, dependencies, and review time.
- The Supervisor thinks of cross-project workload and available hands.
- Chief Tech Leadership adds time considering the full release plan, testing, and post-live monitoring.
- The Chief Business Head looks at one thing, Will the client accept this cost and timeline?
The task gets shaped and reshaped until it’s no longer just about development, it’s about delivery with all its messy, beautiful complexity.
So Why Does the Chief Business Head Cut It Back to 8?
Because at the end of the day, it’s a proposal, and proposals are all about perception.
If we show 14 or 16 hours for a task that the client thinks is “simple,” it risks rejection. The project might not even get approved. The quote may look too heavy, too slow.
So the Chief Business Head, balancing client trust and cost sensitivity, trims it back.
And here’s the best part:
Kyunki Chief Business Head bhi kabhi developer tha. 😂
Yes. That quiet smile they give while cutting hours? It comes from having been there. They’ve debugged at 1 a.m., pulled impossible timelines, and delivered under pressure. So while it might seem ruthless, they know the game, and sometimes they bet on experience, not buffer.
The Project Manager’s Dilemma
As a Project Manager in Nepal, this is the tightrope we walk every day. We know buffer time matters, and we add it carefully, not to inflate estimates, but to reflect the reality of delivery. Yet, we often watch those buffers shrink as the task moves up the ladder. Still, we keep doing it. Because perfect code and real-world delivery are never the same thing. Even when the buffer gets trimmed, the act of adding it sparks important conversations, highlights hidden risks, and sets the stage for clearer expectations. And when things eventually go sideways, as they often do, someone will usually recall, “Didn’t the PM warn us about this?”
Because let’s be honest, there’s a very special kind of joy in being right before things go wrong and a bonus when they had opportunity to say: “Maile to pahila nai bhaneko thiye.” 😂
That “I told you so” moment? It’s human nature. It gives people a strange sense of pride.
Final Thoughts
Adding buffer time is not a cover for inefficiency. It’s a cushion for reality. It shows that the Project Manager understands how projects really unfold. And even if that buffer gets trimmed by the end, we keep doing it.
It gives your team space to breathe. It reduces anxiety. It keeps morale steady. When the team knows you’ve got a fallback plan, they stop rushing, stop panicking, and start delivering better.
That’s the real win.
Because at the end of the day,
Our job is to deliver success, not just schedules.
Extra toppings on Pizza? on the same price? Yes, please! Let’s be Nepali here and say, Extra Gheeu (Clarified Butter) on Thakali Plate? Big yes.
To such practically wonderful creation Always A BIG YES …☺️☺️
Nice post , I would like to read on how managers deal when projects fail, even when the team members are really working hard