Managing Information Technology

References: (Annotated Bibliography)

Adams, E. Biggest Information Security Mistakes that Organizations Make: and How to Avoid Making Them, ISSA. Retrieved June 12, 2008 from: http://www.issa.org/Downloads/Whitepapers/Biggest-Information-Security-Mistakes_Security-Innovation.pdf

This article discusses the importance of working to improve software development to prevent some of the application based weakness. The author states that by using commonly used techniques used in many other professions, software developers could ensure their products are fail proof as possible. He also states that IT professionals place too much faith in networks, new software, people, get their attention diverted to the latest problem and they believe that ‘good’ software is too expensive.

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

This case study describes the advent of software development in India. It specifically follows Jharna (translated ‘Waterfall’) Software from inception to where they were forced to make a decision about what method of project management they would use to develop their software. They began with the ‘Waterfall’ method and felt customer pressure to change to a more Agile approach. There were many reasons to support the change as well as rational how it may be detrimental to make the change. Some of these reasons include having to change the culture and loosing documentation and formalization of the design process, all of which were seen as a foundation in the success of Jharna Software.

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

This case was a marketing document written to extol the benefits of agile software development as opposed to the traditional ‘waterfall’ method. Danube presented a very one sided approach to software development but failed to answer some critical questions from ‘Agile’ critics. How do they document software? Where is development happening? How does Danube ensure they are communicating clearly the changes needed and the processes for recording changes and modifications to the requirement planning stages?

de la Brassinne, P (2002). Web Application Security for managers. SANS Institute retrieved June 14, 2008 from: http://www.sans.org/reading_room/whitepapers/application/27.php

This article talks about the possible ways web based applications may be put in jeopardy while staying within the allowances of the Firewall and SSL. In addition to showing how some programs (or parts of programs) may be exploited, he gives ways to mitigate possible attacks with simple solutions. This paper points out the importance of having quality software from development through testing and implementation. Software is the most common area of weakness for security.

DeLone, W.H., and McLean, E.R. (2003). The DeLone and McLean model of information systems success: A ten-year update. Journal of Management Information Systems, 19(4), 9-30.

This paper is an update from their previous paper in which they tried to find common ground between all the different studies that had been done prior to 1983. They tried to look at all the works and find commonalities that could be used to compare the results. This work was a milestone in effectiveness measuring for IS. DeLone and McLean were pioneers in the field of making research usable as means to understanding IS and its impact of success of organizations and the people who use them.

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.

This paper is focused on the implementation and strategy needed to design or select an ERP system. Dowlatshahi did extensive research on other research that had been published and saw a gap in content. An effort was made to clearly point out the important aspects of the implementation process that are most affective in creating a successful product. He based his study on other research papers and two case studies that demonstrate his points well. One of the case studies was focused on a service based governmental agency and the other was a new manufacturing facility. The author makes four ‘factors’ and breaks them into further detail with the ‘subfactors’.

Feurer, R., Chaharbaghi, K., Weber, M., & Wargin, J. (2000). Aligning strategies, processes, and IT: A case study. Information Systems Management, 17(1), 23-34.

This article discusses the use of process implementation at HP on a “greenfield” operation for another company. They were able to utilize the differences in perspective from many different cross-functional groups within the organization. By using the overall strategy of the company and evaluating all the needs, they were able to save money by utilizing existing technology for most of the operations but developing new software in situations where the strategic gains would be worth the expense. They were also able to evaluate where integration could happen using outside consultants and contractors to do non “core” activities.

FreeBSD.com, Firewall Concepts. Retrieved June 18, 2008 from: http://www.freebsd.org/doc/en/books/handbook/firewalls-concepts.html

This short article gives the general operating procedure for firewalls. It compares and contrasts the different types of firewall rulesets: exclusive and inclusive. Exclusive rules allow all traffic through as long as it does not meet the criteria. Inclusive only allows traffic through that matches the criteria. The third kind mentioned is stateful rulesets, which has some potential errors of Denial of Service. It is possible to use a smattering of each type of ruleset to get the desired security.

Frye, C. (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#

This is a news article talking about a survey of improvements in the face of challenges that plague ‘Agile’ software development. This article did a great job of showing how improvements were classified and where the drawbacks were still lurking. Many articles only show one side of the story so it is important to gather the facts from all sides. One of the points that could have been included is how each customer classified the feedback. For example one of the questions referred to meeting expectations with the ‘Agile’ method versus traditional methodologies. Did the customer give an off the cuff answer or did they actually compare data? Sometimes, if data is not used, “the grass is always greener” syndrome prevails.

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

This interview with post graduate student Mark Cotteleer, describes the research that he has been working on that finds the best ways to implement ERP systems. System integration is never easy or painless but can be successful if done properly. He pointed to many companies that look at their implementation as successful despite the failures of some high profile failures at companies such as Nike, Hersey’s and others. He gives some suggestions on how to ensure success with step by step simplicity.

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

This book is an excellent overview of Project Management. It is very self explanatory and has many useful templates and strategies. It is not meant to be an all inclusive step by step guide, but more of a general understanding of what project management does and its’ generally accepted rules. It is a great first look at Project Management with many great side notes for a quick understanding.

Mcaffe, A. F. (2006a). Pharmacy Service Improvement at CVS (A) Harvard Business School. 9-606-015.

This paper describes how one group of executives set out to fix some of the process problems that were facing CVS Pharmacy. Customers were unhappy and many ways to improve the process of filling prescriptions were identified. The order was changed to a more logical one in which customers would be able to provide feedback while still in the pharmacy. Pharmacists were very concerned about safety and quality so those were place on the forefront of each person’s mind. Although many processes were rearranged the IS did not get modified to a point that was worth mentioning.

Mcaffe, A. F. (2006b). Pharmacy service improvement at CVS (B). Harvard Business School. 9-606-029.

This article is a follow-up on the previous article by the same name. All processes were improved and set up to provide superior customer service. Reduced wait times and better communication about problems with prescriptions before customers were ready to pick up were two of the focus areas. Implementation was brought out slowly to reduce down time and get specialists at implementing the system.

Nickols, F. (2006). Change management: a primer. Distance Consulting. Retrieved June 24, 2008 from: http://home.att.net/~nickols/change.htm

This article gives the basics for change management. It gives definitions for what is understood as “change management” from many perspectives. The purpose of this paper was to provide a broad overview of the concept of “change management.” It was written primarily for people who are coming to grips with change management problems for the first time and for more experienced people who wish to reflect upon their experience in a structured way.

Realsoftwaredevelopment.com (2007). One minute software development manager. Real World Software Development. Retrieved July 1, 2008 form: http://www.realsoftwaredevelopment.com/2007/08/the-one-minute-.html

This article gives a great overview of how to be a good software development manager. It gives practical ideas on how to act, what to say, what to do, when to do it and what not to do in a concise format. This would be a great source for anyone who is considering leading any kind of team. Some of the best insight is to provide clear vision for all team members so that everyone can be successful and be working to the same goals.

Rehman and Paul (2003) The Linux Development Platform: Configuring, Using, and Maintaining a Complete Programming Environment. Pearson Education Retrieved June 30, 2008 from http://www.faqs.org/docs/ldev/0130091154_4.htm

The first chapter of this online book describes the high level view of software development. It starts out with collecting the requirements and establishing if it is an acceptable business model. Then it moves into defining all the attributes from how different parts will communicate to rights and proprieties. Once these are established coding and minor testing are started. People other than the coders do the testing to show any weakness and if there are any identified they are fixed. The last phase is product support which can include adding features or fixing bugs that were found by customers.

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

This article takes a fairly negative approach to the success of ERP systems. The author points out many of the negative aspects of ERP and where most problems come from. It is interesting to note that all the problems do not stem from the software but from customizations and data problems as they travel through the system. Some future advantages include Service Oriented Architecture (SOA) which the author has very little expectation that it will make improvements significant enough to solve the problems associated with ERP.

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.

This paper is a comparison of the experience of implementing an enterprise resource management (ERP) system in 13 companies. It discusses some of the difficulties had and how they were overcome by some of the companies that experienced success in those areas. It also showed what was accomplished without much trouble where divers training methods were used to ensure smooth integration. All companies showed positive and negative effects after the implementations but were still trying to understand what the long term effects would be and how long it would take to become fully integrated.

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

This paper was a marketing document produced by Serena to show the advantages of ‘Agile’ methods they use. It is a one sided document that aims to prove why the ‘Agile’ methods are superior to any others. Serena touts improvements in time and accuracy as the main benefits of their development process. Some of the topics that were not discussed are how they document the software to ensure good post release support to their customers and how Serena can communicate clearly with customers to ensure proper requirements are transmitted.

Straw, E (2008). Measuring Information System’s Effectiveness. Retrieved July 11, 2008 from http://converge.corban.edu/file.php/1764/Measuring_IS_Effectivness.pdf

This paper looks at the problem associated with Information System Effectiveness measurement. Straw effectively uses user satisfaction as the metric to identify effectiveness. The tool being used is called UPISE (User Perceived Information System Effectiveness) which is based on the McLean and DeLeone model. The UPISE model looks at Net Benefits, System Quality, Information Quality and Service Quality from the perspective of the users and uses their responses to determine IS’s effectiveness.

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

This article answers many questions about ERP systems that range from “what is ERP?” to “why do so many implementations fail?” It seems to give a fair approach to both sides of the argument including the ERP developer and the end users. Some of the problems associated with ERP stem from individualization of off the shelf products. Other problems mentioned are associated with people having to do work that they are not prepared for; suddenly the sales rep must answer all the questions for customers and trust the ‘system’.

Young PhD, R (2002). Recommended requirements gathering practices. Crosstalk: journal of defense software engineering. Retrieved July 1, 2008 from: http://www.stsc.hill.af.mil/crosstalk/2002/04/young.html

This article was written by a IT professional at Northrop Grumman Information Technology and give insight into how to collect information to create good specifications for what a software application should provide to its customers. There are many examples of how to gather the requirements including some emotion based questioning and other non-traditional approaches. It also provides good technical knowledge on what to include and exclude while developing requirements.

Managing Information Technology

Week Five – Case Study:

AM Equipment ERP

Create your own case study.

Identify an IS that you currently use and determine its level of success. You should incorporate the results of this weeks survey and the DeLone and McLean IS success model in your methods. Include others individuals in your evaluation process as necessary.

Report your findings in a 3 to 5 page paper. Please thoroughly describe the IS being evaluated, your evaluation technique (including participants), the results, and the problems or limitations of your evaluation.

The IS used for this case study is an Enterprise Resource Planning (ERP) software designed by RLA, named Assist 2K7. AM Equipment implemented this system January 1, 2008 to replace an older custom inventory control system that was replete with bugs and inaccurate information. The old system was not usable for tracking inventory and had to be corrected each month after a full physical inventory. The only useful information available was vendor contacts. Prices, inventory counts, customer information and order history were less than 2% accurate, so it was easy to gain benefits from the new ERP implementation. Assist 2k7 currently has been rolled out into the warehouse, shipping, customer information, order acceptance, purchasing and payment processing.

This paper will evaluate how Assist 2k7 has impacted net benefits. The implementation is in the early stages, so some of the analysis is based on assumptions. Service quality discussion is based on several conversations with the VP/Controller, Picket. Information quality analysis will be a comparison of system use from old to new. System quality will be based on personal experience and the observed interaction between other users and the software. A list of questions used in the evaluation is shown in Appendix A.

The first success marker of an IS is service quality. Since AM Equipment does not have an IT staff, service comes from the software developer or an external network administrator. Service quality is one of the reasons the company left the legacy system for a new IS. The legacy software was custom coded from scratch with very incomplete and non-specific requirements. Many “extras” were added that did not solve problems but typically created them. With all these “bugs” in the code the information was erroneous and the developer had many problems trying to resolve them. Numerous patches and corrections were made typically weeks after the problem was found, but to no avail. With these experiences in mind the company looked for a developer who was capable of giving support during business hours as well as weekends. RLA has been very responsive and has worked well with the network administrators when necessary. No matter what the issue the company (or employee) has, they have been happy to either make modifications or show how others have tackled the same problem. Unfortunately, I did not have access to the cost information for the service provided to AM Equipment.

Information quality has had a dramatic improvement from the legacy system it replaced. Inventory information is now 89 percent accurate; although the target is 100 percent, the company started with approximately five percent accuracy which shows a vast improvement. The system previously used needed to be revised each month after a full physical inventory, which took approximately 52 man hours to complete. That data needed to be changed (as much as 40 percent!) in the system to show even a relatively accurate inventory count. At this early stage of implementation, the company is still doing a month inventory count and is in the midst of a discovery phase to identify where persistent inaccuracies are coming from. Once the problem is identified and corrected, the company anticipates reducing the physical inventory to a random sampling of 20 percent of the inventory part numbers monthly and be further reduced if the IS proves accurate.

System quality evaluation was performed through observation of users and personal experience. Since the inception the system has been extremely reliable. The system needed assistance from the developers only once when it was downed by improper operation internally. Each department interface has been designed similarly to smooth ease of use. Once a module has been learned others can be picked up very quickly because of the intuitive nature of the layout and visual ques. The expandability of this system has aided in the roll-out by using only what was needed and giving the option to add other features as the company matures. As mentioned previously the company is staggering the implementation of different modules to gain full usability while reducing the negative impact of completely restructuring all the companies’ processes.

Net benefits to be discussed are increased efficiency, increased communication, improved individual ease of job and a brief mention of the financial benefit. Assist 2k7 has shown improved efficiency in several aspects from a more integrated system and reduced labor. This better information has enabled employees to depend on system information for most of their information needs without having to ask the customer additional questions or do labor intensive research. Cutting out the additional time spent on research and the irritation of extra questions has increased productivity by approximately 15 percent. Additionally, credit cards are now processed while the customer is still placing their order; this avoids the hassle of getting declined cards and delayed orders while trying to re-contact the customer.

Increased communication has proved to be a huge asset to the management team. Having access to better, more reliable information and standard reports has enabled decisions based on facts rather than partial information and guesswork. Getting information from the previous system was difficult because there was hours of labor intensive data gathering and then it needed to be formatted into a usable format, typically done in Microsoft Excel. Now, virtually any report can be generated with the most current information and ready to present in a matter of minutes. This clarity has enabled managers and employees to see sales trends as they happen, rather than three months afterward discover that many accounts had reduced orders by 30 – 50 percent. The transparency of the new system has enabled the customer service representatives to give accurate information to the customers about shipping status and availability. Giving better information has also reduced the number of customer calls asking about shipping status or delivery dates.

Ease of individual job has been difficult to measure. Customer service and shipping are now required to input more data to accomplish their tasks. This is the main responsibility of each of these departments, so this IS has increased the labor required to fulfill their jobs. However, their secondary responsibility is to problem solve when difficulties arise. This portion has now been made simpler because of the wealth of information that they input for each order. Doing extra work on the front end has enabled turn around for issue resolution to be decreased from 6 hours to less than 10 minutes.

The financial benefit has not been identified at this point. Getting good information about the financial impact of this ERP software will be difficult because we had very little understanding of current state of the business. We anticipate sizable gains, but there is no reliable metric in place to enable quantitative feedback.

This discussion has limitations in that most of the data was gathered from approximations and not recorded information. The company has grown rapidly in the recent years and is just now starting to grow its IS to a maturity capable of providing quality information with enough detail to ascertain trends or analysis from the data available. Additionally, the implementation only started seven months ago and not all portions of the system have been initiated. As implementation continues, company processes will be merged or automated, more limitations as well as benefits will become evident.

Appendix A

Interview Questions:

-Service Quality

1) What is the level of responsiveness compared to the IC (legacy) system?

2) What is the level of attitude of providers compared to the IC (legacy) systems providers?

3) What is the provider’s effectiveness compared to the IC (legacy) systems providers?

4) What is the level of convenience to solve problems compared to the IC (legacy) system?

5) How does the cost of service compare to the IC (legacy) system?

-Information Quality

1) What is the level of usability compared to the IC (legacy) system?

2) What is the level of accuracy compared to the IC (legacy) system?

3) Compared to the IC (legacy) system, how current is the information?

-System Quality

1) What is the level of reliability compared to the IC (legacy) system?

2) How is ease-of-use compared to the IC (legacy) system?

3) What is the versatility compared to the IC (legacy) system?

4) How does the functionality compare to the IC (legacy) system?

-Net Benefits

1) What are the benefits of Assist 2k7 over the IC (legacy) system?

References:

Bailey, J.E., and Pearson, S.W. (1983). Development of a tool for measuring and analyzing computer user satisfaction. Management Science, 29(5), 530-545.

DeLone, W.H., and McLean, E.R. (2003). The DeLone and McLean model of information systems success: A ten-year update. Journal of Management Information Systems, 19(4), 9-30.

Dowlatshahi, S. (2006). 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

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.

Straw, E (2008). Measuring Information System’s Effectiveness. Retrieved July 11, 2008 from http://converge.corban.edu/file.php/1764/Measuring_IS_Effectivness.pdf

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