One of the main key success factors of a S2P implementation project is the quality of deliverables. But before talking about good document quality, you first need to get these documents either from your team or from your software provider.
One of the main key success factors of a S2P implementation project is the quality of deliverables. But before talking about good document quality, you first need to get these documents either from your team or from your software provider.
What key deliverables you will need to efficiently and correctly lead your S2P implementation project?
1. Deliverables types
Your S2P implementation project will follow a specific planning and will go through different phases: design, build, tests, go-live preparation, go-live support… (see #4 Fix and respect your project planning). For each phase, you need to identify the relevant deliverables to get in order to move toward the next step. To do so, you must understand the goals and stakes behind each project phase. For instance, after design sessions, you want your organization to agree on a designed solution. A Blueprint Document will help you to make everybody agree on what the solution will be able to do after go-live by listing all the business & technical requirements and the related solutions, as well as the interface details, reporting needs, specific configuration, etc.
Whilst selecting your software provider and/or your integrator, make sure you all agree on the same RAM (Responsibility Assignment Matrix) or RACI (Responsible, Accountable, Consulted, Informed) detailing who will do what during project
We can mostly split deliverables in two different types: project-oriented deliverables VS solution-oriented deliverables.
The first ones (project-oriented deliverables) are documents that will state the project goals, the requirements, the project advancement, etc. For instance, you will be likely to set a weekly follow-up meeting to discuss project advancement and project issues with the project stakeholders. The project manager will probably use a one-pager to track the actions that has been performed, the one that will be performed, the expected project decisions and the project alerts. This deliverable will be considered as project-oriented since it deals with project management.
The second type of deliverables (solution-oriented) are documents that will be used to configure your solution. For instance, you will need to create a user management matrix to manage profiles & authorizations including items visibility. Even more important, the Functional Design Document will gather all the configuration details (tables used, items codes, UI design, etc.), and the Functional Technical Specifications deals with interface management. Performing a system playback session before unit testing & UAT will help you to assess configuration completion as per business requirements and identify anomalies/gaps to be fixed.
See the release written by Pauline Moreau, Axbility Senior Consultant bellow !
You will also like :
- 12 recommendations to implement a source-to-pay solution | #1 Assess your maturity
- 12 recommendations to implement a source-to-pay solution | #2 Plan a global implementation strategy
- 12 recommendations to implement a source-to-pay solution | #3 Choose the right vendor
- 12 recommendations to implement a source-to-pay solution | #4 Fix and respect your project planning
- 12 recommendations to implement a source-to-pay solution | #5 Remember your project goals and set up KPIs
click for direct access
