By Rizwan Ebrahim

In any service encounter—from having dinner at a restaurant to a complex, long-term technology project—perception is reality. In the end, what matters is customers’ perception of what occurred and how they felt during the process. There are several critical “touchpoints” that can make or break a customer’s perception. If companies adopt certain principles of relationship management and delivery management during both short- and long-term technology projects, they are likely to enrich the experience of business users and achieve a greater level of success.

In the last three decades, IT organizations have matured in their delivery capabilities by adopting standard processes such as Capability Maturity Model (CMM) and IT Infrastructure Library (ITIL). However, many technology projects are still executed with sole focus on process and technology while ignoring an important aspect of being a service provider—managing the experience and perception of the end business users. The results are often mixed, creating a situation in which most business needs are met, but the overall experience is not necessarily positive.

Successful technology projects require close collaboration between the business (“customer”) and technology (“service provider”) and can be considered as short- or long-term service encounters. It is usually within these encounters that business users’ perception of their interaction with technologists causes them to walk away with a positive or negative experience. For technology managers striving to become strategic partners of business, it is important to understand what shapes the experiences and perceptions of their business counterparts.

Relationship Management
Engage your customer and get them emotionally invested in the project’s success.

To make a technology initiative successful, there must be active participation from the business. In this situation, the business doesn’t want the project to be run like a black box; they want to be involved and to take an active role in shaping the final product. Active participation enables the customer to make satisfactory decisions about the project. For example, when the project runs into difficult scope decisions, the customer can sort out the scope items that are truly important from those that are less important. This seemingly simple concept of active participation is where many companies fail. Usually, internal politics or past relationship issues cause strain from the outset. Past failed projects destroy the trust between departments and groups. Many feel it is good enough to communicate through project status, but in reality, that approach is not sufficient.

Active participation takes effort on the part of the project manager, who depends on customer input when there is a need to effectively respond in a way that will satisfy all parties. Many projects get enthusiastic involvement from business early on, only to experience waning participation during later stages. It is common for the technology team to involve the customer up front, but then allow momentum to die during construction and implementation. This is a mistake. The customer should be engaged throughout the project.

Critical decisions about scope and requirements often come up after the requirements have been collected, and project plans often deviate from the baseline. The customer should have a say in what direction to take when these events occur. To truly succeed in getting the customer actively involved, you need to spend time and effort getting to know the customer. Dumping a status report off once a week doesn’t get it done. You should spend enough time and have deep conversations so you can anticipate how the customer might react to a situation.

Give Choices and Build Commitment

Business users are happier and more comfortable when they believe they have some control over the process. Unfortunately, fear of scope change or scope creep often prevents technologists from engaging with users on a frequent basis to review their needs and explain trade-offs. It can also leave the user less than satisfied because the end solution may not meet current needs.

To avoid this situation, have frequent checkpoints with business users to review priorities. If users understand their options and trade-offs, they will feel committed to the solution being delivered. This also ensures that a solution will adapt to any changes in business needs from inception of the project.

Give Bad News Early and Build Trust

Most people want bad news brought to their attention right away. However, technologists dread giving bad news until the last possible moment. It’s not easy, but taking care of bad news earlier will ensure that it won’t dominate the customer’s recollection of the experience and will build trust between business and technology stakeholders. One way to address the issue of delivering bad news is to have frequent checkpoint or status updates with customers. These meetings allow you to get the bad news out of the way as soon as possible, offer contingency plans or alternative solutions and give users the good news of progress made since the last update.

Delivery Management
Deal with changing business needs.

Requirements are often a source of friction between technology and business. From the technology point of view, the business cannot fully communicate what it wants. From the business perspective, technology just doesn’t completely understand the business. In truth, both groups are correct. At times, business analysts who are not the primary user of the system complete requirements. The business analyst likely makes assumptions about the requirements instead of getting information from the source. It is always optimal to get the requirements from the end user and find a way for them to deliver the requirements to the technology team developing a solution. This ensures nothing is lost in translation, and having users draw out the specs gets them engaged and invested in the success of the project.

Both business and technology have to find a common ground to communicate requirements. Business users might have a difficult time writing use cases, but they can always communicate via prototypes or visual layouts of the target applications. Walking users through the flow of events and showing them prototype screens and application flow is an excellent way to draw the design out of the business.

You’re probably thinking you would never have time to build a full prototype of the system, and you’re right—that’s not likely or necessary. All you have to do is create a “storyboard” of the application that includes screen shots and flow design. Then, walk the business through those storyboards. Pay specific attention to their reactions during this time. What they say is important, and so is what they are not saying. Make sure they are engaged during this process. This is the one chance you get to learn their impressions before misunderstandings become very costly. If the first round of screen shots doesn’t go smoothly, don’t worry—try again. Take in feedback and make the screens and flow meet expectations. Tread cautiously around the requirements of a project. Put in effort and focus to get them as thorough as possible up front, but also allow for flexibility during the construction and implementation phases.

Obviously, too much flexibility allows for scope creep, but that’s part of a project manager’s job. Deliver iterations with an upward swing in results and finish strong. End users walk away with a positive overall assessment if they notice a sequence of positive and improving results. Also, users are more impressed with complicated features delivered near the end of the project. However, most solutions are delivered in a big-bang method, which decreases the likelihood of showing real success and building trust along the way.

When people recall an experience, they probably won’t remember every single moment. Their recollection of an experience is strongly biased toward how it ended. Technologists often do a great job of gathering requirements, designing and building a solution, but it’s not uncommon for them to lose steam toward the end of the project. As a result, they might not handle end-stage problems in a proactive manner. To avoid this problem, design iterations so there is a visible upswing in the results delivered. Secure the low-hanging fruits first and schedule better-than-anticipated results toward the end of the project. When the complicated “wow factor” features come later, you will most likely find the initiative ends on a strong, positive note.

Plan for Recovery

Despite best intentions, certain aspects of a project will probably go wrong. Having a recovery plan in place ensures business communicates their dissatisfaction to technology, provides an efficient process for handling issues and captures the knowledge needed for future improvement. This type of plan plays a key role in developing long-term relationships. However, there is lack of risk management or recovery procedures in place. When things go wrong, technology organizations often scramble to recover, leaving the users ultimately dissatisfied with the experience.

Don’t get caught in this scenario. Instead, proactively manage risk, outline recovery procedures and have a strong communication plan in place. In the end, one thing matters in a service encounter—customers’ perception of the service they received. These perceptions can be managed by focusing on the underlying factors that shape these perceptions.

Technology organizations that are service oriented and disciplined in their execution will be perceived as reliable, trustworthy and strategic partners in the success of an enterprise.

Rizwan Ebrahim is a manager at Acquity Group. E-mail Rizwan Ebrahim at rizwan.ebrahim@acquitygroup.com.