Managing Information Technology

Week Four – Case Study:

ERP Implementation

1. Consider the role of a work group manager during an ERP implementation. The work group could be accounting, shipping and receiving, etc. It is unlikely that the work group manager would have influence over the entire ERP implementation. How could you as a work group manager use the strategic success factors and sub-factors to positively impact an ERP implementation?

ERP implementation may be one of the largest information technology transitions that a company can make. Some have likened it to a nervous system transplant (Johnson, 2002). Nearly every aspect of business is affected by the change in processes and even the flow of work. With such a large scale change each manager must do anything that is in their realm of responsibility to make the implementation as smooth as possible. Dowlatshahi (2005) looked through much of the research performed on ERP implementation prior to his paper and found that very little had been written to support companies and managers who are designing or implementing an ERP system. His answer to that lack of information was the “strategic success factors” (and sub-factors) as outlined in Strategic success factors in enterprise resource-planning design and implementation: a case study approach. Some of these can be used very successfully by the midlevel manager to make the implementation smooth.

The first factor of success is the Cost of ERP Implementation (S1). Midlevel managers should be able to evaluate the needs of their particular department as they pertain to the ERP system. Once the needs are identified, they need to be clearly and succinctly communicated to the software selection team. If each manager is able to give a reasonably accurate description of what processes they are involved with and determine any opportunities to streamline, the software team will be able to make an accurate requirements list to evaluate potential suppliers to. Selecting the right system is one way of reducing costs by eliminating the majority of customization needed. If the software is set up to be configured by the administrator it will significantly reduce the cost of changes that may otherwise need to be sourced to a consultant at a cost of up to 60 percent of implementation budget (Robey, 2002). Next, managers should accurately understand what data needs to be transferred to the new system. Data may be held and used in several legacy systems and may be up to 50 percent corrupt (Rettig, 2007). Getting this data translated and formatted in a usable form can be time consuming and costly. The last cost related sub-factor that a manager should carefully consider is how many users from the department need to access the ERP system. Since ERP cost is typically a function of the number of users, it is most cost effective to utilize as few licenses as is realistic. They should make sure not to skimp and entrench new bottlenecks, but it may be worth objectively considering if a change in work flow could eliminate the need for redundancy, which is one of the core rationalizations behind ERP concepts (Wailgum, 2008).

The next factor of successful implementation of ERP is (ROI) return on investment (S2). Since many ERP systems do not show a positive ROI for the first several years it is important that managers understand the objectives in terms of increased efficiency and reduced labor. Managers must set measurable goals for what they expect the implementation to achieve. To set goals it is imperative to understand the present state of the department before any changes are made. Goals should be evaluated periodically to identify any problems; are we meeting, beating or exceeding expectations? These metrics will prove invaluable when the accountants are trying to establish real ROI. The last portion of this factor is how to ensure cultural acceptance in the department. Managers must show how the new processes will benefit the company, the department and the employee. Weather it is reducing mistakes and rework or giving higher probability of added profit sharing potential, the personal connection is critical. If the department views the project as a “directive from the guys at the top who don’t really know what we do”, it is doomed to be less successful than if everyone can be convinced of the benefits.

The third factor is employee training (S3). Dowlatshahi (2005) points out that all ERP systems require the user to have a good grasp on basic computer skills. When those skills are lacking, basic training must be implemented before users ever look at the ERP environment. If low computer competency employees were set up to start using the system, many, if not all, would become discouraged and would harbor ill feelings about the new system. Many people get to know just the basics to get around and accomplish the necessary tasks, but when faced with an unfamiliar environment will start negative attitudes that will perpetuate throughout the department and the rest of the company (Kemp, 2004). The last sub-factor that affects the usability of the ERP system is how it will be trained. Many software providers have training that is built to help users become familiar with the environment and how each process works within the system (Dowlatshahi, 2005). When users are able to efficiently accomplish the tasks associated with their responsibility, success of implementation can be measured. Training is the key for bringing people up to efficient operation. It not only provides confidence in employees but if it is structured carefully it will have documentation for the processes that can serve as a reference in the future. The last aspect of training would be for the manager to ensure that a specialist is available upon roll-out to answer any questions users have once the ERP system is live.

The last factor of success is how well ERP is integrated into the company (S4). Based on the basic tenants of ERP; organizations will be the most successful when ERP is used in every area (Wailgum, 2008). Enterprise Resource Planning theory is based on the fact that any information in the company can be used to make better decisions, analyze data and remove redundancy of data entry. By ignoring any part of the company we lose the inherent benefits of ERP and thus reduce the measurable success.

In short managers have the responsibility to support the direction of the company. ERP implementation can be a high risk activity so it is critical that all midlevel managers support their employees with the expectation that it will be painful but in the end worth the challenges. By providing adequate training and post implementation support they can give confidence to their staff in an uncomfortable time of change. Next, managers need to provide clear vision about the goals of the implementation and give progress reports periodically that show the improvements. The final portion managers can improve roll-out is proper planning to reduce the overall costs in the long run and the headaches of finding problems during implementation. By focusing on these activities managers can have a dramatic impact on the successful implementation of an organization wide ERP system.

2. As you consider #1 above please be very specific. For example, sub-factor 2 of factor 2 discusses corporate culture. As a work group manager you probably will not impact the entire culture of a corporation. However, what are your responsibilities in your work group regarding culture and employee acceptance of the ERP? I hope you are already aware of the fact that telling people they must accept a new IS or that they have no choice but to use a new IS are seldom successful strategies.

Answered in the previous response.

References:

Dowlatshahi, S. (2005). Strategic success factors in enterprise resource-planning design and implementation: a case study approach. International Journal of Production Research, 43(18), 3745-3771.

Johnson, S. J. (2002). ERP: payoffs and pitfalls, Harvard Business School: working knowledge for business leaders. Retrieved July 6, 2008 from: http://hbswk.hbs.edu/archive/3141.html

Kemp, Sid (2004). Project management demystified. New York: McGraw Hill.

Rettig, C. (2007). The trouble with enterprise software, MIT Sloan Management Review. 49 (1) SMR259.

Robey, D., Ross, J.W., & Boudreau, M. (2002). Learning to implement enterprise systems: An exploratory study of the dialectics of change. Journal of Management Information Systems, 19(1), 17-46.

Wailgum, T. (2008). ABC: an introduction to ERP; getting started with enterprise resource planning, CIO. Retrieved July 6, 2008 from: http://www.cio.com/article/40323/ABC_An_Introduction_to_ERP/1#erp

Managing Information Technology

Week Three – Case Study:

Agile Software Development

1. This case study provides a framework for learning about different software development strategies. Consider a situation where you, as the manager of a workgroup, are asked to provide input to your IT department who is considering what software development strategy to adopt. As a customer of the IT department what are your objectives and concerns? What do you recommend and why?

As a customer of the IT department I have four objectives that describe what I want from any development. First, I want the end product to meet or exceed my stated needs. In the planning stages I have an idea of how something may be improved from a process or efficiency standpoint. This is identified as the need and then, if it seems feasible and is approved, it becomes a project. If the software changes or improvements do not meet my needs or make the process more difficult, my needs were not met. However, if IT was able to integrate more of the process into the software and reduce the time or improve the quality, my needs have been surpassed.

Secondly, I need open lines of communication between the stakeholders and myself. If the project is behind schedule or some parameters need to be changed I want to know what is happening. Not just because I am a micro-manager but because I may be able to solve some of the issues if they were brought to light. For example the programmers are running into roadblock after roadblock trying to accommodate a request from my department, but I know that the issue they are having was only a “it would be nice if…” type of request. If that were the case I could save everyone and the company a lot of heartache and remove that as a requirement.

Next, I want flexibility. As the project progresses other requirements may come to light so I need the flexibility to bring this new information to the IT folks without fear of retribution for not having perfect knowledge at the inception of the project. “One of the biggest problems with waterfall is that it assumes that all project requirements can be accurately gathered at the beginning of the project” (Danube 2004). A perfect understanding at the front of the project is obviously impossible, or at least improbable.

Once the project is near completion I want support for pre-implementation training, a smooth transition process including implementation and support after it is up and running. Training and support are critical to the successful transition. Knowing what to expect beforehand and knowledgeable people to answer questions throughout the process will improve speed, give credibility to IT department and create a good environment for future change.

My recommendation to the IT department is to utilize ‘Agile’ software development strategies. This process has been shown to allow for requirement modification much smoother than the traditional approach. Features are created independently and changed often, which allows for easier modifications if new requirements are brought to light late in the project (Bose 2006). This quickly changing code and testing of the process requires that communication be open and often. Any small change will require several people to relate and approve the modifications including me, the customer. This open communication with users should have a side effect of giving the software additional features that were not originally asked for (Serena 2007). With a good process for training and support ‘Agile’ can accomplish the implementation smoothly because the users have actually been part of the development process which will reduce the training needed to bring everyone up to speed.

For the business as a whole, ‘Agile’ is reported to have many advantages that would indirectly benefit my department. According to Frye (2008), 66% of companies utilizing ‘Agile’ have seen an improved time to market; 62% have seen higher productivity; 45% have reduce defects in final products; 34% have lowered development costs. These benefits can be compared to the traditional method that has less than 30% success rate (Serena 2007). That means that the company will see the benefits of the new software sooner, which translates into more money saved or higher quality work implemented earlier. The costs for development are down which may be small in comparison to the reduced cost associated with fixing bugs in the final product. Kemp (2004) states that a bug may cost (in time and money) 100 times more to fix after release, than during development. With these improvements the company and my department will be able to utilize the savings for other changes from additional efficiency gains to pay increases.

2. Are there conditions that favor one software development strategy over another? How might this impact your thoughts and analysis of #1 above.

There are several outside forces that may make it difficult to implement ‘Agile’ software development. ‘Agile’ is by nature less formal than the traditional software development ‘Waterfall’ method. In some organizations the entire business strategy is built upon the formal, command and control style, process based culture. Making a switch to the less formal, collaboration based ‘Agile’ method can be painful or in some cases a cause for corporate collapse (Bose 2006).

Another potentially decision changing condition is weather the IT department working on this development is located in the same place as the customer. If IT is located half a world away in severely different time zones, communications become a huge obstacle for ‘Agile’. The same survey that reported huge benefits using ‘Agile’ also show that communication is the largest problem faced by 52% of companies using it. Having stakeholders in different locations only exacerbates the communication problem (Frye 2008).

The third condition that may give pause to making the change to ‘Agile’ is if software documentation is critical within the organization. The second largest problem faced by ‘Agile’ development is that "the reality is, no matter how much you try, documentation is never up to date" (Frye 2008). This could be a huge problem if turnover is a problem within the company. Most of the knowledge or lessons learned in ‘Agile’ is walking around in developers heads. If that developer were to leave or transferred it would be difficult and time consuming to glean and transfer that knowledge to their replacement (Bose 2006).

Looking at these problems associated with ‘Agile’ should cause pause if any one of these are present within the organization. Consider methods that may be used to overcome these problems before making the switch to ‘Agile’ strategy. However, if all of these circumstances exist, the company should re-evaluate if the benefits are worth the potential problems of switching. It is likely to be more beneficial to make small changes in the traditional method that would make improvements in the areas were improvement is needed. This may result in some kind of hybrid version of software development that fits perfectly into the organization.

References:

Bose, Indranil (2006). Jharna software: the move to agile methods, Asia Case Research Center. Retrieved from Harvard Business School, HKU613P2.

Danube (2004). An introduction to agile software development. Danube Technologies, Inc. Retrieved July 4, 2008 from: http://www.danube.com/docs/Intro_to_Agile.pdf

Frye, Colleen (2008). Agile practitioners face challenges, but see process improvements. Software Quality News. Retrieved July 5, 2008 from: http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1318820,00.html#

Kemp, Sid (2004). Project management demystified. New York: McGraw Hill.

Serena (2007). An introduction to agile software development. Serena Software, Inc. Retrieved July 4, 2008 form: http://www.serena.com/docs/repository/solutions/intro-to-agile-devel.pdf