SOCIOLOGICAL ASPECTS OF THE CUSTOMER & CONSUMER
BEHAVIOR:
MANAGING CUSTOMER EXPECTATIONS:
SCOPE CREEP - HOW TO AVOID IT & THE VENDOR'S RESPONSIBILITY:
POOR ESTIMATION (VENDOR'S RESPONSIBILITY):
LACK OF MANAGEMENT EXPERIENCE:
SOME SOLUTIONS TO UNDERSTANDING THE CLIENT & PROJECT
DEVELOPMENT:
COLLABORATE
WITH THE CUSTOMER:
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
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.
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).
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
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.
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)
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)
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
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#J4
.
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.