The late and over-budget Parliamentary Expense Management System is turning parts of the public sector against agile and iterative methodologies that featured heavily in the project delivery.
The criticisms come from the Independent Parliamentary Expenses Authority (IPEA), an auditor that has a foundational need for PEMS but, like parliamentarians, has been left waiting for a functional system to be delivered.
IPEA held “high hopes” for the SAP-based PEMS – that it would be a purpose-built, transformative system that “provided opportunities for efficiencies and allowed IPEA to add value to [its] support of clients with a modern, agile methodology”.
Its assessment of what’s been delivered so far is savage.
“The outcome to date is a system that has digitised some manual processes,” it said in a submission [pdf] to an inquiry examining a range of IT projects in the federal government.
A concern for development teams working with the government is that PEMS has proven not to be a particularly good advertisement for agile delivery and iterative development.
IPEA simply had different expectations of what agile meant to the project, particularly the extent to which the system or new features would be usable after each sprint or release.
“Although a generalisation, there appear to be different cultural norms and expectations between clients and IT project managers as to the basis for release of a product,” IPEA noted.
“For example, IPEA’s expectation was that a fully functional and easy to use system would be the basis for determining PEMS ‘completion’; however, based on methodologies such as ‘sprint’, ‘agile’, ‘waterfall’ etc., it seems that delivery of a technical solution, with expectations of future releases/upgrades on an iterative basis is an accepted industry norm.
“This iterative approach has advantages such as the ability to release a product early and then, responding to customer feedback, hone a product’s features and build upon a base.
“It does, however, assume that the base is stable, that full functionality is available, there are established channels to receive/incorporate feedback and commitments to ongoing resources and upgrades.”
IPEA said that agile also needed “a certain degree of tolerance for iteration and reduced or undelivered functionality by the users of the system, which we suggest is rarely the case for a government-managed system.”
“Problems arise where these assumptions are not in place,” the authority said.
“With regard to the PEMS experience, an iterative approach was not optimal for the client group where reputational risks arising from inaccurate data and slow service are high.”
Despite not leading the project, PEMS had damaged IPEA’s standing among parliamentarians and their staff.
“While not responsible for PEMS, as evidenced by IPEA’s annual client satisfaction survey, IPEA’s
reputation as a professional service provider to this client group was impacted and has required investment by IPEA to address,” the authority said.
The inquiry that IPEA made its submission to is trying to find lessons from IT project delivery – good and bad – that can be shared more broadly across government.
While it has heard some good individual case studies of project delivery, it’s been unclear whether other departments and agencies – particularly the largest ones with the biggest technology budgets – can profit from any lessons learned, as they may not be cross-applicable.
IPEA’s experience of agile and iterative methodologies has potential repercussions for other government programs, at least in setting expectations for what the methodologies can deliver at regular cadence.