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.


Initiating a Project – The Key Steps

In many cases, certain projects and programs fall into the scope of the ‘general maintenance’ type. i.e. while the project is ‘new’ per se, it is actually just part of a long term release cycle for an established product. The majority of projects will actually fall into this category. And while any project has its own set of challenges, maintenance projects are generally more routine.

So what about a brand new project? Something completely new, off the cuff and outside of the general ‘comfort zone’ for both the project manager and the members of the team? How does one handle the tackling of an entirely new project and what steps does the project manager take in order to ensure the team gains a strong foothold straight out of the gate?

In a previous post, I discussed the topic of the ‘Project Charter’, giving a synopsis of what it is and why it is needed. (For reference, that post can be accessed here: Project Charter – What is it and why is it needed?)

Aspects of that post will be part of this overall discussion since the notion of the project charter is one of the most fundamental aspects when creating a new project from scratch.

So what are the key steps when it comes to project instantiation? I’ve outlined what I consider to be the seven major steps a project manager should take when beginning a project from scratch:

  1. Define Stakeholders – While some may consider this step to occur a little later, an initial set of stakeholders is necessary for preliminary discussions. The list will most likely adjust as the project moves forward until a ‘core’ set of stakeholders is defined. However, to get the ball rolling, a small tiger team of initial stakeholders (people who may have been part of the initial brainstorming sessions) can begin a high level review of key aspects of the project.
  2. Perform Architectural Review and Feasibility study – In many cases, even before full project definition, it is imperative that the initial stakeholders determine the likelihood of the project’s success be determining if a) the project is feasible and b) is capable of being done based on any technology or resource limitations. Without determining this up front, a project manager may spend quite a bit of time on a project plan and assessment only to realize that the project’s key attributes are outside of the capabilities of the organization.
  3. Define the Business Case – In most scenarios, the business case will likely be a compendium of aspects of a marketing requirements document (MRD) which is then drafted into a high level business requirements document (BRD). The business case will often give information on the marketing and revenue (or cost savings) rational for the project. It will be the justification for moving forward and will likely require sign-off from the key project sponsor or the executive team.
  4. Draft the Project Charter – This will be a segway from the previous step. It will be the full document that will define the project scope, attributes, high level milestones, expected deliverables, key expectations, overall vision and main implementation plan. Note that it is absolutely IMPERATIVE that this document be as detailed as possible. Many projects have stumbled in the past due to a poorly defined project charter and composite BRD. This document defines the ‘what’ portion of the project. By ensuring it is complete and signed-off on by all key stakeholders, the expectations and scope of the project should be well understood by everyone.
  5. Define the Project Team – These will be all the individuals that will participate in the initiation, implementation and rollout of the project. For continued review of the project attributes, it is usually a good idea to define a sub-committee of individuals (usually management level resources) that will meet on a regular basis to discuss the progress of the overall project. An added concept is to invite the project sponser to meetings periodically to discuss overall project movement and bring up any key issues that may require the sponser’s feedback.
  6. Perform Project Review – This will actually occur at several stages during the project lifecycle. But it is important to ensure it also happens before the project commences. This is important to ensure that the project charter is reviewed again, that all necessary resources have been committed and that all key stakeholders are on board with the project scope and deliverables. Note that while this may seem redundant with the project charter step, the passage of time between when the charter was drafted and when the review occurs could be several months. So it is important that a refresher occurs and that any new issues or scope changes are cataloged and discussed.
  7. Initiate the Project – Once all other steps are taken care of, the project can commence. As mentioned before, certain steps will be revisited during the full project lifecycle to ensure the project is moving ahead smoothly. Some of these considerations may be things like resource re-allocations, scope changes or budget reviews.

Following the key steps listed above for any new project that comes within the radar of the project manager should allow him/her to be able to move forward with confidence and ensure that the new project is adequately scoped and defined for implementation.