This article is the second part of “How to jeopardize one’s Source to Pay project?” where we present the opposite of the “best practices” to illustrate what one should not do or assume when approaching a Source-to-Pay digital transformation project. These anti-tips are the fruit of 17 years of experience of implementing Source-to-Pay solutions.

Anti-Tip # 5: Remember to change your purchase organization during the project
Before you start the project, you simply do not need to think about the revisions on the purchasing department organization, the relevance of the supplier evaluation criteria, the data governance or the choice of KPIs.
One can easily change the organization during the project without any impact on the implementation cost or schedule. The internal teams will certainly be a bit stressed since they now have to manage two projects at the same time, but this will have no impact on the satisfaction or the end-user acceptance of software solution…. (unless it does…)

Anti-Tip # 6: Do not worry about the availability of the project team
Validating the availability of teams before establishing the deployment schedule is not essential. It is also useless to include project-specific tracks in the workload by planning to move or delegate tasks that one can’t manage. The same goes for the IT department. Source to Pay projects are initiated and led by business departments. One will call the IT department when the time comes, especially for the development of the interfaces. Since IT has no other projects underway, it can respond immediately to this request, right?

Anti-Tip # 7: Deploy everything at the same time. Employees love the big bang!
In the vast majority of cases, it is not recommended to break the project into manageable pieces and to start with a simple and well-defined scope, such as the purchase requisition, the SRM module or the management of tenders. Changing everything overnight, adapting to new software, and managing the ongoing daily tasks at the same time is not a problem for you or your users. On the contrary, they embrace the change especially when it is radical and unannounced. Support during deployment (hotline, training, e-learning …) is totally superfluous.

Anti-Tip # 8: Worries are over after the solution is in place
On the day of ’Go-Live’, one can consider the project finished! It is rare to make adjustments or changes after deployment. As one has not prepared the project scope in advance and deployed everything at once without supporting the users, one has to lay aside all expectations of an optimal ROI anyway. Creating a community of users, promoting knowledge exchanges with the key users or setting up data governance are, therefore “worst practices”. Joining in a process of continuous improvement requires too much time and investment for teams who surely have better things to do. There will surely be a time to consider changes in a year or two … (and re-start the whole project with a new approach)