/
Lessons Learned Register

Lessons Learned Register

 


Introduction


Every project, big or small, is a new journey and will give rise to new experiences. Make your journey as smooth as possible by gaining from these historical lessons learned and contribute to this body of knowledge when you have a lesson yourself to share with others!

 


Lessons learned


Category

Added by

Date

Lesson learned

Best practice or issue?

Advice

Follow up

Category

Added by

Date

Lesson learned

Best practice or issue?

Advice

Follow up

Delivery phase

Jochem

7-1-2025

Clients push to include other topics within the scope of the project because it is important to them. This broadens the scope and can slow down the implementation

BEST PRACTICE

Be keen on what the scope is, what the planning is, and push back on topics that will broaden the scope and therefore mess with the planning

Discussed internally

Project approach

Jochem

7-1-2025

During an implementation, there will be third party dependencies which might slow down the project and implementations

ISSUE

At the start of the project map all third party dependencies and involve them early on in the project. This can be an accountant, Ingenico/Worldline, or any TO

Discussed internally

Getting started

Jochem

7-1-2025

The knowledge level of MXTS of the implementation team is low at the start of the implementation causing unnecessary delays

BEST PRACTICE

When the client is very likely to sign the contract and move to MXTS, start including key people in the client’s implementation team in demo sessions of MXTS.

Discussed internally

Project approach

Jochem

7-1-2025

The roles and responsibilities of the people in the client team should be clear to know what is expected from whom.

BEST PRACTICE

In the kick-off meeting assign the project project products to team members (with back-up) and make clear what the responsibilities of the project manager and work stream leads are

List down roles and responsibilities in the project

Project approach

Jochem

7-1-2025

Be strict towards the new clients about deadlines and information provision. This avoids that we will compensate for the lack of time/effort on the client side

BEST PRACTICE

Comminucate clear deadlines on when input is expected from the client upfront and mention the consequences (delay) when it is not on time

Discussed internally

Getting started

Jochem

7-1-2025

The project scope should be entirely clear and set before the project is started. Otherwise the scope can expand easily

ISSUE

Do not start the implementation with involvement of the client before the contract is signed

Discussed internally

Getting started

Jochem

7-1-2025

The client shares a lot of information twice and it is not clear what is in scope and what is not from the start for the implementation team

BEST PRACTICE

Plan a handover meeting between the Sales team and the Implementation team to discuss basic client information and the scope of the contract

Discuss internally

Getting started

Frank

27-5-2024

Setup new concern continuous disrupting. Not only configurations, but also backend settings like authentication tokens and MXTS user log-out time

ISSUE

Improve generic process. Setup & test configurations before introducing client to it.

Discussed internally

Getting started

Frank

27-5-2024

Put testable configuration in place on ACC to introduce new users, rather than starting up from zero.

BEST PRACTICE

Setup testable configuration based on Maxxton advice, so new users can experience the system and validate / confirm suggested configuration.

Add in implementation guide

Data migration

Frank

27-5-2024

Always have scripted data imports validated via script as well on test environments, before importing on Live. (Does imported data matches source data).

ISSUE

Avoid surprises and complex corrections, of which time spend easily exceed effort to create validation scripts.

Add in implementation guide

Project approach

Frank

27-5-2024

Agile mindset enables successful projects; hit deadlines, reduce scope if needed, customer doesn't need everything

BEST PRACTICE

Explore to what extent an agile approach can be used for a project (Agilometer)

Add in implementation guide

Project approach

Frank

27-5-2024

Consider using new features (meaning not elsewhere in live use) by default as 'increased risk'. Only consider these features 'done' when used in Production (in bulk if applicable).

ISSUE

Put new features in Live use as soon as possible. Either via testing on Production or putting a small scope in live use early (pilot).

Add in implementation guide

System

Frank

27-5-2024

Bugs reduce confidence. This leads to quite some (ineffective) time spend to test, reproduce, report, discuss, monitor bugfix, and regaining confidence.

ISSUE

When targeting shorter durations of implementations, a bugfree system is essential. Or if bugs are present these should prioritized for fixing rather then postponing.

Discuss internally

Configuration

Frank

27-5-2024

It is essential to have documentation of implications for configuring resources at parent level or location level, as well as the implications of multiple levels in location hierarcy.

ISSUE

Create documentation with benefits, limitations and implications of configuration options. This improves velocity in decisionmaking for configuration setup.

Create infographic

Project approach

Frank

27-5-2024

High priority and update-rythm for critical path 'products' where uncertainty is.

ISSUE

For any project critical products where uncertainty is present, an ongoing weekly focus should be present to avoid worries and late / overdue delivery.

Add in implementation guide

Project approach

Frank

27-5-2024

Availability of use cases for user training.

ISSUE

There should be a default list of use cases which can be used to quickly create a scope for testing / user training.

Add in implementation guide