Do you want to know how to set up a billion dollar Government contract without getting sued? I’m writing a book about it: you can read more about that here.
As I go, I’m producing a series of videos on particular problems you may encounter. Some are specific to the really big contracts, others may have application to small procurements too. I love getting feedback on the videos, and particularly any stories you can tell of similar situations you have been in or heard about.
Take a look around the website. If you have any questions, stories or things you would like to see in the book, please contact me at firstname.lastname@example.org
Want to avoid a major project fiasco? Learn from others’ mistakes.
Here is a link to an article by me in Civil Service World, which points out that while learning from experience is commendable, leaning from other people’s experience is so much less stressful.
Now that Procuring Successful Mega-Projects is in the hands of the publisher, I am starting to be more active in the real world again. Recently I gave a joint presentation with Owen Hayford of Clayton Utz at one of their training events. The subject was ‘Today’s solution to yesterday’s deal: managing difficult contracts’.
I presented on some of the things you can do at a management level to improve the workings of a difficult contract, then Owen took over and looked at some of the more drastic remedies you might call upon when the management-level stuff has failed,
We turned it into a two-part article: you can now read my part on the Clayton Utz website. Owen’s part will be published there in the next edition of Clayton Utz Insights.
The Elephant in the Room
If you ignore the elephant in the room, you can get into a lot of trouble.
In 2007 Queensland Health paid its 85,000 staff through an aging payroll processing system that could not be supported for much longer and needed replacing.
Payrolls were run centrally, but the processing of the payrolls was done locally in the various districts. The Queensland Government was then undertaking a Shared Services Initiative, centralising administrative functions to achieve cost savings, so it decided to replace the old Queensland Health payroll system with one that would do the processing centrally.
The concept was simple, but the implementation was a shocker. After ten aborted attempts the payroll system finally went live in March 2010. Thousands of staff received the wrong amount or were not paid at all, and errors continued for months, indeed years.
A ‘catastrophic failure’ was the verdict of the subsequent Commission of Inquiry. Other reports had been more temperate in language but equally damning in content. The cost of fixing the problems was estimated at hundreds of millions of dollars.
So what was the elephant in the room?
Queensland Health provides healthcare and services. At the time it had 85,000 employees across many locations throughout the state and across a range of professional occupations. This was not a standard Government department full of 9-to-5 office workers. Many of the staff worked 24-hour, 7 day a week rosters.
It is obviously more complicated for a payroll system to deal with shift work payments rather than salaries, but that’s okay, any of the big payroll system providers can tailor a system to a particular industrial award.
Enter the elephant.
Queensland Health employees were not covered by one industrial award, but by twelve, under two different pieces of legislation. The twelve awards were impacted by six different industrial agreements, and between them they provided for over 200 separate allowances. KPMG later estimated this resulted in more than 24,000 different pay combinations. It was literally the most complex awards structure of any organisation in Australia.
Several thousand employees had concurrent employment arrangements – they held more than one position, each with different terms and conditions.
The payroll date did not align with the rostering cycle, so pay was always based in part on estimated hours worked rather than actual hours worked, giving constant reconciliation issues
Employees were entitled to submit retrospective claims for work done up to six years previously, giving further reconciliation problems
It must have been obvious to everyone that it would be a great deal easier to introduce a new payroll system if the industrial awards and pay practices were simplified first. But that would have required renegotiating twelve industrial awards and six industrial agreements with 85,000 employees.
It is perfectly understandable that that particular elephant should have been consigned to the too-hard basket. But if you aren’t prepared to solve a problem, you have to be prepared to find a way round it. Pretending the elephant doesn’t exist is not a good idea.
The old system worked, because the payroll processing was done locally, by clerks who understood how all of these different things applied to the particular segment of the workforce they were responsible for.
If Queensland Health wasn’t prepared to rationalise its employment arrangements then it needed to re-think the advisability of procuring a system designed for a simple industrial environment and central processing.
But Queensland Health went ahead with the centralised model. The awards complexity required more than a thousand modifications to the standard software used for interpreting industrial awards. More than fifteen hundred modifications were made to the associated payroll delivery software package, an extraordinary degree of customisation.
Even so, two years after the go-live, implementing the payroll delivery still involved about 130 manual workarounds, plus double handling of pay forms, retrospective payments, ad hoc payments and who knows what else.
Queensland Health had to take on around 500 staff, additional to those required under the previous system, in order to deliver an estimated 200,000 manual processes to process an average of 92,000 forms every fortnight. This for a project that was supposed to result in staff cost savings.
There were problems with the way the implementation was done that contributed to the catastrophic nature of the failure. But the fundamental issue was they went ahead with the project as if the elephant didn’t exist.
What elephants are you ignoring? Think about it.
How not to present an evaluation report
What you say in an evaluation report is important. So is the way you present it.
The Australian Civil Aviation Authority tried to procure an air traffic control system in the early 90s. Things went so badly wrong the Federal Government commissioned a review of the procurement process. [The Honourable Ian Macphee, AO, Independent review of the Civil Aviation Authority’s tender evaluation process for The Australian Advanced Air Traffic System, Australian Government Publications Service 1992 ] Macphee’s report was published in 1992. That’s more than 20 years ago, but the report remains fascinating, because it goes into detail on matters that are normally confidential.
An evaluation report was submitted to the Board of the Civil Aviation Authority in December 1991. It recommended Hughes Aircraft Systems International as preferred contractor ahead of the second-ranked bidder, Thomson Radar Australia Corporation.The report was accompanied by a note from the Chief Executive, which supported the recommendation but asked the Board to note the concerns of the Executive about the risks of the Hughes proposal, in particular in relation to software development. The note didn’t point out that the evaluation team had taken those risks into account but still recommended Hughes.
That was all it took. The Board was completely spooked. The hare was off and running: the Hughes proposal was risky and the Thomson proposal was not. The Board rejected the recommendation and sent management off to have another go.
A management evaluation team undertook an inspection trip covering both Thomson and Hughes. The team did not include anyone with expertise in software development, but they asked more questions about software development than about other areas of risk.
They got very excited about information they collected about the relative numbers of Source Lines of Code, or SLOC in each software development proposal. Thomson had a lot more SLOC than Hughes, which the team interpreted as meaning… the Hughes proposal was more risky!
When they wrote up the report of the trip, they emphasised what they saw as the negative aspects of the Hughes bid in that area and were less critical of Thomson where they had identified Thomson’s risk in other areas as greater than Hughes.
The evaluation team did get a software expert to look at the information when they got back to Canberra. The expert advised the differences in the numbers could be because Hughes would be developing the software from scratch with modern methods and Thomson would be reusing existing software modules: customisation of existing modules uses more SLOC. In other words the difference in SLOC didn’t necessarily say anything at all about the relative risk. The CEO ignored the expert’s report.
Management decided – at a meeting where no minutes were taken – to change its recommendation to the Board …because the Hughes proposal was high risk.
At the Board meeting, appropriately enough on a Friday the 13th, the Board got the original summary of the evaluation results – which still showed Hughes in front on an analysis that had included an assessment of software development risk – a table comparing Hughes and Thomson on the basis of the SLOC differential, with no accompanying expert report and a paper that recommended Thomson on the basis the management team had assessed the Hughes proposal as high risk. Unsurprisingly the Board, none of whom knew much about software, decided in favour of Thomson.
Various things then went wrong and before a contract could be signed the Macphee Review was established. As a result of its recommendations, the competition was re-run with just Hughes and Thomson. The authority made a mess of that as well and ended up in court, but that’s another story.
Be very careful what you say to an approving body. Try not to set any hares running.
And if fresh evidence turns up, don’t consider the new information in isolation. Re-visit the evaluation to make sure it is reviewed by the experts in context and is given its proper weighting, and re-write the evaluation report to demonstrate you’ve done that.