Outsourcing on the example of the A/P project by the Tegan company
Outsourcing is now a very common practice, and more so in IT-related projects. Compared to other alternatives like developing a project, outsourcing is cheaper due to the reduced costs such as housing and labor. About the case study, outsourcing was the best move under the circumstances. To start with, collaboration with the Fan Li business had restrained the existing accounts payable and as such, a quick fix of the A/P was necessary (Upton and Straits 2).
During this time, most of the employees at Tegan’s IT department were occupied with more urgent projects. Therefore, most of the talented employees in the IT department were absorbed in the R/3 project (Upton et al. 2). The remaining employees had little knowledge of the new program, while the rest of the employees had either retired or had little knowledge about how the new program would be executed.
These challenges prevented the company from adopting the second alternative which was to rewrite the system using internal resources. The first option was to “install an enterprise resource planning system (ERP), such as SAP” (Upton et al. 3). Although this alternative was effective and reliable, the budget constraint was too high for the company. Given the shortcomings in the two alternatives, the firm was left with no choice but to outsource the A/P project.
Outsourcing the project was cheap as it would be a fixed price contract. To execute the A/P project, the outsourcing company would receive £25, 000 for the whole project (Upton and Straits 3). However, since the contract was based on a fixed price, in case Hrad incurred more expenses than earlier estimated, the company would have to incur the costs. On the other hand, if the company incurred fewer costs, this would be to its benefit.
Hrad was finally awarded the tender to develop the A/P systems on behalf of Tegan based on the company’s experience with similar projects. Factors like cost, time, expertise, experience, talented employees, and urgency necessitated Tegan to outsource the P/A project. The cost of designing the ERP internally would be £ 5 million while the price agreed with Hrad while the outsourcing company would be £900,000. Therefore, it can be concluded that the move by Tegan to outsource the A/P project was the right thing to do under the circumstances.
The tradeoffs involved in having the requirements analysis for a project
The associated trade-offs for having the requirements analysis for a project performed by one of the firms fixed that would ultimately bid on the project include familiarity with the project at a cost. The major core target functions in project development and management are cost, time, quality, and scope. In the case of the A/P project, quality and scope functionality were compared with cost and time.
Tegan had to cut some of the associated constraints like a high budget to the low budget offered by Hrad Technika. Having the requirements analysis for a project performed by the bidding company, this gave Tegan the surety and confidence that Hrad had the requirements functionality analyzed in advance. Early project planning was essential for the company as it was running out of time.
The project was based on functionality scope and cost rather than time and quality. However, it later emerged that quality was of the essence in the project and so was the time frame. Tegan wanted a vendor who understood the A/P functionality well and who would work at a low cost and a fixed price. By outsourcing the project to Hrad, Tegan saved in cost and time of having another vendor carry out the requirement analysis.
The choice of development methodology employed by Hrad Technika
The major system development techniques in system development or software development are waterfall and the iterative methods (Marks 2). Waterfall involves the use of well a formulated format where the phases are well structured. The deliverables and activities of each phase are well formulated and are accomplished before the other phase starts (Marks 2). In each phase, different people are involved in carrying out the required tasks.
On the other hand, iterative methodologies comprise of RAD approaches and extreme programming (Marks 2). A tight-knit team is used from the beginning to the end of the project. Therefore, based on the two definitions and analysis of the methodologies, Hrad Technika used the iterative methodology. For instance, the firm chose its best team to oversee the project. Additionally, its team was not changed until the flaws were discovered. Additionally, it has been indicated that the methodology used was not a normal windfall method as the steps were overlapping. For example, while the team project was at the definition stage and carrying out LLDs, it was already designing the program (Upton et al. 4a).
It is important to note that although the chosen method was a windfall, it was never followed by the company. For example, “the chosen method was a rapid over-lapping model than the traditional “waterfall “model” (Upton et al. 2008, 4). After defining the project, coding began even before designing was completed. The use of this method allows the project team to identify problems while the project is underway. This can be seen as evidenced by the flaws of the A/P project before its completion.
Why Hrad Technika, the firm that performed the requirements analysis experienced scope and requirements problems
Hrad experienced several problems in the initials stages of systems analysis. The scope and requirement problems emerged once the project commenced although the project used the recommended methodology. According to the case study, the team acknowledges that it did not know “the issues were within the scope of the project” (Upton et al. 4a). This is an indication that Hrad Technika did not undertake adequate research in determining the functionality of the existing program systems. Additionally, it shows that the management at Hrad assumed a lot of the components of the existing A/P systems.
Hrad acknowledges that it had not uncovered some of the issues related to the scope of the systems “such as computational forecasting algorithms for selecting and ordering payments” (Upton et al. 5a). If Hrad had conducted a full analysis requirement without haste and in full collaboration with Tegan employees, the scope and the requirement problems would not have been experienced in the first place.
Additionally, Hrad was running against the set timeframe as they wanted to cover the project in the shortest time possible. It also emerges that even the Tegan project manager at the time named Jones was not even aware of the problems which were associated with the problems. So, neither Hrad nor the Tegan team was aware of the scope and problem requirements.
The most important IT management failures
Based on the case study, the leadership and the management at Tegan were committed to the project. As indicated, Tegan had chosen one of their best technicians to head the new A/P project. From the onset of the project, Tegan was committed to ensuring the project rolled out successfully. The required skills of the chosen manager were unquestionable. On the other hand, Hrad had put in place its best management team and workforce to run the project.
For instance, the company chose Danielle Zelenka to head the project at Tegan. According to the case, she was among the top cream of the Czechian talent (Upton et al. 3a). This is an indication that her leadership qualities were unquestionable. As the project was initiated, Zelenka and her team carried a functionality study to determine how the existing project worked intending to ensure that they knew how the system worked. Both organizations were well managed with leadership qualities exhibited in how they carried their tasks. Therefore, it could agreeable that management leadership was not the major cause of the IT failures that led to the fail of the A/P project.
According to the case study, the time allocated would have been the major cause of the A/P project. For example, Hrad sent LLDs (level design designs) every week to have them reviewed by the Tegan team (Upton et al. 3a). The reviewed documents would then be returned after four days so that Hrad could continue writing the programs. However, as the project continued, the LDDs piled up at the offices of Tegan as it lacked employees who would review them within the set timeframe. As a result, the project was delayed and this was transferred to the Hrad Company.
Another major cause of the IT project failure was a poor allocation of human resources. Based on the case, Jones from Tegan was the only person available and with the required experience on the A/P project (Upton et al. 4). She single-handedly handled the entire project LLDs and carried the verifications. In other instances, she had to rewrite the LLDs indicating the functionality which were not well written or discussed by the Hrad team.
The problems of the workforce delayed the project as it did not follow the set time frame. Additionally, Hrad assumed some functionality elements while writing the LLDs. This forced Jones and her counterpart Maredudd to rewrite the LLDs. The assumption by Hrad who seemed to be working in a fixed time frame led to the delay of the project. The problem of rewriting the LLDs is a sign of poor research by the Hrad team. Poor research as a problem associated with project definition often led to delay.
Another IT management problem that emerged is the lack of concern by Hrad. The Hrad team was notified by the Tegan team that they had a shortage of employees but that was disregarded. As a result, the verification process was delayed. Hrad acknowledges that problems associated with scope led to delay. Furthermore, they acknowledged that enough data on the functionality of the initial A/P projects were not collected which led to the failure. All these problems can be categorized as poor research problems rather than management problems. As a result of these problems, the project failed as it was to be postponed for more than ten months past the set deadline.
Poor communication between the involved parties seems to have caused IT management failure on the A/P project. For instance, Zelenka acknowledges that she was aware of the issues like the response by Tegan’s team (Upton et al. 4a). It emerges that the Hrad project manager was not even aware of the problems associated with the LLD. This indicates the presence of communication problems between Tegan, the Hrad team on the ground, and the project manager at Hrad. As a result of poor communication, no action was taken on the LLD problems. The project wanted extra financing other than the allocated amount.
This is an indication that the set amount was not adequate to sustain the initial project. At the end of the analysis, it seems that Hrad assumed and took some things for granted hence the It management failure.
We can conclude that poor communication, inadequate time frame, poor research, and inadequate allocation of resources especially human resources led to the It management failures of the A/P project.
Options for moving forward as identified by Tegan
Upon the project failure and thorough deliberations, only four options were available. These options are staying with Hrad, initiating a project through the use of SAP in the A/P accounts, having more resources to design and modifying the existing system. The last option was to find another vendor. The best option can be known through a cost-benefit analysis of each.
Table 1: Cost-benefit analysis.
Based on the cost and benefit analysis, the most recommended option that would work well for the company is the first option of sticking with Hrad. Hrad has many associated benefits compared to the other three options. Furthermore, it is better to work with a vendor who has given a word of assurance and acknowledged their mistakes than adopting any of the other three options.
Works Cited
Marks, Dan. Development Methodologies Compared: Why Different Projects Require Different Development Methodologies. 2002. Web.
Upton, David and Bradley, Straats. Hrad Technika. 2008. Web.
Upton, David and Bradley, Straats. Tegan c.c.c. 2008. Web.