INTRODUCTION: EXPECTATION GAP

In the world we live today, businesses and top executives must understand what differentiates their companies from others and must understand the needs of the consumers in their markets. If these two ingredients are understood, a business can develop a strategic plan to create a market niche and develop their customer base to be successful. Development of this information along with the development of the internal business processes can lead to some form of a competitive advantage in the market. The businesses and their representatives are directly responsible for the patterns of purchases (in the long run) of each of their customers. How they (the customers) will react within certain situations is largely due to the education and supplying the customer with enough data and tools to proficiently inform them of what is to be completed and within what context and timeframe. Understanding the customer and their reactions to the environment will prolong the life of the relationship between businesses and their customers.

Understanding the customer can be a starting point for most businesses and a re-evaluation point for most others. There are at times where a gap occurs between what customers expect and what management / businesses presume they expect. This often happens because companies overlook or do not fully understand customer's perceptions and expectations. In spite of a strong commitment and sincere desire to provide quality service, many companies fall dramatically short of the mark, usually because they have an internally directed rather than externally directed focus. An internally directed focus assumes that the company knows what customers should want and delivers or produces that. This orientation often leads to providing products and services that do not match customer's expectations important features and benefits may be left out and levels of performance may be inadequate. According to Michael Wing, A few common elements that contribute to the gab between customer expectations and the product or service offered are as follows:

Inadequate bilateral communication between frontline personnel and management.
An absence of regular interaction between management and customers
An absence of a strong marketing-research program (understanding the customer)
An absence of customer-service accountability. (Wing, p. 14)

The list above covers some basic issues in customer service. Frontline employees are in constant communication with the customers and management tends to not know the needs of those customers. Communication must be bilateral for internal purposes, because the direction of the company is lead by management, but is dictated by the customer. Frontline employees are the bloodline from the customers to the management team. If the management team does not believe that all the information is getting back to them from the customers through the frontline employees, managers must make sure that there is some form of interaction between them and the customer. This also allows for the managers to keep in place some customer-service accountability. Managers are responsible for identifying problems and resolving them, wherever they may exist. A lot of problems exist, but because of the working relationships between the frontline employees and the customers, most customers would not confront the frontline employees about their problems.

These uncertainties create a gap in the customer service that is necessary to continue the relationship. Providing a product or service your customers perceive as excellent requires you to know what it is that your customers expect. This is the most critical component of delivering excellent customer service. Virtually every company thinks it knows what its customers want. However, even if a company is only slightly inaccurate about its assumptions, it could lose the business to another company that has more accurately filled the customer's needs. Also, being only slightly inaccurate can lead your organization to spend money, time and effort on things that are not important to your customers. And in a worse case scenario, it can mean not surviving in an intensely competitive environment.

SOCIOLOGICAL ASPECTS OF THE CUSTOMER & CONSUMER BEHAVIOR

There are countless theories explaining customer behavior and attributes. According to the Consumer Psychology in Behavioural perspective. "The most widely-accepted and influential models of consumer behavior derive in large part from cognitive psychology. As a result, consumer choice is usually understood as a problem-solving and decision-making sequence of activities, the outcome of which is determined principally by the buyer's intellectual functioning and rational, goal-directed processing of information." (Foxall, p. 8). These types of theories on consumer behavior invest consumers with extensive capacities to handle considerable quantities of information and to engage in processing of that information to compare, contrast, and evaluate alternative information for the consumers' purposes and aims. Even early models of managerial type decision-making models were based on this reasoned, goal-directed information processing. With the constant growing competitive markets and the growing field of information within those markets, no one individual nor organization can encompass the information flow by cognitive means. Computers and information systems have replaced the activities of individuals in the decision making roles and organization have built systems to become the cognitive decision making models that once was done by human means alone. So how does this affect the customer? It now means that not only does the organization need to understand the consumer, but the system that is built needs to have that understanding also. Building that type of information within that system takes time and money, but with the business environment as it stands, the information flow of a computer can better deal with the sophisticated information flows and intricate details by compiling all of that information faster. Information within a system can then process the information at a higher rate of speed and return results in a more proficient and accurate manner.

Customers and their behaviors comprise of many attributes and differentials. These differences are not just associated with demographics, groups or any one particular item. There is a complex development of behaviors that exist in the consumer markets. Just by human nature, consumers can be spontaneous, unpredictable, and selfish. By these definitions, businesses, consumers and purchasers are usually trying to find the best advantageous deal around and always looking after number one (number one can be the business or themselves). What makes the customer is not always a predisposition attribute, but rather an educated or enforced protocol that has been in stowed into their mindset. In other words, we as vendors can still influence the consumer. There are ways to enhance the products as vendors and create relationships to influence the consumers to have confidence in the products. Once the consumer's needs are found, vendors can then create the "image" of what the consumer should expect from the products. On the other hand, getting as much information about the customer can give the vendor more information to better serve the market as a whole. The marketplace is characterized by continuous changes in market composition, business practices and structure. To understand what makes up the customer is unique to every business, but there are models, such as EXHIBIT 1: (below) that have some significance in the collaboration of several theories about consumer behavior. Exhibit #1 graphically summarizes previous efforts to explain consumer behavior (Moschis, p. 4). The solid lines and arrows show how efforts have been explicitly directed at the examination of consumer behavior primarily by marketing and consumer researchers. The dotted lines show relationships reported by researchers in the consumer field as well a by researcher in other disciplines. These relationships show an indirect influence on consumer behavior through an intervening variable, that is, they show how one factor affects another variable, which in turn might directly or indirectly affect consumer behavior. (Moschis, p. 4).

The penetration of the Web has become sufficiently pervasive, to the extent that Web consumers now represent a wide range of demographic attributes, such as the whole of the consumer market. With the recent shift in the last 100 years of mass communications, particularly television, it has led to the success of consumers on the Internet in our culture. The web offered a benefit that TV lacked: two-way communications. There are still many people who continue to experience a feeling of strangeness and distrust about the Internet, but the reality of it all, the shift has moved most businesses into the Internet market. Businesses and vendors must realize that the potential of the Internet and consumer behavior within its means. The Internet will become a vehicle as intrinsic to our daily existence as TV's and telephones are in today's world for communication and consumer development. This open-ended subject has many components to it, but the issue at hand is how the Internet impacts consumer behavior. Consumer behavior on the web is yet to be figured out and the models are in the beginning stages, but we now know it is here to stay and there is a large market segment waiting for all businesses to join in the pursuit to easier transactions and information on the Web. According to "The Soul of the New Consumer", we have primarily focused on what consumers like and dislike about online shopping. But how has the Internet changed the other ways that consumers shop? The key reasons new consumers say they like to shop online are:

§ It's more convenient as compared to other methods of shopping

§ It saves time

§ They are more empowered because of better product information and the ability to compare offerings among many different vendors

§ They find better product selection at better prices

§ The primary drawbacks to online shopping are:

§ Some products are simply not conducive to an online purchase

§ Many consumers appreciate and want to experience the "aesthetics of shopping,"

§ Returning products that don't meet their requirements is a hassle.

EXHIBIT 2: shows how Web shopping behavior is affecting other channels from which the surveyed people from this book typically buy. (Windham, p. 153)

MANAGING CUSTOMER EXPECTATIONS

In developing any type of business relationship, especially in a service-oriented type of relationship, expectation on both parties must be monitored and maintained. In Managing to Keep the Customer, the service organization should have the recognition of the needs, coupled with knowledge of what to change, capacity, and willingness of the management team to implement the needed changes. Once a project is in motion, expressing those necessary changes in the current protocols of the client organization is necessary and effective communication of the goals of that client organization is a must. Getting those necessary systems requirements prior to the engagement of a project is always necessary, but is not always easy. Being able to change the project in the middle can be costly for the client and for the vendor. It can cause a change in focus because of the fact that the whole picture was not fully presented prior to the beginning of the project or it can even scrap what has been done and must redo to encapsulate the whole system.

First and foremost, the concept of understanding customer's perceptions must not be an afterthought, but must be the driving force behind every project. "Our expectations are influenced by our previous experience, our knowledge, and our memory. And what we perceive is often what we expect to see or what we are looking for. This mental set functions at the unconscious level to delimit our capability to perceive." (Mahatoo, p.68). Keeping this in mind, we are enabling our client to use prior experience to maintain their expectations. Their perception is not always reality; therefore vendors must "shape" those perceptions, so that it does reflect reality. "A key to the design and operation of project management is understanding the user's perceptions and matching the systems around those perceptions. Failure of most projects stem from systems developers denying that the users have any say in the development of the systems". (Bender, p.28.)

In the development of customer systems requirements and understanding the customers expectations, there is a list of priorities that must be met in order to perceive the system as a whole, according to Paul Bender of Design and Operation of Customer Service Systems:

§ Measure internal knowledge of Customer Service Requirements

§ Identify the types of requirements to be established

§ Determine the format and accuracy needed

§ Establish the Survey Techniques to be used inside the client's business

§ Conduct Interview and gathering of information

§ Analyze the results to establish customer service standards

§ Identify the constraints and define acceptable ranges

§ Then set goals to meet the customer service requirements set

This methodology is just a type of methodology to obtain the essence of what customer's want. After a full review of the requirements, those requirements must be well documented to keep the customer well informed. The goal is to have all the requirements of the system properly defined on paper so that it is well defined in the minds of the customer. This hopefully resolves issues of conflict between the vendor and the customer and what are the functional requirements specifications. A service level agreement is made at that time to define what standard procedures are set out as guidelines to enable the relationship a record of what is to be expected. This provides a contractual record of what the vendor is to provide and at what levels that is acceptable by the customer. According to Steven Bragg, "Outsourcing projects present a conflicting strategy within the vendors' business. The client always wants functional and well-developed systems, and they should expect it, but in order to maintain control of the process, there must be a scope to work under. Customers constantly try to fudge that scope." (Bragg, p. 7) Vendors must define the level of service in explicit means at the beginning of the project and informing the client that changes in that scope can change the timing of the project completion date. A reason that is subject to more disputes is when management does not feel that a supplier is providing the level of service that was promised at the start of the relationship. In these cases, if there is no clear set of performance measurements that both parties have agreed upon in advance, then the termination of the relationship may be rancorous in the extreme, and may involve litigation. Instead, the company and the supplier should make this decision based on performance measurements that have been verified and approved. If those measurements do not exist at the time when management is already questioning the ability of the supplier, it is still useful to being calculating the measurements, since it gives senior management a better basis of information to use when deciding to terminate a project.

SCOPE CREEP -- HOW TO AVOID IT & THE VENDOR'S RESPONSIBILITY

A good definition is located from the web: "Scope Creep is the expression used by project managers and/or vendors who are under pressure to constantly deliver in excess of what was originally agreed. Scope creep normally results from a failure to establish the clear requirements of the business users. As these begin to solidify the scope of the original plan can start to move - and continue to move. If the project manager is not alert to this (all too common) phenomenon, the requirements will constantly change thus ensuring that the projects spends years on delivering nothing, as they are continually reviewing and altering direction."(20.)

This scope creep cycle can be disastrous for some organizations. The cycle of reviewing and changing the requirements may be necessary on the customer's side, but a worse case scenario is that the whole project is cut because of a lack of funding or lack of time. On the other hand, a scope change can be an opportunity. Some scope changes that are clearly beyond an original work package may turn out to be the source of additional work - commonly called add-on work, engagement expansion, up-selling etc. "Good scope management always keeps that possibility in mind. It's a great way to turn a possible threat into an advantage. Some service organizations thrive by expanding existing projects by identifying additional "value-added" work they can perform for their clients. The keyword is value-added, not nickel and diming or padding the contract. Your client will be happier for it. And your project manager and employer will love you for it." (2.)

A good business relationship on a project is crucial to both the supplier and the customer. The vendor has the responsibility to the client to be responsive, unassuming in the requirements stage, due diligence in the gathering of information, and explicit communication in the documentation stage. The vendor then has to complete the engagement by following through on the promises of the documentation. At the implementation stage, the focus of problem solving come into view because of the fact that the systems, even though designed appropriately, are not exactly what the customer wants. So, how do you know when a project has gone 10,000 leagues below the sea in scope creep? Katherine Spencer Lee gives some pointers and explains:

"It's possible to do everything by the book only to find things written in between the lines later. Frequent communication with the clients about their expectations is invaluable, because every change has consequences both in money and time. If you're working with a consulting firm, it's also important to include the account executive in the communication loop. Reinforce project objectives through frequent reviews and progress reports. When a client requests a change, alert everyone involved in writing. (E-mail is appropriate in most cases.) Ask all parties for input on whether the changes will impact the overall project. Be sure to outline how each change may affect budget, time, labor and quality. If adjustments that will impact your billing rate or project fee are made to the schedule, be sure to negotiate this right away. If you delay this conversation, the client may assume the change is "free" and has no impact on the timeline. Bad news is always best delivered sooner rather than later. If schedules are off track or budgets might be exceeded, inform the appropriate parties immediately. Remember, time is money. You want to avoid a situation in which you are forced to take a profit loss, especially with a fixed-fee contract."(21.)

Most of the time, it is not the client who is changing their requirements, but the environment that the business is in that changes the requirements. When customers initiate a project, they do so with a certain idea in mind of the end result. If the project manager does his job well, that idea will be translated into a scope document of some kind. However, once things get under way, a new dynamic begins:

· The customer starts to learn more, and realized that what they originally asked for is not what they need, so they initiate a change in scope, or requirements.

· The business needs can change over the course of the project so that what was originally contracted for, is now not relevant, or

· The marketplace has changed and what was originally contracted for must be delivered early to address a business need.

According to Ted Marcus' survey - These elements will change the original project parameters, to the point that this survey reported that 44% of respondents said poor requirements definition is the reason for scope creep. Furthermore, only 16% of the project managers say "No" to user requests for "significant changes well into the development cycle". From another survey, taken from Glass' book, "Software Runaways", it catalogs some of the more prominent disasters experienced by the software industry. He reports, "Study after study has found that where there is a failure, requirements problems are usually found at the heart of the matter." Problems occur when requirements are:

· too numerous

· unstable

· ambiguous

· incomplete (Glass, p. 21)

As with any large system, the longer the development takes, the more the user [and other parties] will mess with the original specs -- for different reasons. One is that as they learn more of what is possible, they become dissatisfied with the original functionality requested. They realize that they can better serve their business interests by introducing some change into the application. Or, particularly if the development drags on, the business needs themselves will change, and therefore the original requirements are obsolete.

The above assume that the requirements were reasonable at the outset. Yourdon (1997) claims that this assumption is changing and that most development projects today are planned from the beginning to be virtually impossible or called "death marches"; struggles against the odds to achieve, or fall by the wayside. In these cases, a late delivery is very likely indeed.

POOR ESTIMATION (VENDOR'S RESPONSIBILITY)

Inaccurate estimations are "one of the major factors in the breakdown of relationships between IT people and their clients." (10). A project plan is an educated guess at how to reach certain goals, by a certain date, at a certain cost. The plan needs to be put together by the project manager, with the input of the people who will actually be doing the work. To the question; Why are these estimates not borne out? the answer is "It's not that simple.";

In the early stages of a project, particularly a large one, when the estimates are generated, there can be a vagueness about what form the project will really take, both with regard to the tactics of performing the tasks, as well as the actual goals, which can change as work progresses. This results in a risk that: "the schedule dates and budget numbers lack validity at later stages of the project. As more project activities are completed, and more changes occur in your knowledge and understanding of the project goals and objectives and of the possible ways of producing a correct solution, the more likely it is that the assumptions you made early on are incorrect and incomplete. " (DeWeaver, p. 66). This presumes that we find out more about the project as we go along -- even with regard to the goals. But even with projects that are well defined from the start, accurately predicting the end date can be problematic, "because we know so little about accurate schedule estimation, and because estimates are usually made by the people who are least able to make accurate estimates (e.g., marketers and customers), it is simply the norm that schedule targets, and thus cost targets, are unreasonably short. The problem for systems and software is that the field is so young... we are really never quite sure that an unreasonable schedule is, in fact THAT unreasonable." (Glass, p. 11). Additionally, many estimates may be politically driven (Thomsett), with an end result similar to the above. In fact, Thomsett (e, 1998) in a very funny article about the "Estimation Games" played between the project manager and his superiors, suggests that in the most desperate cases, where the project manager has a gun to his head to produce estimates, he take out the most reliable estimating tool around: three dice. Shake, roll, and give the total of months (or weeks or days, depending on the situation) for the project.

Another reason has to do with accurately assessing resource allocation. Ideally, a resource would be fully devoted to a task or project until he had completed his work. In reality, resources are often forced into multi-tasking: juggling several projects at the same time. This leads to obvious inefficiencies from refocusing, finding the work, mentally readjusting, etc. And just as this is true on an individual level, it can be even more pronounced on an organizational level.

A study of a dozen companies applying process management to product development over a period of eight years, showed that:

· Projects get done faster if an organization does fewer of them at a time.

· Investments to relieve bottlenecks yield disproportionately large time-to-market benefits.

· Eliminating unnecessary variation in workloads and work process eliminates distractions and delays, thereby freeing up the organization to focus on the creative parts of the task.

The result of applying these three approaches was that average development time dropped by 30 to 50%. (Adler, p. 134). The impact is that companys estimate their schedules based on a higher level of productivity than is actually the case. The twelve companies studied above were not aware of "of the share of the average workweek that non-project work was consuming." (Adler, p. 143).

LACK OF MANAGEMENT EXPERIENCE

Project managers generally evolve into their role; they do not train for them. In fact, Thomsett notes, "the average commercial IT person has completed a 3 year university degree in computing before they are recruited into organizations. In addition, most IT people would obtain at least 3 -5 days of formal technical education per year within their companies. So, if we look at an 8-year veteran, they would typically have between 300 - 400 days of formal technical education! However, as they are moved into project management, the total of formal education in project management is 0 days! At best, they may receive a 1 to 3 day workshop on project management. No wonder our group& and others & have found that poorly-trained project managers are a major cause of project failure." (Thomsett, twilight zone). To this lack of project management experience we can add the observation that project managers are usually promoted because of their technical abilities, not because of their adeptness at social skills, which is more necessary than technical virtuosity. As a project manager, you "must develop your ability to facilitate, include other people, and [gain] consensus among people with different expectations." (Thomsett, p. 10). DeWeaver echoes this approach throughout her book. This skill set of a high degree of creativity, breadth of vision, and a concern for people, is difficult to realize.

SOME SOLUTIONS TO UNDERSTANDING THE CLIENT & PROJECT DEVELOPMENT

COLLABORATE WITH THE CUSTOMER

Studies show that projects that are deemed "successful" have more direct links between the project team and the customer than those that do not (Keil, p. 33). However, quantity of contact is not enough: the quality of the contact must be there as well. The often-expressed goals are: to work closely with the customer; to involve them; to promote buy-in. The problem is that these terms still promote an "us" and "them" attitude. The truly successful projects will arise when the project team is able to "collaborate" (Highsmith) with the customer. When both have the same goals, see problems the same way, and have joint ownership of the final product. At that level of mutual understanding (the Zen of project management) scope issues will be approached and controlled in a natural way, with both parties sharing the understanding of the costs, risks, and trade-offs of changes to the project. There are a number of corollaries to collaboration, but they all require a close, interactive, relationship with the customer, from the beginning of the concept formation/scope development, to the final implementation. One is the idea of "apprenticing" suggested by Beyer. The apprenticing approach is to work with the customer on a daily basis to observe how he does his job and try to better understand his needs, in an effort to better define the project scope: "It is the relationship between the designers and the customers that determines how well the design team understands the customer problem. This includes not only the overall relationship, but the individual, minute-by-minute process by which a single designer works with a single customer to understand the customer's work." (Beyer, p. 5)

DeWeaver's "humanistic" approach to project management suggests that instead of the traditional system development waterfall, a project should proceed as "successive spirals of product or solution development." (DeWeaver, pp. 46-48). This approach has at its core a joint recognition between the project team and the customer, that what the customer wanted at start may not be what he really wants once more information is developed in the course of proceeding. These spiral are an incremental approach to solving the problem, and in software development terms would be translated into rapid prototyping (RAD) approach. (DeWeaver, p.100-102). A "RADical" approach (Highsmith, b) is in fact a practical corollary of the collaborative element of Highsmith's "Adaptive Software Development" lifecycle. The more the customer is involved in the process, the less likely it is that there will be surprises. In the "old days" the customer and IT met in the beginning of the project and the requirements were transmitted to IT. IT would then go off and build to the reqs. Months, they would present the finished product to the customer. The days this approach can still be used are numbered, at those organizations that do still work that way:

"If you believe that project management is about choosing and using the right organization and time and cost control methods, we predict that you will fail& We believe instead that project management is about enabling people to work together to construct creative solutions that make sense for the organization and the environment in which they operate." (DeWeaver, p.43)

The benefits of collaborating will be evident in the litmus test of any software project: user acceptance. Research shows that users with a high degree of participation in system development will demonstrate greater system acceptance than the users with a low degree of participation. (Saleem, p. 146,165) How does this affect scope? If done properly up front, then both sides will well understand each other, and their should be a good enough understanding and rapport that scope issues will be handled up front.

UNDERSTAND THE EXPECTATIONS

Requirements definition is the background work of scope definition. The problem is, customers do not have requirements, and they have expectations. The job of the information systems project team is to translate the expectations into requirements. Requirements are an information systems issue, a mediator between the business need the customer has and the product requested to meet that need. (Thomsett, expectation). "The word "expectations" has probably been abused and misunderstood more than any other word in the computing culture. To many project managers and systems analysts, expectations are simply those elements of the "requirements" that were not specified by the client. To others, expectations are the difference between what the client wants and what they really need. For the battle-hardened project manager, expectations are a wish list that begin a series of hard negotiations to reduce the expectations to minimum requirements. Finally, expectations are a hopelessly vague set of fuzzy requirements that defy documentation. However, it is our experience that expectations are a related set of specific requirements that can be analyzed and modeled. It's just that data flow and data model and other system-orientated techniques do not capture all the requirements for a business system." When a customer talks about their expectations, from an IS perspective, they are talking about four related sets of requirements:

1. Functional requirements: what the client wants.

2. Quality requirements: how well the functional requirements must be developed.

3. Constraints: when and how the product must be developed.

4. Added value requirements: why the client are really undertaking the project (Thomsett)

HOLDING SCOPE

Rarely will there be a project whose budget or delivery date will permit the developers to incorporate all the desired functionality. In order to help both parties clarify what really needs to be done for the project to succeed, it makes "enormous good sense to separate the system requirements, triage style, into "must-do," "should-do," and "could-do" categories." (Yourdon, p. 134). Of course, just ranking the requirements/expectations is not enough: without further structure, most will be labeled "must-do", and the rest split among the lesser categories. Tackling this problem, a Death March contributor "argues that the users should be required to divide the entire set of requirements into equal groups of three& This prevents the common problem of finding that 90 percent of the requirements have been categorized as critical." (Yourdon, p. 166). Behind this idea, is the concept of "good enough" software, coined by Yourdon and James Bach (Yourdon, p. 148): "For success, it's not required to implement all of the requirements; it's "good enough" if we can implement the "must do" requirements and a reasonable number of the "should-do" requirements. (Yourdon, p. 147).

"Good enough" sounds almost offensive -- as if the customer does not really deserve any better. Highsmith explains it differently, saying, "good enough means something like best value. In a complex environment, the combinations and permutations of value components -- scope (features, performance, defect levels), schedule, and resource -- is so vast, there can never be an optimum value. Good enough is not settling for average, it is delivering the best in a given competitive situation." (Highsmith, 1)

BE FLEXIBLE AND REALISTIC

The responsiveness and collaborative method of working with customers requires a project manager to maintain an attitude of openness and flexibility -- a willingness to let go of control and walk on the "edge of chaos". (See Bardyn and Highsmith (1) both citing M. Mitchell Waldrop, Complexity: The Emerging Science at the Edge of Order and Chaos, 1992.) The "edge of chaos" is a sinister sounding, scary place to be. But that seems to be a more accurate view of the reality of the environment of today's software projects. Project management needs to embrace "as two of its organizing principles that:

· All project goals, objectives, and environments change from the beginning of the project to the end of the project.

· All stakeholders influence and in fact change the project as they work on it, review its products, and implement its results." (DeWeaver, p.42)

How the modern project manager deals with this will determine the success of the project in a large part. In many ways, Thomsett says the same thing in discussing the project manager's "body of good and bad knowledge". Flexibility does not mean just walking on the edge. It also means the ability of keeping a measure of objectivity. If a project manager (or another team member) can recognize that "there is more than one possible "scenario" for the project", then the door is opened to innovating a new approach, geared toward solving a problem cropping up in the project.

EXHIBIT #1

EXHIBIT #2

References:

1. Adler, Paul S., et al. (1996) "Getting the Most Out of Your Product Development Process". Harvard Business Review 74(2) 134-152.

2. Alev, David, "The Scope Went Through the Roof" http://www.consultingacademy.com/a07.htm

3. Bardyn, Janet, and Fitzgerald, Donna. (1998).The Uses of Chaos Theory in Project Management. http://www.newgrange.org/usesof.htm.

4. Bender, Paul S. (1976) "Design And Operation of Customer Service Systems", AMACOM, NY, NY.

5. Beyer, Hugh R., Holtzblatt, Karen. (1995) "Apprenticing with the Customer". Communications of the ACM 38 (3) 45-52.

6. Bragg, Steven M. (1998) "Outsourcing, A guide to..." John Wiley & Sons, Inc. , NY, NY

7. Connell, Charles H. Jr. " Estimating and Scheduling", http://www.chc-3.com/class/modules/schedule.htm

8. Crisp, WynnLee & Williams, Scott, "Managing Scope, Schedule & Budget" http://srd.yahoo.com/goo/scope+creep/12/*http://www.engr.washington.edu/~uw-epp/Transpeed/mss.html

9. Desatnick, Robert L. & Detzel, Denis H. (1993) "Managing to Keep the Customer", Jossey-Bass Publishers, San Francisco

10. De Weaver, Mary Feeherry, and Gillespie, Lori Ciprian (1997). Real-world Project Management: New Approaches for Adapting to Change and Uncertainty", Quality Resources, NY,NY.

11. Foxall, Gordon (1990) "Consumer Psychology in Behavioural Perspective", Routledge, NY, NY.

12. Gilmore, Glenn, "Don't Get Snowballed by Scope Creep"
http://www.eaijournal.com/Article.asp? ArticleID=147

13. Glass, Robert L. (1998). Software Runaways: Lessons Learned from Massive Software Project Failures. Prentice-Hall, Inc., USA

14. Highsmith, Jim. (1997) Messy, Exciting, and Anxiety-Ridden: Adaptive Software Development. (Pub. In American Programmer Magazine, April, 1997) http://www.ksinc.com/articles/CAS.html

15. Keil, Mark; Carmel, Erran.(1995). "Customer-Developer Links in Software Development". Communications of the ACM 38(5) 33-44.

16. Marcus, Ted, "Scope Containment in Information Systems Projects" http:www.gantthead.com/Gantthead/sharedComponents/offsite

17. Mahatoo, Winston H. (1985) "The Dynamics of Consumer Behavior", John Wiley & Sons, Hamilton, Ontario

18. Moschis, George P. (1987) "Consumer Socialization, A Life-Cycle Perspective", Lexinton Books, Toronto Canada.

19. SOS Information Security Glossary "SCOPE CREEP", http://www.riskserver.co.uk/information-security-glossary/gl_scopecreep.htm

20. Spender, Katherine Lee, "Scope Creep -- Mastering Morph Management" http://srd.yahoo.com/goo/scope+creep/5/*http://www.itcmagazine.com/issues/oct01/feature_lee.cfm

21. Thomsett, Rob (1998) It's the Expectations, stupid!, http://www.ozemail.com.au/~thomsett/articles/hot_stupid.htm .

22. Thomsett, Rob (1998) Estimation Games, http://www.ozemail.com.au/~thomsett/articles/games.htm

23. Thomsett, Rob (1998) Into the Twilight Zone, http://www.ozemail.com.au/~thomsett/articles/hot_zone.htm

24. Windham, Laurie (2000) "The Soul of the New Consumer", Allworth Press, NY, NY.

25. Wing, Michael J. (1997) "The Arthur Andersen Guide to Talking With Your Customers" Upstart Publishing Company, Chicago, IL

26. Yourdon, Edward. (1997) Death March: Managing "mission impossible" projects. Prentice-Hall, Inc., USA.