Why do SAP projects lose control? 7 mistakes from a Project Manager’s perspective

Every new IT project usually starts on a positive note. At the beginning, there are ambitious goals, a schedule, a budget, a team of experts, and the belief that since the methodology has been successfully applied in dozens of other projects, everything will go according to plan this time as well.

And then the first difficulties and complications appear.

One requirement turns out to be more complex than expected. A key expert becomes unavailable. An integration with another system does not work as expected. Users start submitting additional requirements. Testing begins to slip, while business decisions remain outstanding. At some point, the Project Manager stops managing the project according to plan and starts reacting primarily to problems. Based on experience from SAP projects, there are many reasons why this happens. Below are seven of the most common ones that can lead to a loss of control over a project.

1. Lack of a clearly defined project scope

One of the most common sources of problems in SAP projects is the lack of a precisely defined project scope from the very beginning. This is particularly important for SAP projects because the system encompasses many interconnected processes, modules, interfaces, and data. What appears to be a relatively small change in one area can have consequences for other parts of the solution.

The problem often starts with a very general objective, such as:

• implementing a new invoicing process,
• optimizing FI,
• or migrating to S/4HANA.

However, such a definition does not answer several critical questions:

• What exactly will be changed?
• What is outside the scope of the project?
• Which processes are included in the analysis?
• Which systems and interfaces need to be modified?
• What will the final deliverable look like?
• What are the key measures of project success?

A lack of a clearly defined scope primarily leads to what is commonly referred to as scope creep – the gradual expansion of the project scope without adequate control over time, budget, and resources.

What should a well-defined scope include?

A good SAP project scope should clearly define:

1. What we are doing (for example: changing the payment process for two company codes, configuring a new payment format, modifying specific interfaces, or migrating a defined scope of data).
2. 2. What we are not doing (for example: the project does not include changes to the payment process for the remaining company codes, rebuilding existing interfaces, or changes to AP processes unrelated to the new payment format). This is often the most overlooked element at the beginning of a project. A detailed clarification of this area can save a significant amount of discussion later.
3. Which systems are included in the project (for example: SAP S/4HANA, a banking system, middleware, a reporting system, or an external system).
4. Which processes are included in the project (this should include a detailed description of the relevant business processes).
5. What the project deliverables are (for example: configuration, development, documentation, testing, migration, training, and user instructions).
6. What the project success measures are (for example: SAP transactions, interfaces, and background jobs meet agreed performance targets, or expected business benefits are achieved, e.g., reduced manual work, shorter processing time, fewer errors, or improved reporting).
7. How scope changes will be managed.

The appearance of new requirements is not itself a problem. In a large SAP project, it is almost inevitable. The mistake is accepting them without formally assessing their impact on the project. Every new requirement should be assessed for its impact on scope, schedule, and budget.

Summary

To sum up, defining a detailed SAP project scope is critical at the outset and should not be treated as a mere formality. It is, in fact, the creation of a project management tool that remains relevant throughout the entire project lifecycle.

The more complex the SAP environment, the more important it is to define the project’s boundaries. The objective is not to predict every individual change. The objective is to establish clear reference points that enable conscious classification of every new request as “in scope,” “out of scope,” or “a change requiring a formal decision.” Otherwise, a project may formally continue according to the original plan while, in reality, it is delivering a completely different project from the one for which the budget and timeline were approved.

2. Overly optimistic planning

One of the most common problems in SAP projects is overly optimistic planning of time, budget, and resources.

When it comes to time, one of the most dangerous statements in a SAP project is something like: “This should take about two weeks.”

The problem is not that two weeks are necessarily unrealistic. The problem arises when the estimate does not account for actual dependencies. Even if development or configuration can be completed within the expected number of days, the estimate must also include time for preparing data, integrations, testing, corrections, business approvals, dependencies on other people’s tasks, and the availability of key resources.

As a result, a task that technically appears to be a two-week task can affect the schedule for several weeks. SAP projects are rarely executed in isolation. A change to one element can affect many other areas. It is often the dependencies, rather than the tasks themselves, that determine the project completion date.

Additionally, overly optimistic schedules usually assume that:

• requirements are complete,
• the business will make decisions quickly,
• test data will be available,
• configuration will work the first time correctly,
• development will not require corrections,
• interfaces will work from the first test,
• users will accept the solution,
• there will be no transport-related issues,
• key experts will be available,
• other projects will not compete for resources.

Each of these assumptions may be reasonable individually. The problem is that the probability of all of them being true simultaneously is significantly lower.

This is why a schedule built exclusively around the “happy path” can look very good until execution begins. “If everything goes well” is not a plan. Project Manager must be able to distinguish between the planned execution time for a task and the actual time required to complete the entire process, including all dependencies.

Optimistic resource planning

Another problem is overly optimistic resource planning. For example, even if the schedule assumes that a dedicated person assigned to the project is 100% available for two weeks, in reality, that same person may also have production incidents, other projects, maintenance activities, meetings, user support, and urgent fixes.

Therefore, resource availability within an organization does not necessarily mean resource availability for the project.

This is one of the reasons a schedule may look realistic from a Project Manager’s perspective, but be impossible for the team to execute.

Optimistic planning of the testing phase

Finally, it is important to note that overly optimistic planning for the testing phase is often a major problem in SAP projects. The testing phase is frequently one of the most underestimated parts of the project.

A typical plan might, for example, assume five days for integration testing and two weeks for business acceptance testing.

However, the project planning phase often fails to answer several detailed questions:

• Is the test data ready?
• Are all systems available?
• Are the interfaces working?
• Do users have the appropriate authorizations?
• Who will perform the testing?
• How many scenarios need to be tested?
• What happens when a defect is identified?
• How much time is required to fix it?
• Does the fix require a complete retest?

In practice, testing is not a single task. It is a cycle:

test → defect → analysis → fix → transport → retest → another defect → fix → retest If the schedule does not allow sufficient time for this cycle, the first testing problems will immediately affect the project completion date.

3. Decisions made too late

One of the problems that very often slows down SAP projects is not a lack of team competence or technical issues, but the failure to make decisions at the right time.

In SAP project, questions requiring business or project decisions arise almost every day. The problem occurs when a question reaches the decision-maker, but the answer comes only when the team can no longer continue working without it.

“We’ll decide later” is often an expensive decision.

In SAP projects, there is often an assumption that a decision does not need to be made immediately: “We will come back to this later.” The problem is that the cost of a decision can increase as the project progresses.

Another very dangerous situation is unclear ownership. It is often not clear: Who is actually responsible for making the decision? The analyst believes the business should decide. The business believes IT should decide. IT believes the decision is the Process Owner’s. The Process Owner believes that input from the Steering Committee is required. As a result, the question starts circulating among different people, and the classic situation emerges: Everyone is involved, but nobody owns the decision.

For key decisions, it is therefore worth clearly defining:

• Decision Owner – who makes the decision,
• Decision Date – by when the decision must be made,
• Input – who provides the required information,
• Impact – what will be blocked if the decision is not made.

Other traps

Another recurring trap in SAP projects is the assumption that questions – and the decisions that follow – should be collected and discussed only during weekly status meetings. If a decision blocks a developer from Monday and the team meeting takes place on Friday, the team may lose an entire week.

Another common phenomenon in SAP projects is avoiding making a decision by saying, “We still need more information.” This is one of the most common reasons for delaying decisions. Of course, some decisions genuinely require additional analysis. However, this process is often unnecessarily prolonged, and the analysis becomes a way of avoiding the decision itself.

At some point, the project needs to move from “We need more information” to “We have enough information to make a decision with an acceptable level of risk.”

A project cannot wait for the moment when all the information is known, because that moment may never come.

Summary

Taking all the above into account, decisions should have their own management mechanism, such as a Decision Log, containing not only a list of open topics but also:

• what the decision concerns,
• what options are available,
• who owns the decision,
• by when it must be made,
• what the impact of not making the decision will be,
• when the issue was escalated.

Project Manager does not have to make every decision. However, he/she must ensure that decisions are made on time by the right people.

4. Insufficient business engagement

One of the most underestimated problems in SAP projects is insufficient business engagement. SAP project is not solely an IT project. The system is primarily intended to support business processes. Therefore, without the active involvement of people who understand those processes, the project team may create a technically correct solution that does not meet the organization’s actual needs.

One of the most common mistakes is treating the business team as the recipient of the solution rather than as part of the project team. SAP project cannot be implemented by IT alone.

One of the fundamental mistakes is treating SAP project as:

IT builds → business checks at the end.

In reality, the model should look more like:Business defines the need → we design the solution together → IT implements → business tests → we jointly decide whether to go live.

Business’s role

SAP consultant may know the system very well, but that does not necessarily mean they understand the specifics of a particular organization. This is why business engagement from the very beginning of the project is so important. The business should actively participate in planning and requirements gathering, including workshops, requirements definition, and key decision-making.

However, business engagement should not end after planning and resume only during testing. Obviously, end users have their daily operational responsibilities. Nevertheless, during the implementation phase, when the solution is being built, business decisions are often required because new questions arise.

Very often, the business is not treated as a permanent part of the project team. It is not invited to project meetings because there is “no time” or because “there is no need.” Key decisions are then made without the business, based on assumptions or best practices. And then, when business testing begins, it turns out the solution does not meet the expectations of those who will use it.

Insufficient business engagement often results from the desire to reduce the burden on the business. The logic is: “Let’s not involve the users too much because they already have a lot of operational work.” However, later the business must spend significantly more time on: explaining problems, additional workshops, corrections, retesting, training, and resolving issues after Go-Live. Saving business time at the beginning of the project can therefore create a much greater workload at the end.

During the testing phase, it is extremely important to allocate enough time to business-related project activities. Testing is much more than simply checking whether the solution works. The business needs sufficient time to properly prepare scenarios and all required test data. This preparation phase is often not taken seriously enough, even though it forms the foundation for project success.

Business’s tasks

Business should:

• prepare test data,
• execute tests,
• confirm scenarios,
• make decisions,
• approve the solution,
• actively participate in preparing the organization for Go-Live.

All of this requires adequate business resources.

One of the Project Manager’s responsibilities should also be to protect Key Users’ time. If an organization expects a Key User to handle: “Normal work + 30% SAP project” without changing any of their other responsibilities, the project may effectively receive only the 30% of time that remains after all urgent operational tasks have been completed. That may not be enough for the project.

Therefore, it is very important to establish from the beginning:

• how much time the business will allocate to the project,
• which operational activities can be delegated to others,
• who will replace the Key User during their absence,
• which project activities are mandatory.

Business engagement must be organizationally secured, not simply expected.

Summary

To summarize, in SAP project the business should not be treated as the recipient of a finished solution, but as a co-creator of the solution. It should therefore be involved at every stage of the project. Project Manager can coordinate the project, the consultant can design the solution, and the developer can build it. However, none of them can replace the business owner of the process.

Therefore, one of the key conditions for the success of an SAP project is not simply having “the business involved in the project,” but ensuring that the business has the time, expertise, and authority to make decisions and approve project deliverables.

5. Treating testing as one of the final stages of the project

One common mistake in SAP projects is treating testing as the final phase, starting only after configuration and development are complete.

The approach often looks like this:

Analysis → Design → Configuration/Development → Testing → Go-Live

At first glance, this seems logical. The problem is that in SAP project, testing should not simply be a stage that follows implementation. Testing should accompany the project from the very beginning.

If testing starts too late, the project may spend months building a solution whose business correctness is verified only near the end.

“Let’s build it first and test it later.” This is one of the riskiest assumptions.The team completes configuration and development, then hands the solution to the testers.

That is when questions arise:

• Does the process actually meet the requirements?
• Have all scenarios been included?
• Do the integrations work?
• Is the data correct?
• Can users execute the process end-to-end?
• Have business exceptions been handled?
• Do the reports display the correct data?

If the answer to any of these questions is “no,” the project discovers the problem very late.

And the later a defect is discovered, the greater the potential cost of fixing it.

Testing is therefore not only a quality-control mechanism. It is also an early-warning mechanism for identifying incorrect assumptions.

A particularly dangerous situation arises when business users first see the target solution during UAT. It may then turn out that: “This is not the process we need.”

This does not necessarily mean that there is a technical defect.

It may mean that the project did not previously validate the following sufficiently:

• requirements,
• the TO-BE process,
• exceptions,
• user expectations.

UAT should not be the moment when the business redesigns the solution from scratch. It should primarily confirm that the solution meets the requirements agreed upon earlier. Where possible, projects should introduce mechanisms that allow the business to validate the solution, or parts of it, during development.

Testing pressure

Another serious problem is when final UAT testing starts too late while the Go-Live date remains unchanged. This is a very common scenario. The project has an agreed Go-Live date. Development is delayed. The original plan allocated six weeks for testing. After the development delay, only three weeks remain. However, the Go-Live date remains unchanged. The business is then put under pressure to complete testing as quickly as possible.

In practice, this means:

development delay → shorter testing period → fewer scenarios → less time for fixes → greater risk before Go-Live.

Projects often try to “recover” the delay precisely at the expense of testing. This is particularly dangerous because testing then becomes a schedule buffer, rather than an essential element of solution quality.

In addition to the above, if testing starts late, a large number of defects may appear simultaneously.

For example:

50 defects → 10 developers → 2 weeks before Go-Live.

The team then starts working in the following mode:

defect → fix → transport → test → another defect → fix → transport → test.

At some point, it becomes increasingly difficult to determine which version of the solution has actually been tested. Transport and testing chaos can emerge.

Project Manager should also be cautious about the following situation: “We don’t have enough time for further testing, so we have to go live.”

This is a very important warning signal. A lack of time does not mean the solution is ready. If testing has been shortened because of earlier delays, the project should consciously assess what has been tested, what has not been tested, and what risk we are accepting. Only on the basis of all these facts can a decision be made on whether Go-Live should take place.

Summary

To summarize, from a Project Manager’s perspective, an important change is to move away from “First we will build the solution, and then we will check whether it works” towards “From the beginning of the project, we know how we will prove that the solution works.”

Testing should therefore be considered already during requirements definition. If the business requires a particular outcome, it should be clear how that outcome will be verified later.

In a well-managed SAP project, testing is not the final obstacle before Go-Live. It is a quality-control mechanism throughout the entire project. And one principle is particularly important: The later we discover a problem, the less time we have and the fewer options we have to fix it, and the greater the pressure on the project. Therefore, testing should not be postponed until the end of the project – we should ensure that problems can be identified as early as possible.

6. Lack of change control

One of the problems that can most destabilize an SAP project is a lack of change control. In practice, almost every project receives new requirements, business changes, additional scenarios, or modifications to previously agreed decisions during execution. The appearance of changes is therefore not itself a problem.

The problem starts when changes are introduced without assessing their impact on scope, budget, schedule, resources, and project risk. At that point, the project gradually starts to look different from the project for which the budget and timeline were originally approved.

Project Managers very often hear: “It’s just a small change.” In SAP projects, many problems begin with exactly this statement. One small change. Then another. An additional report. A new field. An additional interface. A process change. Another exception. Each individual change may appear small, but together they can significantly change the project.

This is why a Change Request should not be perceived as a bureaucratic process. It is a project control mechanism.

Every change may be reasonable. Therefore, Project Manager should not automatically treat every change as something negative.

Instead, he/she should ask:

• What is the impact of this change?
• How much additional work is required?
• Which tasks will be delayed?
• Do we need additional resources?
• Does the project scope change?
• Does the budget change?
• Does the Go-Live date change?
• What new risks are created?
• Who approves the change?

Only then can an informed decision be made.

If a project accepts new requirements without updating the schedule, budget, and scope, the Project Manager eventually becomes responsible for a project that was never originally planned. Change management is therefore a critical element of project delivery and success.

Consequences

It is also very important that the project team and the people making the final decision to add a change to the project scope fully understand that even if a scope change does not require additional budget, it will almost always have other consequences.

The key principle is that if we increase the scope without increasing the budget, we must change something else.

Possible options include:

• Scope ↑ + Budget ↑ – The project is expanded and receives additional funding.
• Scope ↑ + Timeline ↑ – New functionality is added, but Go-Live is postponed.
• Scope ↑ + Resources ↑ – Additional resources are added to maintain the original timeline.
• Scope ↑ + Priorities ↓ – A new functionality is added, but another one is removed or postponed.

The problem starts when the organization expects:

Scope ↑ + unchanged timeline + unchanged budget + unchanged resources. This is mathematically very difficult to sustain.

Summary

To summarize, change control does not mean blocking the business or the project. It means ensuring that every significant change is a conscious decision, rather than an accidental expansion of the project.

Project Manager should create an environment in which it is possible to say: “Yes, we can do this.” But immediately follow it with: “Let’s check what impact it will have on scope, schedule, budget, and risk.”

This changes the question from: “Can we add one more feature?” to: “Are we prepared to accept the consequences of adding this feature?”

Changes are inevitable in SAP projects. A lack of control over changes is not. And the most important principle is: We do not manage how many changes appear in a project. We manage which changes we accept, when we implement them, and their impact on the project.

7. Project Manager finds out about problems too late

A project does not lose control on the day a problem appears. It loses control when the problem remains invisible or is ignored for too long.

If a task is delayed by one day, it is usually still relatively easy to react. If, after three weeks, we are still hearing: “We are almost ready,” the situation is completely different.

This is why Project Manager needs not only a “green/yellow/red” status, but, above all, reliable information.

It is worth regularly monitoring:

• key milestones,
• tasks on the critical path,
• open decisions,
• dependencies,
• risks,
• Change Requests,
• defects,
• availability of key resources,
• business readiness for testing and Go-Live.

The worst project status is not red. The worst status is falsely green. A red project can still be recovered. A project that everyone believes is green for a long time, even though in reality it is already red, can be much more difficult to recover from.

SAP project management is not about predicting every possible problem. That is impossible.

The role of the Project Manager is to create a way of working in which problems are:

visible early enough → assigned to an owner → resolved or escalated.

Therefore, a good Project Manager should regularly ask several simple questions and receive reliable and honest answers:

1. What could put the deadline at risk?
2. Which decisions are still open?
3. Which tasks are delayed and why?
4. Is the project scope still the same as it was at the beginning?
5. Do we have the right business and technical resources?
6. Does testing really confirm that the solution is ready?
7. What should I know today that I might otherwise find out about a month from now?

This last question is particularly important.

Sii x SAP

As an SAP Silver Partner, we have many years of experience in implementing ERP solutions in companies of various scales and process complexities.

SAP offering

Summary

SAP projects do not lose control due to a single major mistake. Most often, it is the result of a combination of smaller problems:

unclear scope + optimistic planning + delayed decisions + limited business engagement + late testing + uncontrolled changes + problems being reported too late.

Each of these elements may appear manageable on its own. The problem begins when they occur simultaneously. Therefore, an effective Project Manager does not focus solely on whether the project is following the plan. They should primarily observe whether the project still has the conditions required to execute that plan. Because problems in SAP projects rarely appear suddenly. Most of the time, they provide warning signals for extended periods. We just need to notice them early enough.

Bibliography and sources

1. SAP – SAP Activate Methodology
2. SAP Learning – Describing the SAP Activate Methodology Structure
3. SAP Help Portal – Getting Started with SAP Activate
4. Project Management Institute (PMI) – What is Project Management?
5. Project Management Institute – Scope and Stakeholder Management: Pain Points, Perils, and Prosperity
6. Project Management Institute – The Standard for Risk Management in Portfolios, Programs, and Projects
7. Project Management Institute – Managing Stakeholders to Achieve True Implementation Success
8. Project Management Institute – Scope Change Control