Project Evaluation Report: GovERP Implementation Challenges

GovERP failed to engage with stakeholders well because the Shared Services Sub-Committee (SSSC) was mainly concerned with power rather than collaboration. The group did not involve enough people from the smaller agencies. Therefore, a lot of stakeholders felt overlooked and excluded. People stopped believing in the project and pulled away from it. Mitchell et al. (1997) explain in their stakeholder salience theory that important stakeholders have power, legitimacy and urgency. For this reason, several agencies resisted the ERP system since they believed it wasn’t right for them. Reaching decisions was a very slow process for the SSSC. The process became apparent as inefficient when delays occurred in 2021. Due to the engagement model, GovERP struggled to unite all parties, which is needed for government IT projects.

GovERP experienced serious problems with its stakeholders, as only a small group made the decisions in the company. Local agencies were often overlooked, which made them feel excluded. For this reason, they tried to resist the standard systems (Kerzner 2017). Also, the SSSC’s long approval delays made people doubt the project’s credibility. Many stakeholders started to question if the project could succeed. In Rowley’s opinion (1997), stakeholder networks in major projects should be open and connected, not restricted and narrow. GovERP did not follow the advice, which frustrated many agencies. The project did not have trust or flexibility, which are both important for success.

GovERP should set up a stakeholder advisory panel of individuals from different agencies. The panel needs to team up with the project team and assist in outlining the ERP system from the beginning. Having agencies involved in planning makes them more likely to encourage the project and less likely to stand against it. This approach agrees with what Mitchell et al. (1997) explain in their stakeholder salience model, which points out that important and pressing voices must be listened to. The panel can design requirements that benefit a variety of agencies, not only the biggest ones.

Another thing to do is to hold meetings for all stakeholders once a month to allow them to give input and get updates. This agrees with Kerzner (2017), who states that projects run smoother when communication is always open and continuous. This approach will allow the GovERP team to change how they communicate and get involved with each group of stakeholders. With these changes, GovERP can be more responsive and open to everyone. It will create trust and smooth the process of using a single ERP system by government offices (Rowley 1997).

The company failed at change management because the move to GovERP was poorly organized. The change in authority from the Department of Finance to Services Australia caused people to be confused and made leadership less effective. The project was delayed, and it became unclear who was responsible for what duty (Office of Government Commerce 2007). The Gateway Review, the process meant to ensure progress, started to slow down the project. In 2022, delays caused by the Shared Services Sub-Committee (SSSC) blocked actions that needed to be done quickly. The first part of Lewin’s (1947) model is unfreezing, which prepares individuals for change. GovERP skipped this part. It brought in changes but did not explain the reasons to the agencies. So, agencies felt isolated and did not want to contribute to the ERP project.

Diagram 1 - Lewin’s Model of Change (Hussain et al. 2018)

It was also an issue that employees were unprepared for the changes. According to Alzahrani (2019), for change to succeed in public organizations, people must be emotionally and mentally ready. Employees should feel secure and realize the benefits of change before they will back it. GovERP did not provide clear information, emotional support or training. It left many staff feeling ignored, which increased their resistance. The change process in Lewin’s diagram (attached) strongly focuses on employee involvement (Hussain et al. 2018). If it’s not there, implementation and leadership will not work well. So, many employees felt excluded, which caused confusion and rejection of the changes.

Their mistakes mainly consisted of two main points. First, the stakeholders were not given enough support or preparation from GovERP. The agencies were not mentally prepared for changes, and they felt unmotivated. Lewin (1947) points out that “unfreezing” is necessary for people to give up their old ways of doing things. GovERP did not follow through with this, which caused resistance. Second, the Gateway Review Process gave more attention to rules and less flexibility. According to Turner (2014), review systems for public projects should be able to respond to new requirements. Reviews were more of a problem than a help because GovERP failed to address them.

To improve future change efforts, GovERP should have set up a change ambassador network. It requires choosing people from various agencies who back the change and communicate it to their teams. They would communicate feedback, guide concerns and help with training. It supports Lewin’s last step, which is refreezing, where the change becomes routine. It is evident from the diagram that for implementation to happen, leaders must involve their employees. If employees join early, they tend to agree with the changes and help achieve the project goals. Alzahrani (2019) also state that trust, understanding and commitment among employees are very important. They could help create these feelings by connecting teams and leaders.

Using biweekly dashboards is the best way for Gateway Reviews to follow the progress and issues in GovERP. As a result, processes would be more flexible and less filled with red tape. The diagram points out that it takes both sharing knowledge and leading others to handle changes well. Giving leaders new updates and clear insights into the data would allow them to see risks early and decide quickly. According to Turner (2014), real-time review tools are more helpful when managing complex projects like GovERP. In addition, reviews should gather feedback from client agencies and those in leadership. As a result, future projects will be more easily adapted and transparent and will include a broader range of people.

Difficulties encountered in public sector ERP projects like GovERP are not the same as those found in private sector ERP solutions. Policies can change at any time, which makes the industry vulnerable. For example, emergency cuts to the budget can unexpectedly change the scope and schedule of projects and cause resources to be shifted. Due to the political nature of the public sector, changes in government can disrupt ongoing projects (Tolefree 2020).

A further serious risk is when different agencies have conflicts. Managing public sector projects usually means dealing with other departments' objectives and priorities. If coordination is poor, these differences may cause groups to work separately and hinder their progress (Hyatt and Gruenglas 2023). Differences in vision among agencies may cause some tasks to be done twice and wasting valuable resources.

Vendor lock-in poses a considerable risk as well. Having all the needs met by just one outside supplier may restrict how much the project can adapt. If the services offered by the vendor are not satisfactory or if better options appear, it can be expensive and challenging to switch. Cantarelli et al. (2010) studied how the lock-in phenomenon can impact the success of large-scale transportation infrastructure projects. The study finds that when commitments are made early and costs keep rising, changing contractors or modifying the project’s plan becomes harder, which may cause extra costs.

The problems seen in GovERP highlight the need for active risk management. A risk dashboard that is updated regularly helps spot threats fast and deal with them quickly. With these dashboards, project managers can regularly watch for risks and respond by making appropriate changes to the plan. GovERP mostly reacted to risks after they became problems. This approach did not consider that policy changes or vendor issues could happen. Not having a clear plan for possible problems puts the project at risk of disruptions. There were not enough efforts to resolve conflicts between agencies, leading to coordination problems and uneven implementation. Because departments did not work together, progress was slow, and accountability was reduced.

Also, the project did not consider the effects of public attention and budget issues enough. When it could not change with the environment, GovERP began to lose trust from stakeholders and its reasons for spending money. If the risk management process had been more active and linked, these weaknesses might have been noticed sooner, giving time to address them and possibly save the project from failure.

According to Agile methodology, the main focus is flexibility, stakeholder cooperation, and development in stages. Since environments for GovERP and similar projects change over time, Agile allows teams to respond to changes rapidly. Regularly checking in with stakeholders allows the project to stay focused on their needs and might help reduce resistance (Beck et al. 2001). Agile relies on disciplined teams and solid management systems to control changes and keep everyone responsible. Following regulations and keeping detailed records is vital in government agencies, and Agile’s flexible approach can be challenging. People in the organization must be ready to change and strive to improve for successful implementation.

The Waterfall approach is preferred for projects where requirements are set and changes are not expected to be many (Kirvan 2022). Using a structured process, the project team can provide complete documentation and clear stages, which helps follow the rules and manage the budget. Still, since Waterfall is not very flexible, it may cause issues in GovERP, where the requirements can change because of political or stakeholder factors. If feedback is not given immediately and changes are restricted, it can cause problems and require expensive corrections. As the methodology is rigid, it struggles to handle the changing nature of public sector projects.

As they used the Waterfall approach, GovERP could not handle the changing requirements and the project’s complexity. The project could not adjust quickly to changes, which caused delays and increased costs. Alternatively, the iterative approach in Agile might have given them the flexibility they required to handle changing priorities and stakeholder input. Agile encourages teams to remain engaged and develop gradually, which fits the requirements of projects like GovERP. Nevertheless, for it to work well, major changes would be required in how a company is governed and how teams operate to match the standards set by the public sector.

Using Agile practices could have enabled GovERP to react better to the changing needs and goals within the agencies. Agile encourages the team to deliver small portions of the system often instead of holding the full product until the project is finished. A report shows how the department used Agile to develop a vital new software system by leaving behind traditional development methods (Brown et al. 2018). The development could be done in stages, issues were caught early, and stakeholders were more engaged, which made the project run more smoothly and effectively.

Stakeholders could have found technical or operational problems sooner if GovERP used frequent, short delivery cycles. If end-users had been included more in the project, the gap between central decision-makers and those in the field would have been smaller. It would also be essential to define who is doing what on the team. As there was often confusion about who was responsible in the public sector, it was important for every Agile team member to know their role, which could have helped deliver results more reliably and improve communication among departments.

Agile by itself may not ensure success in highly regulated government areas, so including structured oversight and formal governance is needed. If GovERP had regularly reviewed and checked for compliance, the approach could have met its reporting and accountability standards. Participating in stakeholder workshops at the end of each sprint made the agencies feel more connected and engaged with what was being achieved. They help collect feedback and show that people’s concerns are being noticed and worked on. As GovERP is a multi-agency system, continuing to communicate builds trust that was absent during the project.

Bibliography

Alzahrani MS (2019) ‘The Impact of Emotional Intelligence on Readiness for Organizational Change: A Case Study on a Government Authority in Saudi Arabia’, American Journal of Industrial and Business Management, 09(09):1880–1889, doi:https://doi.org/10.4236/ajibm.2019.99121.

Beck K, Beedle M, van Bennekum A, Cockburn A, Cunningham W, Fowler M, Grenning J, Highsmith J, Hunt A, Jeffries R, Kern J, Marick B, Martin RC, Mellor S, Schwaber K, Sutherland J and Thomas D (2001) Manifesto for agile software development, Agile Manifesto, https://agilemanifesto.org/.

Brown N, Davenport J, Gates L and Marshall-Keim T (2018) FedCLASS: A Case Study of Agile and Lean Practices in the Federal Government, https://insights.sei.cmu.edu/documents/1948/2018_003_001_527599.pdf.

Cantarelli CC, Flyvbjerg B, van Wee B and Molin EJE (2010) ‘Lock-in and its influence on the project performance of large-scale transportation infrastructure projects: investigating the way in which lock-in can emerge and affect cost overruns’, Environment and Planning B: Planning and Design, 37(5):792–807, doi:https://doi.org/10.1068/b36017.

Hussain ST, Lei S, Akram T, Haider MJ, Hussain SH and Ali M (2018) ‘Kurt Lewin’s Change model: a Critical Review of the Role of Leadership and Employee Involvement in Organizational Change’, Journal of Innovation & Knowledge, 3(3):123–127, doi:https://doi.org/10.1016/j.jik.2016.07.002.

Hyatt J and Gruenglas J (2023) ‘Ethical considerations in organizational conflict’, IntechOpen eBooks, doi:https://doi.org/10.5772/intechopen.1002645.

Kerzner H (2017) Project management: a Systems Approach to planning, scheduling, and Controlling, 12th edn, John Wiley & Sons, Inc.

Kirvan P (2022) What is waterfall model? - Definition from WhatIs.com, SearchSoftwareQuality, https://www.techtarget.com/searchsoftwarequality/definition/waterfall-model.

Lewin K (1947) ‘Frontiers in Group dynamics: Concept, Method and Reality in Social science; Social Equilibria and Social Change’, Human Relations, 1(1):5–41, doi:https://doi.org/10.1177/001872674700100103.

Mitchell RK, Agle BR and Wood DJ (1997) ‘Toward a Theory of Stakeholder Identification and salience: Defining the Principle of Who and What Really Counts’, The Academy of Management Review, 22(4):853–886, doi:https://doi.org/10.2307/259247.

Office Of Government Commerce (2007) Managing Successful Programmes, Tso - the Stationary Office, London.

Rowley TJ (1997) ‘Moving beyond Dyadic Ties: A Network Theory of Stakeholder Influences’, The Academy of Management Review, 22(4):887, doi:https://doi.org/10.2307/259248.

Tolefree TK (2020) ‘Enterprise Resource Planning Implementation in Higher Education: Cost Containment Strategies’, SSRN Electronic Journal.

Turner JR (2014) The Handbook of project-based Management : Leading Strategic Change in Organizations, Mcgraw-Hill Education, New York.