People, process and technology (PPT) is a framework that aligns your workforce, your workflows and your systems so that operational decisions, especially digital-transformation ones, get made deliberately rather than by accident. Get the balance right and you typically see faster adoption of new tools, fewer duplicated efforts, and clearer investment choices. Get it wrong, usually by leading with technology, and you inherit expensive software that nobody quite uses properly.
The one real limitation to know upfront: PPT tells you what to balance, not how to manage the human side of change. It works best paired with a structured change methodology.
Two places to go next in this piece:
- How to apply the framework in practice, with a diagnosis-to-scale sequence you can brief to a team
- A short pre-scale checklist covering owners, metrics and training gaps
Key Takeaways
Sustainable operational improvement depends on balancing people, process and technology together, with technology investment following, not leading, process and people readiness.
| Point | Details |
|---|---|
| Sequence matters | Diagnose people and process readiness before committing to any technology purchase. |
| Pilot before scaling | Test with one team and defined success metrics before rolling out organisation-wide. |
| Pair with change management | Combine PPT with structured approaches like ADKAR to improve adoption outcomes. |
| Data adds a fourth layer | Process mining and telemetry shift diagnosis from opinion to evidence (PPT+D). |
| Oak & Nine connects the view | Its platform unifies HR, finance and operations data so all three pillars are visible together. |
How Oak & Nine helps you run PPT without the department silos
Most PPT rollouts stall because HR, finance and operations each hold a piece of the picture and none of them see the whole thing. Oakandnine is built specifically to close that gap: one connected platform that maps your people, processes and technology together, so a bottleneck in operations shows up as a resourcing question for HR and a margin question for finance, in the same view, at the same time.
For operations leaders, that means real-time visibility into where work actually stalls, not where the org chart says it should. For managing directors, it means resource allocation decisions backed by data rather than department-level guesswork, with preemptive alerts flagging problems before they show up in a quarterly review. If you run a mid-market manufacturing operation, the manufacturing-specific view shows how this applies to shop-floor and supply-chain workflows specifically.
If you're a managing director weighing where to start, the Oak & Nine platform for managing directors is the fastest way to see what a connected view of your own operation would actually surface. Book a walkthrough and bring one real process you suspect is underperforming, it's usually the fastest way to see the platform prove its worth.
Table of Contents
- What is the people, process, technology framework?
- People, process and technology: what to fix in each pillar
- How do you apply PPT in your organisation?
- What are the advantages and limitations of the PPT framework?
- Where does PPT actually get used? Examples and process technologies
- How data and automation are changing PPT (PPT+D)
- Frequently asked questions
- Sources
What is the people, process, technology framework?
The model has a longer pedigree than most management frameworks still in active use. Its lineage traces back to Harold Leavitt's diamond model from the early 1960s, which originally mapped four interacting elements of an organisation: structure, task, people and technology. Over the following decades, structure and task were folded into a single concept, "process," producing the three-part model most managers now call PPT, sometimes referred to as the golden triangle.
The modern working definition is straightforward: PPT holds that sustainable operational performance depends on the interdependence of three elements, your people's skills and behaviours, the processes they follow, and the technology that supports both. Change one corner and the other two feel it. Hand a team new software without retraining them and you get shadow workflows. Redesign a process without touching the tooling and you get bottlenecks nobody can explain.
The discipline PPT forces on leaders, trading off people, process and technology deliberately rather than defaulting to whichever is easiest to fund, is exactly why a 60-year-old model still earns space on a whiteboard.
PPT is most useful in three situations:
- Deciding whether a problem is really a skills gap, a broken workflow, or a missing system
- Scoping a digital transformation project before technology procurement begins
- Diagnosing why a previous change initiative stalled after go-live
What PPT does not do is prescribe how to manage resistance, sequence communications, or build adoption momentum. In modern practice, it works as a diagnostic and planning lens that sits alongside structured change methodologies such as ADKAR, rather than replacing them. Treat it as the map, not the route.
People, process and technology: what to fix in each pillar
Each pillar breaks down and gets rebuilt differently, and most managers spend too long on one and not enough on the other two.
People: skills, leadership and the honest engagement question
The people pillar is about capability and willingness, not headcount. Research into digital transformation consistently finds that success depends on talent across specific capability areas, not general enthusiasm for change. Before you touch a process map or shortlist software, you need clarity on three things: who owns which decisions, what skills exist versus what the new way of working requires, and whether leadership is visibly modelling the change or just announcing it.
The most common failure mode here isn't outright resistance. It's quiet non-adoption: people nod in the meeting, then keep using the old spreadsheet because nobody removed it or explained why the new way is actually better for them.
Process: map it before you touch it
You cannot fix what you haven't documented. Process mapping, standard operating procedures, and bottleneck detection form the backbone of this pillar, and the order matters: map first, then reengineer, then document the new state. Skipping straight to reengineering without a current-state map usually means you're solving a problem you've assumed rather than one you've confirmed. If you want a practical walkthrough of isolating where work actually stalls, bottleneck diagnosis is worth doing before any process redesign conversation.
Technology: selection, integration risk, and knowing when to wait
Technology should be the last pillar you commit budget to, not the first. Selection criteria worth insisting on: does it integrate with what you already run, does the interface match how your team actually works day to day, and is there a realistic adoption support plan beyond a training video. Continued growth in worldwide IT spending means the temptation to buy your way out of an operational problem isn't going away, but unbudgeted integration work is the single most common reason technology rollouts run over time and cost.
Delay technology investment specifically when: the underlying process is still unstable, when nobody has agreed who owns the data the new system will produce, or when the team hasn't been consulted on the interface.
- People tip: Run a two-question pulse check before rollout, "what would make this easier?" and "what will you keep doing the old way?", it surfaces resistance you can actually plan for.
- Process tip: Map the current state with the people who do the work, not just their managers, discrepancies between the two versions are where your real bottlenecks live.
- Technology tip: Pilot with your most digitally confident team first, not your most senior one, adoption feedback is more honest and arrives faster.
Pro Tip: When a technology rollout stalls, check the process map before you blame the software or the team. A tool built for a workflow that changed six months ago will fail regardless of how good it is.
How do you apply PPT in your organisation?
Applying PPT well is a sequence, not a workshop exercise. Rush the diagnosis and you'll pilot the wrong thing; skip governance and a promising pilot dies quietly at month four.
- Diagnose across all three pillars simultaneously. Build a stakeholder map (who's affected, who decides, who's ignored), a process inventory (what's documented versus tribal knowledge), a people capability audit (skills present versus skills required), and a technology landscape review (what you already own that's underused).
- Prioritise using value, complexity and readiness. Score candidate projects on expected value, delivery complexity, and organisational readiness, three axes, not one. A high-value project with low readiness usually needs a smaller precursor pilot first, not a green light.
- Design the pilot properly, before you launch it. Define success metrics before day one, not after. Build feedback loops short enough to catch problems within weeks, not quarters. Assign a named governance owner, not a committee.
- Run it, measure it honestly, then decide on scale. A pilot that "sort of worked" isn't a scale decision, it's a signal to iterate again.
Practical inputs your diagnosis phase needs:
- Interview transcripts or survey data from the people actually doing the work, not just their managers
- A current-state process map with cycle times, not just a flowchart of steps
- An inventory of existing software licences and integration points, many organisations already own tools nobody's using properly
- A readiness score based on past change fatigue, not just enthusiasm in a kickoff meeting
Scaling criteria should be set before the pilot starts, not negotiated afterwards. At minimum, insist on: the pilot hit its predefined success metric, the team that ran it would recommend it unprompted, and the integration cost at scale is known, not estimated. Practitioner guidance on rolling out automation programmes consistently points to federated ownership models, where responsibility for the new way of working sits with operational teams rather than a central project office, as the difference between a pilot that scales and one that quietly dies.
What are the advantages and limitations of the PPT framework?
The clearest benefit is alignment. When people, process and technology decisions get made against a single framework rather than three separate conversations, investment choices sharpen and adoption tends to move faster because nobody's blindsided by a system change nobody explained.
- Faster adoption when the three pillars move together rather than technology arriving months ahead of process redesign
- Clearer investment prioritisation, you stop funding software that has no process readiness behind it
- Shared vocabulary across HR, operations and IT, which reduces the "that's not our problem" deflection during transformation projects
The limitations are real and worth naming honestly. PPT can oversimplify genuinely complex organisational dynamics into three neat boxes when the actual friction sits between departments, not within a pillar. It doesn't prescribe adoption tactics, so pairing it with formal change management such as ADKAR consistently improves outcomes versus running PPT alone. Integration difficulty is chronically underestimated, and measurement gaps are common: many organisations pilot a change but never define what "working" actually looks like in numbers.
Continued growth in enterprise IT spending means the pressure to buy technology first, before process and people readiness catch up, isn't easing. That's precisely the sequencing mistake PPT exists to prevent.
Mitigate all three limitations the same way: combine PPT with a structured change methodology, define your measurement plan before the pilot starts rather than after, and deliver in small increments you can course-correct rather than one big rollout.
Where does PPT actually get used? Examples and process technologies
The clearest way to understand PPT is through a project you'd actually recognise. A CRM rollout, for instance: the people work is retraining sales reps on a new pipeline structure, the process work is defining what "qualified lead" means before the software enforces a stage-gate, and the technology work is the CRM itself, but only after the first two are settled. Invoice automation follows the same order: process first (what approval chain currently exists, informally or otherwise), people second (who signs off and why), technology last (the automation tool that encodes both). HR onboarding is identical in structure: map the current candidate-to-employee journey, agree the people accountable at each handoff, then select the system.
Several categories of "process technology" are worth knowing by name, since vendors use them loosely:
- Business process management (BPM) software, for modelling and enforcing multi-step workflows
- Process mining tools, which reconstruct how work actually happens from system logs rather than how it's assumed to happen
- Robotic process automation (RPA), for automating repetitive, rules-based tasks
- Low-code or no-code platforms, letting operational teams build lightweight tools without a full development cycle
| Project type | Highest-risk pillar | Typical first pilot |
|---|---|---|
| CRM rollout | People (adoption) | Single sales team, one pipeline stage |
| Invoice automation | Process (approval clarity) | One vendor category or spend threshold |
| HR onboarding | Process (handoff gaps) | One department's new-hire journey |
Pick your first pilot by weighing expected return against adoption risk, not by which system is easiest to procure. A project with modest ROI but low adoption risk will teach your organisation more about running PPT well than an ambitious one that stalls at the people pillar.
How data and automation are changing PPT (PPT+D)
The classic model assumed you'd diagnose people, process and technology largely through interviews and workshops. That's changing. Process mining and system telemetry now let you see how work genuinely flows, not how someone remembers it flowing, which shifts PPT from an opinion-based exercise to an evidence-based one. This is often called PPT+D, adding data as a fourth, connecting layer rather than a fourth pillar.
Automation and AI are also moving where value gets created. Routine, rules-based work increasingly runs itself, which means the people pillar now needs analytical and oversight skills rather than pure task execution.
- Governance needs continuous monitoring, not quarterly reviews, once automation is live
- Error rate and throughput become standing metrics, not one-off pilot measures
- Adoption tracking needs to continue well past go-live, early usage numbers often mask a slow decline
Pro Tip: If you're still diagnosing bottlenecks by interview alone, a process mining tool or comparable process visibility approach will surface friction points your team has stopped mentioning because they've normalised the workaround.
Six pitfalls to avoid before you scale anything
- Leading with technology. Fix: confirm the process is stable before procurement starts.
- Skipping the current-state map. Fix: document actual behaviour, not intended behaviour.
- No named pilot owner. Fix: assign accountability before day one, not after problems appear.
- Undefined success metrics. Fix: agree the numbers that mean "working" before launch.
- Ignoring quiet non-adoption. Fix: check usage data weekly, not just satisfaction surveys.
- Scaling too early. Fix: require the pilot to hit its metric and earn an unprompted recommendation first.
Before scaling anything, confirm you have: a named owner per pillar, agreed success metrics in writing, evidence the pilot team would recommend the change unprompted, and a training plan for the wider rollout, not just the pilot group.
Oak & Nine's applied view on people, process and technology
Oakandnine builds a business management platform specifically to eliminate the silos that make PPT hard to run in practice, connecting HR, finance and operations into a single framework so decisions get made with visibility across all three pillars at once, rather than department by department.
The platform surfaces process dynamics as they actually happen and automates the routine tasks that otherwise consume the time managers need for the diagnosis-and-pilot work described above. Real-time insights and preemptive alerts mean issues surface before they compound into a failed rollout.
Applying PPT well has always depended on seeing all three pillars clearly at the same time. That's the exact gap a connected operating view is built to close.
[Author bio: Ronan's practical experience with business management platforms and process optimisation informs this analysis.]
[Case study evidence of Oak & Nine's applied impact for mid-market operations teams.]
Start small, prove value, then govern properly
If you take one thing from this framework, make it a small pilot. Pick a single team, a single workflow, and prove the value before you touch anything organisation-wide, confidence compounds faster than ambition does.
My three priorities, in order: diagnose honestly before you pilot anything, run the pilot small enough to fail safely, then govern it properly once it works. PPT gives you the map. Pair it with people-centred change practice, and you'll actually use it.
Frequently asked questions
What does the people, process, technology framework actually mean? It means treating your workforce's skills, your documented workflows, and your systems as interdependent, so a change to one is evaluated against its effect on the other two before you commit budget or time to it.
Is PPT the same as change management? No. PPT is a diagnostic and planning framework for deciding what to change and in what order. Change management, such as ADKAR, prescribes how to move people through that change. They work best together.
Which pillar should you fix first? Usually people and process, in that order. Technology should follow once the workflow is stable and the team understands why the change is happening, not the other way round.
What is PPT+D? It's the modern extension of PPT that adds data, through process mining and system telemetry, as a layer connecting all three original pillars, shifting diagnosis from interviews and assumptions to observed system behaviour.
How do you know a PPT pilot is ready to scale? It hit the success metric you defined before launch, the team that ran it would recommend it unprompted, and you know the real integration cost at scale rather than an estimate.
Sources
For deeper background: Forbes on PPT's 60-year lineage, Prosci's pros and cons analysis, Smartsheet's complete PPT guide, and Gartner's IT spending forecast. For applied next steps, see Oakandnine's guide to business process optimisation.
- Is The 60-Year-Old 'People Process Technology' Framework Still Useful?
- People, Process, Technology (PPT) Framework: Pros and Cons