When Trust Becomes the Assignment: An S/4 Program Under Pressure

The call reached us on a quiet November morning from a customer with whom we share more than fifteen years of project history. Over the past few years, our contact had become occasional: a few conversations, a few greetings, nothing more. Then came this sentence: “We are in the middle of an S/4 transformation. Our test management is falling apart. The Program Manager will contact you.”

The next day, he did exactly that. The conversation was brief, direct, and without small talk. The Test Manager, an internal employee, had resigned and would be leaving the company in two weeks. The system was still undergoing upgrades, and the first test cycles were scheduled to begin the following week.

His words were simple: “I was told I can buy your services blindly.”

We do not interpret statements like that as compliments. We see them as commitments. Trust is not an advance payment. It is an assignment. It creates responsibility. So we did not wait for contracts. We did not wait for approvals. We got to work. Responsibility first, paperwork second.

For us, being a boutique consultancy is not a business model. It is a mindset. It means taking ownership, making decisions, and acting when situations become critical.

Once we arrived on-site, the seriousness of the situation became evident very quickly. Every project stream maintained its own Excel trackers, often using completely different structures. Reporting consisted largely of weekly status updates delivered verbally. Issue management existed in a separate file located somewhere within the project repository. For an S/4 transformation program at a global automotive supplier, this was more than an inconvenience. It represented a significant delivery risk. An open discussion with the Test Manager of the implementation partner confirmed our initial assessment. Everyone involved was aware of the challenges. The implementation partner had identified and raised the risks early on. However, without customer approval, introducing a new tool was simply not an option.

There was no finger-pointing and no blame. Just the reality of large-scale transformation programs, where critical issues sometimes remain unresolved for too long. As we established transparency and introduced an initial pragmatic reporting structure, one thing became obvious: no new software would solve this situation. No template. No methodology pulled from a drawer. This required people willing to take responsibility while the clock was ticking relentlessly.

The customer had chosen a selective data migration approach, and the system landscape was highly complex: three productive streams, three corresponding quality systems, and one shared development system.

The testing approach consisted of three testing cycles per stream, each containing three phases:

1. Data Validation
2. IT Process Testing
3. Business Process Testing

In total, this resulted in 27 test phases running partially in parallel, supplemented by interfaces, Fiori applications, and add-ons beginning with cycle two.

The existing setup relied heavily on spreadsheets. Structure was inconsistent, transparency was limited, and there was no integrated view of progress, blockers, or risks. Visibility was created in meetings rather than within the testing process itself.

Step 1: Stabilize Without Slowing the Team Down

Within 24 hours, we established a lightweight reporting solution that harmonized the existing spreadsheets just enough to provide a reliable program-level overview. The objective was not perfection. It was visibility. The impact was immediately noticeable. For the first time, the Program Manager could clearly identify where testing activities were progressing, where issues were accumulating, and where risks were emerging. It was not perfect. But it was reliable.

Step 2: Responsibility Before Tool Debates

Introducing a new test management solution was out of the question. Testing activities had already begun, and forcing users to adopt a new platform during execution would only increase disruption. Instead, we leveraged a platform that was already available: Microsoft Teams and SharePoint. With the right structure, these tools are far more powerful than many organizations realize.

Our solution included:

1. A centralized SharePoint-based test case repository with metadata and version control
2. Defects directly linked to their respective test cases
3. Workflow-driven status management (New → In Progress → To Be Re-Tested → Solved)
4. Dashboards providing visibility into coverage, execution progress, defect rates, major blockers, and trends
5. Customized filters, views, and favorites to ensure information could be located within seconds

At the same time, we developed a formal test strategy, created step-by-step guides, and conducted tester onboarding and kickoff sessions. The initial reaction was cautious. That changed quickly. As soon as the first testers experienced how easily they could document tests, record defects, and report progress, skepticism gave way to acceptance, and acceptance evolved into routine.

Collaboration with the Implementation Partner

Our collaboration with the implementation partner remained transparent, professional, and solution-oriented throughout the engagement. Despite the pressure, interactions were constructive and focused on outcomes. Everyone involved shared the same objective: stabilize the program and enable successful testing execution. That is what true project focus looks like.

From Stabilized Test Management to the Next Trust Decision

Once testing activities were running smoothly, the Program Manager approached us with another question: “Could you also take ownership of the cutover?”

Our answer was not an automatic “yes.” Mindset also means understanding your strengths and your limitations. We describe ourselves as “too small to fail.” As a boutique consultancy, trust, reputation, and delivery quality are inseparable. Our project team excelled in structure, communication, coordination, and risk management. The deep technical expertise for individual cutover activities already existed within the customer’s specialist teams and the implementation partner’s organization. Duplicating that expertise would have been inefficient and unnecessary. Our role was different. Our responsibility was to bring all expertise together and orchestrate it into a controlled and executable cutover approach. Our solution was simple: Co-creation. We orchestrate. The expert teams provide the depth.

Cutover: Leadership Under Pressure, Not Technology

Together with all stakeholders, we developed a robust cutover plan through individual interviews, collaborative workshops, mock runs, and full dress rehearsals across all three system streams. The dress rehearsals were intentionally executed during normal business hours. The content mirrored the future productive cutovers, but without the pressure of round-the-clock execution.

The goal was straightforward:

1. Validate procedures
2. Clarify dependencies
3. Surface risks early

The productive cutovers became the ultimate test. Three systems. Three weekends. Three go-lives.

All executed in a 24/7 operating model. Depending on the system stream, execution times ranged from 43 to 57 hours. Every cutover followed the same principles: Calmness. Structure. Leadership.

MS Project: Going Beyond the Standard

We used Microsoft Project extensively and beyond its standard capabilities.

Custom automations and enhancements allowed us to:

1. Control dependencies with precision
2. Calculate and trigger start times automatically
3. Send targeted notifications
4. Generate live status aggregations and management reports

Every stakeholder could instantly understand where their execution window was scheduled and whether timing had shifted. During cutover weekends, we issued status reports every four hours. A 24/7 command-and-control call, supported by dedicated collaboration channels, ensured clear communication and immediate escalation paths. Activities were triggered systematically, feedback flowed directly into live reporting, and stakeholders could immediately identify which tasks were ready to begin and which were approaching execution.

The Result

The outcome was exactly what large transformations need most during critical moments: Calmness. Transparency. Controlled execution. No chaos. No panic. Three cutovers completed successfully, cleanly, and under control.

What Decision-Makers Can Learn

1. Responsibility beats tools. Without leadership, software alone creates little value. Use what you have and make it effective.
2. Transparency comes first. You cannot control what you cannot see. Create visibility before standardization, and standardize before automation.
3. Clarify roles. Leadership, consulting, and operational teams all create value. Success requires everyone understanding their contribution.
4. Cutover is leadership. Plan communication, escalations, and decisions with the same rigor as technical tasks.
5. Being a boutique consultancy is a mindset. Stay close to the customer, stay accountable, and stay clear in your actions.

Why “Blindly Buying” Our Services Is Not Just a Nice Phrase

For us, it is an assignment. A commitment. A signal of trust that must be earned through results rather than managed through presentations. We delivered because we take responsibility seriously. And because we lead programs as if they were our own.

And the customer? They are already preparing their next S/4 transformation and involved us from the very beginning.

Not because of PowerPoint slides. But because of mindset, clarity, structure, and visible results.

If you are currently involved in a program that feels difficult to control, let’s have a conversation. No sales pitch. Just an honest discussion between professionals.