The Four Pieces of Information You Need for a Bulletproof Project Charter

That strategy execution stuff.

Originally published in The Keys to Our Success - 2nd Edition. Available at Amazon.com

Introduction (in a land far far away, circa sometime in late 2001, or 2002)

“So wait, they need the webstore live by when?!?!” - I asked incredulously.

Prior to the annual Emmy awards, a television customer had stated that “they only volunteered to be the prototype client so that they could have a live webstore for the Emmys,” my boss (codenamed M) replied.

“Well, the prototype was only going to cost them $25,000 since our company is funding the enterprise project, and the whole point of being a prototype is that when things go wrong, the customer is not relying on a hard go-live date.”

As an enterprise-wide initiative, the total cost was well in excess of a single webstore; however, we first had to integrate it into our Enterprise Resource Planning (ERP) system and develop a platform to dynamically generate webstores from the ERP data.

“True,” he said, “but you need to figure it out anyway.”

“We are going to have to crash the schedule, work 20-hour days, I’m going to need to spend the next two months in Florida onsite with the developers, and it’s going to cost a fortune!”

Granted, leaving a Michigan winter for a few months to work in Florida was a sacrifice I was willing to make, I’m a team player after all.

“That’s fine,” M replied, “they said money was no object.”

“Everyone says that but no one means it,” I mumbled sardonically.

“Well, do the math and let them know what the cost will be,” M said, ignoring my complaints.

“Me?!?! - I thought that is why you got paid the big bucks?” I definitely did not want to be a part of that conversation.

“That sounds an awful lot like a ‘not my problem’ kind of issue there Mr. Project Manager,” M stated, signaling the end of this conversation. I hated it when he was right, which was more often than not.

Admittedly, my bedside manner was not very good 20+ years ago, but my boss at the time was an awesome leader who let me vent and we had a great working relationship (and are still friends to this day). So, after crunching the numbers I was going to experience the joy of telling a top television network company that their $25,000 webstore was going to cost them well over $400,000 in order to go live in two months in order to be available for their commercials to air. Luckily for me, even way back in 2001-2002 (ish, my recollection of the ordeal is not perfect all these years later) I had a pretty good handle on the key elements of a good project charter; or at least I hoped I did as I picked up the phone to dial the project sponsor and beg for an additional $375,000…

Summary

As unique as every project (and project charter) can be, there is one technique that has proven universally vital to my project, portfolio, program, and PMO management career. That is the ability to gather four pieces of information (CCIRs for you military types) for every charter that I have ever drafted, and the tenacity and tact required to ensure that I get them all each and every time, since this data is non-negotiable in my opinion. These key components are the triple constraints of the project (schedule, budget, and performance constraints) and strategic decompilation of the business case. While this may seem to be an easy data-gathering task, it is in fact the most difficult part of the project manager (PM) and project sponsor’s relationship.  After all, the sponsor does not usually like limitations on their project (few paying customers do), a justifiable desire even if it severely hampers the PMs options. The process is both vital to project success and is typically difficult to execute, hence it is often overlooked by PMs. With an industry-wide project failure rate close to 50%, it is imperative that we embrace best practices that increase success regardless of the personal and professional challenges they require.

What are the triple constraints?

The Project Management Institute (PMI) is a great resource for a PM’s needs; however, I feel PMI has short-changed the importance of the triple constraints in project management in recent years. Projects have limited resources, a limited schedule, and tangible deliverables that need to be met. The triple constraints, also known as the iron triangle, are a way of understanding, visualizing, and ultimately managing these limitations. The triple constraint concept originated during the Apollo Moon Program by NASA 50 years ago and does not show any signs of becoming outdated. The triple constraints include the schedule constraint (you do not have infinite time), the budget constraint (you do not have an infinite budget), and the performance constraints (the project’s output has to perform desired results).

The art of project management usually comes down to the ability to understand and manage these constraints in relation to each other. Nothing exists in a vacuum and project management is no different. These constraints are related to each other; a change in one will have an impact on the other two. From my time in the Army as a dive school student (who ultimately became a Master Diver) I had the joy of writing the General Gas Law about a billion times during our nightly homework, it states: “temperature, volume, and pressure affect a gas in such a way that a change in one factor must be balanced by a corresponding change in one or both of the others.”  In project management, the concept of the triple constraints should become a “general project management law”, though my attempts to create one, spread it into the common vernacular, and reap my riches and worldwide acclaim have so far been unsuccessful; this may be due to my aforementioned suboptimal bedside manner.

Figure 1 – The Triple Constraints aka The Iron-Triangle

Identify the Driver

As indicated in the above image (Figure 1), it is impossible to have a project that is low-cost, fast, and good quality (meets all performance constraints), therefore trade-offs will be required. As the old saying goes, ‘You can have it good, fast, and cheap, now pick two’. One of the PM’s most important roles in the charter stage is to identify these constraints and then identify the driver, or the most important/least flexible constraint. The constraint that is the driver will guide the PM during execution when things go wrong, as they invariably will. Using the digital catalog project example from the introduction, it is safe to say the driver was the schedule constraint, which meant that additional cost and or reduced performance criteria would be an acceptable price to pay to maintain the scheduled go-live date.

The challenge for the PM is to identify the driver through various techniques and then (and here is the hard part) have the sponsor accept the project charter with the driver identified in writing. The sponsor needs to approve the driver to ensure that they understand their commitment and risk acceptance of the project while understanding that the driver will most likely cause the other constraints to shift if the project meets difficulty. Sponsor communication and education (if needed) are key at this stage, any miscommunications will come back to haunt the PM. The sponsor’s signature on a project charter with the driver identified helps mitigate this risk during project execution.

Identify the Weak Constraint

Conversely, the PM should also identify the weak constraint using the same skills and tools used to identify the driver. This helps the PM identify the most flexible constraint on the project and helps select project execution techniques. For example, if the approved weak constraint is the performance criteria, in essence, the sponsor is acknowledging that their schedule and budget are limited but they are willing to “satisfice,” to accept an available option as satisfactory, on the project’s deliverables, which may indicate the project is a candidate for agile execution. However, if the schedule is the weak constraint then a lower priority, an internally staffed waterfall-style project may be a better fit. The PM also needs to know which constraint is the most flexible so they can adjust accordingly when issues arise. Remember, the triple constraints are related, and a shift of any one constraint will cause a shift in the other two. The PM’s commitment to successful project completion means the PM needs to balance these constraints while consistently pursuing the driver as the project’s highest priority. The sponsor and the PM need to be on the same page in this regard or the project is likely to fail. It is better to have a longer, possibly awkward planning stage to arrive at these conclusions than to start a project without them.

Everyone’s circumstances differ, but I have long considered this data to be non-negotiable, which means I am willing (and communicate this to my sponsors) to walk away from a project if I cannot get a consensus on these constraints.

Decompile the Business Case

The final piece of data required for a bulletproof charter is a decompiled business case. Many seemingly good projects fail due to misalignment of the project with the organization’s overall strategy. The reasons that this may occur are beyond the scope of this chapter, however, as PMs, we only need to know that it does happen in order to avoid this trap. Decompiling the business case from the strategic vision of the organization can be thought of as either a top town process where the strategic vision informs each project or conversely, moving from the “means” - aka the project, towards the “ends” - the strategy, can also work and is thought of as a more bottom-up approach. The bottom-up approach is usually the easiest to use when working with the project team.

In either scenario, the key is that the project’s business case needs to be directly linked to a specific element of the organization’s strategy. One training exercise I teach to illustrate this concept is the “ ‘in order to’ progressive elaboration.” Starting with the project, continue to ask “In order to?” until your team runs out of answers. So a project to create a webstore might start with “in order to sell our products online.” Why do we want to sell online? “In order to increase revenue and decrease costs,” in order to… “increase customer retention and satisfaction by offering more value than any other webstore” which aligns with our mission to “deliver the best customer service possible.” This very simple example illustrates one of the techniques needed to ensure strategic alignment which further armors your charter against project failure.

Conclusion

…armed with a bulletproof project charter, my phone call went surprisingly well. The television network customer understood why the non-driver constraints had to shift to accommodate a crashed schedule and they were willing to spend the money it would require to meet their needs. A few minutes during the project charter creation (and the Sponsor’s signature) smoothed the road that led me to project success. That webstore is still live to this day, which is about the best result anyone can ask for in the world of project management.