Allocating Effort by Quarter: Cascading the Balanced Scorecard Down to a PM's Own Work

Who i am
- Software developer
- Gymer
- Book reviewer
- Blog writer
- Project Manager
- Dreamer
A note before we start
A few disclaimers, as always:
- This is a personal perspective, from my context as a PM in Japan-focused IT outsourcing, at a company that runs Balanced Scorecard (BSC) from the corporate level down. Every organization implements it differently — read this as a reference, not a template.
- Project, client, and internal figures have been anonymized or replaced with illustrative numbers where needed.
- I could be wrong about parts of this. I'd genuinely welcome pushback.
Busy all quarter — so where did the effort go?
When I managed a single project, my days were simple: open the board, see what's due, get to work. Life ran entirely on a daily layer.
Then the number of projects grew. Every day looked full — meetings, reviews, issues resolved, clients answered. Day to day, nothing to complain about; every day felt "productive." But at the end of the quarter, looking back, I got stuck on some very basic questions.
How much of my time that quarter actually went toward what mattered — and how much just got pulled along by whatever came up? The things that matter but aren't urgent — training the team, improving process — how much effort did they actually get? Or was it, once again, zero?
I had a solid daily layer. But the quarterly layer was nearly empty. And I think that's the real line between someone who operates and someone who manages: from the PM level up — especially once you start stepping into a division-level role — you have to look at goals and allocate effort by quarter, sometimes by year.
The funny part: the tool for doing this had been sitting inside the organization the whole time. I'd just never thought of it as my job to use.
BSC, in plain terms
BSC (Balanced Scorecard) is a strategic management framework by Kaplan and Norton, dating back to the 1990s.
The core idea: don't judge an organization by financial numbers alone. Look at it "in balance," across four perspectives — Financial, Customer, Internal Process, Learning & Growth. In plain terms: is money coming in, are customers happy, does the machine run smoothly, and are people growing.
Picture a four-legged chair: shorten one leg noticeably, and the whole thing wobbles no matter how solid the other three are. Organizations work the same way — and IT outsourcing especially so. Revenue comes from long-term client relationships, particularly with Japanese clients, so if you only chase financial numbers and near-term delivery, the two things that sustain you long-term — process quality and team capability — quietly erode without you noticing.
At my company, BSC cascades from the corporate level down to departments. And honestly, I used to be like most people: sitting in the annual briefing, nodding along, genuinely convinced — then walking back to my desk and diving straight back into project work. BSC, to me back then, was "the leadership team's thing."
The turning point was a simple question: if the company can cascade BSC down to departments, why can't I cascade it one level further — down to my own work?
In Developing the Leader Within You, John Maxwell makes a point I keep coming back to: to lead others, you first have to lead yourself. Looking back, cascading BSC down to my personal work was exactly that kind of exercise — treating my own time with the same seriousness an organization treats its strategy.
Cascading to the PM level: same four perspectives, different center of gravity
The biggest lesson from actually doing this: cascading isn't copying.
At the corporate level, Financial and Customer tend to dominate — revenue, new contracts, client satisfaction scores. But at the PM level, I don't directly control revenue. What I actually hold in my hands lives in the other two perspectives:
- Internal Process — building, improving, and owning the process within the project(s) I manage directly: how the team reports progress, how issues get handled, how quality gets reviewed before delivery to the client. Not some org-wide initiative — process I can actually change and control myself.
- Learning & Growth — the capability of the developers, testers, and BrSEs on my own team. For someone transitioning from "doing" to "leading," this is the perspective that determines whether you ever actually escape day-to-day operations.
Financial and Customer don't disappear — but from a PM's seat, Internal Process and Learning & Growth are the two levers I can move directly and most heavily. Their results ripple outward into Financial and Customer indirectly: better process and stronger people eventually show up as QCD and client trust — I just have no direct lever into those two perspectives themselves.
How I actually do it — 4 steps
Step 1 — Receive and translate the goals. At the start of each quarter, starting from my leadership's BSC goals, I ask: "given these, what should a PM at my level contribute to each perspective?" I keep it to 1–2 objectives per perspective. More than that, and it's usually a sign I haven't actually prioritized.
Step 2 — Assign a % of effort to each perspective. The unit I use is as simple as it gets: % of my own time. Your time budget is 100% — but don't allocate the full 100%, for reasons below.
Here's what one of my recent quarters looked like:
| BSC Perspective | Main Content | % Effort |
|---|---|---|
| Internal Process | Building, improving, and maintaining process within the project(s) I manage | 20% |
| Learning & Growth | Training dev, test, and BrSE within my team | 20% |
| Customer | Communication and follow-up with Japanese clients | 20% |
| Delivery | Ensuring QCD across running projects | 30% |
| Unplanned buffer | Reserved, unassigned — for whatever comes up | 10% |
That 10% buffer isn't arbitrary — it lines up with a real benchmark in the Japan SI/IT-outsourcing industry, where project management overhead is commonly estimated at around 10–20% of total workload. More broadly, project teams elsewhere tend to plan for only 70–80% of capacity, keeping 20–30% as buffer for the unplanned. I lean toward the lower end of that range, since I've already got a decent read on the recurring risks in the projects I manage.
Step 3 — Break it down by month. Quarterly percentages carry a trap: a false sense of "plenty of time left." So I split the quarter's percentages into a monthly rhythm — which perspective gets pushed this month, which one just holds steady. Early quarter tends to be heavier on planning and process; late quarter, heavier on delivery and review.
Step 4 — At month-end, compare plan against reality. This is the step that decides whether the whole system lives or dies — and the one I've historically done worst. Allocating without reviewing is just a pretty spreadsheet. How to actually review it without it eating your time — that's a story for the next post.
Being honest: where this tends to break
In the spirit of not sugar-coating things, here's what I've actually run into:
- BSC turns into pure formality, fast. Build the allocation table just to "have something to report," and it's dead within a month. The table only stays alive when you're willing to use it to say no: "this doesn't belong to any perspective I've committed to — does it really have to be me?"
- Unplanned work will eat your percentages. In IT outsourcing, client issues can land at any moment. That's exactly why the table above always reserves 10% as buffer — not to "do the unplanned work," but to give the unplanned something to land on instead of cannibalizing the other four perspectives. Skip the buffer, and the first thing quietly sacrificed is always Learning & Growth — the perspective that matters most long-term, and the quietest one when it's starved.
- A plan you don't track is barely a plan. Sitting down at month-end to recall where your time went is slow, inaccurate, and easy to lie to yourself about. For me, this always plays out the same way: I'm tracking consistently, daily and weekly, until a project issue lands — and tracking quietly breaks, and worse, I don't even notice it broke until the month is already over. That's exactly why I started building an automated tracking system for myself.
In short
For the readers who, like me, prefer the short version:
- The daily layer isn't enough. From the PM level up, you need a quarterly/yearly layer too: what the goals are, and where effort is actually going.
- BSC isn't just leadership's job. If your organization already runs BSC, cascade it further — down to your own work. Same four perspectives, different center of gravity.
- At the PM level, your strength sits in Process and Learning & Growth — the two perspectives that aren't urgent, which means without an explicit % assigned, they'll always lose out to whatever's on fire that day.
- The simplest unit is % of your own time. Assign it at the start of the quarter, break it down monthly, compare it at month-end.
- Plan is only the "P" in PDCA. There are three letters left — and Check (actually tracking effort month over month) is the part I'm still automating for myself. More on that system in a follow-up post.
What about you — could you actually answer, right now, "where did my effort go last quarter"? And if you had to redistribute your 100% differently, where would you change it? I'd genuinely like to hear in the comments.



![[Trải nghiệm] Đơn giản là thư giãn](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Funsplash%2FKVym2PAn1gA%2Fupload%2Fv1669547521341%2FpszaH-1Nqm.jpeg&w=3840&q=75)