Project Management Tools - Report Example

?Project Management Techniques Introduction A project is “a temporary and unique work effort with a beginning and an end that creates a product, service, or result” (Furman, 2011, p. 1). The project necessitates the assembly of a team that is committed to work primarily towards the attainment of the specified goal, usually under the terms of a contract, and therefore the work effort is unique. The project is also finite and temporary because it has a beginning and end specified by date, thus distinguishing it from regular operations which is ongoing and without a deadline. Finally, the project is aimed at the attainment of a specific deliverable which is turned over to the customer at project’s end. This case is a project aimed at upgrading the staff computers from Windows XP to Windows 7. It should be accomplished during the winter and spring 2011/2012, and shall be carried out by the six member in-house technical support unit of the organization. By the project’s end, all 400 computers located in the company’s 30 locations situated around England should be running on Windows 7. The computers presently are of varied types and specifications, and by project’s end should be running on Windows 7 without compromising or unduly interrupting the regular workload. The purpose of this report is to examine the project management tools that may be used to provide a systematic means of addressing the project’s planning and implementation. The project shall provide the context for discussion, but a full blown analysis is not attempted at this point. Prescribed Project Management Tools This section provides a cursory examination of the traditional project management tools and comment on their applicable use in the context of this project. The traditional tools that will be discussed are the Gantt chart, the PERT method, the Logic Network, the Product Breakdown Structure, and the Work Breakdown Structure. Gantt Chart The Gantt chart is probably the best-known of the project management tools because its bar chart representation of the project tasks, their duration, the schedule of their beginning and end, and their relationship to each other are easily conveyed in one visual element. It was first developed in 1917, but originally did not display the relationships between tasks in the manner that it does today. In contemporary use, the importance of the Gantt chart as an industry standard is that the time and functional interdependencies of the various tasks are rendered immediately visible (Haughey, 2011). In the figure following, a Gantt chart is presented that may well serve as the initial conceptualization of the project plan. Here it is assumed that the group of six technicians will work in two teams, each team having one member that is familiar with end user requirements. Each of the teams will address half or the 30 locations, and each location can be addressed in two days (including travelling time). The initial schedule is thus laid out in the Gantt chart for one team. Author created The above chart is tentative and not executable for lack of additional data. If the tasks for each location could be broken down further (e.g. hardware modification, software installation, troubleshooting, etc.) and scheduled, e a more detailed and reliable chart results. Even in its tentative state, though, it already presents a useful rendition of the work intended and points out what other information are necessary to obtain. Logic Network The Logic Network depicts the series of activities that a project undergoes. The logical and sequential relationships of tasks are emphasized, and may provide information such as the critical path and the important milestones of the project. As with the Gantt chart, the dependencies are established between the timescale, the project elements, and the workflow ((Haughey, 2011). Author created For this case, the Logic Network shown above pertains to the activity of each team for each trip it takes to one of the 15 locations scheduled for it. In the team, a group of three members is assumed, with each member having a set of computers to address. Assuming near equal distribution of the firm’s 400 computers over the 30 locations, each location therefore has either 13 or 14 computers. The group of three members thus work on either four or five computers to each member. The one member who will be less loaded than the other two (i.e., in the diagram above the one in the middle) may be the member who is most acquainted with end user implications and therefore would be guiding the other two and answering their questions in this regard. Again, the table is not quite operative yet, and will require much more information about added tasks, time considerations, and the specific conditions in each location (i.e., where laptops and desktops are more or less equal, this could be made a criterion for dividing jobs between the technicians). PERT Chart The PERT (Program Evaluation Review Technique) charts come in different forms, but always they depict the sequence of tasks. It was developed by the United States Department of Defense in 1958, and provides a means of analysing tasks to completion and determining the shortest possible time to attain this (Haughey, 2011). In the version shown, the PERT network is embedded with the estimated task duration, the early and late start and finish times, the slacks of non-critical events, and the series of events that form the critical path which could not be delayed if the project is to finish on the designated time. Sourced from: http://www.processma.com/resource/images/pert2.gif The diagram shown is not that of the given case; the case presently being considered lacks the time durations and the process itself. The generic diagram shown above is for illustrative purposes; from it, we could determine that information needed to be obtained by the management team. From the illustration, aside from the task details and durations, it is important to know in greater detail the tasks which must be done serially and which can be done simultaneously. It will be seen from the PERT diagram that tasks may at times be done at the same time, thus shortening the time duration. Product Breakdown Structure (PBS) The product duration structure shows the categorization of products in a hierarchical tree structure, which encompasses the project deliverable in whole and in part. This tool then allows for a clarification of what comprises the deliverable, and aids in the analysis of the work breakdown and apportionment (Haughey, 2011). For the case project being considered, although the project deals with services, it would be useful to distinguish at least among major computer hardware types. Immediately, it is possible to segregate laptops from desktops, because they would essentially need different components (if hardware components are likewise to be upgraded), and also among different platforms (e.g., computers already using JAWS screen reader program would be more fully compatible with Windows 7 and therefore require a simpler or faster approach). The following table presents an example of a product breakdown structure for a project that distinguishes on the basis of hardware component. This detail is best justified by a manufacturing concern, but could likewise also refer to a service repair shop for computers distinguished according to hardware being addressed. The greater detail is justified only in instances when the work is of great volume, and becomes less relevant as the project becomes more particular to a specific object, such as in a custom job. Sourced from: http://upload.wikimedia.org/wikipedia/commons/a/ae/Product_Breakdown_Structure_example.gif Work Breakdown Structure (WBS) The Work Breakdown Structure is similar in many ways to the product breakdown structure, as far as form and structure is concerned because both are hierarchical tree structures. Instead of distinguishing among the elements on the basis of products, though, in this case the work is broken down and decomposed into smaller and smaller tasks, though in no particular chronological context. The milestones are depicted in terms of minor and major deliverables, which could be viewed as stages of accomplishment. Sourced from: http://www.qualitydigest.com/IQedit/Images/Articles%20and%20Columns/January%2010/cutler/working2_clip_image002_0001.jpg According to Haughey (2011), the WBS is the foundation for the detailed project plan. The team gains insight into the different, most fundamental tasks that must be executed, having been broken down from the bigger, aggregate jobs. The individual tasks are thereafter assembled into major activity areas that are most accurate, complete, and most importantly, logical. In the case of the Windows 7 upgrade, the work may be initially broken down into the hardware disassembly phase, the component replacement, and the assembly phase for those older computer models which will require hardware modification. For those computers already compatible with Windows 7 requirements, the tasks will require installation and alignment of some databases, as may be necessary. Additional Project Management Tools The project management tools described earlier are those traditionally employed and in many cases comprise the industry standard. There are other, non-traditional, methods which are currently being introduced and which may comprise the standard procedures in the future. Event chain methodology This is a probabilistic technique which is used to perform schedule network analysis. It is based on the idea that no matter how much planning and research supports a project schedule there will always be an event or occurrence that will tend to radically affect it. An event chain is a series of occurrences wherein one unforeseen adverse event sets of the succeeding other events that dramatically alters the result from what was intended. The focus of event chain methodology is the managing or controlling of such event chains, so as to prevent, forestall, or arrest their development (Virine & Trumper, 2007, p. 151). Process-based management A process is any managed activity or set of activities wherein knowledge, resources, skills, techniques, and tools are used to accomplish the transformation of inputs into outputs (ISO 2008:vi, PMI 2008:37 in Dunne & Dunne, 2011, p. 154). It is usually the case that output from one activity becomes the input for the next chronological activity. “The application of a system of processes within an organization, together with the identification and interactions of these processes, and their management to produce the desired outcome, can be referred to as the ‘process approach’” (ISO 2008:vi). It emphasizes four fundamental concepts, namely (a) understanding and meeting customer requirements, (b) considering processes in terms of added value; (c) obtaining results of process performance and effectiveness, and (d) improving processes on a continual basis and based on objective measurement (Dunne & Dunne, 2011, p. 154). Agile project management Agile project management seeks to improve on traditional project management methods and tools, in those situations that present a more dynamic environment than can be effectively addressed by traditional means. In the academic disciplines, project management is defined as having an end-to-end project lifecycle. In practical applications, though, all the project management applications emphasize the planning stage and are involved therein, before any actual implementation has begun (Chin, 2004, p. 4). The trouble with this is as the project is implemented, the business and project environments change and become more dynamic, and renders the planning horizon shorter, and the pre-arranged plans increasingly irrelevant. Agile project management addresses this by putting the focus of attention as much on the execution of the project as it does on its planning. The agile environment recognizes that the crucial decisions are made during execution, and they determined the success or failure of the project. Project definition and planning are not abandoned; their role, however, changes to one that supports the decisions that are made during the project’s execution than being all made at the beginning (Chin, 2004, p. 4). Conceptually, the agile project management’s environment is defined as: Agile PM Environment = [Uncertainty + Unique Expertise] x Speed Agile management is best applied in the case of the Windows 7 upgrade project, because it is particularly suited to the uncertain conditions the 400 computers are currently in. The problem with the challenge facing the team is the high degree of uncertainty they are faced with, given that the 400 computers spread throughout 30 locations nationwide would be in various states of use, perhaps disrepair, and compatibility or lack thereof with the operating system they are to install. As a result, many decisions will be made at the sites themselves, and as each computer is addressed, catering to the unique need of the user given his/her function in the organization. Risk Management Risk is the likelihood of financial loss in business, as defined by elithecomputerguy (video recommended by the course requirement). All projects involve some level of risk, particularly technical projects such as the Windows 7 upgrade contemplated in the situation presented here. The risk is associated with the possibility that there will always be a level of uncertainty in the project’s outcome (Kendrick, 2004, p. 1). In this project particularly, other than the uncertainties already mentioned, there are other considerations that affect risk, not necessarily unique to this situation. Threats are outside forces that could compromise the business. These include technical threats, natural disasters, system failure (i.e., component quality), accidental human error (always high), and malicious human intervention (impersonation, interception and interference) (elithecomputerguy, 2011). Risk had been conceptually presented through an equation, as follows: Risk = Threat x Vulnerability (according to the video) In this sense, risk is seen as the cumulative function of threat and vulnerability, where threat refers to the presence of a uncertainty in the environment (i.e., an external element) that may adversely affect the business or project, while vulnerability is a weakness or attribute of the business or project (i.e., an internal element) that makes it susceptible to the threat. Applied to this case, there is a threat that several of the computers may have been exposed to viruses transmitted through the internet that would prove immune to virus scanning software the technical group may be equipped with. The vulnerability exists in the computer itself, that it may not have had a firewall or other protection that would lower its resistance to such viruses. The risk, therefore, is higher for computers that had no protection than those that had; the risk to the technical group is in the possibility of delays, additional expenses, and possible requests for replacement components or even units in the course of debugging the computers. Another author presents a refinement of the formula above presented. It is given as: Risk = Threat x Vulnerability x Consequence (Cox, 2008) The additional factor in this equation is consequence, refers to the impact of the threat on the project, given its vulnerability. It is the possible setback that the project will suffer if the threat becomes a reality. In this case, consequence may be illustrated by the fact that not all locations are equally as important to the function of the business, particularly where revenues may be concerned. Furthermore, not all computers will be performing functions of the same nature; some would be more important to the firm’s operations than others. However, if the threat struck one computer which performs largely correspondence functions, the event would not have the same consequences as the threat striking another computer (with similar vulnerabilities) that performs point-of-sale revenue calculations and real-time logistics databasing. The consequences are much more for the latter than the former, thereby magnifying the risk to the firm or project. Activities that may be undertaken to address project risk are the following (Kendrick, 2004). (1) Risk assessment either simultaneous to project planning, or prior to project implementation. For IT applications, this includes threat of hacking, information theft, IP piracy; also downtime, fraud, legal issues (2) Contingency planning including formation of teams, assignment of tasks and responsibilities, action plans, and budget. (3) Designation of a risk officer who should be someone other than the project manager (4) Building up and maintaining a project risk database (5) Creating mitigation plans for risks selected to be mitigated (6) Forming reporting network and communication channels (7) Coordination with local government and emergency response services Project Management Overview In the course of this investigation, various project management tools had been considered and certain aspects of risk management which may have a bearing on the case study of the Windows 7 upgrade. The case centers on the hardware and software upgrade to the new operating system, and does not include the peopleware (HR training) aspect of the upgrade. The four stated aims of the project may be addressed by the corresponding tools listed below: (1) To plan and monitor the upgrade (2) To ensure minimum inconvenience to the staff and clients of the organization (3) To deal with any issues or problems that arise, and (4) To acquire any relevant knowledge that will be useful for future work. Planning and monitoring the upgrade includes the Gantt chart and the PERT model, as they are designed to provide a visual map of the project as it progressed. In the course of planning, the use of logic networks, WBS and PBS would prove useful in the conceptualization of the full implication and information needs of the project. All the traditional tools together also provide the means, through effective scheduling, to ensure minimum inconvenience to staff and clientele alike. In order to deal with any issues and problems arising during the implementation, agile project management provides useful approaches as event develop. Finally, an effective documentation system that would be included in the risk profile databasing would provide useful information for future operations. To gain a full overview of the project structure, another tool, the Project Breakdown Structure shown below, provides a useful means for maintaining a broad and comprehensive perspective of the project. Sourced from: http://www.jiscinfonet.ac.uk/images/project-breakdown-structure.png Conclusion The paper sought to discover the different project management tools that may be used for the the upgrading of 400 computers in 30 locations, from Windows XP to Windows 7. An overview of traditional as well as non-traditional project management tools had been conducted, with a tentative assessment as to their applicability to the case presented. While the case still lacks many relevant pieces of information, it is already apparent that in one way or another the application of the tools described will help even in the early stages of planning, in the conceptualization of the stages and tasks that the project will entail. Particularly useful are the Gantt, PERT, and logic network charts in creating concrete plans and schedules by which to conduct and monitor the project. As for the non-traditional methods, the principles of agile project management will prove particularly helpful, since there are many uncertainties even at the onset of the project, and throughout the duration of its execution. Possible steps that may be taken in order to enhance the expected results of the project include the gathering of as much information as possible prior to the start of the project, such as an inventory of the various computers and their status in order to prepare the team. Prior to the start of the upgrading process, the necessary training should be undertaken by the technical staff as mentioned. Visit to the locations should be planned in such a way that the technical staff avoid doubling back and cut down on trips and trip durations, while scheduling the conduct of the upgrading during the slow cycles of the locations’ activities. Finally, the schedules should be timely communicated to the staff at the affected location so that they may be present during the upgrade procedure. References Aven, T 2004 On how to approach risk and uncertainty to support decision-making. Risk Management, volume 6, issue 4, pp. 27-39. Chin, G 2004 Agile Project Management: How to Succeed in the Face of Changing Project Management. AMACOM, New York, NY Cox, L. A., Jr. 2008 “Some limitations of “risk = threat x vulnerability x consequence for risk analysis of terrorist attacks.” Risk Analysis: An International Journal, vol. 28, issue 6, 1749-1761. Dunne, K J & Dunne, E S 2011 Translation and Localization Project Management: The Art of the Possible. John Benjamins, B.V., Amsterdam, The Netherlands Furman, J 2011 The Project Management Answer Book. Management Concepts, Inc., Vienna, VA Haimes Y. Y. 2006 . On the definition of vulnerabilities in measuring risks to infrastructures. Risk Analysis: An International Journal, vol. 26, issue 2, pp. 293-296 Haughey, D 2011 Project Management Tools. Project Smart Co., UK Accessed 20 November 2011 from http://www.projectsmart.co.uk/project-management-tools.html Kendrick, T 2004 Identifying and Managing Project Risk: Essential Tools for Failure-Proofing, 2nd edition. AMACOM, New York, NY Kerzner, H & Saladis, F P 2009 Project Management Workshop and PMP/CAPM Exam Study Guide. Virine, L & Trumper, M 2007 Project Decisions: The Art and Science. Management Concepts, Inc., Vienna, VA Read More