← Insights

People, Process, Data, Technology: Why the Order Matters

A consulting team and a client engineering team standing in a loose circle at a morning standup, coffee in hand, mid-conversation.

ArcherGrey has a mantra: people, process, data, technology. The failure mode is surprisingly specific: technical teams read it back to front.

That inversion is understandable. A statement of work is written in the language of technology and data: upgrade the platform, implement change processes, configure the object types, migrate the records. Requirements workshops start with artifacts. Sprint boards fill with configuration tasks. Within a month, the project is fluent in the third and fourth words of the mantra and has stopped saying the first two out loud.

But technology and data are not why the project exists. They are outcomes, artifacts that people assemble through processes to reach a business goal. Whatever the company makes, the pattern is the same: people execute processes, and technology and data are simply the tools they use. When a project stalls, the stall is almost never in the object model. It is in the people who have quietly stopped believing in the process.

Which is why the most useful instrument on a long-running program is not the burndown chart. It is a finger on the pulse of how the people feel.

PEOPLE, PROCESS, DATA, TECHNOLOGY The order is the argument SAY IT IN THIS ORDER. RESOURCE IT IN THIS ORDER. People Who has to change how they work, and whether they believe it. Process How the work actually gets done once the room clears. Data An artifact people assemble, not a reason to start. Technology The tool the work runs on. An outcome, never the purpose. HOW THE STATEMENT OF WORK READS IT Configure the object types. Migrate the records. Fill the sprint board. Technology and data can tell you what got built. They can never tell you whether it was worth building.

The standup that nobody wanted

On one long-running program, the two teams met a few times a week. We proposed replacing that with a daily meeting, every morning, same time. Nobody was excited. For the first stretch it felt like a slog: here are the tasks, here is the status, see you tomorrow.

Around the second or third month, the meeting changed. The two teams started to actually know each other. Jokes surfaced. Small connections accumulated, the kind that have nothing to do with the project: weekend plans, hometowns, the small talk that turns colleagues into people. Trivial on paper. Not trivial in effect.

Because rapport is not a soft outcome; it’s an operational advantage. When something unexpected breaks, a team with rapport responds with “I got it, I can help you out” instead of escalation theater. Decisions that would take a formal meeting cycle get made in the daily. And you gain a live read on the question that predicts project health better than any status report: who shows up to this call with energy, and who has gone flat?

The impact compounds. Teams that trust each other get looped in earlier, while decisions are still soft enough to shape. Problems arrive as conversations rather than as escalations, and the people closest to the work stop editing what they tell you. That is worth more to a program than any single deliverable, and it is the direct result of showing up every day as people rather than as roles.

No project plan anywhere has a line item for rapport. It is still the one that carries all the others.

Outcome-driven beats task-driven

Daily meetings run on tasks, and tasks have a gravity of their own. Left alone, a project team becomes excellent at answering “what is the status of this item?” and gradually forgets to ask, “why is this item on the list?”

The counterweight is a deliberate planning rhythm at a higher altitude. Monthly sprint planning, and a broader periodic session covering the epics, the big structural phases of the program. The daily meeting asks what and how. The planning sessions exist to re-ask why: why this series of tasks, what capability will exist when they are done, what will end users be able to do that they cannot do today.

That question routes straight back to the front of the mantra. “Why” questions are answered at the people and process level. Technology and data can only ever tell you what got built, never whether it was worth building.

Teams that skip this rhythm do not fail loudly. They optimize, sprint after sprint, into a perfectly executed backlog that has drifted off the business outcome, and nobody notices until someone senior asks what all this configuration actually changed.

Key takeaways

Say the mantra in order, resource it in order. If the project plan has line items for technology and data but nothing that deliberately builds the people side, the plan has already inverted the priorities it claims.

Meet more often than feels necessary, then protect the cadence. Daily contact looks inefficient until you price what it replaces: slow decisions, formal escalations, and discovering in month six that the team checked out in month three.

Re-ask why on a schedule. Task rhythm is daily, outcome rhythm is monthly or quarterly, and both need a fixed slot on the calendar. The teams that only meet about tasks end up task-driven by default, not by decision.


← Back to all insights

Ready to start?

Shape your PLM future.

Wherever you are in your PLM journey, whether starting fresh or optimizing, our consultants meet you where you are and drive faster ROI through tailored strategy and expert execution.