The Project Charter – What is it and why is it needed?

As part of any project, most project and program managers are familiar with the concept of an overall project plan. It’s a staple concept of the PMI’s PMBOK toolkit, which defines the need to have an over-arching plan of action for all aspects of the project, from its inception to its closure.

The Project Management Plan is actually a compendium of various pieces of the overall project. Some of those areas might be:

  • Time Management
  • Cost Management
  • Risk Management
  • Scope Management

(*Note: the aforementioned list items are knowledge areas from the PMBOK guide)

Of course, all areas have their inherent importance to the success of the overall project. But the area I wanted to focus on for this post is within the Scope Management area. Specifically, the Project Charter.

So what exactly IS the Project Charter and how does it manifest within the overall structure of how most businesses handle their project operations?

To answer that, I am going to Segway for a moment and discuss some of the various types of document forms that many individuals that work in the realms of software or hardware might be familiar with. Primarily, the two document types I want to discuss are the ‘MRD’ or ‘Marketing Requirements Document’ and the ‘ERD’ or ‘Engineering Requirements Document’. To make sure there is full understanding, let’s make sure these are defined well:

  • Marketing Requirements Document – Basically, this is a document that defines the customer’s wants and needs. It is often drafted by Product Managers or Product Marketing Managers and contains various types of analysis of external factors such as who the target customers are, what are some of the competitors for the product and what customers would want from this product. The document is pretty high level and can probably be summarized best as the ‘Why’ portion of things. i.e. why are we doing this project or creating this product?
  • Engineering Requirements Document – This is the low-level document drafted by the functional leads of the various engineering team and other resources that will be working to create the product or execute the project. It contains the fundamentals, such as instructions on how a product is being designed, its various constituent pieces and the development or engineering efforts to create them. Essentially, it’s the core document that breaks down things on a feature basis, covering all functional aspects of the product. To make it simple, this document can be summarized as the ‘How’ portion of things. i.e. how are we building this product or executing this project?

Both of the aforementioned documents are essential to the overarching success of any project or program whose goal it is to create a product or service of some sort. But more times than not, there is a gap that exists between those two documents. And that gap can actually lead to problems downstream in its absence. That document is part of the overall Project Charter and is often manifested in a document known as the ‘BRD’ or ‘Business Requirements Document’.

So what is a BRD and what does it have to do with the Project Charter? If we follow the paradigm we set before, when we defined the ‘MRD’ as being the ‘Why’ and the ‘ERD’ as being the ‘How’, the ‘BRD’ would be the ‘What’.

Now many may ask exactly why a ‘What’ document is needed? It may sound like a cheap Abbott and Costello joke; what is the ‘What’? But kidding aside, there is a very strong rational as to the need for this document to exist as part of the overall Project Charter. The main rational is that, often times, the gap mentioned earlier between what marketing assumes is being built and what engineering is actually building can be quite wide and often, dangerous if left unchecked.

As many know, defining scope is an essential portion of any successful program. It’s part in parcel with the overall initial planning of any project or program. But despite its importance, many may find it shocking that it gets far less attention than is actually warranted. Often times, too many assumptions are made by marketing as to how effectively information and strategy has been passed down the pipeline. At the same time, engineering will also be making assumptions in various areas where the ‘gap’ exists. It’s just part of human nature and is more often than not is handled almost subconsciously. But too many assumptions can cascade. The more both marketing and engineering make assumptions of what they perceive they think they other meant, if those assumptions are left to stew, the end result can be something totally not asked for and not expected.

Which is why the Project Charter and its accompanying BRD are so essential. It’s the point in time where any gaps are filled. It is meant to fill in the blanks and get everyone on the same page in regards to ‘What’ is being built. The ‘How’ and the ‘Why’ are then leveraged against the ‘What’ to ensure all pieces are aligned.

In many post mortem meetings performed by business leaders over the years when reviewing projects and programs that ran into problems, there is a surprisingly high number of instances discovered where they realize the ‘What’ portion was clearly misconstrued. It’s akin to the old game of telephone where, in this case, the Product Manager (or equivalent) says something along the lines of “Customers want a new Smartphone app that allows them to manage their online banking’. And by the time it goes through the channels, engineering receives it and begins to make assumptions. And without a Project Charter and a BRD defining the scope more readily, they may end up producing a nice Smartphone app for Blackberry without realizing that the main customer base uses iPhones!

In closing, any project should always have some assemblage of a Project Charter, either in the form of a full BRD or perhaps a less involved document, depending on the complexity of the project in question. And once drafted, the primary stakeholders should all be made to sign off on this document, once it has been adequately reviewed. This will reduce the likelihood of the knowledge ‘gap’ forming between various stakeholders and galvanize the likelihood that the product being built is going to be exactly what was asked for.