Some departments ceased to exist (such as Department of Regional Australia), others split (DEEWR into two departments, Education and Employment) and still others had parts 'broken off' and moved elsewhere (Health and Ageing, which lost Ageing to the (renamed) Department of Social Services).
This isn't a new phenomenon, nor is it limited to changes in government - departments and agencies are often reorganised and reconfigured to serve the priorities of the government of the day and, where possible, create efficiencies - saving money and time.
These adjustments can result in the movement of tens, hundreds or even thousands of staff between agencies and regular restructures inside agencies that result in changing reporting lines and processes.
While these reorganisations and restructures - Machinery of Government changes (or MOGs) as they are known - often look good on paper, in reality it can take time for efficiencies to be realised (if they are actually being measured).
Firstly there's the human factor - changing the priorities and allegiances of staff takes time and empathy, particularly when public servants are committed and passionate about their jobs. They may need to change their location, workplace behaviours and/or learn a new set of processes (if changing agency) while dealing with new personalities and IT systems.
There's the structural factor - when restructured, merged or demerged public sector organisations need to revisit their priorities and reallocate their resources appropriately. This can extend to creating, closing down or handing over functions, dealing with legal requirements or documenting procedures that an agency now has to follow or another agency has taken over.
Finally there's the IT factor - bringing together or separating the IT systems used by staff to enable them to do their work.
In my view the IT component has become the hardest to resolve smoothly and cost-effectively due to how government agencies have structured their systems.
Every agency and department has made different IT choices - Lotus Notes here, Microsoft Outlet there, different desktop environments, back-end systems (HR and Finance for example), different web management systems, different security frameworks, programming environments and outsourced IT partners.
This means that moving even a small group of people from one department to another can be a major IT undertaking. Their personal records, information and archival records about the programs they work on, their desktop systems, emails, files and more must be moved from one secure environment to another, not to mention decoupling any websites they manage from one department's web content management system and mirroring or recreating the environment for another agency.
On top of this are the many IT services people are now using - from social media accounts in Facebook and Twitter, to their email list subscriptions (which break when their emails change) and more.
On top of this are the impacts of IT service changes on individuals. Anyone who has worked in a Lotus Notes environment for email, compared to, for example, Microsoft Outlook, appreciates how different these email clients are and how profoundly the differences impact on workplace behaviour and communication. Switching between systems can be enormously difficult for an individual, let alone an organisation, risking the loss of substantial corporate knowledge - historical conversations and contacts - alongside the frustrations of adapting to how different systems work.
Similarly websites aren't websites. While the quaint notion persists that 'a website' is a discreet entity which can easily be moved from server to server, organisation to organisation, most 'websites' today are better described as interactive front-ends for sophisticated web content management systems. These web content management systems may be used to manage dozens or even hundreds of 'websites' in the same system, storing content and data in integrated tables at the back-end.
This makes it tricky to identify where one website ends and another begins (particularly when content, templates and functionality is shared). Moving a website between agencies isn't as simple as moving some HTML pages from one server to another (or reallocating a server to a new department) - it isn't even as easy as copying some data tables and files out of a content management system. There's enormous complexity involved in identifying what is shared (and so must be cloned) and ensuring that the website retains all the content and functionality required as it moves.
Changing IT systems can be enormously complex when an organisation is left unchanged, let alone when when teams are changing agencies or where agencies merge. In fact I've seen it take three or more years to bring people onto an email system or delink a website from a previous agency.
As government increasingly digitalises - and reflecting on the current government's goal to have all government services delivered online by 2017 - the cost, complexity and time involved to complete these MOG changes will only increase.
This risks crippling some areas of government or restricting the ability of the government of the day to adjust departments to meet their policy objectives - in other words allowing the (IT) tail to wag the (efficient and effective government) dog.
This isn't a far future issue either - I am aware of instances over the past five years where government policy has had to be modified to fit the limitations of agency IT systems - or where services have been delivered by agencies other than the ones responsible, or simply not delivered due to agency IT restrictions, costs or issues.
Note that this isn't an issue with agency IT teams. These groups are doing their best to meet government requirements within the resources they have, however they are trapped between the cost of maintaining ageing legacy systems - which cannot be switched off and they don't have the budget to substantially replace them - and keeping up with new technological developments, the increasing thirst for IT-enabled services and gadgets.
They're doing this in an environment where IT spending in government is flat or declining and agencies are attempting to save money around the edges, without being granted the capital amounts they need to invest in 'root and branch' efficiencies by rebuilding systems from the ground up.
So what needs to be done to rethink government IT to support the changing needs of government?
It needs to start with the recognition at political levels that without IT we would not have a functioning government. That IT is fundamental to enabling government to manage a nation as large and complex as Australia - our tax system, health system, social security and defence would all cease to function without the sophisticated IT systems we have in place.
Australia's Prime Minister is also Australia's Chief Technology Officer - almost every decision he makes has an impact on how the government designs, operates or modifies the IT systems that allow Australia to function as a nation.
While IT considerations shouldn't drive national decisions, they need to be considered and adequately resourced in order for the Australia government to achieve its potential, realise efficiencies and deliver the services it provides to citizens.
Beyond this realisation, the importance of IT needs to be top-of-mind for Secretaries, or their equivalents, and their 'C' level team. They need to be sufficiently IT-savvy to understand the consequences of decisions that affect IT systems and appreciate the cost and complexity of meeting the priorities of government.
Once IT's importance is clearly recognised at a political and public sector leadership level, government needs to be clear on what it requires from IT and CIOs need to be clear on the consequences and trade-offs in those decisions.
Government systems could be redesigned from the ground-up to make it easy to reorganise, merge and demerge departments - either using common IT platforms and services for staff (such as an APS-wide email system, standard web content management platform, single HR of financial systems), or by only selecting vendors whose systems allow easy and standard ways to export and import data - so that a person's email system can be rapidly and easily moved from one agency to another, or the HR information of two departments can be consolidated in a merger at low cost. User Interfaces should be largely standardised - so that email works the same way from any computer in any agency in government - and as much code as possible should be reused between agencies to minimise the customisation that results in even similar systems drifting apart over time.
The use of these approaches would significantly cut the cost of MOGs, as well as free up departmental IT to focus on improvements, rather than meeting the minimum requirements, a major efficiency saving over time.
Unfortunately I don't think we're, as yet, in a position for this type of significant rethink of whole of government IT to take place.
For the most part government still functions, is reasonably efficient and is managing to keep all the lights on (even if juggling the balls is getting progressively harder).
It took the complete collapse of the Queensland Health payroll project to get the government there to act to rethink their systems, and it is likely to take a similar collapse - of our Medicare, Centrelink or tax system - for similar rethinking to occur federally.
However I would not like to be a member of the government in power when (not if) this occurs.