Shared Data, Shared Decisions: Making Resource Management Work

When people ask me what the best resource management tool is, I sometimes say: "The telephone."

I'm being facetious—mostly.

There are many excellent portfolio, project, and resource management tools available today. They're a far sight better than trying to maintain multiple spreadsheets and manually reconcile them, an approach that almost inevitably produces stale data, conflicting versions, and a great deal of administrative frustration.

But the joke contains an important truth.

No tool—however sophisticated—can support a credible resource decision if the people who hold different parts of the truth don't compare notes.

A project manager sees the work required for a particular project: its scope, milestones, dependencies, issues, assignments, and near-term demand. A resource manager—often the functional manager to whom the resources report—sees something different and equally crucial: each person’s total workload, skills, operational responsibilities, planned absences, competing commitments, and work that's coming down the pike but may not yet be visible to the project team—or even to the individual resource.

Neither view is sufficient on its own.

Credible resource decisions require both.

The real question is not “Who owns the data?”

Organizations often ask who should own resource management data. That’s a useful question, but it can become misleading if it turns into a search for one person, department, or system that’s supposed to know everything.

No one role can.

The project manager should own and maintain the integrated project schedule and its resource demand: the work required, the skills needed, the timing of those needs, and—where applicable—the task assignments that support delivery. The resource manager should own and maintain the capacity and effort forecast for the people or resource pool they manage: skills, workload, availability, commitments, and constraints across the full portfolio and operating environment.

The project manager is accountable for the schedule, but the schedule must remain fluid as resource managers provide current information about capacity and effort. In turn, resource managers need timely visibility into project plans, changing milestones, and upcoming demand. Neither role should be trying to “win” control of the plan. They are jointly responsible for keeping the project schedule and resource forecasts aligned.

Finance should own the financial framework—budget, forecasts, actuals, financial definitions, and controls—even though project teams and project managers may enter or provide much of the underlying information. A project manager may build the initial budget, for example, because they understand the labor, equipment, vendor, and timing assumptions behind the work. Team members may report actual time through timesheets, while project managers may report progress or forecast remaining effort. Finance then validates, consolidates, and uses that information to maintain an enterprise financial view.

Portfolio management should own the portfolio-level view: strategic alignment, priority decisions, portfolio categories, and the rules for comparing initiatives. But that view is not created only at the top. It depends on a steady flow of current information from project managers and teams—updated schedules, forecasts, delivery status, risks, changes, and emerging demand.

In other words, information must flow both ways. Project and team data flows upward to inform portfolio, financial, and capacity decisions. Priority, funding, and portfolio decisions flow back down, shaping what work is started, delayed, resequenced, stopped, or staffed differently.

The PMO, meanwhile, should own the process and operating model: common definitions, governance routines, reporting expectations, escalation paths, and the discipline required to keep information useful. But the PMO shouldn't own the underlying data elements. It cannot. No central function can realistically keep current on every project schedule, resource commitment, skill need, budget assumption, and change in priority across the organization.

The goal isn't centralized data ownership. It is shared visibility built on decentralized ownership. Data may live in a common system, but it has to be maintained by the people closest to its source. The PMO’s role is to make sure those views connect well enough to support credible decisions. In that sense, it helps the organization turn distributed information into coordinated action—and adapt when priorities change.

Each role owns the information closest to its work. Credible decisions depend on connecting those views.

Data may live in a common system, but ownership is decentralized by necessity. The people closest to the work capture and maintain much of the information; the shared process ensures it can be trusted and used together.

Each role has part of the picture

The following model helps clarify who should be responsible for maintaining key information.

Role	Information accountable for or maintained	Why it matters
Portfolio manager	Strategy mapping, prioritization, project portfolio data	Establishes why work matters and how it compares with competing demand
Financial manager	Financial forecasts, budgets, and actuals	Clarifies affordability, funding constraints, and financial trade-offs
Project manager	Integrated project schedule, project demand, status, issues, and task assignments where applicable	Defines what the project needs, when it needs it, and the dependencies that shape delivery
Resource manager / functional manager	Effort forecasts for their resources, skills, resource load, capacity, and broader availability	Provides the full picture of what people are already doing—and what is likely to be required next
PMO	Process, definitions, governance, reporting standards, and decision cadence	Creates the conditions for consistent data and capacity-aware decisions

This doesn't mean each function should keep its own isolated spreadsheet. In fact, that's usually how organizations end up with conflicting versions of reality.

It means each role should be accountable for the data it's best positioned to know and maintain, while that data is connected through a shared process and—ideally—a shared technology ecosystem.

Why availability is rarely what it seems

This is where many resource management processes break down.

A project manager has a legitimate need to focus on the work required to deliver a project. They need people with the right skills, at the right time, for the right amount of effort. If the project schedule shows an upcoming demand for a business analyst, engineer, designer, or subject-matter expert, the project manager needs to address that demand.

But the project manager can't reasonably be expected to see every other demand on that person’s time.

The resource manager can see the broader picture. They may know that the person in question is:

• Supporting a critical operational process that doesn't appear in the project plan.

• Already committed to another approved initiative that begins in several weeks.

• Needed for an audit, regulatory obligation, client deliverable, production release, or organizational priority.

• Covering for a colleague who is away.

• Performing work that hasn't been captured accurately in a formal system.

• One of only a few people with a highly constrained skill set.

• Approaching a level of workload where additional assignments will create delays, errors, disengagement, or burnout.

This is why “availability” can be such a dangerous word.

A person may appear available in a project schedule because they're not assigned to enough visible project work. But that doesn't mean they have meaningful capacity to take on something new. As Agile Manifesto co-author Alistair Cockburn once said to me, “People can’t be scheduled and moved like suitcases.”

A simple example

Imagine a project manager who sees that Maya is assigned at 50 percent to another project. The obvious conclusion is that she's available for 50 percent more work.

The resource manager sees something the project manager may not:

• Maya spends 20 percent of her time supporting an essential operational process.

• She's scheduled to cover a colleague’s leave beginning next month.

• A regulatory initiative will require her expertise in six weeks.

• A newly approved project hasn't started yet, but it will need her soon.

• Her team has already been operating in a sustained overload pattern.

Inside one project schedule, Maya appears available. Across the full system, she's not.

The right answer is not simply “no.” The right answer is a better conversation:

• Is Maya needed now, or can the work be sequenced differently?

• Can the project use someone with a different but sufficient skill profile?

• Can lower-priority work be paused or delayed?

• Is temporary external support justified?

• Does the conflict require an escalation because it affects multiple priorities?

That's the difference between filling a staffing request and making a capacity-aware decision.

The project manager knows the work demand. The resource manager knows the full plate. Decisions require both views.

Why the telephone still matters

So why do I say the best resource management tool is the telephone?

Because even the best system cannot capture every relevant fact automatically.

Hall of Fame baseball manager Whitey Herzog and I were once speaking at the same event. Asked what he thought about the growing use of analytics in baseball, especially when it comes to choosing the lineup, his answer has stayed with me.

He said, in essence, “I’m not against data. Information is never a bad thing. But the data isn’t going to know if a player’s wife just left him and his head isn’t in the game, or if someone has a hangover or a sore arm. The most important job I have as a manager is fielding the right team, and I’m not going to let data alone make that decision.”

That same point applies to resource management as well. Data can show demand, capacity, skills, allocation, and emerging conflicts. But it can't always tell you what's happening beneath the surface.

A resource manager may know that a team is nearing a breaking point even if the formal capacity calculation still looks acceptable. A project manager may know that a milestone has become critical because of a customer commitment, technical dependency, or emerging risk. Someone may be carrying invisible support work. A major initiative may be about to launch. A priority may have changed before the portfolio system has caught up.

Those signals need to be discussed.

The telephone, video call, hallway conversation, or structured resource planning meeting is where people reconcile the difference between what the system says and what's happening in reality.

That does not mean organizations should abandon tools and return to informal resource management. Quite the opposite.

Good portfolio, project, and resource management tools are essential. They create a shared foundation for data, reduce manual reconciliation, expose demand and capacity conflicts, support scenario planning, and provide the transparency needed for disciplined governance.

The point is that technology and conversation have different roles.

Tools are essential for	Conversations are essential for
Maintaining a shared, current view of work, capacity, skills, and allocation	Reconciling competing interpretations and incomplete information
Revealing demand-capacity gaps and resource conflicts	Understanding urgency, context, risk, and changing conditions
Supporting scenario analysis and portfolio trade-offs	Negotiating priorities and deciding which trade-offs to make
Creating repeatable workflows, transparency, and auditability	Surfacing work that's not yet visible or fully represented in the system
Reducing the burden of spreadsheet reconciliation	Keeping assumptions honest and updating plans when reality changes

A good system makes conversations more productive. Instead of debating whose spreadsheet is correct, people can focus on the real questions:

• What are we actually committed to?

• What capacity is genuinely available?

• What must happen now?

• What can wait?

• What should be stopped, reshaped, resequenced, or staffed differently?

• What trade-off is leadership willing to make?

The problem with spreadsheets

Spreadsheets are not inherently bad. They're flexible, familiar, and useful for analysis.

But spreadsheets are a poor foundation for enterprise resource management when they become separate systems of record for different functions.

One spreadsheet may show project demand. Another may show staffing. Another may show finance’s latest forecast. Another may contain a functional manager’s capacity assumptions. Each may be reasonable in isolation. Together, they can create a fragmented and constantly outdated picture.

The result is predictable:

• Project managers request resources based on incomplete availability data.

• Resource managers are forced to reconcile competing requests manually.

• Finance sees budget approvals without a clear connection to execution capacity.

• Portfolio leaders approve more work than the organization can realistically deliver.

• Individual contributors become the unacknowledged shock absorbers for unresolved portfolio conflicts.

That last point matters. When governance and data are weak, overload doesn't disappear. It simply gets pushed down to the people doing the work.

The system may show a full portfolio while the people experience impossible commitments.

Build a shared-data operating rhythm

Connected data is necessary, but it isn't enough. Organizations also need a practical rhythm for reviewing the data and making decisions.

Here are five practices that make the model work.

1. Define one authoritative owner for each type of data

Avoid asking multiple roles to maintain the same information in separate places.

The project manager should maintain project demand, schedule, status, and assignments. The resource manager should maintain capacity, skills, workload, and broader availability. Finance should maintain financial information. The portfolio manager should maintain priorities and portfolio context.

The PMO should ensure the process clarifies those accountabilities and connects the outputs.

2. Agree on common definitions

Terms such as “available,” “allocated,” “capacity,” “forecast,” “committed,” and “approved” often mean different things to different people.

For example, “available” might mean:

• Not assigned to another project.

• Not assigned above a particular percentage.

• Not committed to operational work.

• Available after planned leave, training, and support obligations.

• Available only after existing priorities are met.

If these definitions aren't shared, a resource plan can look precise while concealing major misunderstandings.

3. Establish a regular project-resource planning conversation

Project managers and resource managers need a reliable cadence to compare:

• Upcoming project demand.

• Current resource load.

• Skill constraints.

• Emerging work.

• Capacity risks.

• Shifts in priority.

• Assumptions that may no longer be valid.

The frequency will vary. Some environments need a weekly discussion; others may need it monthly or tied to major planning cycles. The important point is that it happens consistently enough to prevent surprises from becoming emergencies.

4. Treat approval as the start of capacity planning—not automatic launch

A project can be strategically important and financially approved yet still lack the people or skills needed to begin immediately.

Approval should not always mean “start now.”

Sometimes the responsible decision is to:

• Schedule the work for when critical capacity becomes available.

• Reshape scope to fit available skills and timing.

• Stagger the initiative with other work.

• Secure outside support.

• Pause or stop lower-priority work.

• Escalate a portfolio-level trade-off.

This isn't weakness or indecision. It's the very discipline needed for making commitments the organization can actually keep.

5. Escalate cross-project conflicts instead of normalizing overload

Some conflicts can't be resolved by a project manager and resource manager alone. If two high-priority initiatives need the same scarce capability at the same time, someone with authority must make the trade-off.

A defined escalation path prevents the organization from quietly resolving the conflict through overtime, multitasking, missed deadlines, or burnout.

The goal is not more bureaucracy. It is decisions at the right level, made with the best available view of demand, capacity, priorities, and consequences. See my article on Adaptive Alignment for more on this.

Shared data enables shared decisions

Effective resource management is not about creating a perfect database. It's about building a credible, connected view of reality—one that helps leaders make better choices before overcommitment becomes a delivery problem.

The project manager should not be expected to see everything. The resource manager should not be expected to carry the burden of saying no without context. Finance should not be expected to make funding decisions without visibility into execution capacity. And the PMO should not be expected to manufacture clarity from disconnected spreadsheets.

Each role has a part to play.

The project manager knows what the project needs. The resource manager knows what the organization is already asking of the people needed to do it. Portfolio and finance leaders provide the strategic and financial context. The PMO provides the process that keeps those views connected.

And yes, sometimes the most important resource management technology is still a conversation.

Not because tools do not matter, but because tools work best when the people using them are willing to compare their partial views of reality—and make shared decisions accordingly.