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 |
---|---|---|---|---|---|---|
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 |