Project Management: A tool for Project Success
Kesorn Tongwan
Project Management is used as a tool to discipline all resource involved in the project to achieve the goals of the project. The objective of this paper is to indicate how project management plays an importance role to make the project succeed. It also points out the risk and risk management, which is important for the project manager to identify the risk and plan the strategy for it.Go Back To The Top
As the business has shifted from local to global, it raises the competition more intense and complex. Each company needs to improve and develop its system in order to be able to compete with others. Project management is applied to facilitate the organization to ensure that the project has done within budget, on time and meet customer expectation. Project manager needs to consider the risks that happen for each project, duration of the project, and the factor that can bring the project to succeed.Go Back To The Top
Understanding the definition of project is very crucial in order to be able to measure a success of it.
A project is a temporary endeavor, having a defined beginning and end (usually constrained by date, but can be by funding or deliverables), undertaken to meet particular goals and objectives, usually to bring about beneficial change or added value. [1]
A Guide to the Project Management Body of Knowledge (3rd edition, published by the Project Management Institute, 2004) — referred to as the PMBOK and pronounced “pimbok” — defines a project as “a temporary endeavor undertaken to create a unique product or service.” Let’s walk through this definition to clarify what a project is and is not.
First, a project is temporary. A project’s duration might be just one week or it might go on for years, but every project has an end date. You might not know that end date when the project begins, but it’s out there somewhere in the future. Projects are not the same as ongoing operations, although the two have a great deal in common. Ongoing operations, as the name suggests, go on indefinitely; you don’t establish an end date. Examples include most activities of accounting and human resources departments. Next, a project is an endeavor. Resources, such as people and equipment, need to do work. The endeavor is undertaken by a team or an organization, and therefore projects have a sense of being intentional, planned events. Successful projects do not happen spontaneously; some amount of preparation and planning happens first. Finally, every project creates a unique product or service. This is the deliverable for the project and the reason that the project was undertaken. A refinery that produces gasoline does not produce a unique product. The whole idea, in this case, is to produce a standardized commodity; you typically don’t want to buy gas from one station that is significantly different from gas at another station. On the other hand, commercial airplanes are unique products. Although all Boeing 777 airplanes might look the same to most of us, each is, in fact, highly customized for the needs of its purchaser. [2]
Project management is a planning, monitoring and control of all aspects of a project and the motivation of all those involved in it to achieve the project objectives on time and to the specified cost, quality and performance (Alternative definition – The controlled implementation of defined change).[3]
Project manager is an Individual or body with authority, accountability and responsibility for managing a project to achieve specific objectives. [3] Go Back To The Top
In order to manage effectively it helps to understand the typical lifecycle of a project and how it applies to your specific project. You need to decide how the management activities of the lifecycle steps will be achieved, and precisely who will be involved. You must make sure you understand your role in making these things happen in the right way and at the right time. Much of the project management effort across the lifecycle will be driven by the owner/sponsor of the project (known as the Senior Responsible Owner (SRO)), and the Project Manager. To achieve success they will almost certainly need to draw upon the skills and experience of many others from within the organization, its partners and suppliers.[4]
Figure 1. Project Lifecycle
There are two broad issues associated with project success: the criteria used to define and measure success project success criteria and the factors that influence success project critical success factors (CSFs). Generally, project management triangle, or called iron triangle, that consists of cost, time and quality is used to measure the success of the project. Traditional project success criteria focused on the ‘iron triangle’ of meeting cost, time and quality-related objectives and, although there is general recognition in the project management community that defining project success is not so simple, a survey of 236 project managers, reported in 2002, found that iron triangle criteria were still the most commonly cited measures of project success.[5]
Project success can be distinguished between short-term and long-term success criteria. Criteria linked to the iron triangle, such as delivering projects within budget and meeting time objectives and project specifications, are short-term and measured prior to project closure. Long-term criteria, such as providing both tangible and intangible benefits, are often measured after project closure.[5]
Another factor is CSF that is based on the notion that there are a number of factors common to most projects, such as the establishment of a set of agreed project objectives that are critical to success. The general CSF (independent variable) – success criteria (dependent variable) relationship has been the focus of empirical studies in the business and management literature i.e. in relation to supply chain management and, management accounting, information systems development, human resource management, leadership and operations as well as in respect of project environments. [5]
Figure 2. Project Management Triangle [6]
Since the project is temporary and needed to be with in budget, it needs to be assigned the beginning and an end time in order to meet these aspects. Project duration was calculated as the total elapsed time for the project in calendar months. It should be noted that project duration covers all activities, including unplanned or planned lack of activity.[7] However, costs and time are not the main concern for the manager to estimate the duration of the project. Some manager also considers learning curve that is established a long the project process.
Network analysis such as PERT/CRM tool is used to estimate the duration of the project by considering costs. This technique uses the series of arrow to represent activities in the project. The arrow also shows cost of each activity; therefore, the project manager can decide to follow the path that consumes the lowest cost.
Figure 3. An example of Critical Path Methods (CRM) [8]
However, there is argument that the traditional method of crashing Project Evaluation and Review Technique (PERT) networks ignores the stochastic nature of activity completion times, reducing the stochastic model to a deterministic Critical Path Method (CPM) model and simply using activity time means in calculations. The project is then arbitrarily crashed to some desired completion date, without consideration for what the penalty for late completion of the project is. Additionally, the method ignores the fact that reducing some activity times may reduce the mean project completion time more than others, due to such factors as bottlenecks.
The traditional PERT method of crashing uses only the activity time means in calculating the critical path, reducing the stochastic model to a deterministic model. A single critical path is thus calculated and used, whereas, in reality, there may be numerous critical paths. For a large network, the probability that any given path may be the critical one may be very small. As a result, the traditional PERT method of calculating the time to complete the project is almost always too low. The extent to which PERT underestimates the completion times of projects is examined for a variety of networks by Klingel (1966). The traditional method of crashing PERT networks has been to convert the model to a deterministic model by using the means of the activity times. The network is then crashed in a series of iterative steps until the expected completion time of the project is acceptable, the cost of crashing exceeds the benefits, or all activities have been crashed as much as possible. [9]
Although, a scheduling construction project by CPM does not provide a measure of uncertainty, most of the available software is based on CPM; it is deterministic tool. The duration of each activity is assumed to have one value. Yet the time required for completing an activity in a project depends on many factors, including the following.
• Resources;
• Methods;
• Technology;
• Site condition;
• Weather; and
• Regulations.
Another tool that is useful for estimate the project duration is Earned Value Method (EVM). This technique values the project by considering learning curve of the team member. EVM is a popular project control technique that has been used successfully for managing various types of projects since 1960. Most applications of EVM are based on the assumption that project team performance is a constant function of time. The problem with this assumption for cross-disciplinary teams is that a great deal of knowledge transfer and team integration occurs during the project's initial stages. The knowledge transfer and team integration affect team performance during project implementation in a way that performance (per unit time) of the team gradually increases. This causes diffi culties when forecasting the project duration, and makes a linear project control method ineffective when tracking project progress. [11]
Figure 4. The basic earn value method [11]
Figure 5. Extension to EVM [11]
Risk occurs when the organization operates in the face of uncertainty, constrained by capability and cost. The project manager or team project needs to find the dimension that causes the risk. Risk management is usually defined as a set of principles and practices aimed at identifying, analyzing and handling risk factors to improve the chances of achieving a successful project outcome and/or avoid project failure.
Risk and risk management are also important because IT projects (including software projects) can be vehicles of delivering IT-enabled organizational change, so achieving business objectives can be critically dependent upon their success.[12]
Four common risk response strategies are found in the literature:[12]
• Avoidance. Avoidance strategies aim to prevent a negative effect occurring or impacting a project. This may involve, for example, changing the project design so that the circumstance under which a particular risk event might occur cannot arise, or so that the event will have little impact on the project if it does. For example, planned functionality might be ‘de-scoped’ to remove a highly uncertain feature to a separate phase or project in which more agile development methods might be applied to determine the requirement.
• Transference. This strategy involves shifting the responsibility for a risk to a third party. This action does not eliminate the threat to the project; it just passes the responsibility for its management to someone else. Theoretically, this implies a principal–agent relationship wherein the agent is better able to manage the risk, resulting in a better overall outcome for the project. This can be a high risk strategy because the threat to the project remains, which the principal must ultimately bear, but direct control is surrendered to the agent. Common risk transfer strategies include insurance, contracts, warranties, and outsourcing. In most cases, a risk premium of some kind is paid to the agent for taking ownership of the risk. The agent must then develop its own response strategy for the risk.
• Mitigation. Risk mitigation is one or more reinforcing actions designed to reduce a threat to a project by reducing its likelihood and/or potential impact before the risk is realized. Ultimately, the aim is to manage the project in such a manner that the risk event does not occur or, if it does, the impact can be contained to a low level (that is, to ‘manage the threat to zero’). For example, using independent testers and test scripts to verify and validate software progressively throughout the development and integration stages of a project may reduce the likelihood of defects being found post-delivery and minimize project delays due to software quality problems.
• Acceptance. Risk acceptance can include a range of passive and active response strategies. One is to passively accept that the risk exists but choose to do nothing about it other than, perhaps, to monitor its status. This may be an appropriate response when the threat is low and the source of the risk is external to the project’s control. Alternatively, the threat may be real but there is little that can be done about it until it materializes. In this case, contingencies can be established to handle the condition when and if it occurs. The contingency may be in the form of provision of extra funds or other reserves, or it may be a detailed action plan (contingency plan) that can be quickly enacted when the problem arises. Validation and maintenance of contingency plans is a critical part of this strategy to ensure that contingency plans work as expected when required.Go Back To The Top
Project management is very important for the organization to govern the project. A team leader needs to understand project lifecycle, risk and risk management in order to create the strategy for the project to be successful. Moreover, applying the proper tool during the process duration estimation by considering the iron triangle can lead to reach the goal of the project.
However, team project need to keep in mind that when the project seems to not achieve the goal, they need to know when to stop it before they are going to spend beyond the budget. Go Back To The Top
- http://en.wikipedia.org/wiki/Project_management, viewed October 31, 2009
- http://office.microsoft.com/en-us/project/HA102354821033.aspx, viewed October 31, 2009
- http://www.brunswickis.co.uk/project-management-glossary.asp, viewed October 30, 2009
- http://www.berr.gov.uk/files/file40647.pdf, viewed October 30, 2009
- Bryde, David. “Perceptions of the impact of project sponsorship practices on project success”. International Journal of Project Management. Vol. 26 Issue 8 (2008): 800-809.
- http://www.traue.com/pm/page4.html, viewed November 2, 2009
- Berlin, Stanislav , Raz, Tzvi , Glezer, Chanan , and Zviran , Moshe . “Comparison of estimation methods of cost and duration in IT projects”. Information and Software Technology. Vol. 51, Issue. 4 (2009): 738.
- http://www.ehow.com/facts_5544446_advantage-management-information-system.html, viewed October 25, 2009
- Haga, Wayne A , and Marold, Kathryn A. “A Simulation Approach to the PERT/CRM Time-cost Trade-off Problem”. Project Management Journal. Vol. 35, Issue. 2 (2004): 31.
- Omar, Anwar. “Uncertainty in Project Scheduling--Its Use in PERT/CPM Conventional Techniques”. Cost Engineering. Vol. 51 Issue 7(2009):30-34.
- Plaza, Malgorzata. Turetken, Ozgur. “A model-based DSS for integrating the impact of learning in project control”. Decision Support Systems. Vol. 47, Issue 4(2009): 488.
- Bannerman, Paul L.” Risk and risk management in software projects: A reassessment”. Journal of Systems & Software. Vol. 81 Issue 12 (2008): 2118-2133.
- Hoffer, Jeffrey A., George Joey F, and Valacich, Joseph S. Modern System Analysis and Design . Prentice Hal, 2007.
- http://www.mpmm.com/project-management-methodology.php. viewed November 1, 2009
- Hanley, Ken. “The project management triangle”. ComputerWorld, Vol. 14 Issue 6 (1998):19.
- A Kastor and K Sirakoulis “The effectiveness of resource levelling tools for Resource Constraint Project Scheduling Problem”. International Journal of Project Management. Vol. 27, Issue. 5 (2009): 493.
- http://www.hyperthot.com/pm_cscs.htm viewed October 23,2009
- http://www.baz.com/kjordan/swse625/intro.html viewed October 25,2009
- http://www.tenstep.com/open/A1.2PMvsPL.html viewed October 23,2009
- Benaroch, Michel, Lichtenstein, Yossi, and Robinson, Karl. “Real Options in Information Technology Risk Management: An Empirical Validation of Risk-Option Relationships”. MIS Quarterly. Vol. 30, Issue. 4 (2006): 827