PHOENIX CASE STUDY Solved

PHOENIX CASE STUDY QUESTIONS Solved

Q1. The novel is generally about what IT Development and Operations (Dev-Ops) has to learn from manufacturing. Summarize as a list, what these recommendations are. For each recommendation, list a page in the novel where the recommendation is made or referenced.

The list of recommendations are as follow.

1. It is recommended that people need to create alternative deployment plans so as to use if the original plan fails. (p.27)
2. If all the systems and data are lagging behind or slowing the process, they need to be given time before any appropriate decision is made in regard to these delays. (p.27)
3. Dragging security issues around in the operations and development department should not be a concern or cause for implementation. (p.38)
4. Labor force and task force need to be increased by at least 50% if success in deployment is sought after by the department. (p.48)
5. Mutual consensus and agreement has to be made where all the executives agree to one particular idea and set of risks. (p.52)
6. Additional and all appropriate requirements for operations and development department regarding a software or database project should be made so no confusions are created in the hassle. (p.53)
7. People need to lend in their opinions in regard to IR development and operations. This only encourages further input from other colleagues and employees, which is overall beneficial for the entire development and operations department when it comes to manufacturing. (p.78)
8. It is definite that a person or a group of people will need to make several changes in their deployment procedure, when it comes to IT development and operations’ department learning from manufacturing. (p.79)
9. Professionals need to address key issues rather than junior employees who don’t understand much about the tasks that they have been given, such as change implementation. (p.119)
10. Always allow the administrator of a department to handle the problems that arise in the same particular department. (p.179)

Q2. Phoenix turns into a mitigated disaster in its release. Why is that? What were the root causes of the release failure and the need for a ‘war room’ to manage it?

Phoenix turns into a mitigated disaster in its release since there were a number of root causes behind the failure. However, the main reason behind the number of root causes was the fact that not enough time had been given to launch the Phoenix database project. Therefore, the project had to be hurried even when Bill had found a number of problems that would need further addressing before the launch. Steve’s conclusive attitude to hurry things up on the basis of Sarah’s claims is wrong since the operations administrator was Bill, and he should have been heard at the launch meeting rather than Sarah. Furthermore, the problem that was the primal reason for Phoenix’s mitigated turning into a disaster was due to the rise of unethical dilemmas that had begun in the process of solving the issues that had begun once the launch date arrived nearer. The first root problem was the placing of the servers. The servers were needed to reboot every few hours so as to keep the script running, which would begin the operations on the Phoenix project. These servers were difficult to locate at first. Once the servers were found, the placing and location to put the servers in was less in access and this caused the script to run slower than usual. Furthermore, the second root cause was the delay in the processing of the script. This script had made the problem double in its processing rate due to the cause that without the script’s completion, the phoenix project would not operate successfully.

3- What is the role of the character “Brent”? Why is his role in the company/project/story important? (E.g., why did the author include this character?) What did Bill change about Brent’s roll and how his role was managed to make the project more successful? How did these changes help?

The role of the character “Brent” was to act as a lead engineer in his services for the entire organization. In this manner, Brent was made accustomed to handle the engineering problems that would arise in the Phoenix project and in turn, he would be responsible for designing and creating the architecture of the Phoenix database project. Bill changed Brent’s duty in the manner that his role was later turned into supervising and repair engineer for the database project. In this way, Brent was called upon to fix glitches and problems that were continuously arising in the project after the project had been launched and had faced multiple errors and failures. Furthermore, the character of Brent was important overall in the story and was included by the author as he gave a different perspective and opinion toward the Phoenix project and the way it was being handled, when taken into consideration the perspectives of Bill and Steve, the other executives that were in charge of directly commanding the development and operations of the Phoenix Project.

4- What is the ‘Theory of Constraints?’ What role does this theory play in how the Phoenix project release is managed? How does Bill apply this to the prioritization of projects at Parts Unlimited?

The theory of constraints refers to the methodology of identifying the most weak or limiting factor that is attributed to a project. These factors may refer to time, scope, quality, and cost, which are all bottleneck constraints in project management. This theory of constraints plays a very significant role in the management of the Phoenix project since the theory of constraints was not followed periodically in the Phoenix project and that is why the project assimilated into failure rather than success and completion. The Phoenix project lacked time for its launch, as expressed by Bill in numerous positions. The project also lacked quality since appropriate equipment and resources were not given to the project team, which was being led by Bill. Appropriate scope was not given to the project in the manner that the instructions for the completion of the Phoenix database project were not handed to Bill by Steve and he just wanted the project to be completed, regardless of the constraints that were present at the time. Finally, the problem of cost is yet another fundamental approach that has been denied accessibility by the organization where Bill works and where the Phoenix project is under development. This increases costs as functions are not appropriately managed through the other constraints that have been mentioned already. Also, the firm looked forward to limiting costs rather than expanding them to gain more quality and scope for the project that was under development, in particular the Phoenix Database Project.

5- What was the most useful principle about IT management that you learned from reading the book? How do you expect this principle to be useful to you beyond your MS education?

The most important principle in the book in relation to IT management is the theory of constraints itself. This is because the theory defines how each project should be maintained, sustained, and even radicalized through change implementation without affecting the overall result of the project that is under development and operations. If the theory of constraints is followed by me in real life beyond MS education, I am pretty sure and confident that I will be able to complete any given IT development and operations based project with mere ease. This is because I would keep the constraints as the top priority and utilize the weakest and most limiting constraint to its full advantage before I utilize the other constraints that I may have in my reach at the time being. In this manner, my projects would have a wide scope that allows the project to function in a wide range of working fields and activities, massive quality that allows the projects to run smoothly and safely for long periods of time, administered time that would be used appropriately to allow each function fo the project to be given equal amount of time, and a reasonable cost, which would not be too much or too little, so as to keep the entire project in balance and allow the entire project to complete its course without failure in the end or after the project’s launch.