The friction between Agile and PMBOK

My career spans plenty of significant trends in the technology business. I witnessed the first dot-com bubble, navigated the 2008 Great Recession, and experienced the mania of the Artificial Intelligence gold rush. These experiences taught me that the most significant challenge we face in technology is not the technology itself but how people and organizations interact with it. The way we use technology tools is more important than the individual bits and bytes. I am attempting to put these lessons into practice as I study for the PMP exam. As an agile professional earning a PMP credential, I have identified significant friction points in how large organizations manage projects. I want to discuss those friction points and what they mean for technology and organizational dynamics.  

A little history -

When the original signatories of the Agile Manifesto gathered together, they knew existing project management techniques were not working. Technology projects went over budget, and they missed numerous deadlines. Agile suggested a better way, and countless technology professionals have embraced its romantic spirit. Today, that spirit pervades most organizations with some Agile practices used to create software.

The Project Management Insitute released the first edition of the Project Management Body of Knowledge, or PMBOK, in 1987. Seven editions later, it is the standard by which all project managers are measured. Just like the CPA proves that an accountant has professional skills, the PMP proves that a person can be trusted with millions of dollars and hundereds of people to complete projects. It does not matter if you are building a rocket ship or a new lane on an expressway. If you have a PMP, you can apply the principles of PMBOK to any project, and it will be successful. Today, just over 1.2 million people worldwide hold the PMP credential. I am knocking on the door of an elite club of professionals.

The hazing process -

Like any elite organization, becoming a member requires training and a selection process that resembles hazing. Navy SEALs endure grueling physical and mental challenges during BUDs training, ultimately earning the coveted Trident and Flintlock insignia that mark them as Navy frogmen. The PMP is not a tortuious. Prospective project managers must take a forty-hour course and pass a test. The test may seem easy at first, but the content demands a deep understanding of algebra, statistics, organizational behavior theory, administrative paperwork, and the Tuckman and Drexler/Sibbet team development models.

What makes this test so frustrating is that the answers also run counter to most of our experience in the business world. For instance, one of the questions on the test asks, "You are finishing up a project, and the copywrite date on the bottom of the web page reads 2014 instead of 2024; what do you do?" Something like this crops up frequently in web development, so a scrum master or product owner will ask the team to fix it immediately, and it will be in the next release. It aligns with the value in the Agile manifesto, which says we should value customer collaboration over contract negotiation. The PMBOK guide says that if the original request is for 2014, the mistake is not a defect and that the project manager must follow a formal change control request before making the correction. A simple correction becomes a bureaucratic process to navigate.

I am beginning to understand why the PMBOK guide recommends this approach. Agile requires trust to operate. In a corporate environment, it isn't easy to earn the trust of others, so processes are put in place to ensure that work gets done at an acceptable level of quality. If something goes wrong, a paper trail exists to determine where the error happened in the chain of events. It also creates a level of plausible deniability so that a manager or director can say they did what was necessary so they are not at fault. This kind of paper pushing is required in low-trust environments to generate quality and eliminate fraud.

Here is the principle friction point at large organizations: agile says customer collaboration over contract negotiation, but the PMBOK guide requires numerous contract and bureaucratic processes to get work done. It boils down to trust and money. Changes and rework cost money and time, so it is in the interest of the project sponsors to keep rework to a minimum. Thus, all changes demand a formal change control process. It makes sense when you are building a bridge or a skyscraper. I also see it making sense in large enterprise development projects.

Unfortunately, vendors and businesses often weaponize these processes to stifle innovation and extract more money from it. I have been on numerous conference calls where vendors have argued that a defect is a change request because the customer did not state the exact date, time, or verbiage required on a web page. According to the agreed-upon contract, the vendor could ask for more money to fix their mistakes. It was maddening.

Getting stuff done means wandering in the shadows -

So, this is where experience comes into the picture. The answer to the question in the PMBOK guide is to run the correction through a change control board. Agile says the team quickly inspects and adapts, fixing the text error. In a low-trust environment with a vendor, a change request is filed and fast-tracked to meet customer needs. The theory of project management and agile must meet the practical matters of getting stuff done.

One of the biggest realizations I have discovered is that the PMBOK guide predates the Agile Manifesto by thirteen years, and it is not a romantic document. Instead, it assumes the worst about business people and their motivations. It is why project managers put together risk matrixes, communication plans, and change control procedures; they are often the sole individuals held accountable for failure when something goes wrong. Large projects, including software projects, have numerous points of failure. The PMBOK guide is a practical survival guide for navigating this low-trust environment.

So here I am, an Agile professional navigating the hazing process of the PMP certification. The Project Management Institute is not opposed to Agile but understands the practical concerns of businesses that demand accountability for spending. It also acknowledges that quality and trust take time to build in any endeavor. The bureaucracy is a necessary evil to get stuff done correctly.

Lewis Carol said, "Between the idea and reality lies the shadow." I am navigating the shadow realms of the Agile reformation and the PMBOK guide. I have no illusions; perhaps the friction will create a guiding light during my next project.

Until next time.