The A/P System - Case Study Example

1. Was outsourcing the A/P project the right move for Tegan given the other possible alternatives? IT department of Tegan c.c.c. could have handled the A/P project by its own but its staff strength of 100 was divided equally for the rollout of its comprehensive SAP R-3 project and the rest of the information technology function management. The huge talent pool of Tegan was dedicated to the SAP R-3 project and only a few personnel of the IT department could be made available to rewrite the system. No expert of the originally developed A/P was available other than the singular name that was Julia Jones, as the personnel who developed the system had retired. Time was a big issue with Tegan t to be devoted to the A/P project (Upton and Staats, “Tegan” 2). Another option with the IT department was to function on an enterprise resource planning system (ERP) to include the financial accounting module in the currently processing SAP but the cost factor( £ 5 million) proved a big hindrance (Upton and Staats, “Tegan” 3). The A/P system was taken from an old version of a packaged software system, named Dunnock, which has been customized internally and externally many times. Working on the strength of a singular expert would have been a deadly experience had Tegan opted to manage the A/P project on its own. Outsourcing the A/P project, therefore, was the right move on the part of Tegan (Upton and Staats, “Tegan” 2). 2. What are the tradeoffs involved in having the requirements analysis for a project performed by one of the firms that would ultimately bid on the project? Tradeoffs involved in letting one of the bidding companies to perform the requirement analysis were that it could know the functionality of the current system to be repeated ditto on a scalable system employing newer technologies, robust enough to manage huge volumes. By interviewing the users of the system, Hrad, the bidding company could easily prepare a requirements document and get a view of the work involved and offer a genuine bid amount cost-efficiently, which in turn provided a realization to Tegan that they were accepting a bid, which was not demanding exorbitant cost to complete the project (Upton and Staats 3). Further, It presented the opportunity to Tegan clinch the deal with Hrad on a fixed price condition (Upton and Staats, “Tegan” 4). 3. Given our journeys through the world of system development methods in recent lectures, discuss the choice of development methodology employed by Hrad Technika. Development methodology used by Hrad was formal work breakdown methodology, which was used for bidding on the project. Such an approach offered the leverage of the insight on Tegan’s processes sufficient enough to offer a reasonable quote to gain the contract. Hrad could discuss the intricacies of the project with the experts from Tegan, specific business rules and different customizations (Uptron and Staats, “Hrad Technika” 3). Actual work on system development started with the developing of the draft. All the documents related to defined needs were passed to Tegan for getting the LLD. Hrad used the waterfall method to finish the project. As per the waterfall method, Hrad finished the LLDs first of all and then started the coding. To shorten the development cycle of the project, Hrad started working on coding soon after getting clearance from Jones on LLDs (Uptron and Staats, “Hrad Technika” 4). 4. Why did Hrad Technika, the firm that performed the requirements analysis, have scope and requirements problems once the project commenced? From their side, Hrad employees tried heir best to get an estimate of the work by interviewing the current users of the A/P system but when the actual work began with the rewriting of the LLDs, they found the needed functionality missing. On verification it was found that such issues were not the part of the scope of the project. Nonetheless, with the defining of each module, the coding was started a bit advance before completing the remaining design details. Had Hrad completed the design details before starting coding, it would have realized the approaching problems; speedy overlapping of the waterfall model resulted in making an error on the scoping of the project (Uptron and Staats, “Tegan” 3-4). By August 2008, designing was still going on although the project had reached the stage of half-completed. Problems arose because certain issues had cropped up related to system features like calculating forecasting algorithms for choosing and ordering payments were not there in the earlier conducted scope analysis. Late turning of LLDs by Tegan was another reason besides the missing data from the needs documents created problems for Hrad (Uptron and Staats, “Tegan” 5). 5. The case writers’ state: "Sadly, Smith knew that “Leadership” and “Commitment”, the paucity of which was blamed for untold IT failures were not the problems here." Critique- do you agree? What do you see as the most important IT management failures here? Certainly, failure of the project could not be blamed on the lack of leadership and commitment. The fault was somewhere else. First, Tegan could not handle the project by its own because of not only huge investment required but also due to the primary reason that it lacked the expertise on its own A/P project and neither the company Dunnock had sufficient staff to brief Hrad on its old version of a packaged software system. Only one person at Tegan was available who could help Hrad, as she had worked as an apprentice on the originally developed A/P system and she was not willing but had to help by default, as there was no one in Tegan to help the team at Hrad to know the basics of the A/P system. People in the company had moved away from Tegan and some had retired leaving a cruch of needed staff behind. The main reason of the delay in delivering the project was crunch of staff at Tegan to turn the LLDs back to Hrad after crucial feedback. It compelled the IT team at Hrad to follow a methodology, called the “waterfall methodology” in a haste to overlap the coding before completing the designing, resulting in late finding of certain issues, which were not part of the contract, as decided in the scoping of the project. This was the most crucial IT management failure to start work on coding without finalizing the design of the project. 6. Which of the options for moving forward that Tegan identified would you recommend? Tegan zeroed-in on four alternatives to come out of the crisis. One option was to let Hrad continue with the project, as Hrad had already completing almost half job on developing work. The second option was to include in the in-house project, the SAP’s accounts payable module but it was quite costly. That was the main reason of outsourcing the job to outside company that could deliver the A/P project cost-effectively and also there was a crunch of experts at Tegan to be devoted to additional module to be developed in-house. The third option with Tegan was to temporarily patch the current system by devoting resources but it could not be a permanent solution given the problems faced in the A/P functionality to bear the load of visitors’ rush. Finding another vendor was the last option, which could not be justified, as already Tegan had made payments to Hrad on the work completed as per the conditions of the contract (Uptron and Staats, “Tegan” 6). Considering the four options stated above, it would be in the best interest of Tegan to move forward with Hrad by not insisting on timely delivery of the project, as things did not turn up in the right direction because Tegan could not provide sufficient experts to clear the backlog of LLDs, which happened to be the major cause of overlapping and delay. Works Cited Case Studies Upton, David. M. and Staats, Bradley R. Hrad Technika. Harvard Business School. 21 October 2008 Upton, David. M. and Staats, Bradley R. Tegan c.c.c. Harvard Business School. 31 October 2008. . Read More