Why Should You Manage Scope and Customer Expectations?

The Camel is a Horse Designed by Committee

The French shipbuilders produced a curious quartet of battleships over the course of twelve years in the late nineteenth century – the Hoche and her sisters Marceau, Magenta and Neptune. It has been argued by some naval historians that because of the accumulation of various features, bits and pieces demanded by multiple departments, they eventually lost any resemblance to battleships.

A foreign critic described one of the ships as “a half-submerged whale with a number of laborer’s cottages built on its back.” A domestic columnist, while being understandably more sympathetic, referred to her as “Le Grand Hotel.”

During the 1880s, French shipbuilders for some inexplicable reasons decided to design their ships by uniting the scoping, design and building phases into one very confusing process. As a result Hoche and her sisters took a staggering 12 years to build while every new and “cool” naval development was added to the ships’ design regardless of its the compatibility with the original blueprint. As a result of such rampant scope creep the Magenta underwent the following transformations (see Exhibit 1):

Exhibit 1

Sequence of Changes	Description Of Changes
Initial design	Armament -three 13.4 inch guns Top speed – 14.5 knots Displacement – 9,800 tons
First change	Change armament from three 13.4 inch guns to two 13.4 inch guns and two 10.8 inch guns
Second change	Change armament from two 13.4 inch guns and two 10.8 inch guns to four 13.4 inch guns and no 10.8 inch guns
Third change	Lengthen and broaden the ship to increase its speed to 16 knots
Fourth change	Add massive military masts and armored conning tower
Fifth change	Add torpedo nets and searchlights
Sixth change	Add a battery of quick-firing guns

Consequently, when Magenta was completed in 1893, she was three hundred tons overweight and lost 30% of her planned stability. The”Conseils de Travaux, charged with overseeing the construction, was accused of behaving like medieval bishops building a Gothic cathedral and the ship itself was being compared to a “three-storied chateau” rising forty feet above the armored belt with sixty guns of different calibers. It was calculated that if the Magenta had trained all of her guns to one side, she would have capsized.

The final nail in the coffin so to speak was unpretentiously provided by the ship’s captain who claimed, “A ship may go into battle only once in its life, and for thirty years it will be inactive. The superstructures annoying in battle, will notably improve habitability for ordinary life.” No wonder the ship was dubbed “Le Grand Hotel”!

These unfortunate vessels were arguably the worst battleships in the French navy. Their service lives were not long. The Magenta was broken up in 1911 and the Hoche was sunk as a practice target on December 2^nd, 1913.

The lessons of this case study are fairly obvious: good project results can not be achieved if the project manager loses control over scope and fails to curb the expectations of the stakeholders.

The Importance of Scope Management

Scope management becomes one of the key activities once the project has entered the execution stage. I have had a lot of discussions with my colleagues and students alike, especially in recent times, regarding the appropriateness of the scope management process on various projects. Some of them complained that their customers have treated the scope management process with a certain degree of hostility and their management is convinced that the procedure contradicts the best practices of customer satisfaction. Yet others took the discussions further by asking a more appropriate question, “How extensive and formal should the change request procedures be for projects of varying size and complexity?”

While it is practically impossible to provide everyone with a universal framework that would fit the needs of any project, I tend to believe that the principles discussed in this article are applicable to all ventures, large and small, simple and sophisticated. The only difference would be the degree of formality associated with this methodology. On a small, simple endeavor, all the principles discussed below can remain at the verbal level with probably one summary e-mail exchanged between the parties. On the other hand, on a very complicated mega-project there would be a lot of documentation, formal meetings and sometimes sophisticated negotiations accompanying every change request.

Consequently, here we are targeting “somewhere-in-between” projects with an assumption that an experienced project manager would be able to fine-tune the degree of formality to the complexity of the project he is working on.

Managing Scope and Stakeholder Expectations: Why Manage Expectations?

One of the project scoping books I have read recently read contained a very interesting phrase, “The difference between disappointment and delight is not a matter of delivery but of how well delivery matches the client’s expectations.” Therefore, controlling customers’ expectations is one of the key success factors, especially once the project has left the planning stage behind and entered the execution phase.

There are several reasons behind the necessity to limit the stakeholders’ expectations. First, because no matter how good one is at capturing and documenting project scope, no matter how many times the team has inspected and peer reviewed the project documents, there will always be omissions, mistakes and errors. Since nobody on the project team is perfect, the customers should be psychologically ready to accept that certain imperfections will rear their heads as you progress through the execution stage. A straightforward communication of this simple fact should limit stakeholders’ expectations in a healthy way.

People in general – and the project customers in particular – are not always logical. To further illustrate this point, consider a time in your life when you or your significant other has saved a coupon from a hotel or restaurant chain to obtain a significant discount at the said business only to discover upon arrival that the coupon was valid only at participating outlets. All your protestations are put to rest by a polite clerk pointing out to a couple of lines printed in an almost invisible font at the very bottom of the document, “Valid only at participating businesses. Check with the specific branch before the trip.”

On one hand, especially from a legal standpoint, this situation is completely the customer’s fault. After all, he or she was expected to read the entire document and arrive at proper conclusions. On the other hand, however, did the chain do a particularly great job of managing customer’s expectations? Probably not, since it doesn’t take an experienced psychologist to know that the vast majority of people have a short attention span when it comes to marketing media and tends to ignore the small font at the bottom or on the reverse side of the coupons …

So remember that being logically or even legally correct is not the same as making the customers happy. Some of the project managers, including the author of this article like to include a section titled “Scope Exclusions” to the project management documents to explicitly state the features that will be excluded from the project scope. Needless to say, this section of the document is highly visible and created using the same font as the rest of the document.

People, especially if they are from different cultural backgrounds, different industries or even different departments of the same company, tend to perceive things differently. As a result, you may think that you and your counterpart are discussing a scope item using fairly similar language only to discover much later that you had been talking about two completely different things.

One of my favorite examples of differing perceptions is the story that took place during Lady Astor’s (one of the first British female politicians) election campaign in Plymouth some time around 1918-1919. According to the legend, Viscountess Astor was canvassing for her first parliamentary seat in the port city of Plymouth. Because of her status and because she was new in town, she was allotted a senior naval officer as her escort. At one point of time during their improvised campaign they approached one of the houses near the port and knocked on the door. A little girl opened the door and the following exchange took place:

Lady Astor: “Is your mother home?”
Little girl: “No, but she said if a lady comes with a sailor they are to use the upstairs room and leave ten bob”

On a more serious note, I once was working on a project to develop a CRM (customer relationship management) website for a resort booking call center. I was discussing the final details of the system with the Director of Customer Management, a young lady who was not very well-versed in the intricacies of software development. At one point I asked her about the desired system availability or uptime.

Director: “Oh, this is a very important system, so I expect it to operate at the highest availability possible. It should be available 100% of the time.”
Me: “Well, 100% availability is basically impossible, even the most complicated systems have to be maintained and upgraded once in a while.”

Director: “So, what is possible?”
Me: “Theoretically you can have 87%, 95% or 99.9% uptime …”

Director: “We only want the best! I shall choose 99.9%”
Me: “OK, but you do realize we will need $20-25 million for that? By the way why would you need that level of uptime? To put it in perspective 99.9% implies that the system will be off only for less than nine hours in a year”

Director: “Oh, I get it now … You misunderstood me, what I wanted is for the system to be up between 9:00 am and 5:00 pm on weekdays. We don’t care what happens to it outside of these times.”

What happened in our conversation? For me the “best possible availability” of the system meant 99.9% of uptime and multi-million expenses associated with it. Whereas for her “best possible availability” meant the system being available only during the working hours Monday to Friday. Had we not have this discussion, we could have encountered some issues later in the project.

What happens if the project manager decides at some point that, since the scope has been documented, reviewed and baselined, the need for active stakeholder management is diminished? Exhibit 2 illustrates a possible scenario if this happened..At some point in the project – we called it Point X – the line of communication between the project team and the customers is broken or severely weakened. The customers may think that they have provided all the relevant information, and the project team may decide that spending more time talking to customers distracts them from their active duties. What happens from that moment on is that an expectations gap starts to appear on the project, a gap between what the customers want and what the project team will deliver. This divergence can occur for a number of reasons, including change in customer preferences, technical abilities of the project team or imperfections in the original scope documentation to name a few.

Exhibit 2

The end result of this process is almost always very sad and disheartening. Customers show up at the end of the project, inspect the results and find a lot of mistakes, deficiencies and discrepancies between the final product and their own expectations, either real or illusory.

Why Do Changes Happen?

So, why do scope changes happen on the projects? No matter how we, project managers dislike unexpected alterations, in many cases they do have a rightful basis. Exhibit 3 lists some of the reasons of why changes can happen on projects along with some relevant examples.

Exhibit 3

Type Of Change	Explanation/Example
Large scope and complexity of the product	Chances that some scope items could be overlooked increase drastically when one compares building a family house with the construction of a modern port terminal
Poorly or loosely defined requirements	Not enough time was allotted for proper scope definition or the requirements specialists were not trained properly
Changes in business objectives and plans	R&D budgets were cut or the weight of the company portfolio has shifted to other priorities
Technology changes	Competitors released a new product with new and “cool” features and the company management feels that these features should be added to their own product
Changes in laws, policies, directives, etc	Government agency implemented new regulatory rules in the middle of the project
Customers and users who change their minds about things	Customer realized that a house with a pool, a tennis court and a four-car garage will look more imposing than a house without all these features
Customers and users who learn “neat” ways of doing things	Customer read a trade magazine and discovered that “engineered stone” countertops are more attractive and durable than the laminate countertops
Technical team members “independently” decide to improve the product	Team member learned about a new technology or saw an interesting feature in the competitor’s product and unilaterally decided to tinker with the scope

How Much Do Things Change?

Much like a miniscule interest rate compounded with necessary frequency can drastically impact the size of one’s debt, so uncontrolled changes can lead to a “scope explosion” on the project.

According to Capers Jones an average rate of scope change on projects is two percent per month. This doesn’t sound like much but simple calculation will yield a staggering 27% growth in the project scope over the course of one year.

To put this number in perspective, if the initial project budget was one million dollars, a scope change rate of two percent will balloon to at least $1,270,000 by the end of the year! We say “at least” because, typically, late changes in the project cost proportionally more than if the same scope items were to be implemented at the beginning of the venture.

A simple implementation of a change control process decreases the monthly growth rate to 0.5 percent, which in turn leads to approximately 6% annual increase in scope.

Exhibit 4 demonstrates various scenarios of monthly scope change rates and annual increases in the scope of the project.

Exhibit 4

Scenario	1	2	3	4	5	6	7	8
Monthly “scope growth” rate	1%	2%	5%	7%	1%	2%	5%	7%
Project duration (months)	12	12	12	12	24	24	24	24
Final scope increases by	6%	27%	80%	125%	27%	61%	223%	407%

Are All Changes Necessarily Bad?

As was mentioned earlier, it is a natural instinct of any project manager – including the author of this article – to dislike last-minute scope changes. Once you have spent copious amounts of time on scoping, scheduling, budgeting and all other related project management tasks, you want to take a deep breath, lean back in your chair and relax for a while as the well-oiled project machine is chugging along destined to deliver great results.

This brings us to a very important question that came up time after time in my class discussions and in conversations with my peers, “Is all change in scope on the project inherently bad?”

We all know of examples when scope creep has devastated projects, driving them to be late and over budget, or delivering graceless monstrosities that nobody wanted. Having said that, are there any good changes that improve the final outcome? Discovery of a major flaw in the original design, new risks that could not have been foreseen, change in the market conditions – shouldn’t we try to address these changes as soon as possible? The key question for the project manager and the rest of the stakeholders including customers and users is purely economical:

“Is the value of implementing the proposed change minus all of its negative impacts higher or lower than the cost of not carrying it out?”

For example, imagine that you are on a multi-day hiking trip. You are not familiar with the area and your friends provided you with a map of the region, warning you that it was fairly outdated. On the second day of your trip you arrive at the bridge across the mountain river. You discover that the bridge is in a very poor condition and obviously has not been repaired in the last twenty or so years. You and your hiking buddies are carrying some heavy equipment and there is a small chance that the bridge will not support your weight; you will plunge from the height of 200 feet right onto a cluster of giant boulders. However, according to the map, there is another bridge 10 miles north of the first one. If your party chooses to change their itinerary and cross the river via the other bridge, the length of your journey will increase by 20 miles (10 miles in each direction). Would a sensible person accept the modification in plans and go looking for the other bridge or reject the change and proceed across the fragile one? I am fairly sure most people would choose the first option since the value of protecting one’s life is definitely higher than the twenty-mile hike and any other inconveniencies associated with it.

Let’s alter the scenario a little bit. The bridge in this scenario is still in bad condition but it crosses a very calm shallow creek. The distance between the bridge and the water surface is a couple of feet. Consequently the worst case scenario for you and your friends is that you would be forced to take a cold bath. What would an average person do in this case? The responses may vary, but I strongly suspect that the majority of people would prefer to cross the bridge because in this scenario the value of keeping yourself dry is less than the costs of an additional twenty-mile hike.

How to Manage Project Scope?

It should be fairly evident by now that “little” enhancements and improvements, if left unattended, can wreak major chaos on any given project. The history of project management contains many examples – see the beginning of this article – when scope creep had a disastrous effect on projects.

Having said that, announcing to all the stakeholders after completion of the scope definition phase that the project requirements are henceforth frozen is imprudent and impractical. As mentioned earlier, not all the changes are inherently bad. A much better approach would be to:

• Baseline the scope definition documentation when you and your stakeholders think that the document is good enough.
• Communicate to the stakeholders in general, and to customers in particular, that they will be subject to the project management pentagon laws; i.e. in order to add or even remove features, usually project budget, duration, number of resources and/or quality will have to suffer.
• Also explain that the cost of implementing scope changes tends to be directly correlated with how late in the project they were submitted – implementation of technical change right after the end of the planning stage and implementation of the same request one week before project close-out will differ dramatically in the cost and the effort required.
• Begin the execution stage of the project and manage the inevitable changes by trying to minimize their affect on the project.

The proper execution of the last point can be facilitated by using a proper change control process. When implementing scope change control, try to avoid complicated procedures; scope management should be as simple and efficient as possible. Keep in mind that if the process is too complicated and cumbersome, the stakeholders will almost always find some creative ways to circumvent it. This is usually accomplished by communicating and sometimes applying political pressure directly to the project technical team, thus removing the project manager from the equation completely.

Exhibit 5

Exhibit 5 demonstrates typical change control methodology. Once the request for a change has been made, it has to be reviewed by the project team to assess all the potential impacts. The stakeholders are presented with all the pros and cons of the new modification with respect to budget, timeline, possible risks, impact on quality, etc and the go or no-go decision is made. In the event of a go decision, all relevant project documents should be updated.

What Does a Good Change Request Look Like?

I started using a Change Request template similar to the one shown in Exhibit 6 quite early in my career and came to love and appreciate this great tool. Let me explain why. The top part of the document called “Section A” is the actual request to alter the scope of the project. The interesting aspect is that the document requires the customer to fill out this part to the best of his ability. Because of this, I came to refer to this part as the first filtration mechanism on the path of the scope creep. A typical conversation between the project manager (PM) and the change petitioner (CP) goes something like this:

CP: “Hey, Jamal, I have been talking to Bob in Marketing and he told me that it would be really cool to add “
PM: “That’s great. I will send you a change request template …”

CP: “Why?”
PM: “Well, because, since you are the requestor, it is logical to assume that you are the one who knows the most about the details of scope and the value this feature will add to the final product …”

CP: “And?”
PM: “Don’t worry, you will have to provide some basic information, describe the change in as much detail as possible and provide the reasons for this modification. It shouldn’t take more than thirty minutes …”

CP: “OK, I will give it a try.”
PM: “If you encounter any problems with the document, give me a shout. I’ll gladly help you out!”

Dear reader, out of every of ten such conversations in how many cases do you think I ever heard from the person again? At most two or three times. An economist would describe this phenomenon in the following manner, “The total utility of not filling out this document was far greater than the utility he was expecting to derive from implementation of this change”. Or, to put this into more colloquial terms, “This scope change is not even worth half an hour of my time”.

Exhibit 6

What is the Impact of the Change?

Assuming this change was indeed worth the thirty-minute effort, the next step is to assemble either your entire project team or at least all of the technical team leads from different areas. The job of these people is to assess the combined impact of such request on key dimensions of any project: scope, time, budget, duration and quality. The questions that should be asked of the project team are presented in Exhibit 7

Exhibit 7

Type Of Questions	Specific Questions
What is the technical impact?	Are there any conflicts with other scope items? Is there an impact on blueprints, bills of materials, technical drawings, design documents, etc? What other documents will have to be updated?
What is the impacts on timeline and budget?	Technical work to be done by engineers, construction crew, developers, architects, etc. Management work to be done (project manager’s time) Documentation to be updated Meetings you need to conduct (everyone involved) How will the change affect the sequence, dependencies, effort and duration of all the tasks in the project plan? What is the impact on budget?
Other impacts	Is the requested change feasible with all known constraints and staff skills? Will the change affect any indirect areas like marketing, public relations, customer support, training, etc.? What is the impact of the change on all other areas of project management including quality, communications, etc.?

As a result of this exercise all of the segments in Section B should be filled out and the merit of the change request should be discussed either between the project manager and the customer or it should be analyzed by the Change Control Board. Based on my professional experience out of the remaining six or seven customers who filled the request form, approximately five or six decide not to go ahead with the modification requested because of the combination of negative impacts outweighs the value such change will bring to the project.

Documentation

While I have made a promise not to concentrate on specific methodologies or frameworks like Agile, traditional PMI-style or any other types of project management approaches, I still think this would be the right point to talk about the documentation management on projects. There are a number of issues I have witnessed while working as a project manager:

• Change gets implemented but the documentation is not updated
• Several versions of the same document are being used by the project team and the stakeholders
• Several people have access to the same document and can add or delete information without other people’s knowledge
• Project stakeholders are not aware or do not have access to the project document repository

Here are some recommendations regarding document management on projects. First, implement and maintain the version control of the documentation. For example, before the document has been signed-off (baselined, approved, etc.) it gets version numbers in the following format: 0.N, i.e. 0.1, 0.2, 0.3, etc. Once the document has been signed-off or approved the numbering system switches to 1.N, i.e. 1.0, 1.1, 1.2 etc. In both cases the version number increases by 0.1 every time the document owner makes a change. This helps a lot in avoiding confusion with various versions of the same document existing in different forms – as attachments to old emails, documents saved on peoples’ computers, hardcopies lying around on employees’ desks, etc. When one of the stakeholders inquires about project documentation, a team member should ask “What version of the document are you looking at?”

Experience shows that having two or more people with read/write access to the project document is a very likely recipe for a disaster. It would require an unimaginable level of communication and between the document authors to ensure that all changes and updates to the document are be synchronized properly. Therefore, a more efficient model is when a “one author – one document” relationship is maintained throughout the project.

Finally, the project manager shouldn’t assume that all the stakeholders regularly check the project documentation folder on the shared drive and are aware of all the changes and updates made to documents. It would be a good practice to send a broadcast e-mail to all the relevant parties every time any of the key project documents get updated:

“Please note that Project Plan document for the Deltaport Terminal project has been updated. Project budget information in table 3.8 now reads, ‘The project budget for the Deltaport Terminal project shall be $125 million +/- $20 million.’ The latest version of the Project Plan document is now version 1.15”

Article Summary

Once the project moves into the execution phase, scope and customer expectations management become one of the key responsibilities of the project manager.

Management of customer expectations is needed because people are not always logical and may have differing perceptions. Team members should also be controlled in order to avoid “gold plating”.

There are several reasons why changes may arise on projects. These could include poorly defined scope, shifts in strategic business objectives and technology, as well as regulatory laws. Furthermore, some customers request modifications, either because they change their minds about the project scope or they discover new, previously unknown features.

Uncontrolled changes, even if imperceptible at first, can quickly snowball into serious complications: project scope can balloon by 50%, 100% and even 400%.

Project managers working at companies that tend to suffer from chronic scope increases are strongly advised to add future scope creep to their estimates. Capturing historical data regarding scope changes on previous projects is, therefore, highly recommended.

Not all scope changes are inherently bad. Every request for modifications or additions to the project scope should be assessed by answering the following question, “Is the value of implementing the proposed change minus all its negative impacts higher or lower than the cost of not carrying it out?”

Follow a process to deal with changes. Depending on the complexity and size of your projects, the formality of the process will vary but analyzing the change and assessing its impacts on all aspects of the project is essential.

Keep in mind that such analysis could be quite costly, especially late in the project. Assessments of change requests almost invariably add time and financial cost to the project regardless of whether they were approved or rejected at the end of the day!

Finally, make sure that all the contents and the versions of relevant documentation are kept up-to-date and communicate those changes to all relevant stakeholders.

Bibliography

1. “Histrionics: A Treasury of Historical Anecdotes” by Geoffrey Regan (Hardcover – Oct 15, 1996)
2. “Brassey’s Book of Naval Blunders” by Geoffrey Regan (Paperback – Aug 1, 2000)
3. “The Art of Project Management (Theory in Practice (O’Reilly))” by Scott Berkun (Paperback – April 21, 2005)
4. “Estimating Software Costs: Bringing Realism to Estimating” by Capers Jones (Hardcover – April 19, 2007)
5. “Economic Principles: Seven Ideas for Thinking … About Almost Anything” by Douglas Allen.
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
9. “Requirements by Collaboration: Workshops for Defining Needs” by Ellen Gottesdiener (Kindle Edition – Feb 17, 2009)
10. Mastering the Requirements Process (2nd Edition) (Hardcover) by Suzanne Robertson and James C. Robertson
11. “Project Management Body of Knowledge (PMBOK)” by Project Management Institute (PMI)
12. “Project Management” by Robert Santarossa

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