What to Expect in the First Few Months After Adopting a New Platform
In the first few months after adopting a new corporate platform, it becomes clear whether the investment generates value or remains a hidden cost
70% of organizational transformation projects fail to meet their objectives, and the main cause is almost never the technology chosen. This is documented by a McKinsey study that is now routinely cited in management literature, which attributes failure primarily to employee resistance and a lack of management support in the post-implementation phase. This finding should give pause to anyone who is considering or has just begun adopting a new management platform: the most tangible risk does not lie in the selection of the vendor or the technical setup phase, but in the months that follow, when the software is already up and running and the organization must learn to operate within it.
This article is intended for those who have made that decision or are about to make it, and it attempts to answer a question that is rarely addressed in sales presentations: what really happens within the company during the first three to six months after adopting a new platform.
The Gap Between Those Who Adopt and Those Who Adopt Well
In Italy, the issue is no longer access to technology. According to Eurostat data on the Digital Decade, by 2025, 78% of Italian companies will already be using at least one of the following: artificial intelligence, advanced or intermediate cloud services, or data analytics tools—a result that places the country above the European average and among the continent’s leaders, alongside Denmark and Sweden, in terms of cloud adoption.
However, ISTAT data reveal a second, less-discussed truth: the use of management software applies to about 90% of large companies but only 52.7% of those with 10–49 employees. The gap does not lie in access to the platform—which is now within reach of almost anyone—but in the organizational capacity to effectively implement it once it is installed. This is precisely where the battle is fought in the first few months after go-live.
The J-Curve: The Drop in Productivity That No One Mentions During the Sales Process
Anyone who has been througha software implementation knows that efficiency doesn’t improve from day one. In most cases, it actually worsens—temporarily—before surpassing the starting level: this is the phenomenon that organizational analysts call the J-curve, because the productivity graph drops before rising again and stabilizing at a higher level. During this phase, processes that previously required one click now require three, managers must manually validate outputs that the algorithm is supposed to generate automatically, and the most experienced teams—those who had optimized the old system over years of work—find themselves temporarily less productive than their junior colleagues, simply because they have more habits to unlearn.
The problem isn’t the learning curve itself, which is a natural part of any system change. The problem arises when management hasn’t anticipated it: if the board expects an increase in efficiency thirty days after go-live and instead observes a slowdown, the temptation to consider the project a failure—or worse, to partially revert to the old system in parallel—becomes very real. And any return to the old process—even a partial one—lengthens the curve rather than shortening it.
What Really Happens Inside the Organization
During the first few months, three dynamics coexist that are rarely explicitly mentioned in project plans, but which determine the outcome of the adoption more than any technical parameter.
The first is silent resistance, which is distinct from open opposition. An employee who continues to maintain a parallel Excel spreadsheet alongside the platform isn’t sabotaging the project—they’re managing a perceived, and often legitimate, uncertainty about the reliability of the new tool. Ignoring this behavior, rather than addressing it and asking why it’s happening, is the most common mistake observed in projects that fail to take off.
The second dynamic concerns the role of key users—the people the organization identifies, either explicitly or implicitly, as points of reference for their colleagues during the transition. If this role is not assigned deliberately, the company will still have one: it will simply be the person most familiar with shortcuts in the old system, who—by example—will become the informal point of reference in the new system as well, often carrying over practices that the new platform is intended to replace.
The third concernsIT, which, in the common perception, manages the installation but ceases to play a leading role once the technical deployment is complete. This is a sequence error: the integration of systems, the quality of the migrated data, and the management of exceptions that arise during actual use—not just during testing—require IT oversight precisely during the months when the organization’s attention shifts elsewhere.
The factor that statistically influences the outcome
In this context, the most useful insight for decision-makers does not concern technology but rather the approach to managing change. According to Prosci, the leading authority on the ADKAR methodology for change management, projects managed using a structured approach to change are six times more likely to succeed than those left to be managed spontaneously by teams.
This isn’t just a methodological detail for human resources specialists: it’s the variable that, more than any other, distinguishes a project that generates a return from one that remains a cost on the balance sheet without any measurable benefits.
How to Plan for the First Ninety Days
The first few weeks after go-live should be treated as an active observation phase, not as a technical trial to be wrapped up as soon as possible. During this period, management’s primary task is not to measure how much the platform is saving, but to understand where users are creating manual exceptions, where bottlenecks are forming in approval workflows, and which features remain unused because no one has grasped their value in day-to-day practice. This is the time when a rapid—even informal—feedback channel between users and key users is worth more than any adoption dashboard.
In the following month, the focus naturally shifts to standardization: the processes that were managed on a case-by-case basis in the first phase must be standardized through a shared procedure; otherwise, the organization risks cementing many small individual exceptions that, when added together, recreate the fragmentation that the platform was supposed to eliminate. This is also the period when the gap between departments becomes apparent: some business functions adopt the tool more quickly than others, not because of technical expertise but because they already had a more solid process culture to begin with.
It is only in the third month that it makes sense to begin analyzing the first quantitative adoption metrics (average time to complete tasks, percentage of processes that pass through the platform without deviations, reduction in manual errors) and to compare them not with the go-live date, but with the baseline of the previous system measured over a comparable period. Measuring too early produces misleading data, because it captures the organization at the lowest point of the J-curve rather than at its steady state.
The roles of CEO and CFO don’t end with the signing of the contract
For those responsible for the budget and results, the most common temptation is to consider their role complete once the purchase decision has been made, delegating the implementation to IT or the vendor. This view is systematically contradicted by the data: the McKinsey study cited at the beginning attributes a significant portion of failures to a lack of management support —as much as to employee resistance itself. When top management remains visibly involved during the first few months—participating in periodic reviews of adoption, asking for updates on any obstacles that have arisen, and publicly acknowledging even preliminary results—the message sent to the organization is that the change is a genuine priority, not just an IT project left to run its course.
For a CFO, in particular, this also means resisting the temptation to measure the return on investment too soon, by applying the same efficiency metrics to the new platform as to the system it replaced. The economic benefit of a successfully implemented platform typically becomes apparent starting in the second or third quarter, not the first, and evaluating it using the wrong metrics at the wrong time often leads to premature conclusions about an investment that, based on the data, simply needed more time to be fully integrated into the organization.
An investment that is evaluated over the long term, not at launch
The first few months after adopting a new platform are not just an operational detail to be left to IT: they are the period during which the return on the entire investment is made—or lost. Companies that manage this phase with the same level of attention they devote to vendor selection achieve measurably different results than those that view the go-live as the project’s final milestone.
If your organization is considering adopting a new platform or is in the first few months following its launch, consulting with those who have guided other companies through this transition can make the difference between a project that generates value and one that never gets off the ground.
