The Project Management Body of Knowledge, or PMBOK for short, is the official set of standards for Project Management. It breaks projects and project management down into the tiniest of pieces and shows you how those pieces interact with each other. It’s full of formulas and terminology and principles that all Project Managers are expected to know. It is the basis of the Project Management Professional (PMP) exam, which certifies that the person holding the certification is well versed in the PMBOK and in officially sanctioned Project Management methodology and best practices.
So every PM follows these methodologies to the letter, right? Making sure that every project they manage goes through all of the best practices and is in perfect alignment? Well….not exactly.
The truth of the matter is that all of the given best practices and procedures in the PMBOK aren’t appropriate for every project. Think of it like graduating from university: You come out having learned all of the textbook knowledge and best practices. How a computer network should be built. How a piece of software should be coded. How a study should be designed. But once you get into the real world, you learn every quickly that you can’t always implement all of the perfect best practices because you have to work from what’s available…and what’s available often resembles something created by MacGuyver. This forces you to be selective, using the right tools and methodologies for your particular situation and skipping those that aren’t as useful.
This is particularly true when:
- You are a project team of one
- Your projects have a lot of consistency
- You are operating in a non-projectized environment
Let’s take each of these in turn to look at how and why certain methodologies and practices from the PMBOK might not be particularly helpful.
You are a Project Team of One
The definition of a Project according to the Project Management Institute (PMI) and the PMBOK is “A temporary endeavor undertaken to create a unique product, service or result”. While most of Project Management best practice see the PM as not being involved in the active execution of tasks within a project, there is technically no reason why the PM cannot be executing the project tasks as well. In fact, a lot of what you do in your every day life meets the definition of a project, and thus makes you the PM for that project.
Think about something as simple as doing your laundry. Although it feels never-ending, it is a temporary endeavor (eventually all of the laundry does get cleaned) that creates a unique result (clean clothes). In this situation, you will move through all of the Project Management Process Groups:
- You Initiate the act of doing laundry by admitting the need to do it
- You Plan the act of doing laundry by determining when to do it, how much you will do, how the clothes will be sorted, determining whether you have enough detergent, etc.
- You Execute the project by actually sorting the clothes, putting them in the washer on the appropriate cycle, rotating them to the dryer when they are done, etc.
- You Monitor/Control the project as you go, making sure that the stains came out of clothing that had them, pulling out clothing that might be in need of repair, etc.
- You Close the project by taking your now cleaned clothes and putting them away.
In this scenario, there are certain things from the PMBOK perspective that you simply will not do because it does not make any sense for you to do them. For example, from the Cost Management Knowledge area, you probably won’t be developing a budget for doing laundry before you start it. From the Resource Management area, you are not going to be developing or managing your project team while you are doing laundry, because you are the project team. From the Risk Management Knowledge Area, you probably aren’t going to perform a sensitivity analysis or a decision tree analysis to determine how best to respond to risks to your laundry project; you may simply note that if your washer breaks in the middle of the process, you will have to ask to use a neighbors or head to the laundry mat. You still perform Cost Management, Resource Management and Risk Management; you just don’t create the formal testing and reporting advised by the PMBOK because in this case it is not appropriate for your laundry project.
Your projects have a lot of consistency
I’m a big fan of working smarter, not harder. If your projects are always the same or there is a lot of consistency within your projects, this is another time when in the execution of any project you can re-use materials or items from other projects to cut down on project planning and execution. After all, there is no need to reinvent the wheel every time you want to drive your car.
One example from my life is one of the most common types of Projects I manage: Operational Audits for clients. I do several of these projects per year, and they generally have a three month timeline from start to finish. When I first started doing these audits, it took me a lot longer because there are a lot of differences. The clients are different. The institution is different. The items to address are different. The deliverable of the audit is always unique, so that makes these projects.
But in the name of working smarter not harder and seeking consistent project quality, I started standardizing what was consistent across the projects. For example, the Project Scope is always the same on these projects, so I created a template to use for that. The Project Risks are generally the same, so I created checklists and registers of those things. Project Closing is always the same, so I created templates for the final project deliverable.
By doing all of this in the beginning, now when I have one of these projects I can simply pull from my resources and tweak them as needed for the particular project I am working on.
You are operating in a non-projectized environment
Every PM’s dream is to work in a Projectized Organization. This is an organization where the PM has sole authority to assign people, resources and priorities to the project. But there are very few, if any, truly projectized organizations out there. Most of us are working within Functional Organizations, where business function managers call the shots about the way the organization operates and how resources are used; the PM has to work with what’s given within the constraints of the organization’s operating structure.
For example, my department is not considered a profit-generating center for the company. The projects we work on and the tasks we complete are part of how we differentiate ourselves from our competitors and attract new clients. Because of that, we aren’t evaluated by the company the same way as other departments when it comes to whether our department is profitable.
When I’m working on my projects I don’t really have to be as concerned about cost management as a PM in a Projectized organization would be. I don’t really need to calculate cost ratios or perform cost management to the same degree as other departments. As long as the costs I do incur for projects fall within company guidelines, for the most part I am good to go. Were I operating in a Projectized environment, or even within a profit-generating department within the company, I would have to be far more concerned about cost management and I would go into much more depth in that area of my projects.
Now all of this isn’t to say that the PMBOK is not valuable. It is the key resource for all PM’s, and PM’s should be familiar with these best practices. For example, areas of Project Management I am not as concerned in my current position or current projects (like Cost Management for example) were things that I was far more concerned with when I was the PM and Executive Director of a non-profit. That knowledge and baseline are very important for any PM. But just because you are a PM doesn’t mean you have to follow all the methodologies found in the PMBOK for every project. Part of being a PM is about tailoring the methodologies so that they are best suited for your project.