Author: Jamal Moustafaev

“Operation Husky”: Allied Forces and Don Calo

“Operation Husky”, the Allied invasion of Sicily started on July 9^th, 1943. It was a large-scale amphibious and airborne operation, followed by six weeks of land combat. The Anglo-Canadian forces landed on the east cost of the island and had a seemingly simple task in front of them. The resistance was known to be poorly equipped with weapons and ammunition; in some cases their positions were defended by captured Russian artillery that nobody could operate because the Italian army forgot to translate the operating manuals. And yet, despite all of the planning shortcomings, the Italians fought well and it took English and Canadian forces five weeks and thousands of casualties to reach their objective – the town of Messina.

American troops, on the other hand, had a much tougher challenge: the occupation of the mountainous centre and western half of the island. Nevertheless, the American Seventh Army was able to reach the north coast of Sicily in only seven days and with hardly a shot fired. What allowed the US troops to accomplish “the fastest blitzkrieg in history”, as General Patton once described this campaign?

According to some historians, the American government managed to strike a deal with the most powerful man on the island, the capo di tutti capi of the Sicilian mafia – Don Calogero Vizzini. The US Office of Strategic Services (OSS) – the wartime predecessor of the Central Intelligence Agency (CIA) – recruited Charles “Lucky” Luciano to act as an intermediary between the advancing US Army and “La Cosa Nostra”. As a result of these negotiations the mafia protected the roads from snipers, arranged enthusiastic welcomes for the advancing troops, encouraged mass desertions from the Italian army and provided guides through the confusing mountain terrain.

One might wonder what events lead to such unlikely alliance between the Allied forces and the mafia chieftain? A negotiating expert would call this situation “a value-creation exercise in negotiations”. This was a classical case of proverbial synergy, where two sides stood to benefit immensely from one shared goal – the liberation of Sicily from fascists. The benefits, derived from this partnership, however, where quite different but surprisingly congruent.

The Americans were obviously interested in achieving their goal of liberating the island as quickly as possible and in avoiding large casualties. In addition, the Americans and the British were seriously concerned about the spread of communism in Italy in general, and in Sicily in particular.

The situation with the Mafia was not quite as simple. The Mussolini regime took a heavy toll on the “Cosa Nostra”; many of the best Mafia members had been converted to fascism. Others, in 1943, were still in jails and only just about to be released. As a result, the “honored society” had lost most of its power in Sicily and was desperately looking for ways to recapture its former glory. The Mafia was also concerned about the rise of communism among Italian population and viewed them as their natural enemies who jeopardized the “traditional ways” of the country.

Hence the unlikely alliance was struck: the Americans got a free pass to Palermo, thus accomplishing their mission in the shortest time possible with negligible losses. The Mafia “candidates” were quickly promoted to positions of power by the grateful American forces, hence regaining much of its former power in a matter of weeks. Additionally, the common goal of impeding the advance of communist ideology in Italy and in Sicily was achieved.

Introduction: What is a Negotiation?

What is the first thing that comes to your minds when the word “negotiation” is mentioned? I asked this question on a number of occasions of my students, colleagues and high-ranking executives, who I have met through my consulting practice. Their answers, although different in form, typically boiled down to the following:

“Negotiations are a type of haggling process, akin to something that takes place at the Middle Eastern bazaar”, or

 

“It is a discussion were one’s sole purpose is to get as much of the ‘pie’ as possible by being tough, secretive and cold-blooded”

I suspect that we get these impressions from the Hollywood portrayals of the “negotiations” process. You know, veins bulging, fists striking the tables, people yelling and sometimes brandishing heavy weapons …

If you don’t believe me, consider one of the most famous dialogues in movie history, the conversation between young Michael Corleone and his future wife:

Michael: “… My father went to see the bandleader, and offered him $10,000 to let Johnny go, but the bandleader said no. So the next day, my father went to see the bandleader again, only this time with Luca Brasi. Within an hour, the bandleader signed the release, with a certified check of $1,000.”

Kay: “How did he do that?”

Michael: “My father made him an offer he couldn’t refuse.”

Kay: “What was that?”

Michael: “Luca Brasi held a gun to his head, and my father assured him that either his brains or his signature would be on the contract.”

Although at times I did wish that I had my own Luca Brasi when dealing with some of my project stakeholders, I do realize that Hollywood stories bear little resemblance to the real world. In reality, negotiation is a dialogue intended to produce an agreement upon courses of action, not only by actively selling your position but also by focusing on the other side’s interests, needs, priorities, constraints and perspective.

How to Negotiate On Your Projects?

Use Investigative Negotiations
As I have mentioned before, very frequently when negotiating on projects, both parties involved default to the discussion of their respective demands or try to state their positions in the clearest ways possible. Dig into your own memories and try to see if you have ever heard the following statements form your clients or managers:

• “This project must be delivered by October 30^th of this year”.
• “You are limited to ten resources on this project”.
• “The budget is capped at $100,000. This number is not negotiable”.
• “All of the scope items outlined in the Statement of Work must be delivered”.
• “You are not allowed to outsource any parts of the project”.

Project managers are also prone to uttering statements like:

• “We can’t hit this deadline even if we work sixteen hours a day”.
• “If I don’t get the resources I asked for, we are not going to deliver this project”.
• “The budget is too small. If it is not revised, we will not deliver the entire scope by the deadline”.

The problem with this approach is that we focus on the positions or demands of both parties rather than trying to understand their underlying interests and reasons. We assume that the key to a successful negotiation lies in understanding what the counterpart actually wants. While this is true, it is not the end of the process but rather a beginning. Focusing on what their customers want frequently distracts even the most experienced project managers from why they want it in the first place.

Therefore, questions like “why?” and “why not?” become the project manager’s best friends during any negotiation process. Keep in mind that, while a project manager is typically an experienced professional who can plan, scope, budget and control his project, he can not read a client’s mind and know all of the constraints and details associated with the project as seen by the customer. On the other hand, while the customer may know in detail what she wants and why she wants it, she is not a trained project manager who can appreciate all the potential difficulties related to a successful delivery of the project. As a result, an inherent awareness gap exists on every project especially in the earlier stages. Unfortunately, the job of bridging that gap falls on the shoulders of the project manager.

A colleague of mine once told me of a very interesting experience on his project. He was discussing various aspects of a new project he was just assigned to with a fairly “difficult” vice president of risk management at a large international bank:

VP: “This is one of the most important projects in our portfolio. Unfortunately there isn’t much flexibility on the scope and the deadline because this is a regulatory government-mandated project”.

PM: “OK, I understand. I have done some preliminary assessments of the scope of work involved and it looks like I will need a team of ten resources assigned to this project on a full time basis”.

VP: “That is not an option. You can only have seven technical people assigned to your team. Besides, I may need one or two of them from time to time …”

PM: May I ask, why would I be provided with only seven people?”

VP: “Because the guys in my department will be working on generating a lot of reports and conducting analysis at the quarter end. That would be around the same time when your resource needs will reach their peak. You have to understand, I wouldn’t even consider giving you all seven of my team members if it was not for the importance of this project!”

PM: “Oh, you mean I can’t have all ten resources from your department! That is not exactly what I had in mind. Remember Bill, John and Stacy, the external consultants who worked on the ‘BASEL 2’ project?

VP: “Yes, I most certainly do. They have done a great job …”

PM: “If you can provide me with additional budget, I could involve them on our project. That would take the number of resources from seven to the required ten people. What do you think?”

VP: “Yes, I believe I have some flexibility in my budget. Why don’t you contact them and see if they are available?”

What happened in this dialogue? Project manager believed that he needed ten people to ensure a successful delivery of the project. The vice president, on the other hand, could only provide seven (if not less) of his people. These were the starting positions in the example provided. Had the project manager neglected to probe further regarding the VP’s reluctance to increase the project team to ten members, the negotiations would have gone nowhere. However, because he investigated the underlying interests of the executive – to have his people available to work on their regular tasks during the peak season – he was able to discover that the VP hadn’t even considered the possibility of hiring a group of external consultants.

Invent Options for Mutual Gain
One of the prevailing superstitions in project management is the “fixed pie” assumption. In other words, both sides assume that the project results, speaking mathematically, are binary – either the team delivers the project on time or it doesn’t; either the project is on budget or over, etc. Fortunately, negotiations are typically not like NBA Finals when team A meets team B in a seven-game series where the winner gets the Larry O’Brien Championship Trophy and the loser goes home empty-handed.

In my experience, situations on most projects are similar to the famous story when two kids were quarrelling over an orange with each one claiming ownership. Finally, their father entered the room and, operating under the fixed pie assumption, cut the orange in two equal halves distributing the fruit between the brother and the sister. Interestingly enough, the brother ate the orange and threw away the peel. The sister used the peel from her half as an ingredient in pastry while disposing of the fruit.

The situations between the customers and the project teams are almost always fairly similar to the fable described above: the underlying interests, constraints and risk tolerances ob both parties are never identical. The proverbial pie looks quite different to each party. Hence, a good project manager can increase the size of the pie by looking for things that are of low cost to him and his team and high value to the customers (and vice versa).

A student of mine at British Columbia Institute of Technology once mentioned an interaction between an experienced construction project manager and a customer:

Customer: “I would like to add another clause to our contract. If the work on the new mall not finished by the deadline in the contract, I want your company to pay a penalty of $5,000,000”

PM: “Hmm, we have already signed the contract without the late penalty clause; I am not sure how our management would react to that …”

Customer: “I am sorry, but I have been instructed by my boss not to proceed without this modification to the contract”

PM: “And may I ask you why do you guys feel the need to add this clause?”

Customer: “Our CEO is really anxious about hitting the deadline outlined in the contract. He had some bad experiences with construction subcontractors before and wants to ensure a timely completion …”

PM: “I just had an idea! You are very concerned about us finishing the construction on time and we are fairly confident in our ability to do so. Would you be open to the idea of adding (in addition to the penalty clause) a bonus provision to the contract if we finish ahead of the schedule? How does $3,000,000 sound? This way if we are late, we pay the penalty of five million and if we finish ahead of schedule, you give us an additional three million”

What happened in this conversation? The hopeless situation has been defused by the project manager who honed in on the difference in underlying interests. The customer’s interests were deeply rooted in their extreme risk aversion; ensuring that the project is complete on time was paramount. The construction company, on the other hand, was more concerned about generating additional profit. Since they were fairly confident in their ability to finish this project on time, they willingly accepted the penalty clause.

The Need for Objective Criteria

While trying to understand the underlying interests and constraints of your counterparts is one of the cornerstones of successful negotiations, there is one area that has fairly little flexibility – the fairness of the objective criteria used when assessing various dimensions of the deal. All of the inputs into the negotiations process should be reasonable and fair; otherwise you will not get very good outputs. The “garbage in, garbage out” principle, so famous among statisticians, applies very strongly to the negotiations game. I am sure all of us have witnessed biased standards used in project negotiations:

• Imposed duration and budget estimates
• Insufficient numbers of resources allocated to the project team
• High-risk ventures treated as low-risk ones
• Draconian penalty clauses in contracts, etc.

You may, and probably will, from time to time be subjected to pressure that can take many forms. It could be a threat (if you don’t do this, you will be fired), a fake appeal to trust (why don’t you believe me that this could be done in only six months?) or a veiled bribe (I will seriously consider promoting you to a senior program manager if you agree to this).

I like to call these types of requests “deliver me a Ferrari with custom features tomorrow for $500.” Succumbing to these unfair yardsticks is a very dangerous technique to use in negotiation. Just because the customer has heard that a “similar project was delivered in half the time and with quarter of a budget” does not mean that the project manager should instantaneously agree to use this yardstick to assess his own projects.

Exhibit 1 lists some of the questions the project manager could ask when dealing with unreasonable stakeholders insisting on using irrational criteria.

Exhibit 1

Question	Example
What is your theory?	“How did you arrive at this estimate?”
What standards should we use?	“Should we use our own historical data in trying to assess the potential cost of the project?”
Are these standards reasonable?	“Can we really apply the data from the previous smaller project to this particular one?”
What criteria have been used before?	“”What estimation techniques did we use on a previous venture?”
Were they even successful?	“Did we finish the project on-time and on-budget?”

Don’t Lie!
I would like to start this section with a very interesting and, probably very amusing, dialogue between myself (PM) and the Director of a company that shall remain nameless, that magnifies some of the issues we have with honesty on our projects:

Director: “Hey, I am going to assign you to this new regulatory project. Keep in mind, this is a high-profile endeavor; our main client is the Senior VP of our company”

PM: “Yes, I have heard about this project. I have spoken to some of our technical people and they have estimated the project to take about nine months …”

Director: “Yup, that is another problem. I have personally promised that we would deliver the product in three months.”

PM: “What?! Three months? But when he finds out the truth he will be mad!”

Director: “Don’t worry about that. I have a plan. We’ill proceed by breaking the news to him gradually!”

PM (after a very long pause): “And you’re counting on him not noticing the difference between a three-month project and a nine-month project?”

On a more serious note, we encounter lies in the world of project management on almost a daily basis. Customers hide their actual budgets, while project managers, as one of my colleagues eloquently put it, “think of a random number, double it, then just in case double it again”. Lying in negotiations is a frequent phenomenon; we assume that it is easier to inflate the project budget estimate or requirements to obtain the resources.

Alternatively, we are sometimes pressured into decreasing our forecast in order to please our clients or superiors. We justify this behavior by convincing ourselves that everyone lies during negotiations and that by being honest we put ourselves at a distinct disadvantage. This could be true in the short term; e.g. we can obtain a bit of a breathing room by inflating our forecast.

What we forget under the pressure is that, in the long term, our reputations as reliable professionals and our relationships with customers suffer. It takes months, sometimes years to establish yourself as a trustworthy counterpart and to build a trusting relationship with your stakeholders, but if, for whatever reason, you are caught in a lie, the trust and the bond disappear in a flash.

Therefore, it is very important for anyone involved in projects to consider the long-term impacts on your reputation of lying.

So, the obvious question arises from this discussion, “If we are not supposed to lie, how do we overcome the potential difficulties in project negotiations?” Exhibit 2 provides the reader with some of the techniques that should always be at the project manager’s disposal when negotiating with project stakeholders.

Exhibit 2

Advice	Explanation
Prepare to answer difficult questions	Make sure that you have done your homework: familiarized yourself with project scope, can explain how you arrived at time, resource and budget estimates and are aware of all key risks
Do not respond to questions under time pressure	Refuse to provide an immediate answer to the questions if you are not fully prepared to respond
Build trust by asking questions	Ask lots of questions like: “What do you plan to do with our product?” “Who are your customers?” “What do you plan to do if we can’t provide you with the services you need?” “Can you tell us more about your organization?”
Build trust by giving away some information	Start a difficult discussion by saying: “I know we have a lot to talk about, so let me start by talking about the issues that are most important to us. Once were are done, you can do the same”
Educate Your Stakeholders	The best time to do that is when you are not working on specific projects. This will free the customers of all the suspicions about any hidden agenda or subjectivity on your end

Don’t Dismiss Anything as Their Problem
When managing projects in general and negotiating in particular, we are all acutely aware of our own interests, constraints and risks. We know the chances of finishing the project on time and on budget and how many people we need to accomplish a critical task. Unfortunately, in many cases we are not very interested in understanding the customer’s issues and problems. A “my plate is full as it is and I don’t have time to care about the customer’s interests” attitude is prevalent among many project management professionals I have known. As one of my colleagues put it, “I am in charge of nine knowledge areas spread over five project phases with all the inputs, outputs, tools and techniques. And you really expect me to analyze a customer’s hidden worries and concerns?”

I was once told about a very interesting conversation that took place between the project manager (PM) and a Senior Vice President of Sales (SVP) who were both working on a first-person shooter video game.

SVP: “Listen a decision was made to move up a deadline for the ‘Operation Alpha’ project. We need it finished by the beginning of June”

PM: “Well, this could be a bit difficult since we were projecting an October completion for the Christmas season”

SVP: “Listen, the decision to move the deadline comes directly from the top. We don’t have any flexibility on that”

PM: “OK, let me try to understand the situation. What caused, if I may ask, the shift in the release date?”

SVP: “Well, that’s the point, we are not shifting the official release date; it is still in October. But there is an exhibition on the West Coast that we need to be prepared for. The CEO wants to showcase this product at this trade fair.

PM: “I understand. Why don’t we do the following: we can’t finish the entire product by June, but we can provide you with one working level of the game? We were just putting the finishing touches on the “Jungle Battle” section. It is one of the action-filled parts of the game. What do you think?”

SVP: “You know what? This may actually work!”

Let’s analyze what happened in this example. The vice president dropped very unpleasant news on the project manager. What options did a project manager have in this situation?

• Reject the VP’s request outright
• Ask for more money
• Ask for more people
• Threaten that the quality of the product would suffer
• Make a false promise and work his team to death …

What the project manager did, however, is tried to understand the real problems the vice president had. The key issue, as it turned out, was that the CEO wanted to demonstrate a functioning product at the exhibition; however the question of whether it should be a full game or just a part of it has never been discussed. Only the project manager with his technical expertise could propose that alternative.

What If They Are Irrational?
As one of my students at BCIT once exclaimed after the section on project negotiations was complete, “Yeah, this is all great and whatnot, but some of my customers are really crazy! I have difficulty talking to them, let alone negotiating! How would this theory apply in those situations?”

“Crazy” or difficult customers are a curse of every project manager. The interactions between the project managers and the clients, especially during the initiation and planning stages should be frequent and fairly vigorous events. Defining scope, understanding their problems, fidgeting with budget, schedule and constrained resources; all of these activities are fairly challenging even with co-operating and friendly stakeholders. If, however, the customers and your own management are being unreasonable and are not willing to weigh different options by sitting down with the project manager, the experience can become a nightmare.

So, what are the reasons behind such unreasonable behaviour? One of the key motives behind such attitude is the fact that most of the stakeholders are probably uninformed about the possibilities the negotiations open for them. Unfortunately, the only alternative for the project manager is to educate the customer about the negotiation process, typically by leading by example. The section below, “Targeting Different Corners” of this article will provide the reader with several hands-on approaches that should help in addressing this problem.

Also, your counterparts may not have sufficient authority to address the issues you are trying to raise in a discussion with them. While the project manager is sitting with the customer trying a number of various approaches, the stakeholder is rejecting one proposal after another because he has not been provided with enough decision-making power, but is unwilling to admit to that.

I have personally witnessed the following situation on numerous occasions: the president mentioned a project idea to one of his vice presidents, the VP chatted briefly with the director of department X and the director summoned the project manager to his office to discuss the project. The project manager starts asking a lot of questions trying to probe for potential opportunities or “degrees of freedom” on the project, but he is told, in no uncertain terms that the project parameters are not subject to negotiation. This happens because the director does not have enough information or authority to make relevant decisions, but he is, for whatever reasons, reluctant to direct the project manager to communicate with the CEO of the company face-to-face.

Negotiations In The Real World: Where Do You Start?

Targeting Different Corners
The concept of a project management pentagon (see Exhibit 3) has already been covered extensively in article “Top Ten Things You (Probably) Didn’t Know About Estimation”; however, since this theory is used extensively in project-related negotiations, I would like to revisit it once more.

The idea behind the pentagon is that every project has five potentially flexible dimensions: scope, quality, time, effort and budget. In this model scope and quality are positively correlated with time, effort and budget. In other words, the more features and/or more quality the customer wishes to see in the final product, the more money and people should be working on the project for a longer time.

Exhibit 3

What are the options available to the project manager during the negotiations? The project management pentagon can be used as “cheat sheet “when discussing various options available. Here is what I do with it: I walk to the whiteboard and draw the pentagon with scope, time, budget, effort and quality at the top of each corner, and then I suggest that we “attack” each one of the five corners to see, if we can work out an agreeable and fair approach to the project in question. Exhibit 4 contains some of the questions the project manager may ask during the negotiations to obtain the degrees of freedom.

Exhibit 4

Category	Questions To Ask
Scope degrees of freedom	“Can we move some of the desired functionality into the next phase?” “Can we deliver the product or service in stages?” “Can we cut some scope items altogether?” “Can we polish some features less?” “Can we relax the detailed requirements for each scope item?”
Resource degrees of freedom	“Can we add more technical resources?” “Can we add more experienced resources?” “Can we provide our resources with proper training?” “Can we add more administrative support?” “Can we increase the degree of technical resource support?” “Can we eliminate company red-tape?” “Can we increase the level of customer involvement?” “Can we increase the level of executive involvement?”
Schedule degrees of freedom	“Can we set a schedule goal but not an ultimate deadline?” “Can we set a project goal of short schedule, and look for ways to reduce time planning and execution stages?” “Can we use estimation ranges, and agree to refine them as the project progresses?”
Budget degrees of freedom	“Can we share the cost of the project between several departments?” “Can we exceed the project budget by X% without getting the approval of the senior management?” “Can we capitalize some of the project expenses?”
Quality degrees of freedom	“Can we relax the detailed requirements for each scope item?” “Do all the scope items have to be of the highest quality possible?”

Keep in mind that the questions in Exhibit 4 represent only the starting points in the search for the degrees of freedom. Each one of these inquiries has a potential to unravel into a series of new discussions and, more importantly, concession points from the stakeholders.

Let us look at another example that involved the author of this article. The project was a government-mandated regulatory project at a large international bank. Like most of the regulatory projects, it had very few degrees of freedom available: rigidly defined scope, no flexibility on quality, and a strict deadline. To make matters even worse, the IT department of the bank told us in no uncertain terms that our team is limited to five people and even if the Risk Management department was willing to shell out some money (which they most definitely weren’t) for outsourcing, we were not allowed to do that because of the confidentiality laws.

There was however one little nuance to the story. The essence of the project was to provide the government agency with a series of electronic reports with approximately 500 fields in total. We were provided with a list of the required fields but there was a problem – the names of the fields did not always correspond to the names in our database. To make matters even worse, some of the fields required complicated calculations and manipulations.

As a result, the following conversation took place between the project manager (PM) and the senior vice president of risk management (SVP):

PM: “This project could be a bit of a challenge for us. The deadline, scope and quality are fixed and not subject to negotiations with the government. We are not able to get additional internal resources and can’t outsource.”

SVP: “So, what other options do we have? Looks like we have exhausted all of the corners of your project management pentagon …”

PM: “There is one possibility still. You know how the fields in the government document do not correspond directly to the field names in our database?”

SVP: “Yes, I have been informed about that by my people.”

PM: “Here is how we can save some time. Our IT guys are not financial experts; they know all of the fields in the database but they can’t easily map them to the ones mentioned in the government’s documents. No doubt, they can use phones and e-mail to uncover all of the details, but that would take a lot of time. Would you be able to assign a couple of your senior financial experts to help us out with the mapping process? I think we can easily shave a couple of months off the project duration.”

SVP: “Yes, I can see how this could be a problem for the developers. I think, I can assign a couple of my senior managers to help you out.”

Present Multiple Offers
A good project manager can take negotiation methodology one step further and really impress your management and clients. Let’s assume that you have been given a project that should take approximately nine months to deliver according to your team’s objective estimates. Your boss, of course, expects you to deliver the project in seven months. After engaging your management and other project stakeholders in a fact-finding discussion, you can prepare a list of possible scenarios that may look something like that (see Exhibit 5):

Exhibit 5

Offers	Parameters
Option 1	Scope:	Remains the same
	Time:	Seven months
	Effort:	Add two engineers and replace the designer with a more experienced one
Option 2	Scope:	Decrease number of features by 30%
	Time:	Seven months
	Effort:	Remains the same
Option 3	Scope:	Decrease number of features by 15%
	Time:	Seven months
	Effort:	Replace the designer with a more experienced one and outsource some work to a sub-contractor

Why is it a good idea to put several offers on the table? Firstly, it demonstrates professionalism; the stakeholders would definitely appreciate that the project manager listened to their concerns and constraints and prepared not one, but several potentially acceptable options for them. Secondly, it opens three (in this particular example) instead of one, possible doors to a successful project completion.

Summary
Negotiation is not only an active selling of your position but also focusing on the other side’s interests, needs, priorities, constraints and perspectives.

When negotiating on your projects use investigative techniques and questions in order to understand the position of your counterpart as much as possible. Once you understood their situation, try to invent the options for mutual gain, so that both parties can benefit from the agreement.

Insist on using objective criteria for topics of discussion by relying on objective standards, historical data and previous experience.

Never lie during project negotiations as a little tactical “gain” will almost always lead to a strategic loss of trust and damage the relationship with the other party. Also, do not dismiss your counterpart’s issues as “their problem” since sometimes you may be in a possession of a very cheap solution for their very expensive problem.

Understand that people tend to be irrational in negotiations for a reason; typically it is lack of proper negotiations-related training or lack of decision-making authority. A good project manager educates his customer between projects, when waters are calm, rather than during active negotiations.

Finally, use the project management pentagon to your full advantage. Ask questions targeting each one of the five corners and new doors will start to open. In addition, remember that It is always better to present the customers with several potentially acceptable offers rather than just one.

Bibliography

1. “The Honoured Society: The Sicilian Mafia Observed” by Norman Lewis (Paperback – Dec 19, 2003)
2. “Cosa Nostra: A History of the Sicilian Mafia” by John Dickie (Hardcover – Oct 7, 2004)
3. “Mafia Allies: The True Story of America’s Secret Alliance with the Mob in World War II” by Tim Newark (Hardcover – 2008)
4. “Villalba Journal; How Don Calo (and Patton) Won the War in Sicily”, The New York Times, May 24, 1994
5. “Giù le mani, questa è tutta roba di Don Calò », La Repubblica, August 17, 1991
6. “Getting to Yes: Negotiating Agreement Without Giving In” (Paperback) by Roger Fisher, William L. Ury and Bruce Patton
7. “Negotiation Genius: How to Overcome Obstacles and Achieve Brilliant Results at the Bargaining Table and Beyond” by Deepak Malhotra and Max Bazerman (Paperback – Aug 26, 2008)
8. “Bargaining for Advantage: Negotiation Strategies for Reasonable People” 2nd Edition (Paperback) by G. Richard Shell
9. “Software Estimation: Demystifying the Black Art” (Best Practices (Microsoft)) by Steve McConnell (Paperback – Mar 1, 2006)

Don’t forget to leave your comments below

---

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. Mr. Moustafaev is author of “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” (released by J. Ross Publishing in September 2010). He is also the author of various project management and business analysis webinars delivered in partnership with Project Times:

•   Why and How Should You Manage Scope and Customer Expectations?
•   Are We Supposed To Negotiate On Projects?
•   Top Ten Things You (Probably) Did Not Know About Estimation

In addition to teaching a highly acclaimed “Project Management Essentials” course at British Columbia Institute of Technology, Mr. Moustafaev 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”  

For further information, please contact: Mr. Moustafaev Phone: 778-995-4396 

E-mail::[email protected]  Website: www.thinktankconsulting.ca

Mutiny on the High Seas

In 1707 a British fleet under the command of Sir Clowdisley Shovell was returning home after a long mission. The convoy encountered a heavy fog upon entering the English Channel. The admiral gathered his officers and navigators to get a definite fix on their location. After a short consultation the officers reported to Shovell that the fleet was safely off the coast of France. The admiral was about to issue an order to sail North to England when a sailor approached him and asked his permission to speak.

The sailor told Sir Clowdisley that he was keeping track of their position by using his own navigational equipment. He also informed the admiral that the officers were badly mistaken and that the fleet was much closer to English shores than they anticipated. Therefore, according to the sailor it was very dangerous to proceed to England at full speed since they were in danger of wrecking on the Scilly Isles.

Sir Clowdisley ordered the man hanged as a mutineer. Hours later, his flagship and three other boats of his fleet smashed into the rocks. He was swept ashore where, according to one of the legends, he was murdered by a woman who wanted his emerald ring.

By the way, according to British Naval Law, the sailor indeed deserved to be hanged. The danger of mutiny was a real problem on English ships due to bad living conditions, diseases and corporal punishment. Therefore, only the officers were allowed to keep and use navigational equipment. Admiralty’s logic was that if the sailors didn’t know where they were, they would be less inclined to rebel against the officers.

This story was frequently used by historians to demonstrate the incompetence, stubbornness and, even pompousness, of some military leaders. Nonetheless, I sometimes joke with my students that the first mistake the admiral made was that of wasting his project resources. After all, what project manager in the right mind disposes of his precious project team members in the middle of the project?

On a more serious note, in my opinion this story also serves as a great example of how the project can go terribly wrong if the project manager chooses to ignore the critique and the feedback from the stakeholders in general and from his own “technical” team members in particular.

I have already mentioned in an earlier article (1) Defining the Detailed Scope: How and Where Do You Find Requirements? the interesting paradox with walkthroughs, inspections and peer reviews. I have learned about these techniques fairly early in my career, liked the concept and started applying it on all of my projects fairly consistently and at times covertly, because of the pressure from some of my superiors to “quit wasting technical people’s time on ‘silly’ meetings”. I also know that many of my peers in the IT and software development industries utilized such practices on a regular basis as was confirmed by them during our discussions at various conferences and other professional project management events.

Having spent a big chunk of my career in the aforementioned high-tech sector, I naturally assumed that our project management cousins in the fields where project management has taken much deeper roots – engineering, construction and government – are using this tool on a regular basis.

To my great surprise the words “peer reviews” and “walkthroughs” did not generate much interest or recognition/familiarity among my BCIT (British Columbia Institute of Technology) project management students. Over the course of my teaching career at the university I had people from construction, engineering, pharmaceutical, government, utilities, oil and gas, movie and even theatre sectors sign up for my course. Surprisingly enough, very few of them (excluding some of the IT and software people) ever confirmed that they were indeed using or even aware of this powerful technique.

The interesting aspect of this phenomenon is that almost all of them, after a prolonged cheerleading from my end, tried using walkthroughs and peer reviews to validate the scope of the projects, to identify otherwise unexpected risks and to decrease the amount of mistakes and the rework required. The results were, to say the least, staggering. All who tried this methodology reported great results including, but not limited to, projects finished before the deadlines, high quality of final product or service and, most importantly, highly satisfied customers!

Peer Reviews, Inspections and Walkthroughs

Why Conduct Peer Reviews, Inspections and Walkthroughs?
Let us start our discussion on the reviews with a very interesting statistic originating from the IT and software industry. Unfortunately due to lack of reliable information from other sectors we have to rely on the data collected in the high-tech field and then construct generalized extrapolations from them to the rest of the world. So, without further ado, here is a very interesting statistic:

Forty five percent (45%) of project costs industry-wide is rework!

Let’s ponder this number for a while. If we choose to believe in the power of extrapolation to one degree or another, it looks like by eliminating the amount of rework completely we can decrease all of our project budgets in half. Durations would probably fall by a significant number as well.

However, upon further analysis this number does not look excessively abnormal if one remembers the “Cost of Mistake” chart discussed in detail in (2) Kick-Starting Your Projects – What Should You Know About Defining Scope? and “Defining The Detailed Scope: How And Where Do You Find Requirements?” articles. In a nutshell, the study conducted by Barry Boehm (one of the leading thinkers in the field of software development) claims that a mistake that would cost you one dollar to fix at the Initiation stage of the project will typically balloon to a $40 -1,000 deficiency by the project closure.

So, what can happen without the walkthroughs, inspections and peer reviews? Here is a very typical scenario (a bit exaggerated for illustrational purposes) witnessed by the author on numerous occasions throughout his career:

Step 1: Project manager, sometimes with the help of other resources (e.g. business analyst in IT field or architect in the construction industry, mechanical engineer in product development, etc.) develops a project plan and a scope document (e.g. Statement of Work).

Step 2: Technical project team members are still working on other “very important” projects and their functional managers frown upon “distracting them from their urgent tasks.

Step 3: Customers and/or end users are not consulted about the final designs, either because they are “fairly technical” or to avoid “annoying” questions, corrections and other “disruptions”.

Step 4: Project manager presents the documents – project plan and statement of work – to technical people and possibly does a quick walkthrough during the project kick-off meeting.

Step 5: Project team members discover a great deal of deficiencies, mistakes and risks in the documentation but, unfortunately, major commitments with respect to time, budget and scope have already been made

Step 6: Finally, the project team pulls together and based on sheer will and long hours deliver a product that somewhat resembles the scope described in the documentation. In addition, despite all the heroic efforts, the project is late and over the budget

Step 7: Finally, customers walk in the doors and even after cursory inspection of the product find dozens and dozens of defects, omissions and mistakes …

The subsequent sections of this article will attempt to explain what should be done and how it should be done with respect to walkthroughs, inspections and peer reviews in order to avoid the depressing situation described earlier. Exhibit 1 provides the reader wit a high-level overview of the documentation review process.

How to Conduct Peer Reviews, Inspections and Walkthroughs

What Documents should be Reviewed?
Typically it is a good idea to review all the major project, scope and other key documents on your projects. The more that documents get reviewed fairly early in the process, the less are the chances of missing scope items, unforeseen risks and hidden constraints. Having said that, in real life, assembling the entire group of project stakeholders or even stakeholder sub-groups is a difficult and time-consuming task that may not be encouraged at some organizations. Therefore, it seems quite logical to at least concentrate on the most important of the project documents.

Primary documents for the project team members and customers would definitely be the Project Plan and the Statement of Work (aka Scope Document, aka Requirements Document) since they contain the key information crucial to project success. It is also very useful to at least briefly familiarize the project team with the Project Charter in order to inform the technical team members about the project itself, key scope items and constraints. However it is absolutely essential that a project manager conduct a full-scale walkthrough of the Project Charter with the customers and key stakeholders.

How to Organize Peer Review and Walkthrough Meetings?
The best way to conduct peer reviews and walkthroughs (especially on larger, more complicated projects) is to arrange for them at regular intervals during the document development stage. At least two or three meetings should be scheduled closer to the end of Project Charter, Project Plan and Scope Document development stages.

Please note that there is a serious chance that the functional managers may tell you that the technical people are too busy to attend such meetings. Sometimes other stakeholders could feign busyness and refuse or ignore your invitations to the walkthrough meetings. Experience tells us that the best way to convince these people is to share the “Cost of Mistake” chart with them and ask them whether they consider spending a couple of hours now in order to avoid spending several hundred to a thousand hours later a worthwhile investment.

It is a good idea to reserve a two-hour block of time in a medium to large-size well-ventilated conference room several days in advance. You will need at least two hours because the documents – especially on larger projects – tend to be fairly long. Thus, even walking a group of, say, twenty or thirty people through a fifty-page document will probably take the entire two-hour meeting.

Exhibit 1

On the other hand, keep in mind that walkthroughs and reviews of project documents, especially the ones taking place earlier in the process are very vigorous and spirited affairs that could drain all of project manager’s energy and even sometimes hope. Thus, allocating more than two hours for the meeting could have some inherent dangers – people will get tired, start losing their collective focus and may even become a bit cranky!

Always remember, walkthroughs and peer reviews can sometimes be a very humbling experience indeed! One advice I give to my students and my fellow project managers is that a couple of hours of humbling experience is a very small price to pay for discovering mistakes, errors and omissions early in the project.

Preparing for the meeting also involves sending the first draft of the document in question to all the meeting participants with an indication that everyone is expected to review the document with a critical eye and come prepared to voice his or her concerns, suggestions and improvements. Mentioning that a document is just a first draft that could change dramatically after the series of reviews and walkthroughs is especially important because sometimes – and this depends on a number of cultural factors, including but not limited to organizational and country-specific – people could be reluctant to voice their criticism of your work.

I remember a situation when our project had to outsource some of the development work to India and, after working in North America for my entire professional life and thus being used to a fair share of peer critique and feedback, I assumed that no adjustments should be made when communicating to the developers in Bangalore. I remember how we sent a Requirements Specification (Scope Document) to them and arranged for a conference call. I spent about thirty minutes walking our colleague through a fifteen-page document and concluded by asking the typical inspection-type question:

Me: “So, guys, now that I gave an overview of the scope, do you see any problems, risks, issues? Anything that would prevent you from doing proper design and development?”

Team Lead in India: “No, everything seems perfect!”

Me: “Guys, there is no such thing as a perfect first draft of the Requirements Specification! Come on, there must be something”

Team Lead in India: “We don’t see any problems”

Me: “OK, take a couple of days and review it amongst yourselves; if you have any questions, do not hesitate to contact me. We can discuss this again”

Team Lead in India: “Great! We shall call you if anything comes up”

Needless to say I never received any follow-up phone calls or e-mails. While remaining in a blissful state of denial, although all of my experience was telling me that something was very wrong, I continued to receive progress reports from India stating that they were “four days ahead of schedule”. Finally when the product was delivered and inspected by our local team, we discovered that the end-product was so flawed, that we had to redo the entire development phase of the project from scratch. Interestingly enough, we did discover a lot of issues and deficiencies in the original scope document that most definitely contributed to the low quality of the final product.

When I mentioned this story to one of my senior colleagues, a person who, by the way, was born and raised in India, he told me, “You really expected them to criticize your work?! Critique of one’s superiors is not something that is welcomed with open hands over there. They probably saw the mistakes and deficiencies in the document right away but did not want to embarrass you by pointing out the mistakes you made. It is very likely that they tried to address these deficiencies on their own and failed miserably. You should have inspected and peer-reviewed it here first”.

The next step is to conduct a quick document walkthrough either using the document itself or some kind of presentation software. It is good idea to plug your laptop into the overhead projector so that everyone can see what is being discussed and recorded. I typically opt for a Word document so that all of the comments, critique, feedback and follow-up items can be recorded right there. It is a good idea to let people word their comments by themselves rather than rephrase them in format acceptable to you. This way you can avoid future misunderstandings about the content of the feedback.

Whatever form you decide to choose – comments in the word processor document or remarks in your notebook – it is worthwhile to re-record all of the action items from these meetings into some kind of Issues List and disseminate it to all of the meeting participants and other project stakeholders. Personal experience shows that incorporating this Issues List into the meeting minutes that should be created and sent out to all the stakeholders is an effective and time-saving technique.

Running Peer Reviews and Inspections
Before getting into the peer review discussion I would like to point out that there are actually two very distinct types of peer reviews. One can call them proper format review and correct technical context review.

Proper Format Review. This is typically done by an experienced project manager external to the project. Accordingly this person is usually not familiar with the detailed technical scope of the project. Actually in my experience it has been even better if that person hasn’t heard about the project in question before!

The problem is that someone who has been involved in the project extensively and has participated in many of the project discussions is less likely to be as alert and vigilant when reviewing project documentation. In addition, he or she may be subject to the group’s assumptions, either consciously or unconsciously, dominating the project team. A colleague of mine actually came up with a very accurate description of these phenomena; he referred to them as “soaping of the eyes”.

For instance the technical people on the project team may think that they have a very good idea what a “seamless integration” means. An experienced peer reviewer who hasn’t been burdened by team influence will flag this phrase as inappropriate right away.

Therefore the proper format reviewer’s mission is not to validate the technical scope of the project or schedule and budget estimates, or to ask questions like, “What problem were you trying to solve?” His job is to make sure that the document follows the best practices of project management.

The documentation guru’s primary responsibility would be to capture deficiencies and mistakes such as ambiguous language (see Exhibit 4), missing measurability, completeness, consistency, prioritization, proper constructs, etc. (see article “Defining The Detailed Scope: How And Where Do You Find Requirements?” for an in-depth discussion of quality project documentation).

Unfortunately these kinds of reviews can not answer questions like:

• Can this scope item be delivered at all?
• Can this scope item be delivered with the budget and timeline provided?
• Are there any technical inconsistencies in the scope?

Correct Technical Context Reviews or inspections come in handy here. The technical team members probably would focus on the correctness of technical information, unidentified risks, overlooked resource requirements, etc. in the documents rather than the way in which documentation is written.

For example, a statement like

“Build a large four-bedroom three-bathroom Tuscan-style home on a budget of one hundred thousand dollars by the end of next month”

will probably generate different kinds of feedback from the guru and from the technical project team members. The documentation guru will almost certainly notice an inappropriate use of the word “large” and will ask the project manager to associate a measurable attribute with that particular term. As a result the word “large” could be replaced with statements like “5,000 square feet” or “three-level, 6,000 square feet.”

On the other hand, technical team members may have an idea (not necessarily a correct one) of what “large” means or they may just miss it because of the lack of training in documentation reviews. However, they will probably come back to you with a comment that buildings of that size can not be built on a budget of hundred thousand dollars and be completed in month and a half.

Who are the people you should invite to peer reviews and inspections? With proper format reviews it is fairly straightforward – it’s the project manager and the documentation guru, most likely one of the most experienced project leaders in the company who has been properly trained in the fine art of critical reading.

The technical document inspections will require the presence of the project manager, team leads of each functional group involved in the project, all technical team members, quality assurance people, subject matter experts in each of the functional areas and several key representatives from the customer side.

Running Customer Walkthroughs
For a stakeholder walkthrough you probably want to consider inviting your client or customer (whichever is applicable) and if possible the end users of the product. Note that each one of these groups could be in turn subdivided into several clusters; some of these clusters could be primary and some of them could be secondary but both are important.

Also, it would be a good idea to invite key representatives from the technical team since some of the questions posed by the customers and users could only be answered by them. You also need technical team reps in order to explain and justify your estimates.

If you are working on a multi-departmental project at a fairly functional organization inviting other department heads could also be valuable because they could end up providing resources for your project.

Peer Review and Walkthrough Challenges

Some of the issues encountered by the project teams during the peer reviews, walkthroughs and inspections include large requirements documents, large inspection teams and geographical separation.

So, what are the tools at your disposal in battling the “walkthrough fatigue”? First, if dealing with larger documents, attempt to schedule several reviews in stages. This way you can reduce the duration of reviews and maintain the focus of the participants. Also, try not to exceed a two hour time limit on meetings. And one final suggestion: when booking a conference room, pick the largest and the best ventilated room possible. Nothing kills the thought process like the lack of oxygen!

Sometimes the review teams can get very large, especially on key project documents like project plan or project scope definition. Having fifty or more people in the room commenting and providing critique on your documentation can turn into chaos very quickly. Therefore, it could be useful to break the inspection teams into groups for initial inspections, and once the major issues discovered in these separate meetings have been analyzed and addressed properly, the final joint technical team and customer walkthrough involving all the project stakeholders can take place.

Geographical separation can also present certain challenges. Try using tools like video conferencing, teleconferencing or tracking and comments functions in word processing software.

What Kinds Of Questions Should You Expect (And Ask)?

So what kinds of questions can one expect from the walkthroughs with the customers and the technical team members? Exhibit 2 lists some of the questions the project manager should expect when engaging in the walkthroughs, inspections and peer reviews.

Exhibit 2

Question	Document	What Should The Project Manager Do?
“Why are your estimate ranges so wide?”	Project Charter and Project Plan	Explain that the appropriate ranges for the Initiation stage estimates are +75; -25% for regular projects and +300%; -75% for software development and R&D ventures
“Why will it take so long?	Project Charter and Project Plan	Go over the project schedule and explain how the estimates were obtained
“Why will it cost so much?”	Project Charter and Project Plan	Go over the project budget and explain how the estimates were obtained
“Can you finish the project faster?”	Project Charter and Project Plan	Explain the concept of project management triangle (scope, time, budget) or pentagon (scope, time, budget, effort and quality) and find out which areas can be manipulated to deliver the project faster
“Can you find some ways to do it cheaper?”	Project Charter and Project Plan	Explain the concept of project management triangle or pentagon and find out which areas can be manipulated to deliver the project cheaper
“We have to add another high-level feature”	Project Charter	Try to assess which problem the requested feature will solve and if, necessary, add to the “Issues List”. If required, schedule an “offline” meeting
“We have to add another detailed scope item”	Scope Document	Try to assess which problem the requested requirement will solve and, if necessary, add to the “Issues List”. If required, schedule an “offline” meeting
“With respect to project feasibility, who came up with revenue projections?”	Project Charter	Explain the underlying logic in arriving at future revenue forecasts
“You should also mention regulatory projects, competitive advantage, etc. in the project feasibility section”	Project Charter	Have a discussion with the participants and add to the document if necessary
“Have you considered this risk?”	Project Charter and Project Plan	Quickly assess the risk and flag for incorporation into the documentation. Arrange for an offline meeting and/or follow up if necessary. Add to the “Issues List”
“You need to communicate to person X from Department Y; he should be involved in this discussion”	All documents	Add to the “Issues List”. Schedule a follow-up meeting with that person
“Director of Department Z will have to assign resources to this project	All documents	Add to the “Issues List”. Schedule a follow-up meeting with that person
“Hey, that is not what I needed!”	Scope Document	Briefly discuss the problem with the stakeholder. Add to the “Issues List”. Arrange for an offline meeting and/or follow up if necessary
“Oh, I have just realized that we will also be needing this feature …”	Scope Document	Briefly discuss the new scope item with the stakeholder. Add to the “Issues List”. Arrange for an offline meeting and/or follow up if necessary
“You forgot to include this…”	Scope Document	Briefly discuss the new scope item with the stakeholder. Add to the “Issues List”. Arrange for an offline meeting and/or follow up if necessary
“There is conflict between these two (or more) scope items”	Scope Document	Add to the “Issues List”. Arrange for an offline meeting and/or follow up if necessary
“We do not have the capability to make that happen”	Scope Document	Discuss why this can’t be done and what are the alternative ways of reaching project objectives. Add to the “Issues List”. Arrange for an offline meeting and/or follow up if necessary
“I can interpret this statement in several ways”	All documents	Rephrase the statement in a proper format to remove ambiguity

What to Watch Out For: Defect Checklists

So what are the things all the reviewers should be on the watch for during walkthroughs, peer reviews and inspections? When reviewing scope and other project management documents the stakeholders should be asking themselves the following questions under the following categories:

Organization and completeness of the documentation:

• Are all parts of the documents written at a consistent and appropriate level of detail?
• Does the scope definition document provide an adequate basis for design?
• Do we have priorities assigned to each scope item?
• Is there any information missing in the document? Are there any “TBDs” in the documents?
• Did we cover all possible alternatives, exceptions, risks and constraints?

Technical feasibility:

• Is every requirement in scope?
• Can all the scope items be implemented with all the known constraints?

Measurability:

• Do all of the scope items have appropriate measurability attributes associated with them?

Ambiguity:

• Do all the key statements in the document have only one possible meaning?
• Can they be misinterpreted by any of the stakeholders?

“Dangerous words”

• Exhibit 3 provides a list of potentially troublesome words and phrases that tend to frequently appear in project management documentation in basically all industries and types of organizations

Exhibit 3

Words	What To Do About Them?
“Acceptable”, “adequate”	Define acceptability and how the product and stakeholders can decide what is acceptable and what is not
“Efficient”	Explain how efficiently the product performs operations or how easy it is to use
“Fast”, “rapid”	Specify minimum, maximum and desired speed
“Flexible”	What specifically should the product do in response to specific changes in the environment or business objectives
“Improved”, “better”, “faster”, “superior”	Quantify how much faster constitutes adequate improvement
“Maximize”, “minimize”, “optimize”	Provide maximum and minimum acceptable parameters for each value. You can also provide desired range too
“Seamless”, “transparent”, “graceful”	Translate into observable product characteristics
“Several”	How many? Provide a specific number or maximum and minimum acceptable parameters for each value
“State-of-the-art”	Define what this means
“Sufficient”	How much is sufficient?
“Support”, “enable”	Define exactly what functions would constitute support or enabling
“User-friendly”, “simple”, “easy”	Translate into observable product characteristics

Summation

Document walkthroughs, inspections and peer reviews are surprisingly underutilized in many industries despite strong evidence that these practices have a very positive effect on the quality of project results.

Considering the fact that close to forty-five percent of project costs are rework and that the cost of fixing a mistake grows a thousand-fold as one progresses from the project initiation to the close-out, utilization of these techniques is a very worthwhile and rewarding investment.

In a perfect world most of the project management documentation would be properly reviewed by the proper audiences; however, in the “worst-case” scenario at least review the project charter, the project plan and the scope documents.

When conducting reviews and inspections, you should reserve ample time (but not too long, as people will get tired) in a large, well-ventilated room. Email the document in question form ahead of time and inform the reviewers that this is a first draft that may change considerably as feedback is received, analyzed and incorporated. Be aware of cultural and organizational obstacles to conducting candid and open reviews.

Understand the difference between customer walkthroughs, “proper format” reviews done by the experts in your organization and “correct context” technical team inspections and utilize them all at proper times in the project.

Be aware of the types of questions you may be asked and know how to act in each scenario. Maintain an Issues List during each meeting to have a list of all the problems and questions raised for future follow-up. .Also, use a “defect checklist” as a guide in assessing the quality of your documentation.

One final piece of advice: when walking into the review conference room, leave your ego at the door!

Don’t forget to post your comments below

Bibliography

1. “Software Requirements, Second Edition (Pro-Best Practices)” by Karl E. Wiegers
2. “Effective Requirements Practices” (Addison-Wesley Information Technology Series) by Ralph R. Young
3. “Exploring Requirements: Quality Before Design” by Donald C. Gause and Gerald M. Weinberg
4. “Requirements by Collaboration: Workshops for Defining Needs” by Ellen Gottesdiener (Kindle Edition – Feb 17, 2009)
5. Mastering the Requirements Process (2nd Edition) (Hardcover) by Suzanne Robertson and James C. Robertson
6. “Project Management Body of Knowledge (PMBOK)” by Project Management Institute (PMI)
7. “Project Management” by Robert Santarossa
8. “Economic Principles: Seven Ideas for Thinking … About Almost Anything” by Douglas Allen
9. “Software Engineering Economics by Barry Boehm,”, Prentice-Hall, 1981

---

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. Mr. Moustafaev is author of “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” (released by J. Ross Publishing in September 2010). He is also the author of various project management and business analysis webinars delivered in partnership with Project Times:

•   Why and How Should You Manage Scope and Customer Expectations?
•   Are We Supposed To Negotiate On Projects?
•   Top Ten Things You (Probably) Did Not Know About Estimation

In addition to teaching a highly acclaimed “Project Management Essentials” course at British Columbia Institute of Technology, Mr. Moustafaev 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”  

For further information, please contact: Mr. Moustafaev Phone: 778-995-4396 

E-mail::[email protected]  Website: www.thinktankconsulting.ca

Late in 1940 the Soviet government was starting to get concerned that the country was in danger of German invasion despite the signing of the 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 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

Bibliography

1. “Project Management” by Robert Santarossa
2. “Icebreaker: Who Started the Second World War?” (Hardcover) by Viktor Suvorov
3. “The Art of Project Management” by Scott Berkun
4. “PMP: Project Management Professional Exam Study Guide” by Kim Heldman
5. “Project Management Body of Knowledge (PMBOK)” by Project Management Institute (PMI)
6. “Portfolio Management for New Products” by Robert Cooper
7. “Software Estimation: Demystifying the Black Art” by Steve McConnell

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. Mr. Moustafaev is author of “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” (released by J. Ross Publishing in September 2010). He is also the author of various project management and business analysis webinars delivered in partnership with Project Times:

•   Why and How Should You Manage Scope and Customer Expectations?
•   Are We Supposed To Negotiate On Projects?
•   Top Ten Things You (Probably) Did Not Know About Estimation

In addition to teaching a highly acclaimed “Project Management Essentials” course at British Columbia Institute of Technology, Mr. Moustafaev 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”  

For further information, please contact: Mr. Moustafaev Phone: 778-995-4396 

E-mail::[email protected]  Website: www.thinktankconsulting.ca

---

The M247 “Sergeant York” Story

In late seventies the US Department of Defense (DOD) outsourced the development of the self-propelled anti-aircraft (AA) weapon which featured twin radar-directed 40 mm rapid-fire guns to Ford Aerospace. The project was assigned the name of “Sergeant York”, after the World War I US army hero, who undoubtedly would not have appreciated this dubious honor had he been alive in 1979. The weapon was intended to replace the M163 Vulcan Air Defense System and fight alongside the M1 Abrams and M2 Bradley fighting vehicles in the U.S. Army, and was similar in concept to successful Soviet and European systems such as the ZSU-23-4 and Gepard.

In essence it was an air defense weapon mounted on the surplus M48 Patton tank chassis, provided by the Army, which were held in large quantities in their depots. The main job of the weapon was to sit on the front lines and automatically target and shoot down enemy aircraft, especially helicopters. As a result it was designed to hone in on metal parts rotating in the air (i.e. propeller blades).

The final test of the AA gun involved a demonstration involving a prototype weapon shooting down a hovering helicopter on one of the US DOD proving grounds somewhere in the desert in the southern part of the United States. The cost of the project at that time was approximately US $1 billion.

According to the legend cultivated in the aerospace and defense industries there was a portable toilet installed not far away from the testing grounds. Because of the hot climate, the toilet cabin had a small electric fan in it …

You probably managed to guess the rest – the billion dollar piece of equipment “decided” to ignore the much larger target – the helicopter – and targeted the unique signature of the “port-a-potty’s” electric fan!

Further tests revealed that the AA gun had the following deficiencies:

• The radar could not track low flying targets due to excessive ground clutter
• The radar could not distinguish a hovering helicopter from a clump of trees
• Turret traverse was too slow to track a fast crossing target
• The radar can be jammed very easily

As a result, the project that began in 1975 was finally cancelled by then Secretary of Defense, Caspar Weinberger, in 1985.

This story is, in my opinion, a perfect example of a botched scope definition exercise as most of the Department of Defense requirements, both obvious (i.e. ability to track low flying targets, fast moving targets and resistance to radar jamming) and implied (not confusing the helicopter with a clump of trees or a portable toilet) have been left unfulfilled.

What Is The State Of The Industry?

Standish Group and Project Management Institute (PMI) paint a fairly bleak picture: we still only managed to “achieve” a 35% success rate on our projects. Apply this number to a total price tag of all projects in US ($2.3 trillion) and you will arrive at a mind-boggling $1 trillion dollars in underperforming ventures annually! Furthermore, according to the Standish Group, five out of the top eight reasons why projects fail are related to scope definition. These include:

• Incomplete requirements
• Lack of user involvement
• Unrealistic customer expectations
• Changing requirements and specifications
• Customers no longer need the features provided

Further analysis of causes of “bad” requirements yielded the following results (see Exhibit 1):

Exhibit 1

In addition, the study conducted by Barry Boehm (one of the leading thinkers in the field of software development) involved an analysis of 63 software development projects in companies like IBM, GTE and TRW and determined the relative costs of fixing an error at various stages of the project. Exhibit 2 demonstrates a phenomenal increase in the cost of mistake from one dollar at the Initiation stage of the project to $40-1,000 dollar range at the Closeout (see Exhibit 2).

Now, I do realize that this information is based on the software development industry; unfortunately I wasn’t able to find comparable data from other fields. However, I think it would be reasonable to assume that this trend will, to a certain extent, hold true for most of the other industries.

To prove my point I like to use the following example. Imagine that you have made a “one-dollar” mistake at the very beginning of the project … and forgot to include a requirement for an underground parking garage for a condo building your company is about to erect. How much, do you think this mistake will end up costing at the end of the project when you realize that the only way to “insert” the garage is to completely destroy the tower and start the entire project from scratch? The mistake ratio will no longer be 1,000:1 it would probably balloon to 10,000,000:1, wouldn’t it?

The amusing aspect of this story is that until recently I used to apologize for using this “silly” example because this “would never happen in real life”, until I learned that a similar incident did indeed take place in a major North American city. Apparently a real estate development company acquired a hundred-year old heritage building with the intent of converting it into a luxury condominium complex. One “little” thing that they somehow overlooked – heritage buildings do not have underground parking! The problem was finally solved by acquiring (at a great cost) the rights to several dozen parking spots in a new high-rise located nearby.

Exhibit 2

I think, based on the above, it is safe to assume that a considerable share of our project failures originate in our inability to capture the scope properly. However, based on the feedback I was getting from the technical people in various industries (engineers, architects, construction experts, etc.), the scope problem is not rooted in our inability to come up with detailed blueprints, bills of materials or design and architecture documents. The predicament lies in the initial stages of the projects, when we need to elicit high-level initial set of customer problems, issues, needs and propose potential solutions.

Defining the Initial Scope

What Is A Business Requirement?

In order to answer what is a business requirement, let us first determine what requirements are NOT. The business requirement is not a combination of e-mails, voicemails, sticky notes, annotations in your notebook, verbal instructions from the customers and your superiors and/or “drawings on a napkin”. Therefore a business requirement (aka high-level project scope item) is:

“A requirement is something the product or service must do or a quality it must have. A requirement exists either because the type of product or service demands certain qualities or functions or because the client wants that requirement to be a part of the delivered product or service”

Business requirements should be documented either in a standalone “Business Requirements” document or, at least, captured in the Project Charter.

Asking the Right Questions

The first step in every project should be trying to determine what is it that you are going to build for you customers, either internal or external. Setting off on the right foot depends to a large degree on the type of questions you or your team members ask. For example, let’s assume that the first question posed by your management was:

“Can you create a means for protecting a small group of human beings from the hostile elements of their environment?”

As a result of the discussion that may follow, some of the possible solutions could be:

• Shack
• Typical family home
• Buckingham Palace

But what are we building?” is by far not the only question you should be asking at the beginning of the project. Exhibit 3 lists the mandatory high-level questions a project manager should be prepared to ask once the project is handed down to him.

Exhibit 3

Question You Should Ask	Why Should You Ask This Question?	What Happens If You Don’t Ask It?
Why are we doing this?	To make sure there is a clear understanding of the needs and benefits for the project	You may end up working on a project that will deliver little or no value to your company or the customer
What happens if we don’t do this project?	Just another way of ensuring that the management thought through the potential “penalties” of not doing the project	Your company may end with low-priority, “soon-to-be-cancelled” projects while the high-value projects remain on the backburner
Who is the client?	You have to know who the original source of the requirement is	You may end up receiving requirements that have been “distorted” by going through the “chain of command”
What problem are we trying to solve?	As a representative of the “technical” team you may have a much better (cheaper, faster) solution the customer is not aware of	You may end up delivering a “Ferrari” when a “bicycle” solution will do (or vice versa). As a result you may: a) waste company resources b) disappoint your customer
If you don’t know this, then who does?	You need to make sure you are getting the correct information	You may end up talking to the “messengers” instead of real project champions. As a result you may end up with bad-quality information
Who else could be impacted by this feature?	There could be hidden interdependencies between this feature and other ones you are not aware of	You can miss important interdependencies or even contradictions between various scope items.
How much money are you ready to spend?	You need to gain a high-level understanding of the project budget	There could be a significant discrepancy between what the customer wants and what you can deliver at the budget available
How much time do we have?	You need to gain a high-level understanding of project duration	There could be a significant discrepancy between what the customer wants and what you can deliver with the time available

Once the ballpark scope of the project has been determined we can proceed to more detailed questions (these could also fall into the category of Project Charter-level questions):

• How big do you want the house to be?
• Is it going to be a one, two or three-level home?
• What square footage would you prefer?
• What style would you prefer (e.g. Victorian, Tuscan, Contemporary, etc.)?
• How many bedrooms do you need?
• How many bathrooms would you prefer?

Also, keep in mind that all of the questions directed at the entire project in Exhibit 3 should now apply to every scope item under discussion. For example, let’s review some of the questions a project manager can ask with respect to the number of bedrooms:

• Why do you need five bedrooms?
• Would you be OK with just four?
• The budget you mentioned allows only for a four bedroom home; would you like to downgrade the scope or allocate more money to the budget?

 

Assigning Priorities

Since, typically, customers want way more features than the project budget and timeline will allow, it is also very important to assign priorities to the scope items or “features” discovered at this stage. The suggested categories for the priorities are:

• Priority 1 (“Must Have”)
• Priority 2 (“Should Have”)
• Priority 3 (“Nice To have”)

Unfortunately, the concept of assigning priorities is very frequently misunderstood by the project stakeholders. Invariably, a lion’s share of the features gets stamped with a “Must Have” priority label right at the beginning of the process, thus eliminating any potential flexibility in future scope-related decisions.

Therefore, I like to consider the following example of priority assignment. Imagine that we are designing the first-ever car. What scope items would fall into the “Must Have” category? In my opinion, these should include:

• Frame
• Four tires (or maybe even three, depending on design)
• Engine
• Driver-side seat
• Steering wheel
• Brakes

Things like passenger-side seat, seat belts, windows and roof will fall into the “Should Have” category. A car stereo with speakers and navigational system should fall into the “Nice To Have” category.

Getting Rid Of the Ambiguity

Another important and very frequently overlooked aspect of the scope definition is the ambiguous language one can encounter in the project and portfolio documentation. These include words like: “fast”, “pretty”, “big”, “small”, “cutting-edge”, “usable”, etc. The danger of these words is that psychologically we are trained to accept them as normal, everyday concepts. However, when it comes to project management, words like these can act as deadly time-bombs. For example, the word “cutting edge” seems like a normal, even cool word to describe a product. And while it looks fine in marketing materials or TV ads, introducing this word to scope documentation can cause a lot of issues down the road.

The reason for that is, while everyone understands, more or less, what “cutting-edge” means, no two people have an identical understanding of the concept. These differences in understanding can lead to very expensive and time-consuming scope adjustments once the project moves into planning and execution stages.

One of the executives I was having a discussion with told me, “We had a construction project budgeted at $500 million dollars once. Because we allowed the words like “cutting-edge” to sneak into the Business Case our final bill for the project ballooned to $700 million. There always was at least one key stakeholder in the room for whom a given feature was not revolutionary enough! And because we initially made a commitment to being “cutting-edge” there was no way for us to back away from that”.

The Problem vs. Solution Discussion

When gathering the requirements project managers very frequently come across stakeholders’ ideas for a solution rather than the description of the underlying problem. You should always strive is to interpret what is said thereby uncovering the essence. Let me provide you with a couple of examples.

Example 1

Let’s pretend that you are security company expert and you have been contacted by a manager of a very large downtown office building that had experienced a string of break-ins and thefts from the offices of the companies located there. There are two possible scenarios of how this conversation may go:

Scenario A:

Building Manager: “Your company has to install card readers at all the entrances to the building and we need all the employees in this building to have an access card”

You: “OK, no problem. Let’s determine the number of entrance points into the building and the number of people requiring the card and I can probably provide you with an estimate for the project.”

Or we can go with scenario B:

Building Manager: “Your company has to install card readers at all the entrances to the building and we need all the employees in this building to have an access card”

You: “So what you are really saying is that we need to make sure that only authorized people have access to our building, right?”

Building Manager: “Yes, that is exactly the problem we have”

You: “Well our company has a variety of alternatives for you depending on your budget, time and how ‘state-of-the-art’ you want the solution to be. Here is a list of options we can offer:

• Retina scan
• Fingerprint scan
• Palm scan
• Voice recognition
• Card and card readers
• Remote controls
• Chips implanted under the skin
• Hiring a security guard
• ‘Neighborhood Watch’ program”

Building Manager: “Oh, I didn’t realize we had so many options. Let me talk to my colleagues and get back to you”

In which case do you think you have made a better impression on the customer and, more importantly, in which case would the solution chosen address customers’ needs better?

If this sounds like a bit of a cheesy scenario, especially considering the “chip implanted under the skin “part, let me give you an actual real-life and extremely unglamorous example of how this essence principle works.

Example 2

These events took place while I was working at an IT department of a very large international financial institution.

My boss: “Risk Management is having problems with their desktop statistical analysis software. They are asking for an Enterprise Edition of the software and a dedicated server. Our initial ballpark estimates for this project are at $500,000 and we have neither money in our budget nor the resources to accomplish that. You mission is to explain to them that they are not getting this stuff in the next couple of years!”

Me (going over to the Risk Management Department): “What is the problem?”

Risk Management people: “We have to store files on the shared server because of the privacy laws and access them through our desktops. Processing times are very slow. We have to upgrade to Enterprise Server Edition and get a new server”

Me (calling Network and Infrastructure people): “But why is the processing slow? Is it the network or the overloaded server?”

Network people: “We checked the network and it does not appear to be overloaded”

Infrastructure people: “Are you kidding me?! The entire building is using this server. Of course it is overloaded and slow”

Me: “So, what can we do?”

Infrastructure people: “We will give them a dedicated NT server; we think we had one lying around here somewhere …”

The end-result of this story? The entire $500,000 project was diminished to a $2,000 server and three man-days of work.

Constraints, Preferences and the Tilt Concept

In one of the books I was reading I came across an interesting concept presented by the author – “The Tilt Concept”. The author offered his observations of various pinball players. According to him, some pinball players tilt their machines all the time. These are not very good players because they can’t restrain themselves. Some of the players never tilt the pinball machines; they are the worst players because they always follow the rules. The author contends that the best players do tilt the machines, but they never overdo it. Hence, “The Tilt Concept” – If you never tilt, you are not using your resources!

Exhibit 4

WHAT SOMEONE SAYS	WHAT WE DO
“That information is confidential”	We stop pursuing something that may be essential to good design
“That violates standards”	We drop a promising idea
“The boss would never approve of that”	We shrivel into a ball and change the subject

Some of the examples of our being afraid to “tilt” are shown in the Exhibit 4. Tilting also means unnecessarily constraining your design options. Here is agood example of what bold vs. timid designers would do in similar situations (see Exhibit 5)

Exhibit 5

Related to the “Tilt Concept” is the ability to distinguish between mandatory constraints and desired preferences.

For example, an information system designed to tabulate and report US presidential elections must be ready to operate by the first Tuesday after the first Monday in November of the next leap year. If the product is not ready by that day – it has no value for the next four years. This is definitely a constraint! A requirement to upload a photo of the new executive team member on to the company website by end-of-day Friday is typically a preference.

Conclusion

 

A large share of our project troubles is rooted in our inability to capture the initial high-level scope of our ventures. There are several techniques that a project manager should utilize in order to elicit the right business requirements early in the project.

First, in order to overcome this issue project managers have to understand the definition of business requirements and record them properly either in a separate standalone document or include them in the project charter.

Second, project mangers have to ask the right questions including such “uncomfortable” ones as “Why are we doing this?”, “What problem are you trying to solve?”, “What happens if we don’t do this project?” etc.

Thirdly, a disciplined prioritization approach should be utilized on every scope definition exercise. As well, “ambiguity time bombs” should be eliminated from the project management documentation.

Concentration on the essence (i.e. the original problem) rather than on the implied or suggested solutions should always reign supreme in the project manager’s mind.

And finally, understanding the oh so subtle differences between the real, hard constraints and desired preferences is another important ingredient in defining project scope.

Bibliography

1. “Project Management” by Robert Santarossa
2. http://en.wikipedia.org/wiki/M247_Sergeant_York
3. Major Micheal Ditton, “The DIVAD Procurement: A Weapon System Case Study”, The Army Lawyer, August 1988, pp. 3-9
4. “Gunning for Sergeant York”, Time, August 1985
5. “No time for Sergeant”, The Nation, September 1985
6. “Software Requirements, Second Edition (Pro-Best Practices)” by Karl E. Wiegers
7. “Effective Requirements Practices” (Addison-Wesley Information Technology Series) by Ralph R. Young
8. “Exploring Requirements: Quality Before Design” by Donald C. Gause and Gerald M. Weinberg

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. Mr. Moustafaev is author of “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” (released by J. Ross Publishing in September 2010). He is also the author of various project management and business analysis webinars delivered in partnership with Project Times:

•   Why and How Should You Manage Scope and Customer Expectations?
•   Are We Supposed To Negotiate On Projects?
•   Top Ten Things You (Probably) Did Not Know About Estimation

In addition to teaching a highly acclaimed “Project Management Essentials” course at British Columbia Institute of Technology, Mr. Moustafaev 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”  

For further information, please contact: Mr. Moustafaev Phone: 778-995-4396 

E-mail::[email protected]  Website: www.thinktankconsulting.ca

---