How PCL One Delivers Oracle Fusion Faster for Housing Providers
Speed in an Oracle implementation does not come from skipping steps. It comes from not starting at zero, deciding on real screens, and running work in parallel wherever the dependencies allow. Here is what that looks like in practice, and the results behind it.
Most ERP programmes are slow for the same reasons.
Design starts from a blank template. Decisions are made on slides and revisited once people see the real system. Phases run one after another, so testing waits for build and training waits for testing. Third-party dependencies surface late. And the people who designed the solution are not the people who support it.
Each of those delays is avoidable, and none of them is avoided by working longer hours.
The results behind the approach
Under half the typical time
At Riverside, payroll was brought together on Oracle in under half of the typical 20 months.
Two months ahead, on demand
When Riverside's legacy payroll system failed two months before go-live, PCL One advanced the payroll module by two months to protect continuity.
22 payrolls in 4 months
For a global brokerage, PCL One transformed HRIS and 22 payrolls in four months.
Self-sufficient within weeks
When Riverside completed an acquisition within two months of go-live, its own team managed the integration internally.
The same methods apply to finance and purchase-to-pay. The rest of this article explains what they are.
1. Start from a working housing design
We do not begin with an empty Oracle template. We bring a starter housing design: a chart of accounts with fund, cost centre, scheme, block and property built in, component accounting for the asset register, multi-entity and intercompany structures for housing groups, and approval patterns that suit requisitioners in repairs and development.
Discovery then becomes a matter of confirming and adjusting a proven design, rather than inventing one. That is where the biggest single saving comes from.
2. Decide on real screens from the first week
A working Oracle environment is available from the start of the programme, configured with housing data. Design workshops run on that system. Finance and procurement leads see their approval routes, coding and reports as they will really work, and decide there and then.
Decisions made on real screens stick. Decisions made on slides tend to come back during testing, and that rework is where most programmes lose months.
3. Overlap the phases
Design, build, integration and data migration overlap wherever the dependencies allow. Configuration starts on areas already agreed while other workshops continue. Interface build starts as soon as specifications arrive. The first mock data migration runs during build, not after it. Super-users join during design, so training material is written alongside configuration rather than after testing.
Five approval gates keep the overlap under control. Each gate is the customer's decision, and nothing passes a gate on a promise.
4. Pull dependencies forward
The longest waits in a finance implementation are usually outside the project team: the housing management system supplier, the integration platform team, the bank. Specifications, access and test slots from each are requested in the first weeks and tracked as dated dependencies.
Work that does not need to be on the finance critical path, such as a wider CRM programme, runs as its own workstream so finance go-live does not wait for it. Our article on integration through your hub explains how.
5. One team, start to finish
The leads who run discovery are the leads who configure the system, support testing and stay through hypercare. Specialists in data migration, reporting, integration and testing join when their work starts. Nothing is handed between teams, so nothing is re-explained.
PCL One acts as the single accountable partner, as Oracle reseller and implementation prime, with no subcontractors. Decisions do not wait while several suppliers agree who owns a problem.
6. Configure, do not customise
Everything we deliver uses Oracle's standard configuration, APIs and integration services. There is no custom code to write, test and maintain. That shortens the build, and it keeps quarterly Oracle updates simple after go-live, because there is nothing bespoke for an update to break.
Fast and safe are not opposites
A shorter programme only matters if go-live is safe. Every one of the methods above reduces risk as well as time: a proven design has fewer unknowns, decisions on real screens need less rework, early dependencies mean fewer late surprises, and a stable team keeps knowledge in one place.
Our article on cutover and hypercare describes the controls that keep a fast programme safe at the moment that matters most.