Project management is the discipline of defining and achieving targets while optimizing (or just allocating) the use of resources (time, money, people, materials, energy, space, etc) over the course of a project (a set of activities of finite duration).

Project Management is quite often the province and responsibility of an individual project manager. This individual seldom participates directly in the activities that produce the end result, but rather strives to maintain the progress and productive mutual interaction of various parties in such a way that overall risk of failure is reduced.

In contrast to on-going, functional work, a project is "a temporary endeavor undertaken to create a unique product or service." The duration of a project is the time from its start to its completion, which can take days, weeks, months or even years. Typical projects include the engineering and construction of various public or consumer products, including buildings, vehicles, electronic devices, and computer software.

In recent years, the Project Management discipline has been applied to Marketing and Advertising endeavors as they become more technologically oriented, and as multiple communication channels become part of the marketing mix.

 

 

Project Management activities

Project Management is composed of several different types of activities such as:

1. Planning the work
2. Assessing risk
3. Estimating resources
4. Organizing the work
5. Acquiring human and material resources
6. Assigning tasks
7. Directing activities
8. Controlling project execution
9. Reporting progress
10. Analyzing the results based on the facts achieved

Project control variables

Project Management tries to gain control over five variables:

• time - The amount of time required to complete the project. Typically broken down for analytical purposes into the time required to complete the components of the project, which is then further broken down into the time required to complete each task contributing to the completion of each component.
• cost - Calculated from the time variable. Cost to develop an internal project is time multiplied by the cost of the team members involved. When hiring an independent consultant for a project, cost will typically be determined by the consultant or firm's hourly rate multiplied by an estimated time to complete.
• quality - The amount of time put into individual tasks determines the overall quality of the project. Some tasks may require a given amount of time to complete adequately, but given more time could be completed exceptionally. Over the course of a large project, quality can have a significant impact on time and cost (or vice versa).
• scope - Requirements specified for the end result. The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish.
• risk - Potential points of failure. Most risks or potential failures can be overcome or resolved, given enough time and resources. According to some definitions risk can also be negative, meaning that there is an opportunity to e.g. complete the project faster than expected.

Three of these variables can be given by external or internal customers. The value(s) of the remaining variable(s) is/are then set by project management, ideally based on solid estimation techniques. The final values have to be agreed upon in a negotiation process between project management and the customer. Usually, the values in terms of time, cost, quality and scope are contracted.

History of Project Management

Project Management was used as an isolated concept before the Sputnik crisis of the Cold War. After this crisis, the United States Department of Defense needed to speed up the military project process. New tools (models) for achieving this goal were invented. In 1958 they invented the Program Evaluation and Review Technique or PERT, as part of the Polaris missile submarine program. At the same time, the DuPont corporation invented a similar model called CPM, critical path method. PERT was later extended with a work breakdown structure or WBS. The process flow and structure of the military undertakings quickly spread into many private enterprises.

Approaches

There are several approaches that can be taken to managing project activities including agile, iterative, incremental, and phased approaches.

A traditional phased approach identifies a sequence of steps to be completed. This contrasts with the agile software development or flexible product development approach at the other end of the spectrum, in which 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.

Regardless of the approach employed, careful consideration needs to be given to clarity surrounding project objectives, goals, and importantly, the roles and responsibilities of all participants and stakeholders.

The traditional approach

In the traditional approach, we can distinguish 5 components of a project (4 stages plus control) in the development of a project:

1. project initiation
2. project planning
3. project production or execution
4. project monitoring or controlling
5. project completion

Not all projects will visit every stage as projects can be terminated before they reach completion. Some projects probably don't have the planning and/or the monitoring. Some projects will go through steps 2, 3 and 4 multiple times.

Many industries utilize variations on these stages. For example, in bricks and mortar architectural design, projects typically progress through stages like Pre-Planning, Conceptual Design, Schematic Design, Design Development, Construction Drawings (or Contract Documents), and Construction Administration. While the names may differ from industry to industry, the actual stages typically follow common steps to problem solving--defining the problem, weighing options, choosing a path, implementation and evaluation.

Critical chain is an extension to the traditional critical path method.

In critical studies of project management, it has been noted that several of these fundamentally PERT-based models are not well suited for the multi-project company environment of today. Most of them are aimed at very large-scale, one-time, non-routine projects, and nowadays 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, for example 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.

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) and ISO/IEC15504 (SPICE - Software Process Improvement and Capability dEtermination), which have been far more successful.

Agile project management approaches based on the principles of human interaction management are founded on a process view of human collaboration.

Auditing

Auditors may be involved in projects to varying degrees, from a post-implementation review to thorough involvement of each step in the process. Each project should be assessed for risk to determine the appropriate level of review needed. In addition, auditors should consider how important the projects are to the financial statements, the degree of reliance on controls, and the existence of manual controls.

Process risks include:

• Lack of a formal development process
• Unclear strategy
• Lack of concrete standards
• Poor management control

Application risks include:

• High complexity of the project
• Larger projects
• Lack of end-user involvement
• Inadequate personnel

Auditor Review and Recommendations

Auditors should review the development process and procedures, even if they are not involved in a particular project. This review should evaluate the procedures and 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.

In making recommendations, auditors should consider the cost of implementing controls and alternatives such as manual controls. Recommendations should be forwarded to the development team leader, management, or the audit committee depending on the business. Clarifying the cost to the business if the control is not implemented in terms of errors, fixes, and additional audit fees.

Auditing Formal Software Development Processes

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:

• An information systems strategy to align development with the organization’s broader objectives
• Standards for new systems
• Project management policies for timing and budgeting
• Procedures describing the process

Auditing The System Development Process

Regardless of the methodology used, the development process should have the same major steps: planning, development, implementation, and maintenance.

The planning phase determines the nature and scope of the development. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business’s needs. The auditor’s key role in this phase is to understand the business environment and to make sure that all necessary controls are incorporated into the design. Any deficiencies should be reported and a recommendation should be made to fix them.

In this planning stage, auditors look for a cohesive plan that encompasses the following areas:

• Study analyzing the business needs in measurable goals
• Review of the current system
• Conceptual design of the operation of the new system
• Equipment requirements
• Financial analysis of the costs and benefits including a budget
• Select programmers, users, and support personnel for the project
• Project plan including tasks, deliverables, and schedule

After the planning phase, the system is built and tested. Testing is generally performed by a combination of testers and end users. Testing can occur after the product is built or concurrently. Auditors should review the construction and testing procedures and results to ensure that the product will process data accurately, that errors are minimized, and that it meets specifications. Testing verifies these factors:

• The product satisfies the user and business requirements
• Functions as it was designed
• Works with hardware and other software
• Is free of errors

The implementation phase includes:

• Conversion
• Documentation
• Training

In software systems, conversion is the transfer of data from an old system to a new system. This process is often difficult and should be tested carefully for errors. Documentation is prepared both for implementers and end users to facilitate their different needs in understanding the system. Training increases user efficiency. From an auditor's perspective, training is also important because it helps users use the software correctly.

Maintenance

In software products, maintenance is an ongoing process, and it includes:

• Continuing support of end users
• Correction of errors
• Updates of the software over time

In this stage, auditors should pay attention to how effectively and quickly user problems are resolved.

Project management and professional certification

There have been several attempts to develop project management standards, such as:

• ISO 10006:1997, Quality management - Guidelines to quality in project management
• A Guide to the Project Management Body of Knowledge (PMBOK Guide)
• APM Body of Knowledge 5th ed. (APM - Association for Project Management (UK))
• P2M (A guidebook of Project & Program Management for Enterprise Innovation, japanese third-generation project management method)
• PRINCE2 (PRojects IN a Controlled Environment)
• V-Modell (German project management method)
• HERMES (The Swiss general project management method, selected for use in Luxembourg and international organisations)
• ISEB Project Management Syllabus

See also: An exhaustive list of standards (maturity models)

So far, there is no known attempt to develop a project management standard available under the GNU Free Documentation License. There is a proposed Project Management XML Schema.

There is an effort by PMI to develop The Practice Standard for Scheduling. (This document is currently (May 2006) in exposure draft, which is near the end of the standards development process.)