Introduction
The project charter is a true reflection of what leadership believes will be the project characteristics. Although it contains the usual suspects, such as schedule milestones, budget, project description, and its requirements, the charter also provides objectives of the project, performance metrics (also known as expected outcomes), deliverables expected, and responsibility and decision-making roles.
The charter is where the executive and senior leadership of the organization can set the background as to why this project is being accomplished. Beyond scope, schedule, and cost, the project may provide the capability of the company to meet earnings goals and productivity enhancements. The project may also provide the participants the ability to stretch their personal learning and to develop themselves to an ever-increasing skill set.
The context is not just project requirements and its deliverables, but a wider array of dimensions necessary for the whole organization to become better, safer, and more mature. The eventual owner of the deliverables of the project can frame the project for the short-term outcomes upon completion of the project activity, but also has the responsibility for substantial organization shifts, such as increasing sales metrics, process enhancements, human capability improvements, and the intended long-term investment in assets and human capital. This is the leadership role in assuring the charter contains more than just the basics of the project, but also contains the context of the long-term sustainability of the company.
The project team leadership has a huge responsibility to ensure the entire context is understood and reflected in the project charter. The charter has an inherent communication ability to draw alignment of the leadership stakeholders involved and to articulate the strategic thrusts to be executed by the project. At a minimum, the charter developers should ask the broader questions of the context landscape and display those interests within the document.
The organization leadership of performing the project and the organization leadership of receiving the deliverables should both be very clear as to what is expected, why it is important, and how the project will fulfill the strategic objectives of the company.
How Does the Process Work?
The development of a complete project charter is the first step of a project and may be completed before formal approval of the project. It is important the charter be revised when the project has significant direction or scope changes such that it is current. Keep the project charter updated. It is important the charter reflects the human side of leadership, not just the technical activities. The development of the charter should occur before the project plan is fully developed. Of course, the format of the charter should be such that it can easily updated.
Everyone has been involved with a project that has not been successful in one or even multiple areas. The tenant of “if there is a change in one area of schedule, scope, or budget, the others are also affected,” is true for other areas identified in the charter. One can imagine a realized risk of late selection of a piece of equipment that in turn holds up finalizing design, which then cascades to late installation and rising costs. This was the case for the project in this story. The stakeholders involved began raising concerns, and downstream contractors submitted claims. The difficulty was what exactly was expected on the project by the client. The original charter was created and had ranges of times for the delivery of the equipment. These timeframes were met, but the contractor schedules were more precise and differed from the original plan, appropriately so. The charter was not kept up to date, a huge misalignment among the various project documents occurred as well as their requirements and measurement processes. The claims were paid, but the charter could have been more helpful if current.
Charter Development and Contents
The project charter should contain at a minimum:
- Project description ― A brief description of the project and the reason it is being undertaken. This can be one to two paragraphs.
- Project goals ― These broad statements concern what is planned to be accomplished. The goals cannot be mutually exclusive, conflict with other goals, or be too easy or too hard to achieve. Set goals that are a mix of challenging and readily achievable activity. These specific goals should number in the two to four range for most projects.
- Project objectives ― The objectives should be specific and measurable. The project objectives list should be the top six to 12 achievements expected during the course of the project. The format should include a “in order to…what, when, or how much” sentence, clearly identifying with specificity the objective.
- Poor objective ― “Improve client attitude.”
- Better objective ― “To raise customer service ratings by 30 percent within two years of project completion for less than $100,000 in annual operation budget.”
- Project scope ― This defines the work of the project, outcomes, characteristics, and deliverables of the project. This is the foundation of the project and is the most powerful component of the charter. The scope includes all the work in a list of “bullets” with a brief description of the each and examples. Finally, what is not in the scope must be provided.
- Project deliverables ― This should be a high-level description and not a specific listing of documents, components, and functionalities. The project schedule should identify these items. Examples of what could be included as project deliverables include:
- Engineering drawings
- Building or component construction
- System test plans
- Training manuals
- Requirement analysis documents
- Project constraints ― These are real items that can restrict choices when executing the project. They commonly include schedule and cost constraints, but can include staffing, vendor selection and outsourcing, overtime, and even quality. Don’t create artificial constraints or self-imposed constraints. These stem from past experience, ill-conceived logic, round numbers, nice sounding dates like the first of the year, or someone simply saying, “This is the way I want it.”
- Challenge every constraint to ensure it is real and the removal of the constraint does no harm.
- Be a myth buster.
- Limit the constraints to a bare minimum as this will provide ultimate flexibility.
- Artificial constraints ― This story begins with a company that needed to implement their new system to reduce emissions at an industrial facility by regulatory compliance. Coming into the project, it was made clear the new equipment in-service date must be January 1. If this was any other date, the company would have to pay penalties and wait for another implementation date from the regulator. The understanding that most shared throughout the project and at various levels of the organization was January 1 was the only date for implementation.The dilemma was that the project schedule indicated that the equipment actually would be available for in-service much earlier, making the wait to January 1 not necessary. The choice was extending the project by several months later than needed and consuming costs or finding a way to remove that artificial constraint. A small team assembled to look at the impacts of a sooner in-service date determined any early delivery of the project would cause minimal impact to the business. The decision was brought to the leadership team and indeed the earlier date with its savings was approved.
- Project assumptions ― These will be considered true for the project, whether real or not, for the duration of the project. These are rules of engagement for accomplishing the scope of the project. If there are unanswered questions and then conflicts arise, document all assumptions. Limit the assumptions and document only a few. Examples of what could be included.
- No permits needed.
- Training will be limited to new employees.
- Technical resources will be provided in a timely manner by the client organization.
- Vendors will meet schedules.
- Existing drawing are accurate.
- Supplemental staffing is available.
- Critical success factors ― These are musts for a successful project. The absence of one or more of these will virtually guarantee failure in some fashion such as scope incomplete, off schedule, overrun cost or missed standard quality. Limit the critical success factors to six or seven. Examples of what could be included:
- Decisions are timely.
- Business requirements go unchanged after a specific project milestone.
- Support for the project throughout by the client champions is evident.
- High-level project schedule ― This includes a Gantt chart with a work breakdown structure of the summarized schedule. A range of time for the activities may serve well at this stage. This should be a single page or two-page schedule that will align with the budgetary estimate.
- Project risks ― This is a list of risks for the project in the range of six to a dozen. This can be an extensive undertaking, with monetary values or simply an outcome from knowledgeable people who provide input. The risk list is intended to show what might possibly occur on the project and the necessity for contingency in the plan.
- Project costs ― This is a time-scaled summary of capital and expense items for the project. The costs include labor, material, equipment, outsourced work, administrative costs, cost of capital, contingency, and others. Provide a range of costs for each item should be shown. Estimating types and ranges based upon status include:
- Order of magnitude ― up to 2 percent of engineering complete; estimate range -30 to +50 percent.
- Budgetary ― up to 40 percent engineering complete with scope understood ; estimate range -15 to +30 percent.
- Definitive ― up to 90 percent of engineering complete, and scope clear and fairly completely understood; estimate range -0.5 to +15 percent.
- At the point of development of the first charter, an order of magnitude estimate is appropriate. Although difficult, a cost range is best and is appropriate at this point in the project.
- Contingency reserve ― This is part of the project budget and is allocated for project risks. These include overtime will be expected but it is unknown how extensively. Labor increases, material inflation and risk register items are intended uses of contingency. These funds are held in reserve and controlled as to use with project level approval. This is a reserve can be up to 15% of project costs and based upon the project completion status.
- Management reserve ― This is held in the project budget but outside the cost base line and is used for unknowns that may arise in scope as the project progresses. There is an expectation that all or some the reserve will be returned to the company when the project is complete. This is a controlled distribution with beyond project leadership involved with the decision-making in use.
- Additional optional charter considerations:
- Project end measures on quality, cost efficiency, timeliness, and client satisfaction.
- Quality requirements on what is means, looks like, and how it is measured.
- Who are the project stakeholders?
- Defining significant roles and responsibilities.
- Provide a summarized communication and reporting plan.