.Model
of a TECH 394 paper
Paper Outline (professor's):
Bibliography |
Paper Outline (student's): |
|
Projects, project teams, and project management are each a large part of companies in the 21st century. Project management has become a valuable asset in today's workplace, especially in industry. Projects can have serious problems such as scope creep, planning difficulties, and budget problems. These problems can involve the projects themselves, the team members, or the project management. Projects can bring about change in the organization they are used in. In trying to accomplish the project and bring about the change, most team members working on projects encounter problems. These problems can range from simple scope creep to complete lack of planning and preparation. This paper will cover some of these problems and some ways they can be avoided or dealt with if they are encountered. Before a company can begin a project, they must decide what they want to accomplished with the project. They must decide on a project mission. The project mission might be the creation of a new product, improvement on an existing one, changes in the services the company provides, or changes in the structure of the company itself. The company must also makes sure the project will help in some way, usually by making them more money. Before the company can start planning, they need to decide what type of project to do. Different types of projects take different types of planning (Melymuka, 2000, p. 64). Different types of companies do different types of projects. A construction company will have very different problems then a software company (Gorke, 1999, pp. 10-16). Some projects might be dependent on the budget and others might be dependent on the time constraints of the project schedule. Sometimes projects are not planned well enough, but it is not discovered until the project is part way through (Anonymous, 2001, p. 23). In cases like this the project plan timeline has to be redone and if necessary the project must be completely re-planned. The planning phase is probably the most important part of a project. The project plan sets the tone for the entire project. One of the major parts of planning is the allocation of the budget and staff hours (Huff, 2002, p, 35). This can be a difficult task because of the differences in team members' schedules and the current economy. Keeping on a project schedule can be a problem in itself. It can be necessary to bring in new people part way through the project's completion, if it is to the benefit of the project (Stanford, 1995, pp. 84-85). Sometimes it is even necessary to bring in an outside consultant to help with the project (Suss, 2001, pp. 25-28). "When Denver International Airport opened in February 1995, it was a year-and-a-half behind schedule and, depending on how you calculate, $750 million to $2 billion over budget" (Zetlin, 1996, pp. 24-26). Some projects must be completed no matter how much over budget or late it becomes. Projects can involve using different kinds of software, such as Microsoft Works, and AutoCAD. Some of the computer programs might even have to be created just for the project. One way of protecting the project against software problems is to test the computer system many times throughout the project (Brooker, 1991,p. 27). It is important to be aware of the problems that can occur when using software in projects (Jones, 1993, pp. 115-116). These problems can be so serious that they cause the project to fail. Serious problems can include viruses, program bugs, or even miscalculations in the programming. Some projects are joint ventures of two or more companies. This can cause a number of new problems, such as different computer systems, different styles of doing things, and completely different personnel schedules. If these problems can be overcome, the resulting creation can be very beneficial for all companies involved (Gonzalez, 1992, pp. 66-71). All team members involved in a project of such a scale should be ready for more problems then usually encountered with a project. Projects can fail for many reasons. Some of the reasons include little or no "up-stairs" support, the project is too large and complex for the given amount of time and money, or simply because the project was not possible to begin with (Charles, 2002, pp. 22-28; Reddy, 1999, p, 162; Bozman, 1994, p. 16). Other projects are cancelled because the team has not completed the required amount of work by a mid-point deadline (Hoffman, 1996, pp. 1, 125). Some companies have a failure rate of 40% - 50%. Other projects can continue even after a major disaster. Many companies decided to continue the projects they were working on after the terrorist attacks on September 11 (Meehan, 2001, pp. 1, 69). It is possible to see the problems coming before they occur. It is important to be able to recognize the warning signs of the more common problems (Boyken, 1993, pp. 7-8). These warning signs can include things like having to work overtime during the project to finish simpler tasks before the finish date. Another reason a project might fail is that it is something that has never been attempted before. Without any history or other information to research the project could be very difficult (Brown, 1991, pp. 86-87). The more difficult the project, the higher the chances of it failing. Project teams are a useful way of completing projects. Teams can encounter a lot of problems for many reasons, such as not be prepared, or possibly because of Murphy's Law. These problems can range from trouble putting a project team together to keeping the team on schedule. Before a project manager begins to assemble the team, he/she must decide if a team is necessary for the project. Some projects can be done by an individual. Most however are too large and complicated for just one person. It is important to know how many team members to have and how much work each person is capable of doing in the given amount of time (Ratliff, 1999, pp. 31-38). There are many qualities that make up a good team member. These qualities include friendliness, working hard, and the specific skills that are needed for the project (Melymuka, 2002, p. 42). How the team shares the work can make or break a project. Putting together a project team can be a difficult task. The team members must have the necessary skills to accomplish the project on schedule and on budget. It is important to select team members with a wide range of skills (Mead, 2001, pp. 32-38; Nador, 2001, pp. 15, 19; Humphries, 2002, pp. 22-25). Not every member has to have every skill. In fact that probably will not be possible. Most team members will have a few helpful skills and be an expert in one necessary field. One of the major problems for a project team is keeping the team members focused and on track (Marnell, 2002, p. 18). This can be a difficult task, especially if the team members are young. Keeping the team members on task is generally the job of f the project leader or manager (Baker, discipline, 1999, pp. 53-54). If possible, it can be helpful to learn from past teams mistakes and take any advice past team members might give (Kormos, 1998, pp. 52-57; Vik, 2001, pp. 112-119). Their experience can be help to other team members. Getting the team members to work together can be another problem. Getting different people with different backgrounds to work as a team can be a difficult job. It is usually the Project Manager's job to try and get the team members to work together. This can be helped along by getting the team members to become familiar with each other by holding a few early and informal meetings with all the members. This will give them a chance to get to know one another and get more comfortable around one another (Melymuka, 1995, pp. 104-105). Once the team is comfortable around each other they can work a lot faster as a team. Doing the job faster can improve customer satisfaction (Arimes, 1997, pp. 22-25). Which is one of the main objectives of a project and the project team. Project management is a very important part of projects and companies. Almost every project that uses a team will have a project manager. It might not be a formal position, like one that is voted on or assigned. It could be a team member that is looked upon by the other members for leadership and guidance. The job of the project manager is to keep the team on schedule and deal with any personnel problems that might come up during the course of the project. A project manager must have certain characteristics like knowledge of the project, leadership ability, friendliness, and probably most important, experience (Eckert, 1998, pp. 9-14; Schwarzkoph, 1999, pp. 519-521; Cash, 1992, pp. 10-12; Pitagorsky, 2001, pp. 78-82). There are some characteristics that managers can have that are not beneficial to the project. These characteristics can be learned from the people that managed them on other projects. Project managers can learn bad habits and characteristics from their teachers (Morrill, 1996, p. 23). People learn how to lead from the people who have led them. It is important for the project manager to know exactly what will be expected of him/her. A project manager manages the project, they do not manage the team members. This is a common mistake among first time managers. People cannot be managed, people must be led (Baker, How, 1999, pp. 38-41; Koehler, 1992, p. 8). People are too unpredictable to be managed strictly. A leader to must motivate the team members. There is a distinct difference between a project manager and a project leader. A project leader acts more like a motivator. A project manager is more in control of the project itself (Bui, 1999, p. 25-27). It is the difference that can cause many problems with a project manager/leader. Knowing when to be a leader and when to be a manager is one of the hardest parts of the job. One of the jobs of a project manager is to select the team members for the project. This can be a difficult task for the manager. They must pick members with varied backgrounds and expertise. The manager must also pick members who can work together when necessary. The project can be successful or unsuccessful depending on the team members who are chosen (Farooq, 1999, pp. 34-38; Fleming, 1998, pp. 33-36). Team members who do not complete their work can be just as, or even more, harmful to the project as any other problem. The problems and issues discussed early in the paper can potentially have a huge impact on the hovercraft project. Any number of them could serious damage the project by delaying or even forcing it to be cancelled. It is important to be aware of the types of problems and be prepared for them when and if they arise. Doing so can greatly increase the chances that the project will be successful. There are many problems that could affect the hovercraft project. All of the teams need to be aware of the problems and do there best to be ready if they should arise. The most likely problems for the hovercraft project include scheduling problems and keeping the team on task. There are many team members involved with this project and because of this there is a greater risk of scheduling problems and personnel conflicts between the team members. There are many problems and issues that can occur during the project. When done correctly a project can be a great thing. Projects can create wonderful things, like faster computers, and better and safer cars. Projects can be completed using project teams. The team members can have their own problems, but a good team will not let any problem stop them from completing the project on time and on budget. Project managers have a tough job. They must keep the team together and make sure the project is accomplished all while keeping it on time and on budget. If all of these things are done, then what can be accomplish is at times amazing. There are many problems that can arise with a project on the scale of the hovercraft. These problems can range from scope creep during the planning to not having the correct team members with the necessary skills for the project. The team must be aware of these possible problems and be ready to deal with them if they come. If the team can be prepared for the problems, there is no reason why the team cannot overcome them and finish the project on time and on budget. Anonymous. (2001, June). Seattle light rail in question. Railway Age, p. 23. Arimes, G. (1997, March). Doing the job in double time. Planning, pp. 22-25. Baker, J. (1999, August). Discipline of teams: innovative project teams. Successful Meetings, pp. 53-54. Baker, P. (1999, July). How!....anyone can be a leader. Works Management, p. 38-41. Booker, E. (1991, July). Early testing a must for big systems. Computer World, p. 27. Boyken, D. (1993, July). Is your project heading for trouble? How to recognize the signs. Cost Engineering, pp. 7-8. Bozman, J. (1994, May). DCMV Disaster. Computer World, p.1, 16. Brown, M. (1991, January). A bite out of barkers. Management Today, pp. 86-87. Bui, A. (1999, August). Staying in control. Internal Auditor, pp. 25-27. Cash, C. (1992, September). Elements of successful project management. Journal of Systems Management, pp. 10-12. Charles, S. (2002, January). Knowledge management lessons. Online 26, pp. 22-28. Eckert, R. (1998, June). Leadership: a post graduate degree. Executive Speeches, pp. 9-14. Farooq, G. (1999, July). Team building and project success. Cost Engineering, pp. 34-38. Fleming, Q. (1998, August). Project Teams: the role of the project office. Cost Engineering, pp. 33-36. Gonzales, R. (1992, May). The Manitoba Minnesota transmission upgrade project. Transmission & Distribution, pp. 66-71. Gorke, T. (1999, June). Fail safe: Surety for construction projects. Risk Management, pp. 10-16. Hoffman, T. (1996, February). Utility unplugs object project. Computer World, pp. 1, 125. Huff, S. (2002, July). It's all in the planning. Computer World, p. 35. Humphries, T. (2002, June). The design-build project. Cost Engineering 44, pp. 22-25. Jones, C. (1993, December). Sick software. Computer World, pp. 115-116. Koehler, K. (1992, September). Project team management. CMA Magazine, p. 8. Kormos, J. (1998, December). Lessons from the best. Machine Design, 52-57. Marnell, A. (2002, September). Knowledge is power. Buildings 96, p. 18. Mead, S. (2001, December). Using social network analysis to visualize project teams. Project Management Journal, pp.32-38. Meehan, M. (2001, September). After the attacks: projects still on. Computer World, pp. 1, 69. Melymuka, K. (1995, October). Fast teams for fast times. Computer World, pp. 104-105. Melymuka, K. (2002, March). There are projects and then there are internet projects. Computer World, p. 64. Melymuka, K. (2002, April). Hiring a dream team. Computer World, p. 42. Morrill, M. (1996, February). The last boy scout: the proud and the foolish. Journal of Systems Management, p. 23. Nador, S. (2001, October). The fine art of team selection. Canadian HR Reporter, p. 15, 19. Pitagorsky, G. (2001, July). A scientific approach to project management. Machine Design 73, pp. 78-82. Ratliff, R. (1999, June). The use and management of teams: A how to guide. Quality Progress, p. 31-38. Reddy, R. (1999, November). Is your IT project DOA?. Information Week, p.162. Schwarzkoph, N. (1999, June). Leaders for the 21st century. Vital Speeches of the Day, 519-521. Stanford, J. (1995, September). The project from hell. Computer World, p. 81-84 Suss, D. (2001, March). Avoid project hell by preparing for a partnership that works. Communication World, pp. 25-28. Vik, G. (2001, December). Doing more to teach teamwork then telling students to sink or swim. Business communication quarterly, pp. 112-119. Zetlin, M. (1996, July). A slow takeoff. Management Review. p.24-26 |
(home)