Change is essential for growth. But is every change beneficial, especially in ERP implementation?
We all need change in our lives. Without change, we become stagnant. Different stages of life demand different roles, and different roles require different mindsets.
Moving from a developer to a solution architect, or from an individual contributor to a project manager, requires more than learning new skills. It requires a fundamental shift in mindset.
But here is an interesting contradiction:
In personal development, we encourage change. In software development, particularly ERP implementation, change can be expensive, complicated, and sometimes dangerous.
This brings me to an important concept in project management: The Triple Constraint.
The Triple Constraint: Time, Cost, and Scope
Every project operates within three fundamental constraints:
- Time – How long will the project take?
- Cost – How much will the project cost?
- Scope – What exactly are we delivering?
These three constraints are interconnected.
If we increase the scope, we may need more time, more resources, or a larger budget.
If we reduce the timeline, we may need additional resources or have to reduce the scope.
If we reduce the budget, we may need to compromise on scope or extend the delivery timeline.
And at the center of this triangle lies a fourth critical element: Quality.
A successful project is not simply one that finishes on time and within budget. It must also deliver the expected business value without compromising quality.
Is Agile Really Suitable for ERP Implementation?
Sometimes, I question whether Agile, at least in its pure form, is the right approach for large ERP implementations.
Agile encourages us to welcome changing requirements, even late in development.
But ERP implementation is fundamentally different from developing a new software product.
In traditional ERP projects, we spend considerable time during the discovery and requirement-gathering phases understanding business processes, identifying gaps, and defining the scope.
Once the Business Requirements Document (BRD) is signed off, the expectation is that the agreed requirements form the baseline for implementation.
However, changes continue to emerge.
A business user discovers a new requirement. A department wants an additional approval workflow. Management requests another report. An integration requires more fields or a different process.
Individually, these changes may appear small.
But collectively, they can significantly affect the project timeline, budget, and quality.
The real challenge is not change itself. It is uncontrolled change.
Scope Creep: The Silent Threat to ERP Projects
Many ERP implementations operate under fixed-price contracts.
The implementation partner commits to delivering a defined scope within an agreed budget and timeline.
Now imagine that requirements keep changing after the scope has been finalized.
The project team must perform additional analysis, redesign existing solutions, modify configurations or customizations, retest integrations, and repeat user acceptance testing.
Yet the original deadline and budget often remain unchanged.
This creates pressure on the delivery team and increases the risk of compromising quality.
ERP implementations are also relatively slow to change because of their interconnected nature.
A small change in procurement may affect inventory, finance, workflow, reporting, and external integrations.
What looks like a minor requirement can become a significant technical and functional challenge.
That is why scope management is not merely an administrative activity. It is a critical responsibility of project leadership.
ERP Is Already a Product, Not a Blank Canvas
Another important distinction is that ERP systems are already developed products.
When implementing Microsoft Dynamics 365 Finance & Operations, SAP, or another enterprise system, we are not building everything from scratch.
The software already contains established business processes, data structures, accounting principles, and transaction flows.
Our responsibility is to understand the business requirements and align them with the capabilities of the ERP system.
Of course, customization and integration are sometimes necessary.
But there is a difference between extending an ERP system and fundamentally changing how it works.
Excessive customization introduces technical debt, increases maintenance costs, complicates upgrades, and creates long-term dependencies.
Sometimes, the better solution is not to change the software.
It is to change the business process to align with ERP best practices.
This is another form of mindset shift.
Instead of asking, “How can we customize the ERP to match every existing business process?”
We should ask, “How can we achieve the business objective using the standard ERP capabilities?”
Agile vs. Scope Control: Finding the Balance
Does this mean Agile has no place in ERP implementation?
Not necessarily.
Agile practices such as iterative delivery, frequent demonstrations, continuous feedback, and early testing can significantly improve implementation quality.
However, Agile should not become an excuse for unlimited scope changes.
We need to distinguish between:
- Refinement: Improving our understanding of an already agreed requirement.
- Defect correction: Fixing functionality that does not meet the agreed requirements.
- Scope change: Introducing new functionality or changing an approved business process.
These are not the same thing, and they should not be managed in the same way.
A practical approach may be to establish a clear scope baseline while allowing flexibility in how the solution is designed, developed, tested, and delivered.
Significant changes should go through impact assessment and formal change control, with transparent decisions about their effect on time, cost, and quality.
In other words:
Be Agile in execution, but disciplined in scope management.
Quality: The Center of the Triangle
Returning to the Triple Constraint, we have three competing dimensions: time, cost, and scope.
But the fourth dimension, quality, is what ultimately determines whether the project delivers a sustainable result.
A project delivered on time but with unstable integrations is not successful.
A project delivered within budget but with incomplete business processes is not successful.
And a project that delivers every requested customization but becomes difficult to maintain may not be successful either.
Project leadership is about balancing these constraints while protecting the quality of the final solution.
Final Reflection: Change Needs Direction
This brings me back to where I started.
In life, we need change to grow.
In projects, we need change to improve.
But not every change creates value.
Personal growth requires the courage to change. Project delivery requires the wisdom to control change.
A good solution architect understands the technical and business impact of change.
A good project manager understands its impact on time, cost, resources, and commitments.
And a good delivery leader knows when to accept change, when to defer it, and when to say no.
Perhaps that is the real mindset shift required to move from being a developer to becoming a solution architect and project leader.
Success is not about delivering every change. It is about delivering the right outcome, with the right quality, within realistic constraints.