Who needs Project Charters?

“Hey, you know what you have to do; why waste time?” I have heard this question countless times from my managers and customers. One of my bosses went as far as saying, “What do you mean you need a week to write a project charter?!

We are already late with this project and you are telling me you plan on wasting five full man-days on writing a charter? You know what you have to do, I know what has to be done and your team members understand the scope of work, why do you insist on writing that document anyway?”

Conversations like this inspired me to embark on this journey of explaining why we need project charters and how to write them properly.

The Role of Project Charters

There are basically two different underlying needs for the project charters: the micro (project) need and the macro (portfolio) need.

Let’s examine the micro view first. Basically the project charter is a list of several questions that have to be answered, at least at a high level, before you should proceed ahead with a project. The rule  is that no matter how small your project is, if you can’t provide the answers to the questions outlined in this section, , maybe, just maybe, you are not entirely ready to proceed or do not have a project at all.

You do not have to write a project charter when planning to renovate your bathroom but you still have to know the answers to these questions either at the conscious or unconscious level.

Some of these questions include:

  • What problem are we solving?
  • Where do you want to get to and by when?
  • How much money would we need?
  • How long will it take?
  • What kind of resources and materials will we need?

The reason for committing all this useful information to paper is also pretty straightforward. With the amount of information being exchanged in today’s business environments it simply unfathomable that any given person, no matter how superior his or her memory is, can remember all the minute details that should be outlined in the project charter.

Have you ever been in a situation when you left your shopping list on the kitchen counter and only discovered its absence once you were at the supermarket? How well did you do with remembering all of the items on that list?  So here is a “sixty-four dollar” question: why would you consider spending time compiling a twenty or thirty-item shopping list worth around a hundred dollars a good investment of your time and neglect to write a project charter for a hundred thousand dollar project?

Having said that, the rule that quantity does not equal to quality applies very strongly when it comes to creating project charters. Keep in mind that some of the greatest documents produced in the course of human history were extremely succinct:

  • US Constitution (including the Bill of Rights) – 7,000 words
  • Ten Commandments – 300 words
  • Magna Carta – 5,000 words

Two or three pages are more than enough for any project charter, especially considering the fact that executives and senior managers are typically the primary target audience for the project charters.

And now to the macro level: from the portfolio point of view after reading the project charter the senior management should be able to make a “Go/Kill” decision with respect to the project. One of their key concerns is whether the idea for this project initiated in the business case stage still adds value – financial, strategic or any other – to the organisation, since the project charter, with its refined (but still high-level) estimates for the project cost, duration, manpower and revenue projections, should provide the executives with enough data to assess the project’s value to the firm (more about the portfolio view in Chapters 15-18).

Who Should Write Them?

The Project Management Institute (PMI®) insists that project charters must be written by one of the project sponsors – typically a senior executive. By the way, if you  are sitting for the PMP® exam, this is the right answer. In a perfect world, this would be ideal. In reality, few executives have the time and, more importantly, the expertise to write a coherent project charter document.  If you, the project manager don’t write it – nobody will!

Project Charter Contents

Problem/Opportunity Statement

The purpose of the problem/opportunity statement is to identify the real reasons for initiating the project. The expectation is that your company is either trying to address a problem (e.g. a regulatory project) or capitalise on a value-adding opportunity (e.g. increase in revenues). Failure to identify a project as belonging to one of these categories will likely cause your project to be perceived as a waste of company resources.

It is usually easier to identify the problem or the opportunity by answering the following question:

What problem are we solving or what opportunity are we trying to seize? Table 1 provides some of the examples of how this question may be answered in different environments and for various projects.Table 1

Statement Example  Type 
“The implementation of the ABC project will ensure the bank’s compliance with BASEL 2 Accord” Problem
“To prevent a decline in the market share our company must develop a web-based stock trading platform that will offer reduced trading commissions”  Problem
“A new and high-growth market potential exists for cellular phones with built-in high-quality cameras”  Opportunity
“The construction of a supermarket in the Oakmount area will provide our company with additional revenues from the affluent residents of the neighbourhood”  Opportunity

Table 2 demonstrates some of the improper but unfortunately very popular ways of capturing reasons for project initiation.

Table 2

Improper Way  Sample Statement  Issue
“We will do whatever we built last time”  “Phase 2 will be very similar to Phase 1 only much better!” The world has changed since Phase 1. Was it even successful?
“We will do whatever we forgot or did not have enough time to do in the previous phase” “Scope features  dropped from Release 1 will be the heart of Release 2” Features were probably cut for a good reason. Do we really want to concentrate on “Nice-To-Have” scope items?
“We will build whatever is hot and trendy” “The new cell phone will be capable of storing 1,000 songs, taking high-resolution photos and recording movies” Shouldn’t you be concentrating on real customer needs rather than trendy fads?


The goal statement has a dual role; it is supposed to describe at a very high level what the project will deliver and by when. Basically when filling out the “Goals” section of the project charter, you are answering the following question:

Where do you want to get to and by when?

A few examples of goal statements are as follows:

“Prepare and launch the space shuttle Atlantis on March 4, 2002, from Cape Kennedy, Florida”

“Design and build a Victorian-style three-bedroom, two-bathroom home by June 4, 2008”

“Begin the company website development project on January 20, 2008 and complete it by March 15, 2008”


Objectives describe how the goals of the project will be achieved. The question you are trying to answer when completing this section of the project charter is:

How are you going to get there?

It is very useful to utilize the S.M.A.R.T. methodology to improve the quality of the objectives. The S.M.A.R.T. methodology implies that all of the objectives should be:

Identify the expected result. Be as precise as possible on the desired outcome or outcomes

Quantify the results where possible and ensure you have a reliable system for measuring it

Ensure that objectives outlined in the charter are indeed achievable

Clearly connect the objectives of the project to the overall company strategy

Mention the time frame including the deadline (with +/- qualifiers) and where possible with key milestones

A few examples of well-written project objectives are as follows:

“Design and build a prototype of a universal bottle corkscrew opener that complies with the department store specification by June, 2008 (SMART)”

“Complete the registration process for enrollment in the first year of the ABC University’s Business Administration program by May 2010 (SMART)”

“Bob will save $5,000 by the end of August 2010 in order to pay XYZ Training Inc. the required tuition fees for the PMP preparation course. (SMART)”

And now compare them to this statement:

“The feasibility of installing new high-definition colour security cameras will be calculated by our department’s representative (SMART)”

We can’t say that this statement is specific because it is not clear what kind of feasibility the author is referring to. Is it financial, strategic, security, etc.? The objective is not measurable because there is no quantification in it. It is also impossible to assess whether the objective is assignable because we do not know who specifically will be responsible for undertaking it. Based on the information provided, it is impossible to say whether the statement is realistic. And finally, there is no duration, date or deadline of any kind mentioned in the objective.
High-Level Budget and Schedule

Before discussing the budget and the high-level schedule of the project it is worthwhile to revisit the project management triangle (or pentagon) and establish relative priorities between scope, time and budget. Priorities or importance factors are basically percentage weights that are should add up to a hundred percent:

• Scope and Quality Importance Factor – 60%
• Duration Importance Factor – 30%
• Budget Importance Factor – 10%

This importance weighting will allow establishing project priorities from the initiation stage and guide future decision making.

At this point in the project the estimates should be presented with the following plus/minus qualifiers:

• +300%; -75% for brand new, unique projects
> e.g. R&D, new product development
• +75%; -25% for familiar projects
> e.g. new feature development for an existing system.

Project Feasibility

Project feasibility is rooted in a simple concept that “the company that borrows at 10% and invests at 5% will not be around for long”. While financial measures are not the only measure of whether the project should be added to the company portfolio, at least starting to assess the financial value of the ventures is the first great step forward that very few companies seem to take.

The key concept in the Net Present Value (NPV) and Internal Rate of Return (IRR) methods is the time value of money – the concept that one dollar today is not the same as one dollar one year from now.

Net Present Value

The Net Present Value (NPV) formula implies that one has to take the cost of implementing the project and add all the future incremental cash flows discounted to today’s value.

Inv – is the cost of the project
CFn – incremental increase in the cash flow
r – internal discount rate, typically weighted average cost of capital (WACC)

The decision criterion is pretty simple: if the NPV is positive, the project should be accepted; if it is negative the project should be rejected. Note that Net Present Value has a negative relationship with the discount rate, i.e. the higher the discount rate, the lower the NPV will be. See Table 3 for a sample NPV calculation

Table 3

Year Cash Inflows/Outflows Present Value
0 -$100,000 -$100,000
1 $50,000 $44,643
2 $45,000 $35,874
3 $40,000 $28,471
NPV   $8,988
Accept this project since the NPV > 0
Note: Discount rate = 12% per annum

Discount rates act as a risk measurement ingredient. Low-risk projects are typically evaluated with a Weighted Average Cost of Capital (WACC) in the range of 5-12%; most company projects fall into the 15 to 20% range. New ventures are typically evaluated with discount rates in the 25 to 40% range because of their extreme levels of risk.

IRR The Internal Rate of Return concept is similar to the NPV, only instead of solving for the value of NPV, the NPV is set to zero and the equation is solved for the discount rate. This way, instead of assessing the dollar value of your investment, the percentage return on investment is measured and compared to the required benchmark return on investment (ROI) value. See Table 4 for an IRR calculation example. Table 4

Year Project A Project B
0 -$100,000 -$100,000
1 $50,000 $10,000
2 $45,000 $20,000
3 $40,000 $50,000
4 $35,000 $70,000
IRR 27% 14%
Decision Accept Reject
Required IRR 18% 18%

Practical Application

Some common attitudes among project managers regarding the financial analysis methodology are: these formulas are too complicated, the forecast data is notoriously unreliable, there are too many intangibles, etc. Is this your attitude?  The following mini-case studies demonstrate how “putting on an accountant’s hat” philosophy can weed out wasteful projects or decisions in an organization.

Case Study 1 – A conversation between a VP of Finance (VP) and Project Manager (PM)

VP: “I need to automate certain reports we are supposed to submit to the government”
PM: “The estimate for this project is $100,000”
VP: “My people are wasting a lot of their time each year on them. I have a large budget and money is not a significant constraint in this project”
PM: “How many times a year are you supposed to submit these reports?”
VP: “Twice a year”.
PM: “How much time do your people spend on these reports?”
VP: “I have 2 people working on these reports for 5 days each time.”
PM: “OK, let’s do the math … 2 people X 5 days X 2 times/year X $400/man-day = $8,000/year savings”
VP: “That’s correct”
PM: “And we are spending $100,000 to save $8,000 per year … I don’t think the NPV will look very good … Do you still want to go ahead with this project?”

Case Study 2 – VP of Risk Management (VP) and Project Manager (PM)

VP: “We have to finish this regulatory project in 6 months by 31-Dec” (today is 30-Jun)
PM: “Here is the deal … we can do this in 9 months and this will cost us $100,000 or we can “crash” the project by adding more resources and finish this project in 6 months. But this would cost us $300,000”
VP: “I told you it was a regulatory project mandated by the government! We HAVE to finish it in 6 months”
PM: “What happens if we are late?”
VP: “Don’t even think about it!”
PM: “No, really, what happens then?”
VP: “We will have to pay heavy fines”
PM: “How much?”
VP: “$20,000 per month for every month we are late”
PM: “OK, let’s do the math (see Figure 1):
PM: “It looks to me that it would be more beneficial for us to go with the 9-month version of the project”

These examples demonstrate that one doesn’t need to conduct a complicated financial analysis of the project cost and benefits. Actually resorting to complicated formulas and spreadsheet modules early in the project initiation stages does not even make sense if you remember that all forecasts are made with at best a +75 – 25% confidence range. In my experience a significant number of project proposals were weeded out by performing simple “back of the envelope” calculations like the ones in these examples.. These examples aren’t meant to suggest that the financial analysis formulas are not useful and necessary in some situations. Their purpose is to help you make good decisions. However, probing questions, logic, common sense and some fairly simple calculations such as ROI and NPV often work just as well.

Other feasibility measures may include consistency with values, consistency with strategy, regulatory/government-mandated projects, competitive advantage, market attractiveness, etc. (more on it in the portfolio management chapters of this book).

Risk Management

A lot of confusion exists in project management circles regarding assumptions, constraints and risks. This section defines each one of these important risk management categories and provides several examples of each.

Constraints are the things that limit your options with respect to the successful delivery of project products or services. They typically, but not exclusively, include deadlines, budgets, availability of resources, etc.:

“The budget of the project was capped at $100,000”
“The final product must be delivered by October 31st, 2009 in time for the Christmas shopping season”
“The product must receive a rating of 90% from the focus group of users”


Risks are the uncertain things that can jeopardize the project success, i.e. “bad” things that may happen on your project but you are not entirely sure they will:

“There is a possibility of major contractor’s employees going on strike”
“There is a distinct possibility that the regulatory agency may change the scope of the requirements necessary for the successful delivery of the project”

Note that when the probability of risk reaches 100% it becomes either a constraint or a scope item.


Assumptions are typically “good” things that are supposed to happen on your project, but you are not entirely sure they will happen. For example:

“We assume that all the resources required for the successful delivery of this project will be available”
“We assume a timely delivery of the product blueprints outsourced to the external design company”

Typically it is beneficial to start with constraints first since they are definite, well-known aspects of the project and then move on to risks. Items that do not fall into “Constraints” or “Risk” categories can fall into the “Assumptions” bucket. Needless to say, if an item is mentioned in one of the groups it should not be duplicated in other ones.

How big should the project be to warrant a project charter?

How big should the endeavour be to be considered a full-scale project? How to distinguish between business-as-usual tasks that could have a definite start and finish and be fairly unique in nature and real projects? When do you need to apply the project management methodology?

These questions are among the most hotly contested topics at companies considering implementing project management methodologies. In my experience, the correct answer to this question determined whether project management would be viewed as a helpful tool or just another bureaucratic layer in any given organization.

In my experience, some organizations implement a “business as usual” ceiling at some fixed amount. For example, if the endeavour‘s projected budget exceeds $10,000 it should be considered a project, if not – business as usual. This is a fairly easy and straightforward approach that unfortunately has at least two drawbacks. First, what should happen if a budget was initially forecasted to be at around $7,500 and is later increased to $12,000? This is a completely plausible scenario that has perplexed more than one manager. Second, what happens if the “project” cost exceeds the imposed threshold but only requires a few days of work? A manager of a  real estate department of a large construction and development company once remarked, “Sometimes we make purchases of land in millions of dollars, but it only takes us a couple of weeks to accomplish the deal and one person working about 30% of his time (i.e. 10 days X 30% = 3 man-days of effort). Do we have to write a project charter for that too?”

In my experience using an effort threshold has been by far the most successful methodology of distinguishing between a business-as-usual classification and projects. For example, let’s say a large international banking institution used an upper limit of one man-month in order to qualify a job as a project. If the total resources required exceeded approximately twenty man-days – it was a project, if less – business as usual. This approach would allow for the cases when expenditures on a particular undertaking were fairly large (e.g. purchase of a two-million-dollar server) but human effort was fairly minimal.

About Guest Contributor

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting, is an internationally acclaimed expert in the areas of project/portfolio management, scope definition, requirements analysis, process improvement and corporate training. He has done work for private-sector companies and government organizations in Canada and the US.

Mr. Moustafaev is an author of the book titled “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management”. The article you are about to read is actually Chapter 5 of the book.

In addition to teaching a highly acclaimed “Project Management Essentials” course at British Columbia Institute of Technology, Jamal also offers the following corporate seminars through his company:

> “Practical Portfolio Management – Selecting & Managing The Right Projects”
> “Successful Hands-On Management of IT and Software Projects”
> “Successful Hands-On Management of Modern-Day Projects”
> “From Waterfall to Agile – Practical Requirements Engineering”

Mr. Moustafaev holds a PMP certification, an MBA in Finance (Derivative Securities) and a BBA (Finance and Management Science) from Simon Fraser University.

For further information, please contact:

Jamal Moustafaev BBA, MBA, PMP
President and CEO
Thinktank Consulting Inc.
Phone – 1-778-995-4396
E-mail –
[email protected]
Website – www.thinktankconsulting.ca

On This Page

Monthly Newsletter

By: Baz Khinda

Baz Khinda
Commercial Director, BA, MBS, MCTS, CertBusM, PRINCE2, Microsoft P-SSP (Partner Solution Sales professional)

Published: 2 November 2010

Book onto an Event