Staying on the Job

The political uproar surrounding the revamped Job Network can’t eclipse the Herculean effort expended to get one of government’s most complicated information systems up and running. We talked with DEWR to find out what went wrong with application EA3000 - and how the department made it right.

Australia’s media wasted no time jumping on anecdotal reports about the performance of the federal Department of Employment and Workplace Relations’ (DEWR’s) new EA3000 application which, shortly after its July 1 launch, made some surprising occupational suggestions for a number of unemployed people.

There was, of course, the Tasmanian man the system suggested could work as a call girl. Then there was the 62-year-old clothing cutter offered a job as a junior assembler, or the 56-year-old Ballarat woman - struggling with arthritis, high blood pressure and shortness of breath - that the system suggested would make a great combat officer.

It may have made for good “current-affairs” fodder, but the early problems with the system were in fact due to the kind of data quality issues that plague most large systems implementations. Combined with reports of technological problems and the usual political grandstanding, the climate for the introduction of the third phase of the Job Network program - also known as ESC3 (Employment Services Contract 3) - was anything but welcoming.

The situation became even worse in August, when Minister for Employment Services Mal Brough was forced to defend an alleged $2.1 billion government bailout for the 109 Job Network subcontractors that signed onto the outcomes-based program expecting more job seekers to front up for interviews than ever did. Labor has used the dramas around the project to vilify the Howard government’s proclivity towards privatisation, while the Liberals continue to argue that the current system has been a major improvement on its predecessor.

Far away from the political limelight, the fact remains that ESC3 is a major shift from previous unemployment services models. It is a technology-enabled initiative with far-reaching implications for service delivery, and the story of its genesis reflects both the environment it was created in and the inherent complexity of such a far-reaching information system.

Building a New Job Network

ESC3 is only the latest phase of Job Network, which was conceived in the Howard government’s early years as a way to improve the effectiveness of the government-run Commonwealth Employment Service (CES) in helping the country’s nearly 750,000 unemployed.

The CES was terminated in 1998, with responsibility passed on to a network of Job Network subcontractors. Anticipating the shift would require more complex data management. In 1996 DEWR had upgraded the CES’s 1988-vintage Fujitsu mainframe to a more open Hitachi MVS-compatible mainframe system that used DB2 and CICS to track the system’s interactions with workers. Reflecting the competitive nature of the Job Network scheme, the database was partitioned so each member could “own” its own customers.

Aiming to make the shift as painless as possible, DEWR initially gave in to cries of protest from contracted providers who were not keen on having their IT strategy dictated to them. The department built an EDI-based (electronic document interchange) system that would allow providers to keep their current employment systems, yet still communicate with the Job Network mainframe.

Taking stock of lessons learned over the original 18-month ESC1 program, the more ambitious ESC2 began in 2000, with 194 contracted service providers awarded three-year contracts worth around $3 billion.

Supporting them was EA2000, a Visual Basic application designed to improve access to the DEWR mainframe. Yet EA2000 faced its own problems: a classic client/server application, many employment agencies found it difficult to install and maintain. The EDI-based approach was also becoming “a huge legacy and an impediment”, according to Anthony Parsons, general manager of employment systems with DEWR.

Facing the impending expiry of ESC2 contracts, in 2002 DEWR embarked on what was to become a complete reworking of the Job Network technology model. The move was seen both as an opportunity for the network to upgrade its technology and add new features, and as a way of breaking the department’s links with an ever more burdensome past.

Job Network had been reviewed extensively during ESC1 and ESC2 ? including major reviews by the OECD and the Productivity Commission - and ESC3 reflected major policy changes that drew on many of the findings of these reviews. “We used this opportunity to significantly adjust policy settings,” says Parsons. “It was time to reflect on the evolution of the labour market and how well some of those policy settings had worked, and to decide which changes to put on the table for ESC3.”

Several key changes soon emerged as the driving goals of the new program.

First, the new system would only give job seekers access to ongoing service from one Job Network provider of their choice for as long as they were unemployed. This approach was intended to eliminate previously fragmented arrangements that had seen job seekers having to register with multiple providers to maximise their chances of finding work. Multiple registrations had made it impossible for Job Network to keep a continuous record of interactions with each person, and individual providers’ knowledge of each person was limited to their own experiences.

A second problem was in keeping jobseekers actively engaged with their Job Network provider. Historical data had showed that Job Network members’ efforts to find work were intense at the beginning of their interaction, tapered off to a low plateau for much of the relationship, then rose sharply in the lead-up to expiration of the provider’s window of opportunity.

To keep efforts at a more consistent level throughout, EA3000 was designed not only to record the job search but to proactively assist it by matching job seekers’ skills with available positions. Each job seeker would build an online resume with up to five areas of specialty, then let the system regularly search available positions on their behalf. New communication channels - including SMS messaging, an IVR (interactive voice response) phone system and interactive touch-screen kiosks - were introduced to give job seekers more ways to find out about job matches.

Finally, EA3000 was enlisted to help speed the process of linking people with their Job Network provider, which could easily take four to six weeks under the old system. Improving this centred around the creation of a online diary application that would be used by Centrelink to query instantly each Job Network provider’s schedule and book available slots - potentially as early as the same day - on the spot for the job seeker.

Managing the Complexity

Such were the terms of reference for EA3000. Faced with pressure to deliver a working system by the deadline of July 1 this year, Parsons’s team was charged with delivering what from the beginning was going to be an ambitious and massive project.

Just how massive? At its completion, the system was measured as having approximately 9970 function points - a standard method for measuring applications in terms of the number of functions they have, such as printing a document or displaying a screen. Tenderers compare bids by measuring the cost per function point ($1000 per function point is a rule of thumb). Most moderate-sized applications might have around 500 function points, and anything over 1500 is generally considered high risk. EA3000 was, it turns out, more than six times that limit. And while the number of function points was not immediately quantifiable, the system’s complexity was clear as soon as political leaders described their vision for the system.

“When you’re in a front-line policy department like this, you have all sorts of pressures to respond to political change quickly,” Parsons says. “When they described the magnitude of change, we knew that it couldn’t be achieved within 12 months using our traditional systems development approach. We jettisoned as much optional functionality as we could, and went searching for an iterative approach that would let us achieve as much as possible.”

In an ideal world, that approach would have been the Rational Unified Process (now owned by IBM), but its high cost led DEWR to consider alternatives. The department settled on Object Consulting’s Process MeNtOR methodology, a comprehensive change management process that was far more cost-effective than the Rational approach.

As dozens of DEWR analysts began planning the development project, Parsons’s earlier feeling that traditional ways of doing things were not going to cut it were confirmed. Process MeNtOR is based on a train metaphor, with teams seen as a collection of cars whose members get on and off at stations along the way. The methodology recommends a project never have more than seven “trains” at a time, but in EA3000’s early days DEWR had more than 30.

Adopting Process MeNtOR helped Parsons’s team - which rapidly grew to include more than 30 business analysts, 30 testers, 60 programmers and around 80 training, support and other staff - to plan an aggressive yet effective course of development for the project.

The latter half of 2002 was a flurry of planning, development, testing and redevelopment as EA3000 took shape. Yet one very important thing was missing: probity requirements meant DEWR could not communicate with companies bidding to become Job Network providers until after the tenders had closed. This meant it was difficult to ascertain, early on, exactly what they would expect from the system.

“During the early days of scoping and design, I was forbidden from talking with any tender respondent in order to keep the tender process absolutely beyond dispute,” Parsons recalls. “We had to second-guess some of the end-user requirements, saying ‘we think they’d like this’ but couldn’t talk with them to justify our assumptions. When the dust cleared, we had covered around 60 to 70 per cent of their wish list.”

Towards a Better Interface

While designing EA3000, DEWR faced a very common problem: how to build a modern application with a modern user interface, but manage data using an antiquated back-end legacy system such as DEWR’s 1996-era mainframe.

In the past, direct mainframe access - bolstered in EA2000 by a rudimentary interface - had been a simple compromise. But as available technologies improved, it became clear that EA3000 was going to need strong back-end application integration and a flexible presentation layer capable of delivering messages via SMS, e-mail, IVR, a Web browser, in-office kiosks or other interfaces.

Simply building on the previous system, it was clear, was no longer going to cut it. DEWR also made the strategic decision to discontinue the EDI system, mandating that ESC3 members update their IT to reflect current technological realities. “One of our challenges was to take the substantial, legacy mainframe that powered ESC2 and make it such that it could deliver messages through various channels,” Parsons says.

“The old mainframe tool was clunky to navigate and not at all pre-emptive, and users had to know the right steps to complete an operation. We wanted EA3000 to turn that around to follow the logical sequence of business rules, so that we could provide a best-of-breed tool that was really attuned to the workflow. The policy settings were so radically different from ESC2 that there was no easy evolution from the old IT systems that may have been built.”

With EA2000, the department had experimented with bog-standard HTML in order to provide an interface that would run on as many desktops as possible. However, DEWR soon realised that it could build a much richer, usable application interface if it built EA3000 around Windows and associated technologies. Most specifically, this meant using Microsoft’s .NET Framework and WinForms components, which enable direct application calls to the Windows environment to provide features that are impossible using generic Web technologies.

To make the .NET approach work, providers had to be running Windows XP - a requirement that DEWR wrote into the initial Job Network contracts. Yet when subcontractors asked for configuration specifics, the department deferred to Microsoft’s Web site, which is known for providing optimistically low minimum configuration suggestions.

Down the track, DEWR traced some employment providers’ problems to this miscommunication: one company was using Pentium II-based systems with just 64MB of memory. They’d managed to get Windows XP running, but the unsurprising poor performance was being attributed to EA3000 and not to their outdated technology. Such issues demonstrate the inherent complexity in ensuring that 109 different companies were reading from the same page as DEWR.

Troubleshooting = Political Damage

After a fiercely busy development cycle, EA3000 went live on July 1. The department was on the back foot soon afterwards as minister Brough suffered a roasting from political opponents - first over the highly lampooned anomalous job matches, and second over the more political issue of the number of unemployed people actually showing up at interviews to participate in ESC3.

1 2 Page 1
Page 1 of 2
6 digital transformation success stories