You can’t scale what you don’t structure: the case for project-centricity

Highlights

• In project‑driven organizations, scaling rarely fails because of missing tools, but because there is no shared structural logic
• Project centricity means treating the project as the central organizational reference for processes, data, and decisions
• Best‑of‑breed tool landscapes increase complexity when they lack an overarching organizing principle
• An integrated platform strategy (e.g. built on Dynamics 365) enables consistent data across the entire project lifecycle
• Sustainable scaling is achieved incrementally through stable structures, not rapid tool rollouts
• Project centricity is an ongoing organizational design choice

Many organizations today have powerful systems in place, established project management methods, and a broad tool landscape. Yet scaling often remains difficult. Transparency comes too late, steering is reactive, and as organizations grow, operational complexity increases faster than their ability to manage it.

In project‑driven companies, the root of the problem is rarely missing software. More often, it lies deeper: the absence of a shared structural principle that processes, data, and decisions can align around. This becomes particularly evident in environments where projects vary widely in size, run over long periods of time, and involve many different roles.

The experiences described here are based on a customer project delivered by proMX and were first presented by Gruner in a keynote at the proMX Project Operations Summit 2025. The talk provided insights into the long‑term platform and organizational development of a project‑driven engineering company with over 160 years of history.

The reality of project‑driven organizations

Project‑based organizations often manage thousands of projects in parallel – ranging from very small, short‑term initiatives to major projects running for decades. Accordingly, large numbers of employees, departments, external partners, and administrative roles are involved.

In practice, the supporting systems are frequently the result of historical growth:

• multiple ERP systems
• separate file repositories
• CRM solutions not connected to operational processes
• no end‑to‑end link between project execution, financial oversight, and documentation

The result is fragmented workflows, duplicate data entry, and a growing reliance on unofficial channels such as Excel, cloud storage, or messaging tools. These workarounds are usually a clear sign that a unifying structure is missing.

A seemingly obvious response is to search for better individual tools: a more powerful project management solution, a new ERP system, or additional specialist software. However, this approach still focuses on functionality rather than structure. The underlying problem of isolated systems with their own internal logic remains unresolved. For organizations with small IT teams in particular, a best‑of‑breed strategy quickly becomes a burden.

💡 Scaling does not fail because of tools – it fails because there is no overarching organizational principle.

The design decision: project centricity as an operating model

The decisive turning point in this journey was a conscious design decision: establishing the project as the central structural unit of the organization. In this context, project centricity does not mean classical project management. It means that all project‑related information has a clear and explicit link to the project itself. The project becomes the shared reference point across roles and systems.

In concrete terms, this includes:

• sales and quoting
• effort and resource planning
• tasks, time, and costs
• communication, documentation, and archiving
• evaluation and reporting

The project is no longer treated as a temporary work package, but as an organizational framework. This logic goes beyond individual departments and connects operational work, management, and financial oversight.

Why a platform strategy becomes the logical next step

Once this logic is applied consistently, the next decision follows almost automatically: a platform strategy instead of a collection of isolated systems.

During the evaluation of traditional PM and ERP solutions, Dynamics 365 stood out for its ability to support an integrated, extensible platform. The implemented landscape included:

• Dynamics 365 Project Operations for project‑related processes
• Dynamics 365 Finance for financial control
• the broader Microsoft ecosystem with Microsoft 365, Power Platform, and Azure
• third‑party systems connected via APIs

A core principle was to capture information once and reuse it across systems. The project reference acts as the connective element that makes this integration possible.

Structure over speed: a phased implementation

The implementation did not follow a big‑bang approach. Instead, it was carried out step by step over several years. Initial efforts focused on fundamentals such as collaboration and financial transparency. This was followed by CRM, early PSA approaches, and later the transition to Dynamics 365 Project Operations and the Finance module.

Not everything went smoothly. In particular, the transition from Dynamics 365 Project Service Automation to Project Operations required extensive clean‑up and restructuring, as existing projects and planning logic were not directly compatible. This phase took significant time but was necessary to achieve a consistent structure.

The key insight: sustainable scaling is not created by speed, but by the stability of the underlying structure.

What project centricity has changed in practice

The consistent application of project centricity led to tangible changes in day‑to‑day work:

• effort estimates are mandatory before quote creation
• projects are planned in a standardized way, regardless of size or duration
• project reviews are conducted monthly based on consistent planned and actual data
• the majority of employees work in CRM and Project Operations, while Finance is mainly used by the finance department
• communication, documents, and external collaboration are clearly anchored to projects

The result is not full automation, but significantly improved transparency and consistency in managing project‑based work.

Key learnings: scaling requires structure and discipline

Several lessons can be drawn from this journey:

• a platform strategy should be defined early
• change management is not a side topic, but a major cost and success factor
• standard functionality is more robust in the long run than extensive customization
• updates bring opportunities, but require continuous engagement
• integration saves more time in the long term than it costs to implement

Project centricity is not a state that is reached once, but an ongoing organizational design task.

Conclusion: why scaling without project structure does not work

In project‑driven organizations, scaling means more projects, more stakeholders, and more decisions. Without a clear structural unit, this complexity is managed manually – with increasing effort and declining transparency.

Project centricity provides the necessary order. It makes the project the shared reference point for organization, processes, and systems. Only on this basis does scaling become manageable.

Are you facing similar challenges in a project‑driven organisation or looking to establish a more project‑centric way of working? Let’s talk then. We support companies in structuring project‑based work and integrating Dynamics 365 into their organisational and system landscape in a sustainable way.

Frequently Asked Questions (FAQ)