CCS Chronicles: a third-party software provider’s perspective

Those working in the early childhood education and care (ECEC) sector would be forgiven for thinking that it was only the policy around how access to early education is subsidised that changed with the introduction of the child care subsidy (CCS) in July. The reality though was very different.

 

Behind the scenes there was a massive overhaul in sector and government systems that record, transmit and store information about children’s attendance at ECEC services, and that receive, process and ultimately pay the child care subsidies (CCS).

 

 

As Scott Loose, Managing Director of QK Technologies noted, the change was “not just about a change for the child care sector in terms of subsidies, the government effectively threw out their entire child care management system”.

 

 

The key drivers for this wholesale reset were:

 

 

The introduction of the new child care subsidy required a new system be built to manage the processes that the system required in order for the subsidy to be paid.

The Government was part way through a broader overhaul of it’s existing enterprise software platforms that was centred around using German company, SAP’s platform technology.

 

• Challenges around the inappropriate use of subsidies have been well documented in recent years and were cause for real concern at the government level. As a result, part of the system reset was rooted in introducing more stringent rules around payment and better reporting to ensure a better level of integrity.

 

Gillian Mitchell, Group Manager Transition and Engagement at the Department of Education and Training explained “We, under family assistance law, are responsible for payment integrity. So it is important that we are sure the CCS is being paid to people to which it should be paid.”

 

 

It’s good to talk

 

Given the magnitude and complexity of the transition it was essential that third-party software providers and the Government openly, regularly and respectfully engaged to ensure that the Government had a comprehensive understanding of the practical realities of the new system in the context of the day-to-day operation of an ECEC centre and could adjust their needs accordingly.

 

This period lasted for about seven months, ending in January 2018 and was largely conducted through regular provider meet-ups at which the vast majority of third-party software providers would attend.

 

Although there was certainly some appetite on behalf of the third-party software providers to have commenced the engagement process earlier than in July of last year the forums resulted in some significant reshaping of the agenda towards a solution that was more consistent with the sector’s needs.

 

Mark Woodland, CEO of Xplor, said “We had a lot of dialogue with the Government about what will and won’t work. We felt it was important that the government groups who may not have much to do with tech or childcare in their day jobs understood the extent of the scope and its impact.”

 

But although the software providers were grateful to have been included in this dialogue in the initial months of the process, there was materially less enthusiasm for how the actual development phase was to unfold thereafter.

 

 

Shifting goal posts

 

As is always the case with an IT project of this nature, developers are guided by a set of specifications that detail precisely what code needs to be written to ensure the systems can interact with each other effectively.

 

For the CCS project the specifications were supplied by the Government to the software providers.

 

They consisted of 12 different sections which represented the different interfaces that needed to be created.

 

An interface reflects a specific task or set of tasks that would need to be completed as part of the CCS process for example, there was an account management interface and an Additional CCS Child Wellbeing interface.

 

The challenge the developers had was that these specifications were changing on almost a weekly basis which meant that any code that had been written based on previous interfaces had to be scrapped and rewritten. The reason being that the Government was developing its own system in tandem with the third-party software providers. It has not been built yet and as they were working through there build they came across situations where revision was then required.

 

These revisions were then passed down to the software provider development teams in the form of a spec change.

 

So in effect, while the providers were busy developing code that they thought was right, they were then informed that actually the code was wrong and that new code would need to replace the old code.

 

The frustration that this caused was very significant.

 

 

Acceptance is the key

 

But the reality was that despite how very difficult that period was the software providers were powerless to do anything about it and actually, the quicker they accepted that this was the way it would be, the easier it was to process the changes and keep moving forward.

 

As Mr Loose noted “We basically said, it doesn’t matter what the Government was doing, we are going to treat the Government like a partner” and went on to add “the attitude was that we need to do this, whatever we need to do, whatever the roadblocks are, we need to make this work.”

 

This attitude was eventually mirrored across all of the software providers but at different points in time.

 

There appears to have been a correlation between the speed of acceptance with the smaller, less well capitalised providers taking longer to come to terms with the situation.

 

 

A big, big job

 

But gradually over time the focus moved away from resisting the Governments practices to recognising the necessity and urgency of the job in hand and what it would take to get things done.

 

As Tom Jamieson, CEO at the time at Kids X App, said “We started in September with a small group of coders and then by January we were cranking into full-scale deployment mode.”

 

The scale of commitment from the majority of these business was very material.

 

For QK Technologies, 70 per cent of their business-as-usual resources were allocated to the development and support of the CCS project from January to July 2018.

 

Xplor, who have a large development team, created a new working group to focus on the CCS.

 

Kidsoft differed from QK and Xplor as their resource bases were quite lean prior to the CCS so needed to scale up to be able to cope with the requirements. Hubworks! ramped up development as needed. 

 

Kidsoft increased their development team by four times and their help desk team by three times, and HubWorks! increased their help desk team by three times although Ruby O’Rourke, CEO of HubWorks!, noted that even an increase that large wasn’t large enough to respond to services who hadn’t performed the pre July 2 requirements. Ms O’Rourke says that no matter how much information the government or HubWorks! provided to the sector, only a quarter of services were ready for the July 2 transition, leaving 75 percent of services calling for support post July 2. 

 

Once the teams were in place they were then incredibly active executing on development and training strategies.

 

Thousands of hours of webinars were hosted, hundreds of face-to-face site visits conducted, scores of forums and technical sessions attended, huge volumes of phone calls fielded, and of course millions of new lines of code had to be written, tested and then applied.

A big, big job indeed.

 

 

And at what cost?

 

But with the increase in staffs costs were increasing as well and in some cases increasing a lot.  

 

The full project cost for Kids X App was in excess of $1 million.

 

For QK Technologies it was a similar amount.

For Kidsoft and HubWorks! profitability costs were in the hundreds of thousands of dollars.

 

When asked about this, Gillian Mitchell, from the Department of Education and Training, who managed the transition and implementation, said that “the third-party providers operate as a business and the costs of transition were business expenses.”

 

She went on to note that “We (the Department) did nothing different this time from the way we did things when the National Quality Framework was rolled out or when we switched from the system they had before childcare management system (CCMS) came into being.”

 

So although the Government recognised that the software providers had borne significant costs to become transition ready no compensation would be forthcoming as the costs were basically business costs and therefore not the Government’s responsibility.  

 

 

To make matters worse

 

And to make things harder for some of the software providers each was faced with their own company-specific circumstances that needed to be overcome.

 

For example, QK had to manage the fact that a number of their larger customers had just made significant acquisitions that required a customised response in terms of mapping and transition.

 

Kidsoft themselves took on a material acquisition six weeks out from transition that needed integrating.

 

HubWorks! was working on two system delivery deadlines, one being the CCS for 2 July 2018.

 

And Kids X App’s original program spanned right across the centre needs spectrum from programming to payments to activity management and more, making the reconfiguration that much more complex and meaningful.

 

But despite these challenges all providers managed to achieve their interface registration sign offs by 2 July 2018.

 

 

The post transition world

 

In the first week post the CCS transition all software providers reported a relatively quiet week.

 

Time was spent ensuring that mapping of family details from the old system was accurate and that the CCS-specific information was being correctly reflected.

 

As Mr Woodland noted “the first week was easy. It was the second week when the pain started to come through.”

 

No matter who you were, large or small, the second week in July was very challenging as centres across Australia began to sift through their CCS payment schedules and realised that not everybody had been processed correctly for one reason or another.

 

It was this period that really tested the third-party software providers as their support lines exploded with calls from centre managers desperately trying to resolve problems that were linked directly to whether money had or had not been received correctly.

 

Those providers with well resourced support desks and responsive developer teams fared better in this phase than those that didn’t but all found it very hard.

 

 

A few key trends emerged

 

But if one dug a bit deeper into the data, a few key trends emerged.

 

Firstly, centres in lower socio economic areas were much more active on the phone lines than those in higher socio economic areas.

 

Secondly, although larger providers required more customised support than smaller providers in the run up to transition, it was the smaller services that dominated the support lines post transition.

 

Thirdly, across the different types of ECEC services, FDC consumed by far the most support time. One HubWorks! customer, who was an FDC operator, used 9 per cent of the total help desk hours provided in the two months post transition.

 

 

Has the transition been good for business?

 

Having commenced the process with 27 software providers, 11 have now closed, leaving 13 remaining, with 3 services absorbed by HubWorks!

 

Of the five larger players involved in the sector, four of them noted an increase in customer numbers over the period and one a decrease.

 

Some of those gains would have been from purchasing closing businesses, some from picking up customers who were unsatisfied by their old software provider’s management of the transition, and some who needed a new provider due to their previous provider closing down.

 

It seems that high costs of making the transition happen have been mitigated somewhat by the opportunities that have presented themselves along the way.

 

 

Looking ahead

 

Nearly three months on from transition there is no doubt that activity levels have normalised materially from those seen back in July 2018.

 

Development requirements have paired back to a business-as-usual level and help desks have more or less settled down also.

 

But the CCS transition for the software providers is not yet complete.

 

As Mr Karzon notes “There are still new interfaces planned along with other changes”

 

He went on to state that “One of the challenges however, is that we have limited visibility on what that might look like and how it will impact the software and our customers.”

 

So whilst the providers are actively winding down their CCS focus and reallocating resources to new projects and initiatives, there will still be a need to keep a watchful eye on the Department of Education and Training and the Department of Human Services so that they can be ready to navigate the next set of requirements as and when they arrive.