As part of the Project Charter it is important to define dependencies on the deliverables and resources of other projects and initiatives that are outside the control of the project team. If you have any of these dependencies, they can present major risks to your project schedule. As such, they should be included in your risk management strategy as well as being called out separately in the Dependencies section of your charter

Here is an example of a dependency I encountered in a real-world project:

The project I was managing needed a couple of PC’s to be available in each location for the staff to access for some of their tasks. Another project was ordering and installing these PC’s for a different purpose. I asked to be included in the status reports for that project so I could monitor progress. When I noticed the project completion date slipping to the point of endangering the project I was managing, I offered to advise the person (not a professional PM) managing the project to help them get on track. This was successful and my project avoided any impact.

Be sure to actively identify current projects and initiatives that could impact your project and plan your strategy.

Constraints are any limitations to solution options that have been imposed on a project. It is important to know these early on so time is not wasted pursuing these options. Here are some examples:

• The solution must work with Microsoft Internet Explorer 8 as that is the company standard
• The solution must be an Oracle product for seamless integration with our other Enterprise systems
• The new department we are adding as a result of this project must fit into this 30′ x 50′ area

When project constraints are uncovered, be sure to understand the reason why. It is possible the constraint could be removed. I was involved with a project where the service provider was preselected but without looking at the competition. I convinced my business partners to conduct formal “Request for Proposal’s” with the leading competition and the result was a different provider was selected.

Constraints are included in the Project Charter so that the Sponsor and Core Project Team understand and agree.

In upcoming posts I will discuss Risk Identification and Management in detail. For now, you just need to know that a risk is an uncertain future event that can have a negative impact on your project’s schedule, scope, budget or quality. The event has a probability of occurring less than 100% and greater than 0%. If the probability is 100%, then you have an issue, not a risk. Some risks can have a positive impact but we will not discuss that here.

You state the risk as follows:

• If occurs, then causing the project <scope, schedule, budget, quality> to be impacted in the following specific ways .

At the Project Charter level, you are interested in identifying only the highest impact risks so that your risk management strategies can be accounted for in the scope and schedule.

Some Project Charters will list “Assumptions” in its own section. I have eliminated assumptions from my own charter template as I feel if you have assumptions that can impact your project, then that is just another form of risk. I now include any assumptions in my risk section.

The Project Charter should contain a high-level timeline so that expectations can be set and preliminary commitments established. If not enough is known at Charter time to be reasonably certain of this timeline, then it should be noted as to when the baseline schedule will be established.

The timeline will contain elements that depend on your organization’s methodology. You will want to note target completion dates for major milestones and phases. Here is an example for a software development project:

• Requirements – Jan 31
• Design – Feb 23
• Development/Unit Testing – April 8
• System Testing – April 30
• User Acceptance Testing – May 21
• Transition to Production – June 8
• Production Stabilization – July 8

For projects not involving software, your phases and major milestones will be named according to the nature of the project. Here is an example where the project is to order and install new equipment in several locations:

• Scope established – Jan 15
• Products Ordered – Jan 30
• Products Tested – Feb 21
• Products installed in pilot locations – March 15
• Products installed in all locations – June 1

At the Project Charter level, the scope of work is not meant to be all-inclusive and at a fine level of detail. That is done when detail requirements are addressed.

You can derive part of the scope by taking each Project Objective (refer to the post on Project Objectives for more detail) and listing the major work activities needed to accomplish that objective. These should be at a level of detail enough to get a high-level understanding of the effort and duration of the activity. This is a judgment call and varies by type of project.

In addition to the above, you can list the major business processes that are impacted by the project. A process is impacted if one of the following is true:

• there will be new or changed process steps
• there will be new sources of data or information for the process
• there will be new recipients of data or information from the process
• there will be changed or additional owners of the process.

Listing the major activities and the impacted processes should be sufficient for scope at the Project Charter level. Your organization’s standards may require more, but this should be the minimum.

Project Objectives are very different from Business Objectives. I have seen Project Charter’s with the two types of objectives mixed into one objectives section and I find it very confusing. I recommend placing Project Objectives in its own section.

Project Objectives should satisfy the following criteria:

• Produce a product, service or result that survive and are maintained after the project is over. Some examples of this are (1) a new business “Standard Operating Procedure”; (2) new software installed that meets all of the acceptance criteria.
• Have a definition of “done” that is agreed to by the Project Sponsor and the Project Team.

Project Objectives are important for the following reasons:

• They define the scope of the major deliverables of the project
• They will be used to define much of the activity scope of the project
• Meeting all of the Project Objectives is one of the criteria for project closing

The combination of having well defined Business and Project Objectives will get your project off to a great start and help keep it on track. Take care to get these right.

As stated in the post “Building Blocks of a Successful Project Part 2”, Business Objectives are the “CEO’s view” of the project. They should make or save money, take advantage of opportunity, respond to new law and regulations, or increase competitive advantage. They should be specific and measurable to avoid what I call “Mom and apple pie” objectives like “We will be more efficient”. Really? Exactly how efficient? Will be be able to cut costs or deploy those efficiency savings to revenue opportunities?

Why is this important? Because everyone on your project is a decision maker whether you acknowledge it or not. Every day of a project, many “micro-decisions” are made without asking for clarification as that would be very inefficient. People will make these decisions based on assumptions due to lack of clarity in the objectives. Clearly stating the Business Objectives will help everyone make better decisions by asking themselves “does this decision support the Business Objectives as stated?”.

Another reason it is important is they create a measuring stick for the health of the project. At any point in the project the question “Are the Business Objectives still obtainable?” needs to be asked. If the answer is “no”, the project is evaluated as to whether it should continue or not. Many projects forge ahead even if the Business Objectives are no longer possible because “we have spent a lot of time and money already”. This is a concept called “sunk cost” and this fact is irrelevant in good decision making. If a project no longer offers a return on investment (ROI), there is no point in throwing more money and time at it.

At the end of the project and at regular, predetermined intervals,  the actual outcomes need to be measured against the original objectives. If the outcomes met or exceeded the objectives, congratulations, your project was a success! If the outcomes fell short of the objectives, you can consider doing the following:

• Find the root causes and address them, which may mean spending more time and money if the ROI warrants it.
• If the ROI for spending more time and money to correct the root causes is not positive you can leave the project deliverables in place and not make any additional investment.
• If the project results are actually having a negative impact and additional investment will not help you may need to reverse the implementation (if feasible) to prevent further damage.

My advice is to spend as much time as you need getting the Business Objectives right. It is the most important thing you will do on a project.

When I teach Project Management to non-PM’s, the Project Charter is one of my “points of emphasis”. I state that if they only do one of the things I teach, then the Project Charter is it. All of your planning and execution will be based on the elements contained in there.

The Project Charter is important enough that I will be using future blog posts to examine the contents in detail and include examples. Here are the sections:

• History of the project
• Business Objectives
• Project Objectives
• Scope
• Timeline
• Stakeholders
• Risks and Assumptions
• Issues
• Constraints
• Dependencies
• Sign off