Skip to content

Methods and Approaches for managing expectations

May 4, 2008

IT Readiness

First — even before dealing with customer expectations — make sure the IT team is truly ready for the project:

  • Is there an IT and project governance process?

  • Are people available with the right skill sets and attitudes?

  • Are there established practices and policies for mature technologies and systems, and best practices for new ones?

  • Is there a control and risk management structure surrounding IT?

  • Are there performance measures to determine how IT is able to meet the organization’s objectives?

  • Are the right tools available?

  • Is IT part of the business and strategic plan?

Any negative answers to these questions represent important gaps that need to be addressed before attempting to manage expectations. Such gaps can impede the team’s ability to deliver and execute, which is the ultimate expectation of any customer.

There are many checklists available as part of frameworks like COSO and COBIT. Also, any of the established consultancies, including the “Big Four,” can perform an IT review and gap analysis to determine the overall health of the IT function.

Know the Customer

Next, know who the customer is. Who are you trying to please with the project? It may not always be obvious, and may not be the actual project sponsor. Talk to the sponsor and others involved with the project to uncover any “hidden” customers. Are sales people actually setting expectations directly with end customers? It is impossible to manage expectations without knowing who the customers are and how expectations are set.

Knowing the customer also means knowing what motivates them, both personally and professionally. Determining this takes skill and cunning, and involves spending time talking with them and mining the corporate grapevine. But knowing what makes the customer tick will help the IT team deliver on their expectations.

Finally, knowing the customer means knowing which customers “count” more than others (yes, not all expectations are created equal). Who really controls the project’s funding and sets management and board-level expectations? That individual’s expectations may be different than those of the actual end users of the system being planned, but are as important to understand and satisfy.

Make sure not to forget the type of information and delivery the customer wants. Simplistically, we might assume that all senior executives want the famous “executive summary” version delivered verbally, that middle and line managers want detailed narratives and spreadsheet formats, and that IT managers want techie-speak and diagrams delivered via e-mail or online collaborative methods. But reality is sometimes more complex than that, so beware assumptions. The best way to know how much information someone wants, what type of information is needed, and how it should be presented is to simply ask.

Take a History Lesson

Know the customer’s history with past projects. What were customer expectations in these projects? To what extent were they met? How were they not met and why? For this last question, ask both the customer as well as the other involved project team members individually. To get at the truth, avoid the “groupthink” and “political correctness” that can occur in a group setting.

Planning and Communication at the Outset

An initial communication session with key sponsors, customers, and leadership is necessary to:

  • Flesh out goals, objectives, and expectations at a high level.

  • Discuss funding, resourcing, and planning at a high level.

  • Determine any incorrect assumptions that may be held by leadership and the team leader concerning the project.

  • Establish the type and frequency of communication and support needed from the project team.

  • Clarify and gain agreement on project scope.

  • Agree on key success factors needed and how leadership can help or hurt the outcome of the initiative.

  • Give leadership confidence in the approach.

The general plan produced by the end of the project’s initial phase will help manage expectations within the project community and the company at large. It should describe the following typical aspects of the project: key deliverables, critical milestones, business requirements and scope, technology requirements, risks, change control process, resourcing, and estimated budget.

When it comes time to define requirements, realize that requirements cannot simply be based and prioritized according to customer need; end users may have no idea of the technical capabilities, costs, time needed, or other resources needed to make these requirements work. A key part of expectations management is reconciling the gaps in customer expectations, development capabilities, costs, time requirements, and quality requirements.

This overview session is just the beginning of communications, not the end. The goal of this session, and the general plan produced following it, is to get the IT team and its customers on the same page at the outset of the project.

Customer Orientation

Embrace the principle of customer orientation. Understand that seemingly “impossible” or unrealistic customer requirements may be a good thing — they drive the development of better software, systems, and business processes. But customers are usually realistic too — if something cannot be done, tell them and explain why. If something is expensive or time-consuming, tell them that too. In all cases, move away from a mindset of the customer as a “loose cannon” and think of them as a partner.

Stay close to the customer. That might mean placing key, high-value business analysts into the business unit (still reporting to IT) to stay close to changing requirements, and to better understand how the system will actually be used. Other business units have IT-skilled staff that will act as a liaison to the IT department — keep them close. Otherwise, frequent face-to-face meetings are a necessity.

The Business Analyst and Speaking the Customer’s Language

IT departments have long recognized the need to bridge the gap between themselves and the business, and have often done so by “translating” business requirements into IT speak so that systems can be built (with varying degrees of success). What they have been less adept at doing is the reverse – translating IT design back into business-speak. Thus, requirements get transformed into design, and after various levels of testing the customer gets to see a prototype or working system. This, however, comes late in the game, and accounts for many project delays as misunderstood requirements get hashed out and corrected.

Speak the customer’s language. Have people within IT — either business analysts or management — who speak the language of the customer. When the customer is located in another country, this may indeed mean having someone working with them who does speak their country’s language.

Listen

Listen to and understand what the customer is saying – and what they might not be saying up front. Listen to what is said and what it left unsaid, and always pay attention to context – statements that seem to come out of nowhere may have a very relevant context. Don’t ignore “buzz”, rumors, or other discussions that the customer might be having with their peers, competitors, and others. Sometimes, the way they describe their needs or the project to an outsider can tell a lot about their true expectations.

Take careful note of ambiguous or other unclear statements made by the customer — they are often the key to previously unexpressed, but crucial, expectations. If a customer is asking for the system to be “foolproof,” what are they really trying to say? Are they making comments about the end-users’ abilities? Are they saying that they only have limited time to attend training? Are they asking for a robust, online, context-sensitive help system coupled with online training tools? Or perhaps they are suggesting something about prior systems that were extremely buggy or had poor user interfaces?

Try to understand all expectations, and make sure that project requirements reflect these as much as possible. Do not ignore or disregard expectations just because they are difficult or political.

Be Approachable

Make sure that key project staff members get to know the customers and make time for them. If key project staff members are seen as too busy or enigmatic techies, the business will not open up about their expectations. Clearly communicate how the IT team plans to meet business needs, and exactly which deliverables will be produced to do so.

Communicate Clearly

Communicate constantly and in the manner that the customer requires and expects. Status meetings, memos, e-mails, instant messaging, newsletters, bulletins, intranet or Internet postings, message boards, blogs — there are so many high- and low-tech ways to communicate. Make sure to understand the best way to reach customers and get the message across. Be frank. Knowing how to communicate, negotiate, build relationships, persuade, and sell effectively in various business settings is an art unto itself and is beyond the scope of this report. If these skills are at all lacking in the project management team, it is time to develop and train staff in these skills. For certain high-value/high-risk projects, it may even be warranted to bring in outside expertise with the required soft skills to help manage the project.

Some communications are best done in private or in an “offline” setting, particularly those about expectations that are political or represent hidden agendas. People generally do not like to do things in a public context, such as change their minds, admit to their lack of knowledge, or discuss interpersonal or interdepartmental conflicts.

How to achieve clarity in communications is a topic outside the scope of this research report. However, some important pointers relevant for technologists (whether in verbal, formal written, or informal written communications) are:

  • Speak and write clearly and concisely.

  • Group and organize thoughts.

  • Be sensitive to customers and users who are non-technologists when explaining the impact of technology choice and design.

  • Remember basic paragraph structure as a guideline: use an introduction, followed by clarifying points, followed by a summary.

  • Avoid using technical or any other type of jargon.

  • Avoid using “buzzwords.”

  • Be able to summarize where necessary, and “drill down” as needed.

Also, whether writing high-level agreements or detailed requirements, avoid unclear terms like “fast” (how fast), “integrated” (how — via common components, middleware or file transfer, real-time, or batch?), and so on. Be as clear and quantitative as possible — doing so opens up some interesting discussions with the customer about what they actually expected versus what was assumed.

It is possible to over-communicate, but under-communicating is much worse. Communicate early and often.

Flexibility

Requirements do change, expectations evolve, and the business landscape is constantly shifting. Change cannot be eliminated — it can only be managed. Psychological research into so-called “cognitive bias” has shown that decision makers are often unduly influenced by their starting points i.e. how their thoughts about a topic are initially framed. These are the cognitive equivalent to the economic concept of “sunk costs” – costs that have already been expended on a project and should therefore not be considered in future project decisions. Do not be constrained by initial project decisions, or designs/processes that have resulted from these decisions. Instead, maintain focus on the future state, and what it will take to get there.

Dangerous Assumptions

Never make assumptions about what a user wants, what they mean, what they think is important, or what they think is not. When making an assumption, always explicitly confirm this with the users. As we will discuss, the traditional model of doing this via documentation of requirements, specifications, and service-level agreements may not be conducive to really understanding what the user wants. Nothing takes the place of discussion, walkthrough, and demonstration.

Some have argued that all customers will expect certain things, such as quality, security, and good system performance. And every project should define testing and quality management processes, security architecture, and so on. But what are quality requirements exactly? How long are customers prepared to wait for fully regression-tested software? And how much are customers willing to pay for hardware, network, and software upgrades to achieve sub-second response time, if that was even what they needed? Do not take anything for granted.

Exaggerate at Your Own Risk

Don’t exaggerate or underestimate resource needs, time requirements, technological capabilities, or any other key project factor. Salespeople and management may exaggerate to increase sales or please senior management, and “techies” may underestimate the complexity of meeting requirements and expectations by focusing narrowly on their own deliverables. Anyone responsible for solution delivery cannot afford to lose their customer’s trust by presenting them with inaccurate information, even innocently or with good intentions.

Educate and Negotiate

Explain how the team is approaching various aspects of project planning and various project deliverables. Let customers know why the approach the team is considering will work e.g. perhaps it has worked in the past, delivers the best value for money, or may represent industry best practice). Get their input where possible. Transparency in decision-making goes a long way toward building trust, gaining confidence, and getting even the less-obvious expectations out on the table.

The education process is sorely needed when customers approach with changes to the initial scope and requirements. Educate the customer about the inevitable tradeoffs between requirements, schedules, cost, and quality. Make sure that they will realize that their change requests will be evaluated and be presented with an impact analysis of each change. Impacts may include any or all of the following types of statements:

  • This change can be done with existing resources in 10 person-days at a cost of $8,000. It does not affect the critical path of the project, so it will not affect the overall due dates.

  • This change requires new people (contractors) and new technologies, which can only be acquired in a 6-month period at a total cost of $120,000.

  • This change can be absorbed in our existing budget with no impact on schedule.

  • This change will have an impact on system security, and requires a review by the auditors before we can determine if it is do-able.

  • This change requires a complete upgrade of our application software, which is not scheduled for another year. Changing that schedule cannot be done by our project team, but can be brought before the IT Steering Committee.

  • This change entails completely new and complex functionality. To completely test this, it should be subjected to unit, functional, regression, and user acceptance testing using our automated test tools and test beds. This will push the project delivery date out four months. Alternatively, we could “fast track” testing to lessen the impact on the delivery date to only six weeks, but we cannot guarantee quality. If the customer is willing to live with a period of time in production where there may be production issues (which the project team will help solve), then this might be an option.

  • Instead of this change, here are three alternatives that can be presented at minimal cost and at no impact on the project schedule.

Where many IT projects have gone wrong is not in failing to be receptive to the customer. In fact, most IT staff are eager to please and will try their best to work overtime to fulfill these requests, but of course it is usually impossible to avoid impacts on schedule, quality, or costs. Where they have failed is in communicating the impact of the customer’s change requests.

The process of communicating impact inevitably opens up discussion and negotiation about what can be achieved and when. Key project people should be skilled in the art of negotiation, and training courses are available to fill this gap as needed. Negotiating with the customer (and others on the project team) will usually mean seeking “win-win” situations. Often, it is necessary to soften the blow of not meeting certain requirements by meeting or exceeding others.

IT as Consultant

While IT ultimately is the “servant” of its customers, it must also act as consultant and advisor to them in order to deliver them what they want. This means not blindly following their instructions and meekly accepting every change request, but rather pointing out when they make unrealistic or inefficient choices or decisions, and showing them better ways to achieve their objectives. It also means helping to discover simpler solutions, which invariably reduce delivery time, development costs, and ultimately support costs. The customer may be king, but they are not always right and do not always know what happens in a development process. They need things to be explained to them and a partner to help them meet their goals. Do not be afraid about releasing “IT secrets” – a better understanding of IT’s processes, resources, and constraints will better help customers understand where the IT team is coming from and what constrains it, which will help to manage their expectations.

How Am I Doing?

Follow former New York City Mayor Ed Koch’s favorite maxim and keep asking, “How am I doing”? When discussing the project, get into the mode of asking, “Let me make sure I understood what you said; you mean “. Don’t just ask about requirements and expectations at the onset of the project — keep asking if expectations are being met. This process involves asking many other questions like:

  • What do you hope to get out of this project?

  • How will the project affect you? Your position in the organization?

  • What has changed since we first set requirements?

  • Why did it change? How did it change? Who or what changed it?

  • Is there anything we are not doing that you wish we would?

  • Is there anything we are doing that you wish we would not?

  • What can we do better?

  • Do you feel like we are listening?

  • If there is anything you could change about the project manager, the project team, or the project in general, what would it be?

  • Thinking out of the box, if you could change aspects of corporate structure, company policies and practices, corporate culture, or other facets of the company to make this project more successful, what would you change?

  • What do you see as the biggest risks to project success at this point?

  • Are there any new factors or criteria that are now of importance to you?

Many of these questions ask the same thing, in slightly different ways. It is important to listen closely to the replies to these questions and pick up on any inconsistencies. Some people are “people-oriented” while others are more “analytical.” The former may shrug off questions about making changes to the organization, key success factors, and the like, but may respond better to questions about people (e.g. the project team, the project sponsor, other customers and users). The latter may prefer not to address people questions, but may reply to areas near and dear to them (e.g. risk management, quality, commercial implications, market analysis, and so on).

Also remember that (with some exceptions) people don’t like to complain. Make sure that any neutral responses to questions aren’t masking deeper-seated dissatisfactions. Challenge each of these responses by asking how things can be improved. With many people, if you don’t ask, they won’t tell. There are many techniques for collecting this feedback, including interviews, surveys, questionnaires, suggestion boxes, and many online tools. In some cases, collecting this feedback anonymously will be helpful.

Some corporate cultures do not encourage this “questioning” sort of approach. Others will not facilitate access to key players like the project sponsor or key customers. In these cases, test expectations by dropping hints and clues about possible next steps and watching how key project people and users react. Also keep an “ear to the ground” and be particularly sensitive to news and rumors. Enlist well-connected staffers throughout the organization to cultivate a “grapevine.”

Document or Show?

As important as they are to the development lifecycle, never rely on written requirements and specifications as a tool to manage expectations. Understand that even with the best quality procedures, version-controlled requirements documents, traceable specifications and design documents, and a perfectly implemented development methodology, there may still be customers with unmet expectations. Remember that saying “it’s not in the requirements” will not win any points with these customers. As much as some in IT would like it to be so, the requirements document is not a contract (at least when IT is internal to the organization), but rather a point for discussion and agreement about the desired system or solution.

Requirements and specifications are a fundamental tool to assist developers in providing what is understood as the customer’s expectations. Their inherent weakness is that many end users and customers cannot or choose not to read them. Some view these documents as inaccessible technical tomes. Others view them as quasi-legalistic documents that are almost adversarial in nature in attempting to pin down business requirements that may naturally change as the business environment inevitably does. Furthermore, customers will invariably pay more attention to an actual prototype system, a “realistic” looking demonstration and walkthrough, or other means of demonstrating process and functionality than paper requirements documents — although visual tools like process maps, flow diagrams, and the like may be well-accepted in certain environments. Generally, it is better to listen, understand the truly critical success factors, and then deliver what the customer actually wants.

Documentation is still important. Critical high-level agreements regarding schedule, cost, scope, and quality between IT and the customer must be documented and kept up to date. More detailed documentation may also be necessary for audit and control purposes. However, the key point is that documentation rarely helps to manage user expectations.

Progress Reporting

Give regular and frequent progress reports. As with other communications, these reports should provide the type and level of detailed information required by the various members of the project team. Management may (or may not) want a dashboard-style presentation, and the project team itself may want more detailed descriptions of status, accomplishments, plans, issues, and risks.

Deliver Bad News Early

Rare is the project that does not have some unexpected problems — resignation of key staff, non-functional software or repeated test failures, or a disaster that wipes out key project information. One can plan ahead for these possibilities with a good project risk and mitigation analysis, but one cannot plan for everything. When bad news happens, do the following:

  • Stay calm.

  • Understand the impact on the project team, impending milestones and deliverables, and the project plan as a whole.

  • Determine one or more alternative solutions.

  • Attach timetables and costs to these solutions.

  • Quickly communicate the problems and proposed solutions to the project steering group and sponsor.

  • Be prepared for difficult reactions, but keep focused on finding a solution.

Trying to work through a bad situation quietly does not work; notice of delays, cost overruns, scope cuts, or quality problems will only be delivered late in the game. This will diminish the IT team’s reputation in the eyes of the customer. No project sponsor likes to hear of problems, but if these problems are presented with solutions, then at least it is clear the project is being well managed.

Going Above and Beyond

Try to give extra. Expectations management often means dampening certain expectations because of budget, schedule, or quality constraints. When the IT team goes the extra mile to meet some of these expectations, this pleasant surprise to customers will go a long way. Promise less, and deliver more.

The Comfort Zone

Taken together, these suggestions will help establish a level of comfort, then trust, with key customers. Only if a customer has some degree of trust in the IT team will they permit it to manage their expectations. It is important to maintain this trust in order to keep an eye on expectations as the project progresses. Always treat customers well, since now more than ever customers have many choices to meet their project needs. Although the IT team may have reached the comfort zone, it should not be complacent — there is always a competing IT provider ready to “eat your lunch.” Cultivate repeat customers.

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: