People: the missing line in the project plan

· business-agility, meetup, project-management, people

Florin Pintilie presenting “People: the missing line in the project plan” at the Melbourne Business Agility Meetup

At the July 2026 Melbourne Business Agility Meetup, Florin Pintilie explored a variable that influences every project but rarely appears as its own concern in the project plan:

People.

Florin isn’t arguing that project managers should add people as a seventh constraint alongside scope, budget, timeline, quality, risk and benefits.

Instead he’d like us to remember that:

People are the thread running through every project variable and every phase of delivery.

A technically credible plan can still fail when it assumes that people behave like interchangeable resources: consistently available, immediately productive, perfectly informed and unaffected by the environment around them.

Florin suggests a people-centred approach that retains the discipline of project management while asking better questions about the people delivering, supporting and using the outcome.

Along these lines, consider choosing the word “people” over “resources” when you mean people. It disambiguates the ask.

The people dimension is not the soft side of the project

Florin repeatedly framed that caring about people does not mean ignoring delivery discipline.

People issues have direct project consequences:

Engaged and intrinsically motivated people are also more likely to collaborate, identify problems early and produce better outcomes.

Some friction can be valuable. A team willing to challenge assumptions during idea formation and discovery may experience more disagreement early, but avoid far more expensive disagreement once delivery is underway.

The cold, commercially minded argument for paying attention to people is straightforward: ignoring people costs money and time.

People affect every project variable, across PMI and PRINCE2 frameworks

PRINCE2 defines six project variables: scope, budget, timeline, quality, risk and benefits.

Project variables as defined by PRINCE2, with people at the centre influencing scope, budget and timeline, quality, risk, and benefits

Florin walked through how each is influenced by people.

Budget and timeline

A plan becomes more realistic when it accounts for actual availability and capacity.

People take leave, become sick, join and leave projects, require onboarding, support colleagues and participate in activities such as planning, reviews, testing and knowledge transfer.

A spreadsheet that divides effort by headcount may be mathematically correct while remaining operationally impossible.

Scope

Scope is interpreted by people.

Requirements may be ambiguous, incompletely recorded or understood differently by sponsors, delivery teams and users. Priorities also change as people learn more about the problem.

Managing scope therefore requires more than controlling a baseline. It requires building shared understanding and recognising how changes affect both the people doing the work and those depending on its outcome.

Quality

Quality depends on having people with the appropriate skills, experience, context and support performing the work.

It also depends on the environment around them. When people are overloaded, unable to raise concerns or pressured to meet an implausible deadline, they are more likely to take shortcuts.

Risk

Risk identification improves when it involves people with different perspectives and direct knowledge of the work.

Collaborative assessment can expose risks that are invisible from the project office. The same diversity of perspective helps teams develop more creative and practical responses.

Benefits

Benefits are realised by people changing what they do.

A project may deliver every specified output and still fail when users reject the solution, operational teams cannot support it, or stakeholders do not behave in the ways assumed by the business case.

Understanding who benefits—and what must change for those benefits to appear—is part of project delivery, not a post-project concern.

Project phases mapped across PMBOK and PRINCE2 to simplified stages: Idea, Discovery, Planning, Delivery, and Close

Idea: should we do this project?

At the idea stage, the question is not simply whether an outcome is technically feasible.

It is:

Does this solution fit the people it is intended for, and can they use it successfully for its intended purpose?

Florin used the consumer version of Google Glass as the example.

The technology was impressive, but the product created social problems that its technical capabilities could not overcome. People felt uncomfortable about the possibility of being recorded, wearers attracted negative attention, and some businesses banned the device.

The project answered can we build it? more convincingly than will people accept it?

The lesson was that technical achievement does not guarantee usefulness. Social expectations, behaviour and lifestyle are part of product feasibility.

Discovery: understand real work, not the process diagram

Discovery asks what is being built and who it is being built for.

That requires more than interviewing a sponsor or documenting the ideal process. It means observing how work actually happens, including exceptions, workarounds, competing priorities and stressful conditions.

Florin illustrated this with the London Ambulance Service computer-aided dispatch project.

The system was designed around an idealised process but did not adequately reflect how call handlers, controllers, dispatchers and radio operators coordinated during real emergencies. Under pressure, people adapted constantly, worked with incomplete information and handled situations that did not fit a clean sequence of steps.

The result included system failures, incorrect dispatches, operational disruption and eventual withdrawal.

The broader lesson was:

People do not work like process diagrams.

Good discovery studies the real environment rather than treating deviations from the documented process as inconvenient noise.

Planning: build a delivery capability, not just a schedule

The planning phase is often dominated by dates, budgets, dependencies and resource allocations.

Florin argued that it should also consider:

Queensland Health’s payroll implementation illustrated the consequences of getting this wrong.

Heavy reliance on contractors, turnover, limited documentation, weak knowledge transfer and inadequate operational preparation left the organisation dependent on knowledge that departed with experienced people. The system then required years of remediation at enormous cost.

The planning lesson was concise:

If critical knowledge walks out the door with contractors, the project is not ready for delivery.

Contractors and consultants are not inherently the problem. The risk comes from treating knowledge retention, onboarding and handover as secondary administrative activities rather than core elements of the delivery plan.

Delivery: create the conditions for people to succeed

Once work begins, the project manager’s role shifts.

The focus becomes creating an environment in which people can execute on the plan.

That includes:

Florin’s framing was that project managers should not merely assign and monitor work. They should actively shape the conditions surrounding it; recasting and reframing it when appropriate.

A retrospective, for example, is not valuable simply because it appears in the calendar. It becomes valuable when people can speak honestly without expecting punishment or dismissal.

Close: leave the organisation stronger

A project close is usually associated with acceptance, sign-off, documentation and releasing resources.

The people perspective adds several further questions:

A project can deliver its specified output while leaving behind an exhausted team, disengaged stakeholders and missing knowledge.

That may satisfy a narrow definition of completion, but it wastes much of the value created during delivery.

Project focus and people focus are complementary

Florin contrasted two ways of examining the same project decision.

A project-focused response to a budget overrun might include:

These are legitimate project-management responses.

A people-focused perspective adds:

The discussion in the room also highlighted that communication cannot begin when the bad news arrives.

A project manager who has built trust and maintains dialogue with sponsors and stakeholders can discuss an emerging problem early, explain the evidence and work through options. Without that relationship, the same message can feel like an unexpected failure presented too late.

Empathy does not replace accountability or decision rights. The sponsor may still make the final decision. Empathy improves the information and options on which that decision is based.

Exercise: A ten-day project that is not really ten days

The group exercise gave meetup attendees a seemingly simple planning problem:

The arithmetic initially suggests ten development days.

The people dimension complicates that answer.

Are all four developers equally familiar with the system? Can all work proceed independently? How much collaboration is required? Who reviews the code? Does testing start only after development? How quickly can defects be resolved? Are people working on anything else? What uncertainty is hidden in the estimate?

The point is not to produce a perfect new number.

Instead, consider that a date derived from effort divided by headcount is only the beginning of a delivery forecast. Before committing to it, a project manager needs to understand the people and the system in which they work.

Strongest insight

The strongest takeaway from the session was that putting people at the centre does not weaken project management.

It makes project management more realistic.

The project plan still matters. Scope, budget, timeline, quality, risk and benefits still need to be managed. But plans improve when they recognise that projects are delivered through human judgement, coordination, learning, motivation and relationships.

In Florin’s closing words:

People are not another line in the project plan. They are the thread running through the entire project.

Slides

Download Florin’s slides (PDF).

Thanks

← All articles