Project Management is a unique field in that people generally don’t choose it as an initial career path. They enter via the back door through a technical field, or they want to learn project management theory with the goal of advancing into the role. For this reason, many people who practice project management are not well equipped with project management theory.
There is, however, a such thing as a project management career. In large construction, oilfield, or industrial projects, project management will consist of a team whose only job description is to manage the project. When that project completes, they seek out the next large project to manage. This is not the norm, however, as most projects in the world are small and must be administered by people from the related technical field.
On this page we will provide a brief overview of project management theory. And we do mean brief. A good textbook on the subject will run 400-500 pages long. Nonetheless, you can get a running start to seek out further knowledge.
Our central reference will be the Project Management Body of Knowledge (PMBOK) produced by the Project Management Institute (PMI). There are two other “official textbooks” on project management:
- The IPMA Competence Baseline, produced by the International Project Management Association (IMPA)
- Managing Successful Projects with PRINCE2, produced by Axelos in the UK. This documents outlines the PRINCE2 method rather proclaiming to be a comprehensive guide to project management.
Since the PMBOK guide is generally the most widely used source of project management theory in the most parts of the world, we will use it here. It can be purchased at any major book retailer, or Amazon.
Definition
Let’s start from the beginning. The definition of a project is “a temporary endeavor undertaken to create a unique product, service, or result.” Notice the following two key words within that definition:
- Temporary: It has a defined start and finish date. Some projects seem to go on and on forever, taking up space in the budget like an unwanted house pest. But this is not healthy.
- Unique: It produces a product or service that is specific to that project. The product can be similar, or even exactly like, another project, but they are two distinct products.
Organization of a Project
Before we go any further, we need to establish the basic organizational structure of a project. The key people involved in a project are defined as follows:
- Project Sponsor. One level above the project manager, this person is the organizational contact for the project. They often deal with funding the project, providing resources and support and are usually accountable for project success. They can be internal or external to the organization carrying out the project.
- Project Manager. The person that handles the day-to-day administration of the project and project team, and is directly accountable for its success. Large projects can be managed by a project management team.
- Project Team. The person or people who perform the project’s technical work, reporting to the project manager.
- Stakeholders. A party that has an interest in the work being performed by the project. This ranges from investors to affected parties to government regulators. I often refer to the project sponsor as a stakeholder – they are effectively the most important stakeholder – although this might confuse the definition a bit.
Phases of a Project
The foundation upon which the PMBOK is built consists of the five phases that every project goes through:
- Initiating. The tasks required to authorize, fund and define the project, generally on the organizational level (above the project). The organization defines a business need the project is meant to satisfy.
- Planning. The project management team define how the project will be carried out, who will do the work, how long it will take, and so forth. The planning phase should define the project in sufficient detail that all stakeholders’ expectations are understood.
- Execution. The project work is completed and the end product or service is achieved while secondary stakeholder requirements are satisfied.
- Monitoring & Controlling. Concurrent to the project work (execution phase) the project management team monitors and controls all aspects of the project – schedule, cost, stakeholder’s requirements, etc. If any part causes problems, changes to the project plan are made.
- Closing. The project has completed it’s product or service, and the project must be closed.
Just to make it sound more complicated than it is, these phases are also called process groups, but in this tutorial we will try to use the term phase wherever possible.
In each phase, one or more project management documents are created. These consist of:
| Phase | Project Documents |
|---|---|
| Initiating |
|
| Planning |
|
| Execution |
|
| Monitoring |
|
| Closing |
|
The part that is frequently underestimated is the second phase: Project planning. The Project Management Institute has suggested that planning effort be roughly 20-30% of the total work. This may seem like alot but believe me, it reduces problems further on.
In fact, the planning group is by far the largest within the PMBOK. It contains more than half of the processes even though it is one out of five process groups. The project management plan that is generated during the planning phase encompasses all of the knowledge areas, and it should be scaled to the size of the project.
Knowledge Areas
The five project phases (i.e. process groups) are in chronological order, but within each phase are various parts of different “knowledge areas.” Thus, the ten knowledge areas are encountered at various times during a project.
The knowledge areas are:
- Project Integration Management. The stuff that doesn’t fit in any other category, like developing the project management plan itself, making changes to the project, etc.
- Project Scope Management. Scope is the work that is included in the project. It should be defined in the planning phase (i.e. the project management plan) and changes should be well defined.
- Project Time Management. Creating, monitoring and enforcing the project schedule, milestones, and completion dates.
- Project Cost Management. Estimating the project costs, and monitoring and controlling them throughout the project.
- Project Quality Management. Determining the quality standards that apply to the project, and monitoring the quality of work produced.
- Project Human Resource Management. Ascertaining the people requirements of the project, acquiring them, and developing them to ensure they produce the required results.
- Project Communications Management. Establishing the communication needs of each stakeholder, and making sure they are involved to the required degree.
- Project Risk Management. Figuring out who the biggest alligators under the bed are, and how to make sure you never see them.
- Project Procurement Management. Hiring the outside consultants and contractors necessary to get the job done, and managing them.
- Project Stakeholder Management. Identifying each stakeholder and making sure they’re happy.
The Project Management Plan
The project management plan is the central foundation of project management, and as such we will focus a separate section on it. It is a document that gives the project manager their direction throughout the project, aiding in decision making. It manages the stakeholder’s expectations. But most importantly, it tells the project sponsor, who is usually the project manager’s boss, how the project will be managed. Thus, it can also be a career-changer.
It should contain enough detail to define the project so that all stakeholders understand how the project will be managed. When project changes occur (deadlines, budgets, etc.) the project management plan should be updated. The project manager should always have a current “plan.”
This plan should be available to all project stakeholders, if not directly provided to them. But the project sponsor should absolutely be familiar with it and understand how the project is being managed.
The Other Documents
The other documents which round out my list of introductory project management documents are:
- Project Charter
Optional for small projects, this document authorizes the project to proceed, outlines funding status, and provides an overview of the project from the organizational point of view. - Status updates
Since a project has a finite beginning and end, providing regular status updates during project execution is very important. The frequency and amount of detail depends on the project, of course, but the existence of status updates is almost universal to good project management. - Stakeholder communications
As a minimum, the project manager must communicate with the project sponsor and project team throughout the project. On top of that, almost all projects have stakeholders who are either actively influencing the outcome, passively interested in the outcome, or actively opposed to the outcome. Correspondence that can influence the project success should be in writing, even email if possible. Keep a paper trail. - Variance analysis
This involves the calculation of, as a minimum, the cost variance and schedule variance. It requires an estimate of the percent complete of each task, and the resulting variance (cost or schedule) tells you how far ahead or behind the project is. This is an excellent early warning signal for project distress, and takes only about 5 minutes once you’ve figured out how to do it via spreadsheets or project management software. That’s why I include it within introductory project management. - Project change documentation
When a change is made to the project management plan, it should be documented. For small projects this could be as simple as an “update log” within the project management plan. The important thing is not so much the format, but the underlying concept that the project has been planned out and changes to it need to be official. All project changes should be approved and signed off by the project sponsor. Change can involve the schedule (deadlines), costs, quality requirements, etc. - Final Reporting
Projects virtually always need some sort of closure. Final details of the product as-built, as-designed, or as-performed, and completion certificates for vendors’ contracts. This tends to be underrated while at the same time it tends to be highly visible to the project manager’s bosses. Do your career a favor and close the project well.
Navigation
- Next Page: Project Management Plan
- Home: Project Management Tutorial
