Outline
Packaged software has proved to be a very important aspect in the application of information technology change management. Current managers are resorting to this due to its efficiency, ability to deliver in bigger volumes and its cost-effectiveness. However, traditional approaches to decision-making driven purely by intuition are no longer adequate to deal with the complex problems faced by the modern application criteria of COTS projects (O’Brien 2004, p.127). It is thus important to develop systems that provide the information and analysis necessary for the decisions which must be made in an approach to successfully launch a company IT process.
The systems that have been identified are known as decision support systems (Gordon & Judith 2003, p.76). Despite the fact that database systems provide an important component to decision support systems, the complexity that has generated the problems that now face the policymaker are not similar to the ones which database systems have been applied in the past (Gordon & Judith 2003, p.76). It therefore calls for a properly thought out and well executed software project to ensure deliverables are met. To avoid the failures experienced by other organizations, TMH Corporation will have to incorporate some of the additional activities that are not common to the intensive COTS projects.
Introduction
The importance of packaged software has emerged to be a very important aspect when applying a development strategy in the information technology departments of an organization. The level of interest that different companies have developed in the vendor-supplied software is a clear indication of how this new approach to information system like the commercial off the shelf (COTS) application has been embraced. The promise that COTS solution will offer not only a cheaper but also faster solution to the frequently problematic custom-developed IT projects is the drive behind this new IT system phenomenon.
THM Corporation has grown fairly quickly due to success in both exploration and the production of oil and gas from established fields off the west coast of Australia, the Timor Sea and Bass Strait. They are currently exploring East Timor and off the coast of Vietnam. The company has also developed substantial markets for its products in China, Indonesia, Vietnam, Malaysia and Australia and has multiple offices in the Region. Rapid growth has meant that its information systems have not always kept pace with its physical growth. Roger Gates, as the Chief Financial Officer, would highly welcome any solution that would be cost-effective, offers shorter and easy schedule for implementation as well as high efficiency with lower risk in the business process of the company.
Most organizations have stuck to the traditional waterfall system highlighted in the figure below.
However, Tayntor (2006, p.28) highlights the changes to SDLC Phase during a COTS implementation in the table below:
However, traditional approaches to decision-making driven purely by intuition are no longer adequate to deal with the complex problems faced by the modern policymaker in a firm (O’Brien 2004, p.127). It is thus important to develop systems that provide the information and analysis necessary for the decisions which must be made in an approach to successfully launch a company process. The systems that have been identified are known as decision support systems (Gordon & Judith 2003, p.76). Despite the fact that database systems provide an important component to decision support systems, the complexity that has generated the problems that now face the policymaker are not similar to the ones which database systems have been applied in the past (Gordon & Judith 2003, p.76). In essence, these problems are not known in advance or prior to implementation since they are constant changes that consequently evoke the emergency of the answers that need to be generated.
In actual sense, Roger Gates approach may be considered as both traditional and modern. This is because while it is clear that he had developed a cross-functional cooperation on the new product development across the discipline involved, the key decision making on this strategic commodity remained centralized.
A survey conducted by Minkiewicz (2004, p.88) in the United States and Canada provided some relevant data on how purchasing is organized. This survey was based on some in-depth analysis of international purchasing practices at 302 large multinational industrial and service companies. The result of this survey was later compared with similar survey which was conducted in 1995. The results showed that a substantial amount of organizations were drifting away from the centralized towards decentralized approach to management purchasing of information system (p.91).
Cross-functional Cooperation and Implementation
In spite of it being a new concept, this approach that seems to be popular with Roger Gates provides a consolidation of needs on components for the whole organization with one single contact point (the department in question). Even though the contracting process is done at the corporate level, all the purchasing activities and ideas are decentralized. So how do companies balance between Centralized and decentralized approaches to management system purchase? Before this question is answered, it is important to critically analyze the centralized versus decentralized purchasing approaches.
Centralized Vs Decentralized management information system purchase
To some extent the question of whether to use a centralized or decentralized approach to management purchase may not be adequately answered. As seen in THM Corporation, most companies will balance between the extremes of centralized and decentralized (Gordon & Judith 2003, p.137). Chandra & Kamrani 2004, p.272) outline the following criteria to be used in the purchase of information systems, i.e. whether to use centralized or decentralized approaches;
Commonality of the purchase requirement: The greater the commonality of the purchases products required by the business units, the more benefits can be obtained from a centralized or coordinated approach (Chandra & Kamrani 2004, p.273). This is why it is noticeable that THM Corporation is inclined towards purchasing through decentralized decision process approach because the IT is definitely a common utility in the organization. This is as opposed to buying of raw materials and packing materials that is often centralized at one corporate location (Brownsword 2000, p. 14)
Geographical location: In practice, there seems to be significant differences in trading and management practices between Europe and the United States for example. Even within the European context a lone, businesses have segmented the regions in line with cultural practices which seems to be varied as people themselves (Berg 2008, p.241). When business units are situated in different countries and regions as in the case of THM Corporation, it may be tricky to make decisions at centralized location. Hence the need for a thorough compatibility research that would ensure the identified purchase will be effectively received well by all the units.
Supply market structure: At times the company may be confronted with some of its supply markets with only one or limited number of very large supplier organizations. In a situation like that, the power balance is definitely to the advantage of the supplier and it makes if the corporation in question adopt a coordinated purchasing approach in order to arrange for a better negotiating position with the powerful trading partner (Berg 2008, p.242; Ellis 2005, p.25). In this sense, it is most probably important if the corporation work with the specialists in this field, most importantly the department in their organization, in this case the department of IT.
Potential for saving and the expertise required: the potential for saving is as important as the system purchase itself. If the purchase of COTS is promising to reduce the cost of expenditure, then it is important if the process is highlighted from the process of purchase to the cost of maintenance (Minkiewicz 2004, pp.48-49). The expertise required to maintain the process is also crucial in that the whole system will require that it is maintained to avoid serious breakdown crisis that have seen some COTS fail. It must be noted that prices are also closely related to laws of supply and demand (p.50). As a result of this, most of the buying of the software and hardware are centralized in many organizations.
It is critical to understand that decisions to purchase an IT system cannot be made in isolation and should never be aimed at only maximizing the purchasing g performance. Research shows that experience with companies where purchasing is basically recognized as a primary activity shows that the principles of policy functions will contribute to a permanent reduction of the cost price of the end product, whilst at the same time stimulating innovation from suppliers (Weele 2005, p.23)
It is therefore very critical to apply more additional technologies, methodologies, and approaches to database and operating systems research (as well as other software and hardware research) in order for them to become truly effective in supporting policymakers (Weber 2005, p.43; Weele 2005, p.124).
Implementation schedule: custom development of software schedule of implementation is usually tedious and long because it requires that the contracted firm carry out all the processes in the software development cycle (SDLC). Such processes as system design, construction, and system analysis, testing and quality assurance are some of the processes that the custom development will have to handle single handedly. However, contracting the process for a packaged service will mean all the tedious work will be handled by the contracted firm.
Risk of implementation: THM Corporation is facing several risks ranging from schedule and budget overruns to the delivery of incomplete or even inaccurate functionality from the use of custom-developed system. This may lead to the end users refusing to use the software, especially if the requirements were not well understood by this rebellious group. However, Tayntor (2006, p.27) says that packaged software whose functionality has been proven will help minimize these eminent risks since most of the process of development are complete and the functionality defined to help the company to exactly understand the expected outcome.
The Possible Problems
Modification of COTS software: Additional functionality or benefits that COTS software would add means the plan to modify the software. In general terms, COTS software definition has somewhat an ambiguous definition since it is does not have source code available (O’Brien 2004, p.42). Normally COTS software comes in a package as a commercial product and the solutions to the specific problems of an organization may require that the systems of integration of the several off the shelf components that are not compliant with the traditional definition of COTS are put into use (Ellis 2005, p.151).
In this case packaged COTS software with source code that are either furnished by the customer or otherwise obtained is lacking (Ellis 2005, p.151). That is to say that even though these projects are not related to COTS, they are significant and should be looked at critically.
Generally speaking, it is every concerned manager’s dream to have COTS software satisfies all their intended functional needs. However, this is often not the case. If in any case the source code is made available, it the project teams responsibility to decide whether the there is need for modifications or not (Ellis 2005, p.154). Ellis (2005, p.155) says that it is wholesomely a bad idea to make modifications to COTS software since this would reduce the productivity that is obtained from the application of components of COTS. Furthermore, any chances of the supplier maintaining the components of COTS are automatically jeopardized (Ellis 2005, p.155; Gordon & Judith 2003, p.167.
The productivity and the efficiency of the organization are as a result of major factors as costs, functional size, extent of modification, the technical complexity, and the final operating platform (Weber 2005, p.211). These factors need a thorough augmentation to help seal the gap of unfamiliar of COTS solution code, quality of COTS training and documentation, vendor cooperation, development team experience with COTS solution and the its process of integration (Weber 2005, p.222). Gordon & Judith 2003, p.189) advises that one area that should never be forgotten is to include the any additional cost required to maintain the COTS component especially if it has undergone modification since the vendor will not continue to support their solution.
Who would be doing the work? It is essential to know that contracted firm to work on the implementation of the project is an independent individual who may have their own working policy (Tayntor 2006, p.117). However, the contracting firms (in this case THM Corporation) should be ready to monitor the works and ensure that all the persons hired the consultant are qualified individuals in their areas of specializations.
Tayntor (2006, p.188) says that one way of doing this is through interviewing of the proposed consultants to come up with the best team. The company should be in a position to ensure that particular clauses are clear such as the roles played by the vendor and the company in ensuring that the work does not lead to contractual disputes (118). Tayntor advises that the company should reserve the right to remove any consultant who is deemed incompetent or who causes personality conflict within the contract period. Again this should apply in areas where the company feels that that the consultant needs replacement (p.126).
The use of sub-contractors: some vendors may decide to use sub-contractors to carry out the assigned duties. This may increase the risks to the contracting company (Tayntor 2006, p.117). In case the company allows the firm to use sub contractors, a clause should be included to guide this process. Again the company should be ready to perform background checks especially if the vendor is working at the site of the company (p.114). This clause is meant to minimize the risks associated with the external persons contracted infringing the regulations that guides the works of the company.
What are the acceptable deliverables? There are specific levels of value of the software package that are needed to be cleared for the agreement to meet its goal. Such areas are how long will the process take and what are expected as outcome to the process. In all these cases, it is important to establish the acceptance criteria, rework period if the company is not satisfied with the deliverables, and what will result into ultimate rejection of the outcome (Tayntor 2006, p.117). The ownership of the deliverables should be made clear as the company would want to.
Cost: it is apparent that developing in-house system is relatively costly to any organization; hence to ensure a cost-effective option, a packaged software solution is of much importance. Typically, the cost-effectiveness of the packaged system is seen on both installations stage all the way up to the maintenance cost or cost of running the system (Tayntor 2006, p.27). Tayntor says that despite the fact that the cost of developing packaged software is much greater than a single custom development project, it should be noted that the vendors’ expectation of licensing the software to many customers will automatically reduce the cost of purchase by these firms, largely due to large economy of scale. Furthermore, the support and upgrade costs “are spread among these many customers (p.27).
Conclusion
A proper and a well thought out and executed software project can be done at a faster rate at a lower cost than a similar project implemented with custom-developed components. As represented by this scenario of THM Corporation, many organizations goes around implementing a not-so-thought of COTS projects hence fail in planning since they would be working with the assumption that the project is basically a small integration projects that are easy and void of the complexities as highlighted above. The failures largely occur when the projects fail to incorporate some of the additional activities that are not common to the intensive COTS projects. It is therefore advisable to look into details these unique activities to merge for successful implementation and management.
Reference List
Berg, N 2008 Secrets to a Successful Commercial Software (COTS) Implementation, Boston: Wiley Publishers.
Brownsword, L 2000, Lessons learnt applying commercial off-the-shelf products, Software Engineering Institute, Carnegie Mellon.
Chandra, C & Kamrani, A.K 2004, Mass Customization: A Supply Chain Approach, Springer. Web.
Ellis, T 2005 COTS Integration in software solution- a cost model, Systems Engineering in the Global Marketplace, MO: St. Louis. (1) 24-26.
Gordon, S R, Judith RG, 2003, Information Systems: A management Approach (3rd Ed), London: Oxford University Press.
Minkiewicz, A 2004, The real costs of delivering a COTS-based system, Proceedings for IEEE Conference on Aerospace and Defense, Big Sky Montana.
O’Brien, J 2004 Category Management in Purchasing: A strategic Approach to Maximize Business Profitability, New York: Sage Publishers.
Tayntor, C B 2006, Successful Packaged Software Implementation, Boca Raton: Auerbach Publications.
Weber, S 2005 Information Technology in Supplier Networks: A Theoretical Approach to Decisions about Information Technology and Supplier Relationships, London: Physica- Verlag Heidelberg. Pages 272.
Weele, J A 2005, Purchasing and Supply Chain Management: Analysis, Strategy, Planning, Cengage Learning EMEA. Web.