Understanding DSP Software Development

When government agencies introduce policy or regulatory changes to tax, accounting, payroll, invoicing, superannuation or business registration processes, they often underestimate the impacts on Digital Service Providers (DSPs) who are ultimately responsible for delivering these changes.

What may seem like a simple change or implementation for the government can amount to a multi-million dollar investment by the software industry. With the government increasingly relying on DSPs to deliver changes in natural business systems, they need to understand the challenges and costs from an industry perspective.

In this article, we delve into the costs and complexities within the DSP software development process, highlighting the importance of early and ongoing engagement with the software industry.

Please note that this article provides a simplified overview of the software development process.

Software Development Process

DSPs typically plan and budget their development roadmaps up to four years in advance. Development roadmaps cover new products and features alongside regular compliance changes, such as annual tax changes and minimum wage reviews.

When compliance changes arise, DSPs will need to reprioritise their roadmaps. While these roadmaps are designed with a level of flexibility, compliance changes outside of regular development cycles or complex changes are disruptive and will delay a DSP's ability to deliver new products and features to customers.

Planning

DSPs usually prioritise compliance changes over existing work in their development roadmaps to support customers with meeting their obligations.

DSPs can appropriately plan and allocate the required resources when compliance changes are known well in advance. Ideally, government agencies will share their roadmaps with DSPs to better inform these development plans.

The main challenges that DSPs may face as they plan and prioritise compliance changes include:

Understanding the legislation or regulations: DSPs will rely on subject matter experts (internally or externally) to interpret the legislation or regulations and provide instructions for developers to implement. DSPs may also work with the responsible government agency to clarify ambiguities. Misinterpretations during this stage can lead to costly errors.
Conflicting compliance work: DSPs implement compliance changes driven by different government agencies. For those operating in multiple countries, managing these different compliance changes presents further challenges.
Complexity: Compliance changes that do not align with existing business processes or patterns are more complex and require DSPs to invest more resources.
Budget cycles: DSPs will have different budget cycles based on the countries they operate in and where they are headquartered. When compliance changes do not align with a DSP's budget cycle, it can be complicated to allocate resources.

Development

Delays and changes during the legislative process can affect software development. As a result, DSPs often wait for policy to be enacted before starting the bulk of their development work.

While the end costs depend on many factors during development, such as complexity and implementation timeframes, DSPANZ uses the following approximation for development costs:

A single on-shore development team costs on average $100,000 per fortnight in wages and associated costs. Multiple teams may be required for multiply fortnights during development.

Several challenges can impact the development process and increase costs, including:

Skilled developers: DSPs require experienced and knowledgeable developers (who are in high demand) and often compete with each other when hiring. If DSPs must hire or utilise developers from different teams, this can cause development delays.
Relying on legislative and technical information: DSPs rely on timely legislative and/or technical information from the government (where applicable) on compliance changes to support their development. When this information is not available or it is delayed, DSPs need to invest more in development and testing.
Product lifecycles: DSP products will be in different stages of their lifecycles when compliance changes arise. The older the product, the more complex and expensive it can be to make updates.
Delays: When the legislative or consultation process is delayed, DSPs will place development teams on standby until the government provides an update. If development teams are not utilised for a short period, they will be redeployed to other projects and may not be available once development can resume.

Testing and Release

The policy commencement date or government agency start dates often serve as the go-live date for software products and services. DSPs will treat these dates as deadlines to ensure their customers can meet their obligations.

DSPs must coordinate the release process to ensure they are prepared internally and can then support customers with changes.

The main challenges that DSPs face during testing and release include:

Testing issues: Delays or problems during the testing phase can substantially impact the release timeframe.
Hosting environment: A DSP's hosting environment will determine how compliance changes are released to customers. Different deployment methods are required for cloud-based solutions, applications, and on-premise software, each with its own challenges.
Customer education: While the government may run education campaigns on compliance changes, DSPs are ultimately responsible for training and educating their customers. DSPs will develop training materials and documentation to support customers.
Support and maintenance: DSPs will provide ongoing support and address any unforeseen issues after releasing changes. DSPs may be required to make changes based on customer feedback.

Ongoing Challenges

Outside of the challenges above, DSPs face several ongoing challenges in the software development process that are not necessarily unique to specific phases, including:

Charging for compliance costs: Customers expect compliant software, but DSPs cannot directly charge them more for new compliance features. DSPs must either absorb these costs or review their licensing fees to account for increased operating costs.
Increased hosting costs: Compliance changes that require DSPs to collect and host more data will increase their data hosting costs. Again, DSPs can either absorb these costs or pass them on to customers through increased fees.
Early consultation: When government agencies know about compliance changes impacting DSPs and their customers, they should engage with DSPs as early as possible. Early and ongoing engagement during this process allows DSPs to effectively plan and allocate resources and reduce the costs of complying with changes.
Implementation timeframes: Government agencies should provide DSPs with sufficient time (approximately 12 months, depending on the change required) between the policy announcement and its commencement to implement the necessary software changes. Short timeframes and complex changes significantly increase costs.

Key Takeaways

Early consultation and engagement between government agencies and DSPs can mitigate many of the disruptions and costs during software development that are outlined in this article.

When government agencies better understand these challenges and costs for DSPs and work in partnership within the software industry, they enable more efficient and effective digital ecosystems.