The Problems of Hospitality Management - Research Paper Example

Project Management – Critical Review By William Blue College Of Hospitality Management The given scenario deals with a company which contracted an outside software developer to design a software code which would be used by the company’s customers. The scenario tells us about how the software development proceeded and what problems were faced by the company. To begin with a critical review, it would be best to start off with the problems that were faced by the company. First of all, there was no proper procedure to decide which software house would be chosen for software development. In the absence of any information, it can be assumed that there was no proper check and balance while the current software house was appointed. Issuing tenders and rewarding the contract after viewing a software house’s portfolio would have been a much better option. Secondly, it appears that the company had a tight schedule for software development. Developing software cost a lot and requires a sufficient amount of time. Rushing through, as in this case, would mean some important minute details might be missed out which might be detrimental to the functionality of the software. Another major problem faced was that there was a clear misunderstanding as to the requirements of the software. Clearly if one won’t mention properly what’s required from the other person, then in case of any fault it’s the first person’s fault (i.e. the company’s in this case). Requirements need to be set out in correctly and in great detail before a vendor is contacted for software development. Once a software is developed then subsequently it becomes pretty difficult to rectify a mistake as often times that requires re-programming the software altogether. Yet another major issue with this project was that the management team of the company kept on changing. This definitely would prove to be very fatal as it’s the management that’s responsible for strategy setting and defining what’s required out of the software. Consequently, there might be clear cut differences in the way different managements operate and in what they require from the software. Constantly changing the company’s management would mean every time a new management came in, there might be some new requirements for the vendor to be featured in the software. What the original management wanted and what the new management got would clearly be different and problems related to product use might also be faced by the new management. Another critical problem with the software was that with such short deadlines set by the company, the vendor wasn’t able to deliver a fully “functional” software, as per the company’s requirements. The situation was also not good between the vendor firm and the company. As the software was not made a hundred percent as required, due to faults of both vendor and the company, there was constant tension and finger pointing between the two organizations. There is no point asking two people who aren’t compatible with each other to work mutually, and this is the core reason that leads to a lot a finger pointing and a generally hostile environment between people of the two organizations when they worked mutually during the testing and validation part. This situation had been averted if a couple of precautionary steps had been taken. Firstly, the company should have done their proper homework before a vendor was hired. In the given scenario the schedule was extremely fast paced and there were misunderstandings on requirements of the project. Had the management of the company taken sometime and jotted down what they want from the software then clearly the requirements of the project would have been clear and the vendor would have then designed the software accordingly (Kerzner 2001). Another way how the current situation could have been averted was by setting realistic deadlines (at the start of the project) and binding the management of the company to work until the project software is finally in their hands. As it is the management that’s responsible for setting the software requirements, management changes should be avoided until the product is finally in hands as every subsequent management might want something different form the software and call for alterations and this would not only increase the total project cost, but bring about problems in the software design and not to mention the time delay. A project manager is an individual who is responsible for the entire management of a project. Had the project manager carried out his tasks responsibly in the first place then none or very less problems would have occurred. It is the project manager’s job to achieve the goals of the project with the given level of resources. He is the one who is primarily responsible for planning, controlling and monitoring the project resources. In the given scenario, there was no project manager at all. The vendor received instructions directly from the company’s management and designed the software accordingly. Had there been a proper project manager in place then there would be no need to worry about things like changes in management and deadline issues. Change is management becomes an issue since in the absence of a project manager, instructions are taken directly from the management (Kerzner 2001). However with the existence of a project manager, the management could change without causing any harm to the company (Haynes 1989). The project manager needs to understand that he is the person who is responsible for the success or failure of a project and for managing the issues of scope, time and cost of the project (Dixon 2000). He should plan the project by coordinating with everyone involved, from the company to the vendor’s firm. The project manager could have planned on the project efficiently by first understanding what’s required of the project. This understanding would be gained from the management. Secondly, he should have a look at his resources and tried to manage his tasks within the allocated resources. Thirdly, efficient project plan would involve setting responsibilities of each and everyone involved in the project and then tracing them up to the day they finally do their work. It would be very helpful if a project lifeline is followed for future projects of similar type. A project lifecycle consist of four phases. It starts with project initiation, next comes project planning, moves on to project execution and finally comes project closure. The project initiation phase consists of defining the project. Here we need to decide what the project we are working on is and what we require of it. In the second stage, which is project planning, we are required to set a detailed plan of the project. This is a heavy stage as it demands planning of all the procedures and steps that need to be carried out. The next step in the project lifecycle is the project execution. The project execution project consists of putting the project to life or “bringing it online” (Heerkens 2000). This step further involves exercising planning and control on the project. The final phase of project closure comes in when the project has almost reached its end. Here a post implementation review is carried out. A post implementation review is a study carried out to see what was planned and what subsequently has been achieved (Project management body of knowledge 1986). It is a also a way to learn lesson for projects in the future. For future projects of a similar type, we need to understand that it is very important to serve the expectations of people who have an interest in our project. The importance of stakeholders over the years has increased in the field of project management as it is them who can help by becoming supporters of the project and alternatively it’s still going to be them who may act as or bring barriers in our project completion (Blogdijk 2008). In the given case study for instance, political considerations had the project stuck in between nowhere for a two weeks period. In our future projects we need to think about all the possible stakeholders and their interests and then only will we be able to successfully face their hurdles laid by them in our way head on. Another very important aspect of project management is how to create effective project teams. If we need to manage future projects well then effective team management is one aspect we need to capitalize well on (Project management institute 2004). To set up an efficient team, we first need to get the right people to do the right job. Work should be started by selecting the best available people for the job. There are many factors which need to be considered in making such a selection including the work completion skills of the probable team workers, the level of experience they have, their effect and influence of the operations of the organization and determining how effectively they work with other members of the team. However, many a times project manages don’t get the say to select who they will have in their team (Lewis 1998). In such a case resources would be assigned by the organization to the project manager. In such a scenario it is advisable that time is given to team members to meet each other and let the “ice melt” before they start working together as a team (Kendrick 2004). At this stage it is essential for me to discuss a project management failure scenario. This scenario is featured in the Kaplan Publisher’s ACCA Business Analysis Book P3. A new inventory system was to be incorporated in a ABC company. The management of the company set down the project requirements and contacted a vendor for the system to be developed within a short deadline of two weeks. The project manager in charge of the project was explained the modalities of the project. The vendor subsequently started work on the project. Just two days into deadline, the main system got damaged due to a fire at the vendor’s office. As backup was done on weekly basis, this meant that now the entire project went back one entire week. The vendor employed extra staff to deliver the work on time but the problem with them was that they weren’t familiar with the company’s working. The project got delivered finally two days after the deadline without any testing for bugs. When the company used to software, it found a major bug in it which literally rendered the system useless. This is just one of many example of a failed project management story. However, proper care would make sure projects are carried out well from their start till the time they end. References BLOKDIJK, G. (2008). PMP/PMBOK 100 success secrets, project management professional, the missing exam study, certification preparation and project management body of knowledge guide application guide. [S.l.], Gerard Blokdijk. http://www.myilibrary.com?id=225572. KENDRICK, T. (2004). The project management tool kit 100 tips and techniques for getting the job done right. New York, AMACOM/American Management Association. http://www.books24x7.com/marc.asp?bookid=4546. (1986). Project management body of knowledge. Drexel Hill, Pa, Project Management Institute. DIXON, M. (2000). Project management body of knowledge. High Wycombe, Buckinghamshire, UK, Association for Project Management. PROJECT MANAGEMENT INSTITUTE. (2004). A guide to the project management body of knowledge (PMBOK guide). Newtown Square, Pa, Project Management Institute. LEWIS, J. P. (1998). Team-based project management. New York, American Management Association. http://www.netlibrary.com/urlapi.asp?action=summary&v=1&bookid=2438. HEERKENS, G. (2002). Project management. New York, McGraw-Hill. http://www.netlibrary.com/urlapi.asp?action=summary&v=1&bookid=75939. HAYNES, M. E. (1989). Project management. Los Altos, Calif, Crisp Publications. KERZNER, H. (2001). Strategic planning for project management using a project management maturity model. New York, John Wiley. http://www.myilibrary.com?id=36401. KERZNER, H. (2001). Project management a systems approach to planning, scheduling, and controlling. New York, John Wiley. http://www.books24x7.com/marc.asp?bookid=2380. Read More