HISTORICAL PERSPECTIVE: INITIATION “BARBAROSSA”
Late in 1940 the Soviet government was starting to get concerned that the country was in danger of German invasion despite the signing of a peace treaty with the Nazis in 1939. The suspicions were initially aroused because Hitler began to accumulate a significant number of motorized, infantry and tank divisions in the vicinity of the Soviet-German border.
However German Foreign Minister Ribbentrop continued to insist that those troops were simply preparing for the Operation Sealion – the invasion of England.
Joseph Stalin, the dictatorial leader of the Soviet Union, who was not exactly known to be an overly trusting individual, needed reliable information regarding German plans and intentions. He delegated this task to Filipp Golikov, the Chief Intelligence Directorate, of a powerful and highly secretive organization called the GRU (Military Intelligence), The GRU was an organization similar to the Russia’s KGB, only much larger, more powerful and more secretive.
Golikov concluded that he required 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. Golikov ordered operatives 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 off 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, 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 the 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 degrees F (-10 C). Hence, by the same token he assumed that the 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 the winter of 1941, the German 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 from this story including project scoping and risk planning, but let us 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 of “Operation Barbarossa” initiation.
One of the key parts of a 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 German High Command (OKW). And upon discovering that the temperatures in some regions can drop to a mind-boggling -49 degrees 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 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 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 (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!
THE PROJECT CHARTER CONTENTS
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 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
|“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|
Table 2 demonstrates some of the improper but unfortunately very popular ways of capturing reasons for project initiation.
|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 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. 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 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 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
|Year||Cash Inflows/Outflows||Present Value|
|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.
IRRThe 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|
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. There 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).
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 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? 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 endeavor‘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.
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: