How to Implement a New Platform People Will Use

The platform rarely fails. The launch does.

Organisations spend six months choosing a system and six weeks planning the rollout. Procurement runs a rigorous process. Vendors get scored, security signs off, finance approves the business case. Then the contract gets signed, a go-live date lands in the calendar, and the work of making the thing succeed falls to whoever has capacity.

Twelve months later the platform sits at low adoption, and the review blames the vendor.

We launched two Bigtincan platforms, a learning management system and a content management system. Both went well by most measures. Delivered, integrated, signed off, no drama at go-live. And adoption still moved slower than we wanted, for reasons no implementation plan had a line item for.

This piece is about the work after the purchase decision. If you have already worked out where your enablement budget should go, this is the next problem. Buying the right platform and landing the right platform are two different disciplines, and the second one gets a fraction of the attention.

What else is your organisation carrying this quarter?

Audit the calendar before you commit to a go-live date. Your launch is competing with everything the business has already scheduled, and the scheduled things win.

Most launch plans assume they have the organisation's full attention. Very few do. Competing platform rollouts are the obvious conflict and rarely the biggest one. The calendar is full of fixed events with deadlines attached. Your launch date has a deadline you set yourself.

• End of financial year. The June crunch, plus the reporting tail through July and August. Finance, sales and operations are unavailable in any useful sense.
• Performance review cycles, mid-year and annual. These consume every people leader you need as an adoption lever.
• Audit and security review windows. Certification renewals and penetration testing pull the exact team you need for integration work.
• Product launches and go-to-market moments. Marketing and enablement are already fully committed.
• Peak trading, whatever it looks like in your industry. Retail before Christmas, education at enrolment, professional services at tax time.
• The December and January shutdown. In ANZ this removes weeks of momentum, and a launch landing into it loses its stabilisation window entirely.
• Restructures, code and system freezes, and integration work following an acquisition.

Audience capacity is one cost. A sales team in the final month of the financial year will not learn a new system.

Your launch team is the other, because it is the same small group of people. The security specialist reviewing your platform is also delivering the annual audit. A twelve week timeline crossing two fixed events is not a twelve week timeline.

Map the year before you pick a date. Where the date is imposed on you, name the collision in writing early.

Who do you need on a platform launch team?

You need functional coverage across enablement, marketing, technology and security, and communications, plus one named person accountable for the seams between them.

Our launch team had the functions right. Enablement owned capability and content strategy. Marketing owned positioning and the internal brand. Technology and security owned architecture, integration and policy. Comms owned the narrative and the cadence. Four groups, all competent, all engaged.

What we did not have was a single owner of the space between them, and it cost us.

The roles, defined tightly

• Executive sponsor. Holds the business case, clears blockers, and visibly uses the platform. A sponsor who never logs in tells your organisation everything it needs to know about priority.
• Platform owner. One accountable name. Owns the rollout end to end, including the seams. This is not the same person as the system administrator.
• Technology and security. Owns integration, single sign-on, identity, permissions and policy compliance. Involved from requirements, not from testing.
• Data and integrations owner. Owns what flows in and out, and what happens when a field changes upstream.
• Content owner. Owns what goes in, what stays out, and who approves both.
• Capability owner. Accountable for people being able to use the platform, across launch training, ongoing capability and new starter onboarding. Distinct from the content owner, who owns what sits in the platform rather than whether anyone can work it. On a small launch this is usually the platform owner wearing a second hat. The role outlives the project, so name the handover to whoever owns induction before the launch team disbands.
• Comms lead. Owns audience segmentation, sequencing and message discipline.
• Champion network. Practitioners inside teams who use the platform early and answer questions their colleagues will not raise with a project team.
• Vendor customer success manager. Owns escalation, release visibility and configuration advice. Treat them as part of the team rather than a support ticket.

The scaling question

Size changes how these roles get distributed, not whether they exist. Size them against the platform's user population.

Rough markers, and they are judgement rather than benchmark.

Under about fifty users, one person carries several hats. Platform owner, content owner and trainer, often the same individual. Workable, as long as the hats are named and the time is protected rather than absorbed as a side project.

Past about fifty users, split platform owner from system administrator. The owner works on adoption and governance. The administrator works on configuration and support. Blend them and urgent configuration work crowds out important adoption work every week.

Past roughly a hundred and fifty users, or as soon as the platform touches more than two functions, add coordination and a governance forum with real decision rights. Coordination becomes the job at this point, and leaving it as an implicit part of somebody else's role means it does not get done.

Governance, decided before launch

Two questions settle most later arguments. Who approves content before it goes live, and who holds administrator rights. Leave both undefined and you get either a bottleneck or a free-for-all, and the free-for-all is worse because it degrades quality quietly.

The failure mode to avoid is the launch where everyone owns it. Shared ownership of a seam means nobody is watching it.

How long does a platform implementation take, and what does it really cost?

Our Bigtincan learning management system took twelve weeks. The content platform took roughly twenty-four.

Same vendor, same launch team, double the timeline. In our case the gap came down to three things. Migration volume, because existing content had to be assessed, cleaned, reformatted and in many cases retired rather than moved. Permission complexity, because who sees which asset was a business rules exercise rather than a configuration step. And integration surface, because the content platform touched more systems, more consumers and more publishing workflows than the learning platform did.

Plan in phases rather than by fixed month markers. Not every phase applies to every platform, and working out which ones apply to you is a scoping job worth doing early.

• Requirements and technical validation. Functional needs tested against security and identity policy before a build starts.
• Configuration and integration. Single sign-on, identity provisioning, data flows.
• Content migration, where a predecessor system exists and content is coming across. Some platforms launch deliberately empty and fill as the work happens, which removes the phase entirely. Where it does apply, scope it on volume and on how much should be retired rather than moved.
• Permissions design, where access rules are a business decision rather than a setting.
• Testing and sign-off.
• Training design and delivery. Design depends on locked configuration, which lands later than planned on most projects, so protect the time or it gets compressed into the fortnight before go-live.
• Launch and stabilisation.

Procurement cycles, security review queues, HRIS integration work and competing release freezes are what stretch them.

Licence fees are the visible cost. Implementation, integration engineering, migration effort where it applies, training design and delivery, ongoing administration, and internal hours across every team involved for the length of the project. Internal hours are almost always the largest line and the least likely to appear in the business case.

What belongs in a platform launch comms plan?

Segmentation and sequencing, not volume. A single all-staff announcement is not a comms plan.

Segment by what each audience needs to do.

• Executives need the business rationale and the ask, which is visible sponsorship.
• People leaders need to know what changes for their team and how to answer the questions they will get. A manager who has not been briefed will default to protecting their team from extra work.
• End users need to know what changes for them personally, when, and where to go for help.
• Support functions need to know before the first ticket arrives.

Sequence in three phases. Before, so nothing arrives as a surprise. During, with a heavier cadence through launch and stabilisation. After, at intervals tied to review cycles rather than trailing off once go-live passes.

Say plainly what the platform replaces and when the old one goes, and describe the problem it solves in the reader's language rather than the project's.

What should user acceptance testing cover?

Real workflows performed by real users under their actual permissions. Not features demonstrated inside an administrator account.

Our content platform failure surfaced here, later than it should have. We had underbaked the technical requirements. During UI testing we found some functionality would be unusable for the people who needed it, because technology and security policies disallowed it. The functionality worked. The policy said no. Both groups had done their jobs correctly, and the gap between the two belonged to nobody, because the RACI was not tight enough to make the seam somebody's problem.

Tightening the RACI is the single change I would make to how we do this. Not more documentation. Clearer accountability at the joins, specifically where functional requirements meet security policy.

The clash was findable during requirements. Finding it during testing meant rework under deadline pressure.

Your test plan should cover:

• Real workflows end to end, by role, under production permission sets
• Edge-case populations, including contractors, part-time staff, multi-site users, field workers and anyone outside standard identity provisioning
• Every functional requirement checked against security and acceptable use policy, ideally at requirements stage and again before sign-off
• Usability, meaning whether someone unfamiliar with the platform completes a core task unaided and in less time than the method it replaces. Measure clicks, time and completion without help, rather than asking people whether they liked it
• Accessibility against WCAG, tested rather than assumed
• Mobile and offline behaviour, particularly for field or frontline users
• Single sign-on and provisioning, including what happens when someone changes role or leaves
• Privacy and data residency, meaning where the data physically sits and whether the arrangement satisfies your obligations
• Defect triage with agreed severity definitions and written criteria for what blocks go-live
• A rollback plan, documented and tested, with the authority to delay go-live genuinely held by someone

A sign-off process with no realistic power to say not yet is a formality rather than a control.

How do you train people for launch, for the long term, and for new starters?

Existing staff are the hardest audience. New starters are the easiest, and they will drive your adoption curve.

Our launches went smoothly. Uptake did not follow. Existing staff largely stayed away, and the reason they gave was consistent. They already knew the content. They had built their working habits around the old way, they were experienced, and a new system offered them a cost with no obvious benefit. Nobody was being obstructive. They had made a reasonable trade.

What shifted usage was new starters. As people joined and their onboarding introduced both platforms as the way work gets done here, usage climbed. The new cohort had no competing habit to protect. They learned the platform as the default rather than as a replacement.

Which inverts the usual assumption. Launch-day training gets treated as the main event and onboarding as maintenance.

Three horizons, then, with different jobs.

Launch cohort

The task is habit replacement, not feature familiarisation. I already know this is a much harder objection than I have never seen this before, and it does not get answered by a demonstration.

What works better. Training built on the person's real work rather than sample content. Explicit comparison showing where the new way is faster than the old, credibly and specifically. Retiring the old path on a published date, because parallel systems always resolve in favour of the familiar one. And champions inside teams, since a peer saying this saved me an hour carries weight no project communication will match.

Ongoing capability

New functionality arrives continuously with a modern platform. Vendor releases add features nobody was trained on. Without a rhythm for this, capability freezes at launch-day level while the platform moves on. A short, regular cadence tied to release notes handles it, along with refreshers aimed at the workflows people avoid rather than the ones they have mastered.

New starters

This is where our adoption came from, and it warrants deliberate design rather than a slide in an induction deck. Position both systems as how the work is done, not as tools available to you. Build the platform into the first real task a new starter completes. Person forty-one joining in March needs the same quality of introduction as the launch cohort received in November, and by then the project team has usually disbanded.

Sustained transfer depends on the same conditions as any other capability work, which is a longer argument in its own right. For launch planning the point is narrower. Training the launch cohort is the smaller half of the job.

How do you keep a platform current after go-live?

Through clear accountability and scheduled maintenance, because platforms decay by default.

Content ages. Links break. Permissions drift as people change roles. The vendor ships features nobody adopts. Licences sit unused. None of it triggers an alert, and all of it erodes trust in the system, which is much harder to rebuild than to protect.

What holds the line:

• A content register with a named owner and a review date per asset. Content with nobody behind it is the fastest route to a platform people stop believing.
• Retirement rules agreed in advance. Content past review with nobody attached comes down. Making the rule automatic avoids relitigating each item.
• Vendor release management. Someone reads the release notes, decides what to adopt, and tells people what changed.
• Data hygiene. Broken integrations, stale user records, orphaned permissions.
• Licence and seat review, so you stop paying for people who left and you catch teams sharing logins.
• Integration monitoring, because upstream systems change without telling you.

Decommissioning the old system

The retirement plan needs as much rigour as the launch plan, and it usually gets none.

Two platforms running in parallel means split content, split habits and split trust, and people will keep using the one they know. Set a retirement date, communicate it early, and hold it.

Before switch-off, work through what has to be kept and for how long. Records retention obligations, regulatory requirements, and anything with legal or audit relevance. Decide what gets migrated, what gets archived outside the new platform, and what gets deleted, with the decision documented and approved. Then confirm access is genuinely revoked. Legacy systems left quietly running are a security exposure and a licence cost nobody is reviewing.

The vendor relationship

Your vendor is a resource you have already paid for. Set a quarterly business review with real content, meaning adoption data, open issues and roadmap. Understand the escalation path before you need it. Ask what comparable customers do well, since a good customer success manager has seen dozens of launches and yours is their pattern-matching opportunity as much as your own.

What review cycles should you run after go-live?

Run three early checkpoints, then move to a longer value cycle, and decide renewal on evidence rather than sunk cost.

At thirty days, look at access and friction. Who has logged in, who has not, where support requests cluster, what broke. This window is for fixing obstacles rather than judging success.

At sixty days, look at behaviour. Are people completing real work in the platform, or visiting once and returning to the old method. Depth over breadth.

At ninety days, look at the adoption pattern by team and by role. Variation between teams is usually a manager signal rather than a tool signal, and it tells you where to direct effort.

Then shift to a six-monthly value review and an annual commercial review. The value review asks whether the intended outcomes are showing up. The commercial review asks whether the licence, tier and configuration still match how the platform is used.

Measure adoption depth rather than login counts. Better signals include repeat use by the same person, task completion inside the platform, content created and reused, and the proportion of the target population using it monthly rather than ever.

Continuing because switching is painful is a decision, but it should be a conscious one.

The launch is the product

The system you bought is not the thing your organisation experiences. What people experience is the rollout. The clarity of the accountability, the honesty of the communication, the quality of the testing, the design of the onboarding, and whether anyone kept the thing current after the project team moved on.

Our platforms launched well and adopted slowly. Tighter accountability at the seams would have caught the permissions problem at requirements instead of testing. Treating existing staff as the hard audience would have got us to the same usage curve months earlier.

Both are planning decisions, and both cost nothing except attention at the right moment.

Our adoption arrived in the end. It arrived with people who never knew the old way, on their timetable rather than ours.

If you are about to introduce a new platform, or you have one sitting at lower adoption than the business case promised, get in touch. We work with enablement and L&D teams on the part vendors do not sell, which is landing the thing properly.

Frequently asked questions

How long does a platform implementation take?

In our implementation the learning management system took twelve weeks and the content platform took roughly twenty-four. Those are two data points from one organisation rather than benchmarks. What drives the difference is migration volume, permission complexity and integration surface, so scope those three honestly and your own range will look nothing like ours.

What does a new platform cost beyond the licence fee?

Implementation and configuration, integration engineering, migration effort, training, ongoing administration, and internal hours across every team for the full project duration. Internal hours are usually the largest cost and the least likely to appear in the business case.

Why is adoption low when the launch went well?

Usually because existing staff have working habits and see no personal benefit in changing them. I already know this is the most common objection and the hardest to shift with training. The two levers with most effect are retiring the old path on a published date, and building the platform into onboarding so new starters treat it as the default rather than the alternative.

Who should own a platform launch?

One named person, accountable end to end, distinct from the system administrator. Functional teams cover their own areas competently. Failures concentrate in the seams between them, particularly where functional requirements meet security policy, and a seam without an owner is a seam nobody is watching.

How many platforms can an organisation launch at once?

Fewer than most roadmaps assume. Change capacity is finite, and competing launches in the same window means both underperform. Before committing to a date, audit what else is landing in the same quarter and sequence rather than overlap.

What should user acceptance testing include?

Real workflows performed by real users under production permissions, covering edge-case populations like contractors and part-time staff, accessibility, mobile behaviour, single sign-on and provisioning, and every functional requirement checked against security policy. Sign-off criteria and a rollback plan should be written down before testing starts.

When is the worst time to launch a new platform?

Into a fixed organisational event. End of financial year, a performance review cycle, an audit or certification window, a product launch, or your industry's peak trading period. Two problems compound. Your audience has no capacity to learn, and your launch team is the same people delivering the competing event. Map the year before you commit to a date, and sequence behind the fixed events rather than beside them.