Tegan Hrad Write Up Essay Example

Tegan Hrad Write Up Essay Example Tegan Hrad Write Up Essay Tegan Hrad Write Up Essay Was outsourcing the A/P project the right move for Tegan given the other possible alternatives? Outsourcing has seemed to acquire a rise in popularity and usage in our modern times. Outsourcing involves entering into a contract in which an in-house company process, or processes, is ultimately handed over and dealt with from a third party’s perspective. I would have to say that there are three primary, helpful factors to outsourcing, especially when it comes to the world of business. To start off, the cost of operations can be trimmed down through outsourcing. This, in turn, would assist a corporation or business in accumulating more lucrativeness. Secondly, every organization out there has the intention of delivering top-of-the-line services and goods. Outsourcing can contribute to more efficient deliveries. Specifically concerning information technology or something that would be considered to be a bit more technical, outsourcing can bolster efficiency within that particular field of a technical nature. Thus, productivity would be improved through outsourcing. Thirdly and lastly, within a set interval of time, an establishment has the ability through outsourcing to complete projects promptly. This is due to the fact that while a third party is handling a certain progression of a certain company, that individual company can now use its human capital and employees – that may originally were going to have to deal with a peculiar development stage of a certain project which has now been outsourced – in other, more beneficial ways. More labor can be put into other areas. Yet, when concerning one’s self or a company’s self with such an area as information technology, outsourcing must be looked at with meticulous contemplation in order to guarantee the best possible outcome. Experts, on both sides of the aisle, the customer / purchaser and the outsourced business, must exhibit exemplary communication between the two of them. Both sides need to be participating constantly and engaged. Items will need to be analyzed on a constant basis. Participation and engagement will be critical again. With all of this in mind, I would have to say that the A/P project being outsourced, on the part of Tegan, was not a good move. They might have thought it was a good move, but it turned out not to be because the project bombed, especially in terms of the time interval in which it was supposed to be completed. Obviously, there were failures in regards to communication. Additionally, I think Tegan did not make available various pieces of crucial material that could have helped Hrad. Maybe if Hrad had possessed more intricate information or more information at a faster rate of speed, they could have optimized various systems and system functions by the intended due date. SECTION 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? The main focus, concerning the requirements analysis for a project, is to figure out how a system specifically runs and how all the intricacies within that system work together. In the course of any requirements analysis process, tradeoffs must be pondered. Additionally, when an organization ultimately decides to pick that other outfit to perform whatever assignments need to be done, a thorough thought process will have to go in to that as well. A variety of tradeoffs happen based on many motives. Allow me to expand a bit. Leading off, I have to begin with cost. Cost is an essential, necessary component to undertake requirements analysis. Practically every business out there is attempting to lower costs when taking on any pursuit while simultaneously trying to extract returns at an utmost level. Therefore, if the requirements analysis method is too pricey to do it in-house, the more fitting and suitable approach would be for that business to outsource to another agency the particular tasks and jobs it wants done. I think ideally a firm or business group of sorts would love to use their own employees to complete tasks that the company needs to be fulfilled. Unfortunately, employees can be limited in their knowledge bases. Internally speaking, it may not be able to be done and then upper management may have to hire new people or possibly more people based on the size of the project or project duties. This ramification may not have been in the minds of senior management. Basically, can senior management hire specialized laborers or can they scoot on by without them? Cost definitely plays a role right here. What will be economical for the company? How long can companies consistently pay for specialized labor to work within their internal structures? What outsourcing options does a company have? Subsequently, constrictions and limitations regarding information technology are an integral part of the requirements analysis process. As a firm or company is mulling over the idea of outsourcing, the individual company needs to understand how technologically advanced the other agency is. What are the boundaries and controls of that other agency? Do they actually have a proficient team of technological professionals that will be able to deliver what they promise or will they get stuck on something somewhere in the middle of the project? That would not be good. Whenever a company out there, no matter how big or small it is, indicates to go with an outsourcing partnership, it always helps to uncover and verify the technical aptness of the agency that will be providing the commissioned package of goods and services. Thirdly, time is critical. The deliberation of time intervals and what needs to be finished within a certain time is vital when dealing with a requirements analysis. This is yet another tradeoff. Can we as a company, with everything that is already on our plate, complete projects x, y, and z on our own or do we need assistance getting such projects done in a more timely fashion? To top off this section, if time is the key element that will make or break a project or series of activities, the companies that are researching outsourcing firms and will eventually pick one needs to find one that is efficient in accomplishing the sought after goal of time management. It is always nice for a business to have a positive rapport with an outsourcing firm. It might loosen up any stresses and that outsourcing firm may win the bid. Yet, how friendly is too friendly? Maybe a friendship could be cause for a lax / careless atmosphere. SECTION 3: Given our journeys through the world of system development methods, discuss the choice of development methodology employed by Hrad Technika. I know in class thus far and in this current case (in certain spots), I learned about some different types of development methodology. From what I gathered, I believe the range of methodologies crosses the spectrum from agile methods and waterfall-type routines over to engineering, iterative, and joint access / design. One can even notice that within the Tegan C. C. C. document, the waterfall model is mentioned in the middle of page four. Furthermore, within the Hrad Technika document, on its page four, it used such keywords as iteratively on the top of that page and then jointly and joint meeting in the middle of that page. I found it fascinating to go back through my notes and sort of match up some of these buzz words in the context of these two cases as I read through them. I got to see some of these methodologies referenced, shining a bit more light upon them. Concerning Hrad Technika and what they employed, I would have to say the methodology that was exhibited was one of Joint Access and Joint Design. Moreover, I would say the waterfall methodology popped up too. Within the first kind of methodology (joint methodology), the creators (the outsourced firm, Hrad) remain in contact with the customer (Tegan) concerning choices about what characteristics need to be assimilated into the layout of the current system in place. It is also helpful if the customer (Tegan) has some know-how in regards to all the various pieces and cogs that should be built in and encompassed within the system. What the new system is going to be should be a clear picture within the customer’s mind. That notion will aid and benefit the minds and thinking processes of the designers, also known as the outsourced firm. The outsourced organization would then develop, foster, and nurture such demanded aspects and components into the system. Anything and everything that would be integrated or expanded upon into the system should adhere to strict compliance. The outsourced company cannot put something into the system that is not agreed upon or simply will not fit into the system. In continuation, once the system has been finalized, the client gets to test it. Hopefully the client does test it and does not just start running with it immediately. The customer company needs to make sure they are getting the correct requirements they negotiated. Most likely testing will occur, and this is where both parties can record any inconsistencies and inefficiencies. If rectifications need to be made or functionality needs to be improved, this is where it happens. When jointly designing usages and purposes, both sides need to cooperate. It is only through this cooperation that a successful end result can be achieved. Tegan and Hrad need to be on the same page. After reading both cases, it was quite obvious that there were some alignment problems. Furthermore, within this joint methodology, it is obligatory that both sides have the same real time, working awareness and information for what the anticipated system is supposed to become (this also appeared to be problematic). There cannot be delays or miscues sending and receiving data and material. If there is a break down in any of the topics previously discussed, it will cause a failure within the development of the proposed, newer and better system. I do believe with the joint designing, both companies put forth what they considered to be an adequate amount of effort but through their supposed efforts, they jointly took a nose dive together. I truly believe each side wanted to help the other side, but they never accurately matched up with each other. It wasn’t meant to be. In addition to the joint access method, I also saw elements of the waterfall method illustrated by Hrad. However, with the project climate constantly changing, the waterfall method may not have been the best choice by Hrad. Probably a better choice by Hrad would have been something along the lines of an iterative method. The waterfall method can be quite linear and rigid. It does not allow for flexibility and scope adjustments. I think the term scope creep ended up hitting Hrad pretty hard there towards the end of both cases. With the waterfall method, it seemed to me like Hrad could not really go back to a previous phase. It seems like the waterfall method displayed by Hrad caused the project to overrun not only in regards to time but with cost too. SECTION 4: Why did Hrad Technika, the firm that performed the requirements analysis, have scope and requirements problems once the project commenced? Hrad Technika decided to implement a methodology that involved sharing. The sharing was intended to be mutual and on a consistent basis. Regrettably, barriers that revolved around steady interaction and dependable exchanges of information hindered a good amount of project requirements. Even though Hrad Technika performed the requirements analysis, many of the goals and ideas that were slotted to take place did not meet the standards that needed to be in place. Problems had arisen. First off, the analysis stage was not a success. Hrad had enormously depended upon their former understanding of the system. This understanding and knowledge had come about when they had actually contrived the requirement document. Through this, I can infer that most likely during the quality analysis phase, the project did not excel and outshine, as it was meant. It probably did not show promise and turned out to be a flop. Once again, over-confidence in relation to the system and supposed familiarity with the system contributed to the failings and deficiencies of the planning and devising committees of Hrad. As an end product of all of this, there ended up being a wide-ranging shortage of awareness. The customer (Tegan) and the outsourced firm (Hrad) were not on the same page at all when it came down to the requests and wishes for what wanted to be done with the A / P System. Secondly, the Low Level Design Documents come to mind. There seemed to be time lost or time not properly used concerning the LLDs. I do not think the company of Tegan embraced a correct development methodology. Moreover, I do not believe Tegan had enough adequate resources or enough expert-type employees. There are two great quotes on page three and then page four in the Hrad Technika case that back up the previous sentence. The first one was: â€Å"While at the initial meeting, there had been many people close to the A / P project, it unfolded that it was only the most vocal person at the meeting who understood the system: Julia Jones. † The second was: â€Å"As a short cut, Hrad decided that it would be impossible for Julia Jones (the expert) to review every [single] document, so they distilled what they knew onto a set of PowerPoint slides which they presented to Jones for her reaction. Additionally, the interruption of said time was intrinsic regarding the end date for the project. As a consequence of all these time issues, the managing team obviously wanted to take precautions and preventative measures to try to condense the time of culmination for the project. However, in a way, this over eagerness to remedy time management difficulties headed towards some other errors t hat inadvertently held up the typical and customary functioning of the system. Overall, another methodology should have been used. I think the system failure was due to the methodology that got picked. There should have been another course of action where Tegan did not have such a principal role. If that had been the case, maybe Hrad could have improved the performance of the system. SECTION 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? It is quite evident that there was a deficiency in the commitment and leadership categories from both sides, Tegan and Hrad. This paucity, as it is called, caused several complications throughout the execution of the A / P project. Thus, I do not agree with the quotation above. I think leadership and commitment were some of the major problems and contributed greatly to the unsuccessful nature of the project. I mean, Tegan did not exactly express an overwhelming dedication to the project due to the fact that it never truly released a sufficient amount of knowledgeable staff to help accelerate the LLD reviews. In response to all of this, Hrad was pretty accommodating and compliant to the seemingly inflexible ways of Tegan. The mannerisms of Tegan displayed an attitude as if they did not care if the project was a success or not. Furthermore, Tegan was adamant about having a fixed-price contract. This was all regardless of over-flowing costs and even the enthusiasm and cooperation of Hrad to pay for some of the additional costs. This right here is sort of exemplifying in a way that Tegan really did not want to go the distance with this project. I feel as if Tegan just wanted to pay someone swiftly and have the outsourced company get it done swiftly too. Moreover, another conceivable drawback that could have endangered and threatened the project was employing the exact same company that also performed the requirements analysis. Concerning one final thought and going back real quick to the fixed-price contract, the usage of this kind of contract forced a sizeable test upon Hrad in tackling the new transformations of the execution of the project. The system had some very complex pieces to it that were not initially recognized. SECTION 6: Which of the options for moving forward that Tegan identified would you recommend? I would have to state that the project at hand was an immediate failure. Many conditions and obligations were not met. It is also obvious that more time and more money will be necessary to guarantee that at some point the project will be officially completed. Two primary reasons for the shortcomings of this project, yet again, included the sluggish rotational speed in regards to the LLDs and how fast they could send them back and forth to one another accompanied with appropriate feedback and secondly, the consciousness that suddenly came about in regards to the fact that other and new elements needed to be incorporated into the system of which had not been delineated within the requirements analysis. Out of the four possible choices on page five of the Tegan document, I would go with a mix of one and three. Tegan should â€Å"stick with Hrad†, and they should also continue to â€Å"devote resources to ideally fix, or at least patch the existing system. † The fundamental recommendation, as I see it, would be to expand the timeline rather than to considerably shrink the project’s functionality. I think Hrad is starting to see the complexities, they just need more time. An entirely new outsourced firm, I think, would be bad. A new firm might not even see what Hrad is recognizing right now for an even longer period of time, which could possibly produce what would seem like an eternal drag of resources and money. I think this recommendation would be the best. I think it would be advantageous to Tegan and Hrad logically speaking because eventually the deliverables would be met, they would specifically be met by Hrad, and maybe some sort of relationship restoration could be had.