Introduction

Systems development projects have a high failure rate.  Often, the users of a system are dissatisfied with it because it does not meet their expectations.

What is the cause and effect relationship between expectations and failure?  No doubt, a poorly designed system will fail to meet expectations.  But sometimes users have unrealistic expectations without regard for constraints of budget, time, manpower, etc., and the best system that developers could produce will go unused because it doesn’t meet these high expectations.  In this latter case, the expectations were actually the cause of the failure, not the other way around.  Perception can be more important than reality.

Project managers have two things to manage: the development of the system and the perception of the system.  For this paper, we are focusing on the latter aspect of project management: managing user expectations.

The intended audience of this paper are developers and managers of systems (or those who strive to be).  Because the strategies discussed are presented in the manner of tips or guidelines, the pronoun “you” is sometimes used as well as the imperative sentence.  This is a conscious choice: the formal tone is traded for improved clarity.  (I don’t think the formal tone should be sacrosanct, especially if the informal is easier to understand.)

First we will consider the importance of managing user expectations.  Then we will explore several strategies for managing user expectations.  In looking at these strategies, we will discuss which strategies are appropriate in which situations.  In concluding, we will contemplate whether there are any “right” or “better” strategies.

The Importance of Managing User Expectations

            We might be tempted to think that the importance of managing user expectations is a new concept.  The importance of the users’ involvement has been recognized at least since the 1970s.  For example, J.K Buckle in his 1977 book Managing Software Projects states “…a well-informed and educated customer will always be able to get the users to accept unpalatable facts much better than any implementer could.” (Buckle, 9)  Jeffrey S. Keen in his book Managing Systems Development of 1981 imparts “…development projects only exist for the line-users’ benefit…, and they should, therefore, be user-orientated.”  (Keen, 288)

Yet in many traditional discussions of systems development, the concept of paying attention to the user’s perceptions seems almost a sideline or an afterthought.  Maybe a few acknowledgements to the issue are made versus pages and pages on other topics.  In Managing the System Life Cycle, 1982, Edward Yourdon says “I define quality assurance as the final opportunity for the user to voice his dissatisfaction with the system, or for the developers to discover that they misunderstood the structured specification.” (Yourdon, 125)  Saying “final,” Yourdon hardly seems to be putting the users views and feedback at the forefront.  In today’s quality-focused environment, his feeble concern for whether the users’ needs are well understood seems almost flippant.  Furthermore, he states his idea of quality in such negative terms (“to voice his dissatisfaction”) that we might surmise he harbors the old antagonistic attitude toward his users.  Proponent of prototyping Bernard H. Boar proclaims in a 1984 book “The idea that the developer or project manager knows best is long dead.”  In fact, this kind of attitude persists today.  “[W]e tend to regard customers as loose cannons—or, even worse, as irrelevant to the development lifecycle.” (Gainer)  Systems developers tend to assume that the wisdom of their designs will enlighten users when they see the finished project.

Perhaps there was a time when systems developers could afford to take the attitude “the users will take whatever we give them.”  “There are two types of systems; those a user must use (such as Accounts Payable), and those that they choose to use (Sales Trends).” (Boar, 46)  Nowadays, users have choices.  Sometimes the user can choose to do it ‘the old way.’  Sometimes there are alternative software products to use.  In other cases, the management has the choice to outsource system development versus using an in-house IT department. (Lawrence, 196)  “[T]he empowered user…can choose between a dictatorial IT department and a supplier who promises to meet their needs.” (Bradbury)  This ability to choose is a large part of the reason developers must pay attention to users’ expectations.

Awareness has been growing lately.  A recent article states “Expectations management is the key to successful projects…The difference is the focus on managing the customer, rather than the product or development team.” (Gainer)

Academic research supports the notion that user expectations are important.  “The available evidence shows that the apparent cause of many system failures is user dissatisfaction with system scope…, system goals…, or the system’s general orientation to the business problem….” (Ginzberg, 461)  “…MIS and MIS implementation failure may well result from the improper management of user expectations.” (Ginzberg, 462)

In the following sections we will take a look at some techniques for managing user expectations.  We will consider traditional as well as current thinking on the topic.

Documentation

            The traditional approach to managing user expectations has been a rather legalistic one.  “A great rule to live by when managing a project: Write down the customer's requirements and get the customer to agree with what you wrote.” (Feibus)  The idea has been “let’s make sure we document what we’re doing with the system.  Then we will have the customer sign off on the document.  That way we’re covered.”  

The documentation effort, at least in the beginning, was probably well-intentioned.  Conventional wisdom says that if the requirements of the system are properly defined in the requirements stage of development, the resulting system will be right.  The inherent assumption is that if the system is designed right, users will appreciate it.

Managers of system development realized that discrepancies arose between the computer department’s view of the system and the user’s view.  They figured users didn’t know what they wanted, didn’t know what they needed, and didn’t know what to expect when their systems were delivered.  So project managers focused on making documentation complete and detailed.  The thinking is “the users are not understanding the systems we are creating.  We need to document them better.”  One name for a document which spells out every conceivable aspect of the system is  functional requirements specification (FRS).  (Buckle, 2)  A closely related type of documentation recommended by some as a way to manage user expectations is the service level agreement (SLA). (Wolverhampton, Decisys)  “Once the parties have established the real user requirements, it is standard procedure to set out your solution on paper in a Service Level Agreement (SLA). This provides a contractual record of what you are to provide.”  (Bradbury)

            “Even in the most orthodox traditional waterfall-based projects, stable requirements simply do not exist.” (Gainer)  Early efforts to manage the customer focused not on managing expectations but instead on controlling change.  Sometimes a “scope of work” document is recommended to “keep the project under control.” (CRMC)  Project managers noticed that users changed their requirements frequently.  To fix the problem, they thought, we must put restrictions on how changes take place to the system and formalize the process.  (Metzger, 116)

            Software packages exist to help document the requirements and manage changes to the requirements.  This is an extension of the same technique, simply a more high-tech and efficient version of it.  (Feibus)

            These documentation-oriented methods are very much alive today.  They are very suitable in a contracting or consulting type situation in which the customer is a separate legal entity from the company who is creating the system for them.  In this case, a legal contract is needed, and it is appropriate to detail the deliverables in documents, legally binding or not.

            The legalistic approach seems less appropriate when the systems department and the users work for the same organization.  To protect the systems department from any claim of negligence on an official level while ignoring the attitudes of the users is antagonistic.  “[M]anaging user expectations is all too often interpreted by IT staff as how to keep users quiet.” (Bradbury)  Users may develop negative judgments about the systems department precisely because they think the systems department is treating them as adversaries.  A more elementary problem with this type of documentation is that often users don’t understand it.  Sometimes the users will not even sign off. (Bradbury)  If the documentation is not helping the users, it serves only the confrontational purpose of shielding the systems department from official accusations of incompetence; if no sign-off is obtained, even that purpose is not served.  Documentation remains an important part of the systems development process, but it does not always serve the purpose of managing user expectations.

Educate Users

"They don't have to know how we work. We exist solely to serve their information needs. If something changes, we have to accept that and deliver what they need on time." (Gainer quoting a co-worker)  This sentiment is more cooperative than the they’ll-take-what-we-give-them attitude since it’s more customer-focused.  But it still assumes that the user doesn’t need to know or shouldn’t know how the computer department works.  Rather than making the processes of the systems department some sort of mystery, educate the customer about your processes and the constraints in which you’re working.  Of course, not all users are going to be sympathetic to the pressures you are under, but many will.  Better to have them understand early-on and be less than perfectly happy than to have them taken off-guard by the end result.

The most important area about which to educate customers is the impact of change.  “[I]f the customer and stakeholders don't understand the gravity of a requirements change, requirements discovery can lead to requirements creep. You, the project manager, must understand your team's development lifecycle model and be able to explain it to the customers and stakeholders in conceptual (rather than technical) terms.” (Gainer)  Let users know that only two of three can be provided: low cost, fast deliver, and no bugs; convey the concept of “good-enough” software. (Gainer)  Educate users on how changes affect the cost of the project and show them the benefit of deferring changes to future releases of the application. (Levine)  “[E]xplain to the users that there will be problems.” (Bradbury)  Just as a football coach can’t keep it from raining, a project manager can’t prevent unforeseen factors.

While we are on the topic of education, we should note that it is also very important that the developers are educated.  Know the users and their business well. (Computer World)  Users will have more respect for developers who know their business and will accept bad news from them more readily.  The education of both parties helps in making sure you speak the same language.

When is the strategy of educating users not appropriate?  Well, sometimes users are going to want the short version of the story, the short answer to their questions.  If you start rambling about the parameters in which you are working, users may think you are waffling.  Also, you are limited in how much time you can devote to this education process, both of the users’ time and your time.

The bottom line: use the strategy of education  unless you have a specific reason not to use it.

Communicate Well with Users

            Merely viewing the users as those to be educated is still a slightly condescending approach.  “The idea behind expectations management is to orchestrate the relationship.” (Gainer)  Good communication is central to the relationship.  What are the marks of a good communication relationship?

            As mentioned earlier, honesty and forthrightness tend to work better than secrecy, but you can be diplomatic.  Don’t assume that every request must be fulfilled, but “[i]f possible, don’t just say no to requests that are out-of-bounds.  Instead, suggest a viable alternative.” (Orenstein)  “Explain the cost implications of what they are asking while remaining sympathetic.” (Bradbury)  It’s okay to help users see your point of view and communicate what is feasible. (Orenstein)  “Being asked to provide a business justification for technology requests will help to separate users' wants from true needs.”  (Bradbury)

            In the traditional view of systems development, the requirements could be gathered early in the process; then the developers would go away and develop the system and the user might not see them again until the presentation of a finished product.  This linear view of systems development has been going out of favor over the years in support of a more incremental approach. (Yourdon, 129)  We must realize “determining requirements is often a process of discovery.” (Gainer)  The contact with the users and their involvement should be ongoing.  “ISD [information systems development] is substantially different from many other product development efforts… provides more opportunities to develop and manage user expectations.” (Hartzel & Flor)  “[U]ser perception of representation [in the development process] is the most significant influence on user satisfaction.” (Lawrence, 195)  Even after the system has been implemented,  IT departments should monitor users to see if they are happy and if requirements are changing, and act on the feedback.  (Bradbury, Ives & Co.)  Furthermore, the communication should be two-way.  As a developer, you should “get feedback any way you can.” (Orenstein)  Be responsive, and “[e]valuate the end-users’ requests promptly.” (RMS)  Regular reporting on project status is essential: report successes, but also report problems before they become crises.  “No one is served if the schedule begins to slip and you don't tell them early on. Believe it or not, they want to know." (Gainer)

            The tactic of reporting deserves special attention.  Keeping users abreast of developments means they will rest easier, they will not be surprised by outcomes, and they will be more convinced that the project is being well managed; as a result, users’ attitudes toward the project will be better.  Reports should list accomplishments, issues, and metrics.  Accomplishments can be mundane but essential such as getting the team e-mail access.  Issues are potential obstacles to the project; this is where you warn users that something bad might happen.  The metrics section is perhaps the most crucial section of the report.  It is important to have objective measures for evaluating the progress of the project. (Gainer)  Making goals objectively measurable goes along with the idea of documenting to manage expectations.  If users know what concrete outcomes to expect, their expectations will be more realistic.  When they see concrete results, they will be more satisfied.  Measurements should address business issues, not merely technical ones. (Everest)

            Like educating users, communicating with users should be done whenever possible.  The only caution is again not to take up excessive amounts of users’ time.  Reports should generally be written or electronic documents that are brief and may simply feature bullet-point lists. (Gainer)  Such a document is take-it-or-leave-it for the user; that is, they can decide how much time to devote to reading the documents.  Meeting weekly for an hour to tell users how things are going might be excessive.  Likewise, when gathering information, use the most efficient means possible.

            Like the education strategy, communication is almost always a good idea.

Prototyping

            We have looked at various strategies for managing user expectations:  Clarify user requirements through detailed documentation.  Have users sign off on the requirements definition as well as any changes.  Educate users on the way systems development works.  Communicate with users and involve them in the process throughout the project life cycle.  Report to users on how the project is coming along.  All these strategies may prepare users to expect what is realistic and be more satisfied with it.  If we take these ideas a step further, wouldn’t it be nice if users could have a preview of what the system will be like and have the opportunity to comment on it?  That is precisely the idea behind prototyping.

            Prototyping means building a working model of the system.  A prototype doesn’t do everything the final system will do.  Rather, it simulates some of the essential features.  For example, the user might be able to see how the interface will look with regards to screen layout, menus, buttons, etc.  Maybe all of the buttons don’t work.  Probably, the system is not connected to the production database, so maybe only some phony data can be retrieved.  But the essence of the system is represented.

            The prototype can be a great tool for zeroing in on users’ needs.  Prototyping has many benefits.  It accommodates the communication style of the user instead of the developer. (Boar, 38)  The prototype gives the user and the developer something concrete to talk about, greatly alleviating communication problems and misunderstanding. (Boar, 40)  A prototype is much easier for a user to evaluate than a requirements definition because it is closer to their everyday experience:  “It is atypical to ask a user to approve a 6 level decomposition of a process.” (Boar, 39)  Instead of users being disappointed at the end of a project when the system doesn’t do what it should, they are excited at being involved with developing something new.  “Users can’t wait to see a prototype.”  (Boar, 39)   With regard to cost, “[o]n the face of it this sounds…inefficient and expensive…but there are few things more expensive than…a system which the users will not use.” (Kenny, 43)  Research has shown that prototyping leads to better designs, better matches with user needs, and improved maintainability. (McConnell, 562)

            Interestingly, literature on more traditional methods sometimes alludes to the benefits of prototyping even though the term is not mentioned.  “The user should receive something tangible….  He can then review it….  [U]sers should see a model of their eventual system.  This may be in the guise of detailed mock-ups of inputs, screen layouts, and output reports.” (Keen, 291)  “One reason for doing this is to produce a demonstration for the user at the earliest possible time – a primitive version of the system that he may be able to use in an experimental fashion.” (Yourdon, 128)

            The benefits of prototyping are clear, and we may be tempted to think of the prototype as a silver bullet.  Although Bernard Boar is a strong proponent of prototyping, he offers guidelines for when to use the technique and when not to use it.  A good candidate system for prototyping is not batch processing in nature but rather full-screen periodic database reporting and interfacing; prototyping helps most with developing a good user/machine interface.  Operational support and record management systems are good candidates while heavily algorithmic systems and those for decision support and ad-hoc retrieval and analysis are not; in other words, good candidates “are the business” not “about the business.”  Because of the time and resources necessary, prototyping is not recommended for “crash” projects.  (Boar, 63)

The characteristics of the users are important when deciding whether to use prototyping.  Although satisfying, prototyping requires users to devote substantial resources to refining the model.  Users should be sold on the prototyping concept, having been dissatisfied with the prespecification experience.  The users must be willing and able to make decisions.  “When a model is ready to be reviewed, the process comes to a loud and visible halt if nobody will review it.” (Boar, 65)

“The candidacy question can often be phrased as follows: ‘Why shouldn’t we use prototyping in this situation?’” (Boar, 66)

Conclusion

            Are there any “right” or “better” strategies for managing user expectations?  By now, it should be clear that some strategies are more appropriate for certain situations, although most projects will call for some of each of these strategies.  Documenting requirements is always a part of the system development process but use the documents as contracts only when there is a genuine contractual relationship between parties; even then, the contract should not be the only method for managing expectations.  Educate users on the systems development process, the constraints under which the IT department operates, and especially on the impact of changes on the budget and schedule.  Strive to communicate well with users continually throughout the development process, but do not let the process of education or communication take up too much of the users’ time (or your own).  Utilize prototyping for user/machine interface, operational support, record management systems.  A careful mix of these strategies will ensure users know exactly what to expect from their information systems.

References

Note:  All web pages last accessed as of November 26, 1999.  Last modified date noted for web page entry only if no release date indicated on face of page.

Boar, Bernard H.  1984.  Application Prototyping:  A Requirements Definition for the 80s.  New York:  John Wiley & Sons.

Bradbury, Danny.  1996.  “What do users want?:  Meeting user requirements can be a tricky business when users want more than is actually needed, which calls for skillful IT management.”  Information Week,  May.  http://www2.vnu.co.uk/vnu/nc/nn/features/15_5p27.htm

Buckle, J.K.  1977.  Managing Software Projects.  New York: American Elsevier.

Computer World.  1998.  “Nailing Down User Requirements.”  CHIME Healthcare IT Warehouse.  Computer World,  June, p. 51.  http://warehouse.chime-net.org/news/jun98/article2.htm

Customer Relationship Management Community.  1998.  “Defining Expectations Before Automation.”  Digital Consulting, Inc.  May.  http://www.dci.com/news/sfaplus/articles/1998/05/19plan.htm

Decisys, Inc.  “Service Level Agreements: Demonstrating how your network meets business objectives and user expectations.”  Summit Online.  http://www.summitonline.com/service/papers/netgen6.html  Last modified September 11, 1999.

Everest.  1998.  “Outsourcer Accountability: Fact or Fiction?”  http://www.measurement.net/html/accountability_page_2.html

Feibus, Andy.  1998.  “Manage Your Project's Requirements:  Tools let users keep track of what's needed most from a software project.”  Information Week, October.  http://www.informationweek.com/705/05olpro.htm

Hartzel, Kathleen S. & Paulo R. Flor.  1997.  “Expectation Formation in the Information System Development Process.”   Baylor Business Review.  http://hsb.baylor.edu/ramsower/acis/papers/hartzel.htm  Last modified September 24, 1997.

Gainer, Jeff.  1999.  “Manage Your Users by Managing Expectations: You thought you only had to handle your developers? Think again.”  Enterprise Development,  September. http://www.enterprisedev.com/upload/free/features/entdev/1999/09sep99/hc0999/hc0999.asp

Ginzberg, Michael J. 1981.  Early diagnosis of MIS implementation failure: Promising results and unanswered questions. Management Science, 27(4), 459-478.

Ives & Company.  1998.  “The 10 Commandments of Successful SFA.”  Chip Systems, Inc.  http://www.chipsys.com/sb10sfa.htm  Last modified: January 23, 1998.

Keen, Jeffrey S.  1981.  Managing Systems Development.  New York: John Wiley & Sons.

Kenny, Anthony.  1989.  Managing Software:  The Businessman’s Guide to Software Development.  Boston: Blackwell Scientific Publications.

Lawrence, Michael & Graham Low. (1993). Exploring individual user satisfaction within user-led development. MIS Quarterly, 17(2), 195-208. 

Levine, Stanley H.  1999.  “Army Modernization: Digitization Overview.”  The Army Digitization Office.  June.  http://www.ado.army.mil/br&doc/acqreform/Acquisition%20Briefing/sld035.htm

McConnell, Steve.  1993.  Code Complete: A Practical Handbook of Software Construction.  Redmond, WA: Microsoft Press.

Metzger, Philip W.  1981.  Managing a Programming Project, 2^nd Ed.  Englewood Cliffs, NJ: Prentice-Hall.

Orenstein, Earl.  1996.  “Help Desk Procedures Week 2.”  Swinburne University of Technology.  February.  http://opax.swin.edu.au/303847/itd501/week2/sld007.htm

Resource Management Systems.  1999.  “Frequently Asked Questions.”  http://www.rms.net/lc_faq_enduser_sys_req.htm  Last modified: March 9, 1999.

Wolverhampton, University of.  1998.  “CP3397 Week 11 Systems Management & Systems Security.”  http://scitsc.wlv.ac.uk/~cm1906/din.smandss/tsld024.htm  Last modified: January 7, 1998.

Yourdon, Edward.  1982.  Managing the System Life Cycle: A Software Development Methodology Overview.  New York: Yourdon Press.