Joseph Stalin, the dictatorial leader of the Soviet Union, who did not exactly have a reputation as an overly trusting individual, needed reliable information regarding German plans and intentions. He delegated this task to Fillip Golikov, the head of powerful and highly secretive GRU, the Chief Intelligence Directorate (Military Intelligence).

Golikov concluded that he required some certain indicators that would tip him off about the impending invasion. As a result, all GRU operatives in Europe were ordered to keep a watchful eye on the ... sheep farming industry. The head of GRU ordered his staff to create a file on every large sheep breeder and on every market where sheep were sold. From that point on he would receive a daily report with prices of sheepskins and mutton from all major European livestock breeding centers.

Furthermore, Soviet spies started paying a lot of attention to ... oiled rags discarded by German soldiers after cleaning of their weapons. These rags were gathered all over Europe (wherever German troops were stationed) and dispatched to Moscow via diplomatic channels. Upon arrival in Moscow the rags were transferred to the leading research centers for analysis.

Based on the "sheep memos" and the results of the chemical studies, general Golikov regularly reported to Stalin that the Germans were in no way ready to attack the Soviet Union. Golikov also insisted, and Stalin agreed, that warnings from all other intelligence sources including even British Prime Minister Winston Churchill should be ignored.

Let's examine Golikov's reasoning. He was convinced that any country that was considering invading Russia had to undergo a rigorous planning and preparation stage. For example, he contended that since the winters in Russia were extremely cold, the invading army would have to be supplied with warm overcoats. At that time the only overcoats that could withstand Russian winters were made from sheepskins. Hence, argued the general, if the whole German army of six million was to be provided with sheepskin coats, a lot of sheep would have to be slaughtered. This, in turn, will have a dual impact: the sheepskin prices will skyrocket and the price of mutton on the world markets will plummet.

Golikov also knew that German gun oil would freeze at the temperatures below 14 F (-10 C). Hence, by the same token he assumed that German High Command (OKW) would have to replace the type of gun lubricant their army was supplied with. In the meantime, as long as Soviet experts were reporting that the Germans were still using the same "old" oil, there was no serious threat of invasion.

The dual irony of this situation is that Hitler decided to attack the Soviet Union without any preliminary preparations for cold weather. Initially Soviets suffered several disastrous defeats and were able to stop the Germans only near Moscow. However, by the time German troops reached the Soviet capital in winter of 1941, their soldiers were suffering from bitter cold and their weapons (including tanks, artillery and airplanes) were refusing to function properly because the gun oil would freeze and jam all the equipment.

One can identify several project management lessons in this story including project scoping and risk planning, but I would like to concentrate on the initiation stage of this project, especially the questions that haven't been asked and the answers that were not provided at the earlier stages.

One of the key parts of the project charter is the "Objectives" section where the planner is supposed to explain, at least at a high level, how the project goals will be met. If the goal of the operation was "We shall conquer the Western part of the Soviet Union by the end of 1941", the objectives section should have provided broad-stroke details of how to achieve the goal. And while the direction of strategic army thrusts, stockpiling the materiel, accumulation of the troops, tanks and artillery was planned more or less properly, the simple inquiry along the lines of "Oh, and by the way, how cold does it get in this vast country we are going to invade?" somehow completely evaded the OKW. And upon discovering that the temperatures in some regions can drop to a mind-boggling -49 F (-45 C) at least one of the German generals might have realized that woolen overcoats would not protect their soldiers from the bitter cold, and building fires under the tanks to liquefy the oil (the task that many Wehrmacht soldiers had to perform on a daily basis) is not the best way to run a successful military campaign.

Who Needs Project Charters?

"Hey, you know what you have to do; why waste time!" I have heard this comment 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 a project charter is a list of questions that have to be answered, at least at a high level, before you are clear to proceed with a project. The rule that I always continue to repeat to my students is that no matter how small your project is, if you can't provide the answers to the questions posed below, maybe, just maybe, you are not entirely ready to proceed or do not have a project at all. Having said that, 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. 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 is simply unfathomable that any person, no matter how superior his memory is, can remember all the minute details that should be outlined in the project charter.

Having said that, the rule that quantity does not equal 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

The point I keep repeating to my students, both in academic and corporate environments - 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 organization, 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.

The 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 capitalize on a value-adding opportunity (e.g. increase in revenues). Failure to identify the project as belonging to either one of the above-mentioned categories is probably a very good indication that the project is a good candidate for the "we have just decided to waste some of the company resources" team.

In my opinion it is always 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?

Here are some of the examples of how this question may be answered in different environments and for various projects (see Exhibit 1)

Exhibit 1

Statement Example	Type
"The implementation of the ABC project will ensure 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 neighborhood"	Opportunity

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

Exhibit 2

Bad Way	Example	Problem
"We will do whatever we built last time"	"Phase 2 will be exactly like Phase 1 only way 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"	"Features cut from Phase 1 will be the heart of Phase 2"	Features were probably cut for a good reason. Do we want to concentrate on "Nice-To-Have" scope items?
"We will build whatever is hot and trendy"	"Version 5.0 will be mobile device ready, entirely Java-based and RSS compliant"	Shouldn't you be concentrating on real customer needs rather than trendy fads?

Goals

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?

Below you will find several examples of goal statements:

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

"Design and built a Victorian-style three-bedroom, two-bathroom home by June 4, 2008"

Objectives

Objectives describe how the goals of the project mentioned earlier 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:

• Specific - Identify the expected result. Be as precise as possible on the desired outcome or outcomes
• Measurable - Quantify the results where possible and ensure you have a reliable system for measuring it
• Assignable - Ensure that objectives outlined in the charter are indeed achievable
• Realistic - Clearly connect the objectives of the project to the overall company strategy
• Time-related - Mention the time frame including the deadline (with +/- qualifiers) and where possible with key milestones

Here are some of the examples of well-written project objectives:

"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 enrolment 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 color 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 (there is probably more than one department representative). 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 supposed to add up to hundred percent:

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

This importance weighting will allow the establishment of 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
• o e.g. R&D, new product development
• +75%; -25% for familiar projects
• o 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 (more on this later) at least starting to assess the financial value of the ventures is the first great step forward that very few companies have so far taken.

The key concept in the Net Present Value (NPV) method 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 formula (see Exhibit 3) 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.

Exhibit 3

Where
Inv - is the cost of the project
CF_n - 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 will the NPV be. See Exhibit 4 for a sample NPV calculation

Exhibit 4

 

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

The discount rate acts as a risk measurement ingredient. Low risk projects are typically evaluated with a 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.

Practical Application

I have frequently received somewhat critical feedback from my students regarding the financial analysis methodology. Among them were: these formulas are too complicated, the forecast data is notoriously unreliable, there are too many intangibles, etc. Therefore I thought it would be quite useful to provide a couple of mini-case studies to demonstrate how "putting on an accountant's hat" philosophy can weed out wasteful projects or decisions in the organization.

Case Study 1 - A conversation between 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 two people working on these reports for five 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 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 six months by 31-Dec" (today is 30-Jun)

PM: "Here is the deal ... we can do this in nine months and this will cost us $100,000 or we can "crash" the project by adding more resources and finish this project in six 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 six 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:

PM: "It looks to me that it would be more beneficial for us to go with the nine 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 the examples above.

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

Constraints are the certain things that constrain 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"

Risks

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 a constraint.

Assumptions

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 did not fall into "Constraints" or "Risk" categories can fall into the "Assumptions" bucket. Needless to say, if the item was 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?

Various versions of this question have been discussed by me and my students or coworkers countless times. How big should the endeavor 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?

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 the project management would be viewed as a helpful tool or just another bureaucratic layer in any given organization.

In my experience using effort threshold has been by far the most successful methodology of distinguishing between BAU and projects. For instance one 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 allowed us to account for the cases where expenditures on a particular undertaking were fairly large (e.g. purchase of a two-million dollar server) but human effort was fairly minimal.

Conclusion

To sum up the points made in this article:

First, project charters play a dual role in the life of projects. They represent a list of questions that need to be answered before moving on into the planning phase, and they play a strategic role for the organization's executives who need to make "Go/Kill" decisions based on the information in the document.

Second, although officially it is not the direct responsibility of the project manager to write the project charter, the practical experience in the field of project management indicates that it is in the best interests of the project manager to make sure it is indeed written and written properly.

Third, when writing the project charter try to be succinct but make sure you answer all of the questions fully.

Fourth, when discussing project feasibility always try to provide at least "back of the envelope" calculations of NPV or ROI. While financial forecasting (both revenue and cost projections) is notoriously unreliable, the financial models can be a great tool in weeding out projects with a definite negative value.

And finally try to establish a company-wide definition of what exactly constitutes a project in your organization. Use either a project budget (less reliable) or project effort (more appropriate) measured in man-months or man-days as your yardstick.

Good luck with your projects

 

This is an excerpt from my new book “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” that is was published by J.Ross Publishing.

About the Author

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East.  Read Jamal’s Blog @ www.thinktankconsulting.ca

• Please follow me on Twitter: 
• Like our page on Facebook: 
• Connect with me on LinkedIn: 
• Subscribe to my RSS feed: 

Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.