Project management

Project management is the discipline of planning, organizing, securing, and managing resources to achieve specific goals. A project is a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables) undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. The temporary nature of projects stands in contrast with business as usual (or operations), which are repetitive, permanent, or semipermanent functional activities to produce products or services. In practice, the management of these two systems is often quite different, and as such requires the development of distinct technical skills and management strategies. The primary challenge of project management is to achieve all of the project goals[] and objectives while honoring the preconceived constraints.[ Typical constraints are scope, time, and budget.[ The secondaryand more ambitiouschallenge is to optimize the allocation and integrate the inputs necessary to meet pre-defined objectives.

History

Roman soldiers building a fortress, Trajan's Column113 AD

Project management has been practiced since early civilization. Until 1900 civil engineering projects were generally managed by creative architects, engineers, and master builders themselves, among those for example Vitruvius (1st century BC),Christopher Wren (1632 1723), Thomas Telford (17571834) and Isambard Kingdom Brunel (18061859). It was in the 1950s that organizations started to systematically apply project management tools and techniques to complex engineering projects.

Henry Gantt (18611919), the father of planning and control techniques. As a discipline, Project Management developed from several fields of application including civil construction, engineering, and heavy defense activity. Two forefathers of project management are Henry Gantt, called the father of planning and control techniques, [ who is famous for his use of the Gantt chart as a project management tool; and Henri Fayol for his creation of the 5 management functions which form the foundation of the body of knowledge associated with project and program management. Both Gantt and Fayol were students of Frederick Winslow Taylor's theories of scientific management. His work is the forerunner to modern project management tools including work breakdown structure (WBS) and resource allocation. The 1950s marked the beginning of the modern Project Management era where core engineering fields come together working as one. Project management became recognized as a distinct discipline arising from the management discipline with engineering model. In the United States, prior to the 1950s, projects were managed on an ad hoc basis using mostly Gantt Charts, and informal techniques and tools. At that time, two mathematical project-scheduling models were developed. The "Critical Path Method" (CPM) was developed as a joint venture between DuPont Corporation and Remington Rand Corporation for managing plant maintenance projects. And the "Program Evaluation and Review Technique" or PERT, was

developed by Booz Allen Hamilton as part of the United States Navy's (in conjunction with the Lockheed Corporation) Polaris missile submarine program; These mathematical techniques quickly spread into many private enterprises.

PERT network chart for a seven-month project with five milestones At the same time, as project-scheduling models were being developed, technology for project cost estimating, cost management, and engineering economics was evolving, with pioneering work by Hans Lang and others. In 1956, the American Association of Cost Engineers (now AACE International; the Association for the Advancement of Cost Engineering) was formed by early practitioners of project management and the associated specialties of planning and scheduling, cost estimating, and cost/schedule control (project control). AACE continued its pioneering work and in 2006 released the first integrated process for portfolio, program and project management (Total Cost Management Framework). The International Project Management Association (IPMA) was founded in Europe in 1967,as a federation of several national project management associations. IPMA maintains its federal structure today and now includes member associations on every continent except Antarctica. IPMA offers a Four Level Certification program based on the IPMA Competence Baseline (ICB). The ICB covers technical competences, contextual competences, and behavioral competences.

In 1969, the Project Management Institute (PMI) was formed in the USA. PMI publishes A Guide to the Project Management Body of Knowledge (PMBOK Guide), which describes project management practices that are common to "most projects, most of the time." PMI also offers multiple certifications.

Approaches
There are a number of approaches to managing project activities including agile, interactive, incremental, and phased approaches. Regardless of the methodology employed, careful consideration must be given to the overall project objectives, timeline, and cost, as well as the roles and responsibilities of all participants and stakeholders.

The traditional approach

A traditional phased approach identifies a sequence of steps to be completed. In the "traditional approach", five developmental components of a project can be distinguished (four stages plus control):

Typical development phases of an engineering project

initiation; planning and design; execution and construction; monitoring and controlling systems; completion.

Not all projects will visit every stage, as projects can be terminated before they reach completion. Some projects do not follow a

structured planning and/or monitoring process. Some projects will go through steps 2, 3 and 4 multiple times. Many industries use variations of these project stages. For example, when working on a brick and mortar design and construction, projects will typically progress through stages like Pre-Planning, Conceptual Design, Schematic Design, Design Development, Construction Drawings (or Contract Documents), and Construction Administration. In software development, this approach is often known as the waterfall model,i.e., one series of tasks after another in linear sequence. In software development many organizations have adapted the Rational Unified Process (RUP) to fit this methodology, although RUP does not require or explicitly recommend this practice. Waterfall development works well for small, well defined projects, but often fails in larger projects of undefined and ambiguous nature. The Cone of Uncertainty explains some of this as the planning made on the initial phase of the project suffers from a high degree of uncertainty. This becomes especially true as software development is often the realization of a new or novel product. In projects where requirements have not been finalized and can change, requirements management is used to develop an accurate and complete definition of the behavior of software that can serve as the basis for software development. While the terms may differ from industry to industry, the actual stages typically follow common steps toproblem solving"defining the problem, weighing options, choosing a path, implementation and evaluation."

Critical chain project management Critical chain project management (CCPM) is a method of planning and managing projects that puts more emphasis on the resources (physical and human) needed in order to execute project tasks. The most complex part involves engineering professionals of different fields (Civil, Electrical, Mechanical etc.) working together. It is an application of the Theory of Constraints (TOC) to projects. The goal is to increase the rate of throughput (or completion rates) of projects in

an organization. Applying the first three of the five focusing steps of TOC, the system constraint for all projects is identified as are the resources. To exploit the constraint, tasks on the critical chain are given priority over all other activities. Finally, projects are planned and managed to ensure that the resources are ready when the critical chain tasks must start, subordinating all other resources to the critical chain. Regardless of project type, the project plan should undergo Resource leveling, and the longest sequence of resource-constrained tasks should be identified as the critical chain. In multi-project environments, resource leveling should be performed across projects. However, it is often enough to identify (or simply select) a single "drum" resourcea resource that acts as a constraint across projects and stagger projects based on the availability of that single resource.

Extreme project management

In critical studies of project management it has been noted that several PERT based models are not well suited for the multi-project company environment of today. Most of them are aimed at very largescale, one-time, non-routine projects, and currently all kinds of management are expressed in terms of projects. Using complex models for "projects" (or rather "tasks") spanning a few weeks has been proven to cause unnecessary costs and low maneuverability in several cases. Instead, project management experts try to identify different "lightweight" models, such as Agile Project Management methods including Extreme Programming for software development and Scrum techniques. The generalization of Extreme Programming to other kinds of projects is extreme project management, which may be used in combination with the process modeling and management principles of human interaction management.

Event chain methodology

Event chain methodology is another method that complements critical path method and critical chain project management methodologies. Event chain methodology is an uncertainty modeling and schedule network analysis technique that is focused on identifying and managing events and event chains that affect project schedules. Event chain methodology helps to mitigate the negative impact of psychological heuristics and biases, as well as to allow for easy modeling of uncertainties in the project schedules. Event chain methodology is based on the following principles. Probabilistic moment of risk: An activity (task) in most reallife processes is not a continuous uniform process. Tasks are affected by external events, which can occur at some point in the middle of the task.

Event chains: Events can cause other events, which will create event chains. These event chains can significantly affect the course of the project. Quantitative analysis is used to determine a cumulative effect of these event chains on the project schedule. Critical events or event chains: The single events or the event chains that have the most potential to affect the projects are the critical events or critical chains of events. They can be determined by the analysis. Project tracking with events: Even if a project is partially completed and data about the project duration, cost, and events occurred is available, it is still possible to refine information about future potential events and helps to forecast future project performance. Event chain visualization: Events and event chains can be visualized using event chain diagrams on a Gantt chart.

PRINCE2

The PRINCE2 process model PRINCE2 is a structured approach to project management, released in 1996 as a generic project management method. It combined the original PROMPT methodology (which evolved into the PRINCE

methodology) with IBM's MITP (managing the implementation of the total project) methodology. PRINCE2 provides a method for managing projects within a clearly defined framework. PRINCE2 describes procedures to coordinate people and activities in a project, how to design and supervise the project, and what to do if the project has to be adjusted if it does not develop as planned. In the method, each process is specified with its key inputs and outputs and with specific goals and activities to be carried out. This allows for automatic control of any deviations from the plan. Divided into manageable stages, the method enables an efficient control of resources. On the basis of close monitoring, the project can be carried out in a controlled and organized way. PRINCE2 provides a common language for all participants in the project. The various management roles and responsibilities involved in a project are fully described and are adaptable to suit the complexity of the project and skills of the organization. Process-based management Also furthering the concept of project control is the incorporation of process-based management. This area has been driven by the use of Maturity models such as the CMMI (capability maturity model integration; see this example of a predecessor) and ISO/IEC15504 (SPICE software process improvement and capability estimation). Agile project management Agile project management approaches based on the principles of human interaction management are founded on a process view of human collaboration. This contrasts sharply with the traditional approach. In the agile software development or flexible product developmentapproach, the project is seen as a series of relatively small tasks conceived and executed as the situation demands in an adaptive manner, rather than as a completely pre-planned process.

Processes

The project development stages Traditionally, project management includes a number of elements: four to five process groups, and a control system. Regardless of the methodology or terminology used, the same basic project management processes will be used. Major process groups generally include: initiation

planning or development production or execution monitoring and controlling closing

In project environments with a significant exploratory element (e.g., research and development), these stages may be supplemented with decision points (go/no go decisions) at which the project's continuation is debated and decided. An example is the stage-gate model.

Initiating

Initiating process group processes The initiating processes determine the nature and scope of the project.

- take the ideas and intentions of a group of people who see the need for a project in their organization and convert them into a formal, planned, resourced and funded project, in a way that - clearly and explicitly defines the objectives and scope of the project, - develops an overall schedule of activities and resources (project plan) required to carry out the whole project, - develops a detailed schedule of activities and resources (stage plan) required to carry out the next stage of the project, - defines a project organization structure which can be used to effectively manage and carry out the necessary work, - establishes a convincing business case for the project, - gains commitment and approval to the project from the appropriate level of senior management, so that - the project is firmly set up for success, and

- the probability of producing a high quality product on budget and on schedule is maximized. Overview At the start of any project, there will be a variety of ideas and opinions about the purpose and scope of the project, what the final product of the project will be, and how the project will be carried out. The Project Initiation Stage is concerned with taking these ideas and intentions and developing them into a formal, planned, resourced and funded project. In order to define a project in this way, it is first necessary to clearly and explicitly define what the project is intended to achieve and what its scope of interest will be. By defining this first, a benchmark is created for assessing the quality of what is actually produced at the end of the project. It is also necessary to develop a process by which the project objectives can be achieved. This process will typically involve carrying out a number of tasks and producing a number of products during the course of the project. The tasks produce the products. For clarity of purpose and for control reasons it is useful to arrange these tasks in a top down structure, which progressively specify the required work in more detail. This is called a work breakdown structure. LBMS provides a series of standard work breakdown structures for strategic planning and applications development. However, it is important to look for opportunities to customize this for the particular circumstances of the project and its objectives. The work breakdown structure will provide a benchmark by which the quality of the project process can be assessed. The Project Initiation Stage must also define what resources and associated time commitment are required to carry out the project. The work breakdown structure provides a basis from which this estimation can be carried out. The resource and time commitment can be used to calculate an end date for the project and an estimate of its cost. This information is key input into the establishment of a business case for the intended project. The overall project schedule is not at a sufficient level of detail to enable the allocation of actual resources to tasks, or to control progress. It is necessary to produce a more detailed plan for these purposes. This

detailed plan is only produced for the next stage of the project, usually covering an elapsed time of two to four months. The way the project is managed and executed is the key to its success. The involvement of the right people for data capture and decision making is also crucial. It is necessary to identify and recruit these people at the start of the project and to define the project organization structure. It is also necessary to establish the procedures that will be used by the people in the Project Organization Structure to carry out and control the project work. Finally, in order to establish a resourced and funded project, it is necessary to establish a clear and convincing business case for the project. This business case should be reviewed, and hopefully accepted by management. The business case will identify the projected benefits of meeting the objectives of the project, and balance these against the costs and risks associated with realizing these benefits. The business case can also be used as a benchmark to compare against actual results, costs and benefits in order to assess the ultimate success of the project. The Project Initiation stage is described here as a sequence of steps. In reality, once the objective and scope have been defined, many of these steps occur in parallel, and the step products are developed iteratively, since there are many dependencies between the steps. It is necessary to plan the Project Initiation stage, albeit in an informal manner. Therefore it is important to create a Project Initiation Kick Off Plan scheduling the activities and resources. At the start of the project it will be necessary to classify the project by size: - Small (3 to 20 elapsed days) - Medium (1 to 3 elapsed months) - Large (4 to 9 months). Projects of greater than 9 months should be organized as a program containing multiple, but discrete, medium and large projects. Regardless of size, all projects will need to address the factors described above. What will vary is how long it takes to execute, and the detail of

the product. Project Initiation should be conducted in a relatively short timeframe when compared to the rest of the project. Small projects should take one or two days, whereas medium to large may take two to four elapsed weeks. Small projects will produce a Project Initiation Checklist. Medium and large projects will produce a Project Initiation Report. The Project Initiation Report is an overall plan for carrying out the whole project, and a more detailed plan for the next stage of the project. It consists of: - clearly defined objective, - clearly defined dimensions of scope, - overall schedule of activities for the project (project plan), - project organization, - clearly defined project control procedures to check and confirm quality, usage of resources, costs and time, manage change and track issues, - clearly stated business justification for the project, - project budget. In addition to the above, the plan for the next stage consists of: - detailed schedule of activities for the stage (stage plan), - quality review standards for products to be produced, - identified resources and associated costs , - control tolerances. By completing the Project Initiation Stage, the chances of a successful conclusion to the project will significantly increase. Upon completion of the Project Initiation stage the Project Board will make one of two decisions:

- Go / No Go for the whole project. - Go / No Go for the next stage. The "go / no go" decision for the whole project generally applies to small and medium projects, where the detailed stage plan will be for the whole project. The "go / no go" decision for the next stage generally applies to large projects. The next stage will usually be a detailed analysis of requirements. At the conclusion of this stage the project plan will be updated and a detailed stage plan for the next stage created. A recommendation to proceed will then be taken to the Capital Aquisition Committee (CAC) for funding the entire project.

Step 01: Description

Project Kick Off

Objective To - produce a plan which defines how to perform the Project Initiation Stage itself, in a way that - ensures the involvement and commitment of the key people who see the need for the project and also of those who will fund it, - takes account of the background to the project and of previous and related initiatives, - establishes a team to carry out the Project Initiation Stage, so that - a clear and explicit plan is available for setting up the project. Overview As the Project Initiation Stage is concerned primarily with producing a plan for the overall project, so the Project Kick Off Step is concerned with producing a plan for the Project Initiation Stage.

Project Kick Off is therefore concerned with producing a plan of the work required to produce a plan for the whole project. The Project Kick Off step is concerned with carrying out a high level review of the background to the project and of related initiatives, recruiting the involvement of those senior people who will be the ultimate customers and sponsors of the project, reviewing and customizing the standard work breakdown structure for the Project Initiation Stage and setting up a small team to carry out the Project Initiation Stage. The manager for the Project Initiation stage may be different to the manager of subsequent stages. When scheduling the Project Initiation activities, understand that there is great deal of interdependency between the steps. Project Kick Off should be carried out quickly. If Project Initiation Stage takes four weeks, Project Kick Off should take one day. In order to expedite this stage avoid producing a detailed plan based upon estimates for each task. Review the outline of the Project Initiation Report and determine the number and sequence of interviews, workshops and investigations that are required to create the it. The end result of the this step will be a Project Initiation Kick Off Plan listing deliverables, techniques, committed resources and timescales for the Project Initiation Stage. A Project Initiation Kick Off Report is not required for small projects. Task .010 Recruit Project Sponsor

Recruit a Project Sponsor responsible for the commitment of all resources required to successfully conduct the Project Initiation Stage and to facilitate compliance and commitment to all major project decisions. This Project Sponsor will chair the Project Board which also includes both Technical and Client representatives. Document the responsibilities to be performed by the Project Sponsor. It may only be possible to identify the Project Sponsor at this time, with other Project Board members being identified later in Project Initiation when the Project Scope is better understood.

Lack of a Project Sponsor of sufficient seniority is a major risk to the project. It is recommended that no work continues until this is achieved. Task .020 Recruit Project Initiation Stage Manager

Recruit a Stage Manager for the Project Initiation Stage who has experience in the development approach and/or the business area under study and possesses the level of experience and skill to manage the successful completion of the Stage. It is likely that the Stage Manager will also fulfill the roles of the Project Co-ordinators until later in Project Initiation. Document the responsibilities to be performed by the Stage Manager. Task .030 Review Related Studies

Review any previous studies addressing the area of interest. Ensure their content reflects the current situation. Examples include Terms of Reference, strategic level plans (Information Technology and/or Business), and on-going project documentation where there is a possibility of scope overlap. Task .040 Prepare Project Initiation Kick Off Plan

There is a great deal of interdependency between the Project Initiation steps and tasks. However it is important to define the project objective and scope first before attempting the remaining steps. Attempts to create a detailed Project Initiation plan with estimates for each and every task will take far too long. The WBS should be considered more of a checklist. It is important to apply JAD to gather high quality information in a reduced time frame. Review the activities in the Project Initiation stage and the outline of the Project Initiation Report. The steps equate to the sections of the report. It is recommended that the work be organized around producing the sections of the report. Determine what information is needed and assess the best means of gathering it. This may be in the form of research, interviews and workshops. Identify the number of workshops. For each one, specify the objective, deliverables and participants. Identify and recruit additional resources to perform the Project Initiation stage. Business Analysts will be involved in defining objective and

scope, determining organization, requirements, approach and costs, coordinating other resources, preparing the recommendation and ensuring the successful completion of the Project Initiation stage. Clients will be primarily involved in determining requirements and preparing the business justification. Systems Analysts may be involved in determining the project approach and selecting the appropriate template. Identify resources who will be required to review and approve the Project Initiation Report. Estimate the effort and elapsed time for the remaining activities. Create the Project Initiation Kick Off Plan listing deliverables, technique, committed resources, start and end dates. Ensure that each team member knows their project commitments. Document any assumptions made while producing the Kick Off Plan. Task .050 Brief The Team

Brief the project team on all aspects of the Kick Off Plan. Publish a summary for absent team members and staff who will be assigned later in the stage. Task .060 Initiate Stage Control Procedures

Initiate the control procedures that will be used during the stage and ensure that all members of the Project Organization understand the procedures and know their individual responsibilities. Initiate logs for: - quality reviews and follow-up, - change control, - issues. Create any files that are needed for the stage. These may be in paper or electronic form. Task .070 Review Project Kick Off

Review the Project Initiation Kick Off with the Project Sponsor and gain agreement to execute the Project Initiation stage.

Task .080

Kick Off Project Initiation

Arrange a formal Kick Off meeting with all the resources participating in the Project Initiation. It is important that the project in formally kicked off by the Project Sponsor in order to foster a team spirit. It will also raise the profile of the project in the organization.

Planning and design

After the initiation stage, the project is planned to an appropriate level of detail (see example of a flow-chart). The main purpose is to plan time, cost and resources adequately to estimate the work needed and to effectively manage risk during project execution. As with the Initiation process group, a failure to adequately plan greatly reduces the project's chances of successfully accomplishing its goals. Project planning generally consists of determining how to plan (e.g. by level of detail or rolling wave); developing the scope statement; selecting the planning team; identifying deliverables and creating the work breakdown structure; identifying the activities needed to complete those deliverables and networking the activities in their logical sequence; estimating the resource requirements for the activities; estimating time and cost for activities; developing the schedule; developing the budget; risk planning; gaining formal approval to begin work.

Additional processes, such as planning for communications and for scope management, identifying roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting are also generally advisable. For new product development projects, conceptual design of the operation of the final product may be performed concurrent with the project planning activities, and may help to inform the planning team when identifying deliverables and planning activities.

Executing

Executing process group processes Executing consists of the processes used to complete the work defined in the project plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan and other frameworks that might be applicable to the type of project at hand.

Monitoring and controlling

Monitoring and controlling process group processes Monitoring and controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project. The key benefit is that project performance is observed and measured regularly to identify variances from the project management plan. Monitoring and controlling includes: Measuring the ongoing project activities ('where we are'); Monitoring the project variables (cost, effort, scope, etc.) against the project management plan and the project performance baseline (where we should be); Identify corrective actions to address issues and risks properly (How can we get on track again); Influencing the factors that could circumvent integrated change control so only approved changes are implemented

In multi-phase projects, the monitoring and control process also provides feedback between project phases, in order to implement corrective or preventive actions to bring the project into compliance with the project management plan.

Project maintenance is an ongoing process, and it includes: Continuing support of end-users

Correction of errors Updates of the software over time

Monitoring and controlling cycle In this stage, auditors should pay attention to how effectively and quickly user problems are resolved. Over the course of any construction project, the work scope may change. Change is a normal and expected part of the construction process. Changes can be the result of necessary design modifications, differing site conditions, material availability, contractor-requested changes, value engineering and impacts from third parties, to name a few. Beyond executing the change in the field, the change normally needs to be documented to show what was actually constructed. This is referred to as change management. Hence, the owner usually requires a final record to show all changes or, more specifically, any change that modifies the tangible portions of the finished work. The record is made on the contract documents usually, but not necessarily limited to, the design drawings. The end product of this effort is what the industry terms as-built drawings, or

more simply, as built. The requirement for providing them is a norm in construction contracts. When changes are introduced to the project, the viability of the project has to be re-assessed. It is important not to lose sight of the initial goals and targets of the projects. When the changes accumulate, the forecasted result may not justify the original proposed investment in the project.

Closing

Closing process group processes. Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned. This phase consists of: Project close: Finalize all activities across all of the process groups to formally close the project or a project phase Contract closure: Complete and settle each contract (including the resolution of any open items) and close each contract applicable to the project or project phase.

Project controlling and project control systems Project controlling should be established as an independent function in project management. It implements verification and controlling function during the processing of a project in order to reinforce the defined performance and formal goals. The tasks of project controlling are also:

the creation of infrastructure for the supply of the right information and its update the establishment of a way to communicate disparities of project parameters the development of project information technology based on an intranet or the determination of a project key performance index system (KPI) divergence analyses and generation of proposals for potential project regulations the establishment of methods to accomplish an appropriate the project structure, project workflow organization, project control and governance creation of transparency among the project parameters Fulfillment and implementation of these tasks can be achieved by applying specific methods and instruments of project controlling. The following methods of project controlling can be applied:

investment analysis costbenefit analyses value benefit Analysis expert surveys simulation calculations risk-profile analyses surcharge calculations milestone trend analysis cost trend analysis target/actual-comparison

Project control is that element of a project that keeps it on-track, on-time and within budget. Project control begins early in the project with planning and ends late in the project with post-implementation review, having a thorough involvement of each step in the process. Each project should be assessed for the appropriate level of control needed: too much control is too time consuming, too little control is very risky. If project control is not

implemented correctly, the cost to the business should be clarified in terms of errors, fixes, and additional audit fees. Control systems are needed for cost, risk, quality, communication, time, change, procurement, and human resources. In addition, auditors should consider how important the projects are to the financial statements, how reliant the stakeholders are on controls, and how many controls exist. Auditors should review the development process and procedures for how they are implemented. The process of development and the quality of the final product may also be assessed if needed or requested. A business may want the auditing firm to be involved throughout the process to catch problems earlier on so that they can be fixed more easily. An auditor can serve as a controls consultant as part of the development team or as an independent auditor as part of an audit. Businesses sometimes use formal systems development processes. These help assure that systems are developed successfully. A formal process is more effective in creating strong controls, and auditors should review this process to confirm that it is well designed and is followed in practice. A good formal systems development plan outlines: A strategy to align development with the organizations broader objectives Standards for new systems Project management policies for timing and budgeting Procedures describing the process Evaluation of quality of change