Project Management Knowledge Areas

Project management knowledge areas describe the key competencies that project managers mus develop. There are nine knowledge areas of project management. The four core knowledge areas of project management include project scope, time, cost, and quality management. These are core knowledge areas because they lead to specific project objectives. Brief descriptions of each core knowledge area are as follows:

• Project scope management, involves defining and managing all the work required to complete the project successfully.
• Project time management, includes estimating how long it will take to complete the work, developing an acceptable project schedule, and ensuring timely completion of the project.
• Project cost management, consists of preparing and managing the budget for the project.
• Project quality management, ensures that the project will satisfy the stated or implied needs for which it was undertaken.

The four facilitating knowledge areas of project management are human resource, communications, risk, and procurement management. These are called facilitating areas because they are the processes through which the project objectives are achieved. Brief descriptions of each facilitating knowledge area are as follows:

• Project human resource management, is concerned with making effective use of the people involved with the project.
• Project communications management, involves generating, collecting, disseminating, and storing project information.
• Project risk management, includes identifying, analyzing, and responding to risks related to the project.
• Project procurement management, involves acquiring or procuring goods and services for a project from outside the performing organization.

Project integration management, the ninth knowledge area, is an overarching function that affects and is affected by all of the other knowledge areas. Project managers must have knowledge and skills in all nine of these areas.

Project Management Offices

The concept of a project management office, sometimes referred to as the PMO, has been around for several years. You’ll find that many organizations are establishing PMOs in many different forms. PMOs might also be called project offices or program management offices. The PMO is usually a centralized organizational unit that oversees the management of projects and programs throughout the organization. The most common reason a company starts a project management office is to establish and maintain procedures and standards for project management methodologies.

In some organizations, project managers and team members might report directly to the PMO and are assigned to projects as they are initiated. In other organizations, the PMO provides support functions only for projects and trains others in project management procedures and techniques. Still others, depending on their size and function, have experts available that assist project managers in project planning, estimating, and business assumption verification tasks. They serve as mentors to junior-level project managers and act as consultants to the senior project managers.

The PMO usually has responsibility for maintaining and archiving project documentation for future reference. This office compares project goals with project progress and gives feedback to the project teams. It also measures the project performance of active projects and suggests corrective actions. The PMO evaluates completed projects for their adherence to the project plan and asks questions like “Did the project meet the time frames established?” and “Did it stay within budget?” and “Was the quality acceptable?”

Project management offices are becoming more common in organizations today, if for no other reason than to serve as a collection point for project documentation. Some PMOs are fairly sophisticated and prescribe the standards and methodologies to be used in all project phases across the enterprise. Still others provide all these functions and also offer project management consulting services. However, the establishment of a PMO is not required in order for you to apply good project management practices to your next project.

Understanding the Project Environment

Virtually all projects are planned and implemented in a social, economic, and environmental context, and have intended and unintended positive and/or negative impacts. The project team should consider the project in its cultural, social, international, political, and physical environmental contexts.

• Cultural and social environment. The team needs to understand how the project affects people and how people affect the project. This may require an understanding of aspects of the economic, demographic, educational, ethical, ethnic, religious, and other characteristics of the people whom the project affects or who may have an interest in the project. The project manager should also examine the organizational culture and determine whether project management is recognized as a valid role with accountability and authority for managing the project.
• International and political environment. Some team members may need to be familiar with applicable international, national, regional, and local laws and customs, as well as the political climate that could affect the project. Other international factors to consider are time-zone differences, national and regional holidays, travel requirements for face-to-face meetings, and the logistics of teleconferencing.
• Physical environment. If the project will affect its physical surroundings, some team members should be knowledgeable about the local ecology and physical geography that could affect the project or be affected by the project.

Application Area Knowledge, Standards and Regulations

Application areas are categories of projects that have common elements significant in such projects, but are not needed or present in all projects. Application areas are usually defined in terms of:

• Functional departments and supporting disciplines, such as legal, production and inventory management, marketing, logistics, and personnel
• Technical elements, such as software development or engineering, and sometimes a specific kind of engineering, such as water and sanitation engineering or construction engineering
• Management specializations, such as government contracting, community development, and new product development
• Industry groups, such as automotive, chemical, agriculture, and financial services.

Each application area generally has a set of accepted standards and practices, often codified in regulations. The International Organization for Standardization (ISO) differentiates between standards and regulations as follows:

• A standard is a document established by consensus and approved by a recognized body that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context. Some examples of standards are computer disk sizes and the thermal stability specifications of hydraulic fluids.
• A regulation is a government-imposed requirement, which specifies product, process or service characteristics, including the applicable administrative provisions, with which compliance is mandatory. Building codes are an example of regulations.

There is an overlap in the concepts of standards and regulations that cause confusion. For example:

• Standards often begin as guidelines that describe a preferred approach and later, with widespread adoption, become generally accepted as if they were regulations
• Different organizational levels can mandate compliance, such as when a government agency, the management of the performing organization, or the project management team establishes specific policies and procedures.

Reference: A Guide to the Project Management Body of Knowledge (PMBOK ® Guide)

Project Phases and Project Life Cycles

All projects are divided into phases, and all projects, large or small, have a similar life cycle structure. At a minimum, a project will have a beginning or initiation phase, an intermediate phase or phases, and an ending phase. The number of phases depends on the project complexity and the industry. For example, information technology projects might progress through phases such as requirements, design, program, test, and implement. All the collective phases the project progresses through in concert are called the project life cycle.

The end of each phase allows the project manager, stakeholders, and project sponsor the opportunity to determine whether the project should continue to the next phase. In order to progress to the next phase, the deliverable from the phase before it must be reviewed for accuracy and approved. As each phase is completed, it’s handed off to the next phase. You’ll look at handoffs and progressions through these phases next.

Handoffs
Project phases evolve through the life cycle in a series of phase sequences called handoffs, or technical transfers. The end of one phase sequence typically marks the beginning of the next. However, the completion of one phase does not automatically signal the beginning of the next phase. For example, in the construction industry, feasibility studies often take place in the beginning phase of a project.

The purpose of the feasibility study is to determine whether the project is worth undertaking and whether the project will be profitable to the organization. A feasibility study is a preliminary assessment of the viability of the project; the viability or perhaps marketability of the product, service, or result of the project; and the project’s value to the organization. It might also determine whether the product, service, or result of the project is safe and meets industry or governmental standards and regulations. The completion and approval of the feasibility study triggers the beginning of the requirements phase, where requirements are documented and then handed off to the design phase, where blueprints are produced. The feasibility might also show that the project is not worth pursuing and the project is then terminated; thus, the next phase never begins.

Phase Completion
You will recognize phase completion because each phase has a specific deliverable, or multiple deliverables, that marks the end of the phase. A deliverable is an output that must be produced, reviewed, and approved to bring the phase or project to completion. Deliverables are tangible and can be measured and easily proved. For instance, a hypothetical deliverable produced in the beginning phase of a construction industry project would be the feasibility study.

Deliverables might also include things such as design documents, project budgets, blueprints, project schedules, prototypes, and so on. This analysis allows those involved with the opportunity to determine whether the project should continue to the next phase. The feasibility study might show that environmental impacts of an enormous nature would result if the construction project were undertaken at the proposed location. Based on this information, a go or no-go decision can be made at the end of this phase. The end of a phase gives the project manager the ability to discover, address, and take corrective action against errors discovered during the phase.

Sometimes phases are overlapped to shorten or compress the project schedule. This is called
fast tracking. Fast tracking means that a later phase is started prior to completing and approving the phase, or phases, that come before it. This technique is used to shorten the overall duration of the project.

Most projects follow phase sequences within a project life cycle and, as a result, have the following characteristics in common: In the beginning phase, which is where the project is initiated, costs are low, and few team members are assigned to the project. As the project progresses, costs and staffing increase and then taper off at the closing phase. The potential that the project will come to a successful ending is lowest at the beginning of the project; its chance for success increases as the project progresses through its phases and life cycle stages. Risk is highest at the beginning of the project and gradually decreases the closer the project comes to completion.

Stakeholders have the greatest chance of influencing the project and the characteristics of the product, service, or result of the project in the beginning phases and have less and less influence as the project progresses. This same phenomenon exists within the project management processes as well.