The Testing Preparation Gap: Why Your Team Needs 12 Weeks, Not 12 Days

"Testing starts in November." The program director's announcement lands heavily in the conference room. It's currently August. Your SimCorp implementation has been in the build phase for eight months. Configuration workshops are ongoing. Data mapping exercises are still being finalized. And now, in three months, your operations team is expected to test a platform they've barely touched.

Around the table, faces show varying degrees of concern. The head of middle office tries to calculate when she can pull people off daily reconciliations to learn the system. The IT director wonders how to best prepare the team. The CFO asks the question everyone's thinking: "Are we ready for this?"

The honest answer requires careful assessment. And this scenario plays out at investment management firms around the world every year.

The Universal Timeline Pattern

Most implementation timelines follow a familiar sequence:

• Months 1-4: Requirements gathering, vendor selection, contract negotiations

• Months 5-12: Build and configuration phase (implementation partners leading development, internal team providing input)

• Months 13-16: Testing phase (internal team validating comprehensive workflows)

• Months 17-20: Parallel run and go-live preparation

The challenge? During those critical 8-12 months of build and configuration, internal operational teams – the people who will use the system daily – often have limited hands-on time with the evolving platform. They attend demos, answer questions when asked, and provide sample data. But active system experience is typically minimal.

Then testing arrives and teams discover that watching configuration happen is quite different from executing complex workflows yourself.

Why Training Works Best With Hands-On Experience

Most implementations include formal training programs covering system navigation, standard workflows, and core platform functionality. This foundation is essential; it gives teams the conceptual framework needed to understand the platform's extensive capabilities.

However, across the implementations we've supported globally, we've consistently observed that training achieves the strongest outcomes when teams can immediately apply what they've learned to their actual implementation environment.

Think of it this way: Training teaches you the language of the platform. The build phase is where your team learns to speak it fluently using your organization's specific vocabulary, your instruments, your custody relationships, your workflows, and your data.

The timing challenge:

Most implementation timelines position formal training 2-3 weeks before testing begins. By that point, configuration decisions have already been made. Teams learn the platform in a training environment, then encounter their specific implementation for the first time during UAT.

The optimal approach:

Teams achieve substantially higher capability levels when they combine formal training with concurrent hands-on involvement during the build phase. This creates a powerful learning cycle where training concepts can be immediately practiced and validated against your actual implementation.

The Three Capability Dimensions That Develop Over Time

Dimension 1: Platform Knowledge

Teams need to understand both what the system does and how it's been configured to do it in your environment. When a test doesn't produce expected results, they need to distinguish between:

• A platform behavior that differs from legacy system expectations

• A configuration choice that should be revisited

• Incorrect or incomplete test data

• A test script assumption that needs adjustment

This diagnostic capability develops through experience, not just training. Teams who have been hands-on during build can often resolve issues in minutes that would otherwise require escalation and investigation.

Dimension 2: Configuration Context

Understanding the platform mechanically isn't enough. Teams also need operational context:

• Why configuration option A was chosen over option B

• What trade-offs were considered during design decisions

• Which workflows intentionally differ from the legacy approach (and why)

• What the expected behavior should be in your specific setup

One European pension fund we worked with spent three weeks of testing time discussing reconciliation tolerances. Not because the configuration was wrong, but because the testing team hadn't been involved when those thresholds were established. That context could have been absorbed naturally during configuration workshops.

Dimension 3: Validation Confidence

Perhaps most critically, teams who haven't been involved during configuration often lack confidence to question decisions that don't align with their operational experience.

Implementation partners bring platform expertise developed across numerous deployments. Your team brings deep knowledge of your specific operational requirements, risk tolerance, and business objectives. The strongest implementations achieve collaboration between these two expertise domains, each informing and validating the other.

A team that's been hands-on during configuration can say, "This approach doesn't match our custody workflow. Let's discuss alternatives." A team encountering the configuration for the first time during testing may hesitate to raise such concerns, assuming the design is correct simply because experienced consultants configured it.

The 12-Week Capability Development Window

Based on our experience supporting organizations globally, meaningful system capability develops over approximately 12 weeks of hands-on involvement. This isn't classroom time, it's active participation in the implementation process itself.

This means involvement in:

• Configuration workshops (observing decisions, asking questions, understanding trade-offs)

• Sandbox exploration (experimenting with workflows using realistic scenarios)

• Data mapping validation (ensuring your actual data behaves as expected)

• Configuration review sessions (validating setup decisions against operational requirements)

• Knowledge documentation (capturing the "why" behind configurations)

This development cannot be compressed into the two weeks before testing starts. It needs to occur during the build phase itself, which is why organizations that achieve the strongest testing outcomes begin capability development 3-4 months before UAT begins.

At one sovereign wealth fund we supported, we embedded with the operations team four months before testing. By the time UAT started, they had logged 200+ hours of hands-on system time. Testing completion was 40% faster than projected, with 85% of issues resolved within the testing team without requiring escalation.

Dimensional Community's Independent Expertise

Dimensional Community is an independent consultancy specializing in SimCorp implementations, with deep technical knowledge gained from supporting implementations across pension funds, asset managers, and sovereign wealth funds globally.

Our independence allows us to:

• Provide unbiased validation of configuration decisions from a purely client-centric perspective

• Embed dedicated, non-rotating consultants directly with your operations team

• Tailor capability development specifically to your data, workflows, and operating model

• Focus explicitly on building your internal capability to reduce long-term dependency on external support

  
  

We work collaboratively with your implementation partners, whether that's SimCorp, a system integrator, or other consultancies, to ensure your internal team develops the expertise needed for testing success and long-term operational excellence.

Our goal: Your team becomes genuinely self-sufficient, capable of making configuration decisions, troubleshooting issues, and fully leveraging the platform's capabilities without perpetual external dependency.

The Super User Development Model That Works

We use a 70-20-10 learning model adapted specifically for investment management system implementations:

70% - Experiential Learning

Hands-on involvement with the actual system using your real data and scenarios. This happens during configuration development, not after. Users participate in workshops, experiment in sandbox environments, and work through actual business processes alongside experienced consultants.

20% - Social Learning

Learning from experienced SimCorp professionals through mentoring, shadowing, and collaborative problem-solving. Our consultants work to not just configure systems, but to explain rationale, demonstrate alternatives, and build internal expertise as work progresses.

10% - Formal Training

Structured training programs and targeted workshops on specific modules. This formal training is most effective when it reinforces hands-on experience rather than trying to replace it.

Three Questions to Ask Right Now

• When does your testing phase begin? (If it's less than 4 months away, capability development should begin immediately)

• How many hours of hands-on system time does your testing team currently have? (If it's less than 50 hours per person, additional experience is needed)

• Can your team explain why specific configurations were chosen? (If they can't, they need more context to test effectively and validate setup decisions)

If any of these answers concern you, the solution is building capability now, during the window when your team can still participate in configuration decisions and develop expertise organically.

ASSESS YOUR READINESS

Is your testing phase starting within the next 6 months? Use our Team Readiness Assessment to evaluate whether your operations team has the knowledge, confidence, and capability to test effectively.

The assessment evaluates:

• Current team capability levels across key platform modules

• Knowledge gaps that could impact testing effectiveness

• Timeline analysis: Do you have enough runway to close capability gaps?

• Specific recommendations for accelerated capability development

→ Get in touch with our team to request your Team Readiness Assessment: