A Credibility Equation for IT Specialists

A few years ago, we were discussing the role of information technology (IT) specialists in business process reengineering projects with a group of chief information officers. One bitterly exclaimed, “What role? I found out that my company was starting a major reengineering project when I read about it in the Wall Street Journal.” That surprised us. But what surprised us even more was that we heard similar stories as we continued our research.

For instance, in a reengineering effort at California State Automobile Association, top managers engaged outside consultants to plan a vision for the future.1 The internal IT organization was not invited to participate in redesigning key business processes such as customer service. When IT specialists visited project team rooms after hours, they were shocked to discover that the plans for the reengineered processes would involve major changes in the IT infrastructure. Unless they began immediately to make the needed changes, IT would hamper the implementation of corporate strategy. In this case, IT was critical to the organization’s strategic initiatives, yet its own internal IT group was left out of the planning.

Reengineering is not the only situation in which IT groups are left out of decision making that clearly involves IT. We have heard CIOs talk about not being consulted when their chief executives decided to outsource their IT functions. Why does this occur? We can think of many reasons, including genuine oversight of the IT implications for some strategic initiatives. However, we believe that a major contributing factor is the IT specialists’ low credibility. In this article, we examine the issue of IT credibility and what IT groups can and should do about it.

IT Units Are from Mars

The IT specialists we talk to are usually well aware of their low credibility with businesspeople. Yet they often unconsciously hold theories about credibility that prevent them from doing what they can to improve the situation. IT specialists think businesspeople just don’t understand what the specialists do to help the business. If businesspeople did understand, they would value their IT colleagues. In other words, many IT specialists believe that other people’s ignorance leads to negative stereotypes of IT people. The obvious solution is for other people to change their negative views.

We don’t deny there may be some truth to this theory. After all, businesspeople sometimes do have incorrect or incomplete beliefs about IT.2 But if IT specialists want to improve their credibility, they must acknowledge that it is their problem, and, therefore, it is up to them to take the first steps toward change. Businesspeople don’t lose sleep over the low credibility of their IT specialists, so it is clearly unrealistic to expect them to push for a solution. On the other hand, they may well respond favorably to IT specialists’ initiatives.

Put differently, IT specialists should ask themselves what they do that might contribute to their low credibility in the eyes of their business counterparts and what they can do differently to change negative perceptions. Here, the trick is to recognize that IT specialists and businesspeople view credibility very differently.

We like to explain this by using an analogy to male-female relationships. You may have read (or had read to you) excerpts from a popular self-help book that claims men and women come from different planets. Men and women are said to differ in how they “keep score” of the others’ contributions and failings:

“A man thinks he scores high with a woman when he does something very big for her, like buying her a new car. . . . He assumes he scores less when he does something small, like giving her a hug. Based on this kind of score keeping, he believes he will fulfill her best by . . . doing something large for her. This formula, however, doesn’t work because women keep score differently. When a woman keeps score, no matter how big or small a gift of love is, it scores one point; each gift has equal value. Its size doesn’t matter.”3

When two parties unknowingly use very different scoring schemes, they can arrive at very different totals for each party’s outstanding “credit balance.” This, in turn, can generate both nasty disagreements and great confusion about how the disagreements arose. We think that a similar process may occur in situations of low IT credibility. A large part of the problem may boil down to differences in how IT and businesspeople keep “credit balance” scores.

For the sake of illustration, assume an IT unit from Mars. The IT group has just completed an extensive renovation of the organization’s IT infrastructure —on time and within budget. But last month, in the heat of project cutover, the unit ignored thirty small ad hoc data requests from clients. The IT unit doesn’t think this is a problem, since the one big win far outweighs any small defaults. But if their customers keep score like Venusians, the IT unit is seriously in the hole (see Table 1).

This example shows that credibility is the result of the credit others give us, regardless of the credit we take. Therefore, if IT specialists are to change their credibility, they must understand how businesspeople score them and play to win in the businesspeople’s game.

The Credibility Equation

The body of academic literature on professional credibility in organizational settings is lean but consistent.4 The two major elements of credibility are perceived expertise and perceived trustworthiness, which are both necessary. But establishing trustworthiness is often neglected. To the surprise of many experts, expertise alone does not inspire trust and generate credibility. In many cases, technical experts brought in to cope with difficult situations face great hostility and resentment. Successful technical experts do not rely on their expertise alone but work hard to establish their trustworthiness with clients (see the sidebar). In fact, we believe that many people do not “credit” another’s expertise until the latter has established trustworthiness. Conversely, trust alone does not convey credibility. We can think of many trusted advisers who lacked genuine expertise. (Rasputin comes to mind.)

So, what leads people to trust others? Research has identified four important dimensions of perceived trustworthiness: similarity and likability, prolonged interaction, appropriate behavior, and consistent behavior.

· Similarity and Likability.

Not surprisingly, people tend to trust people who are similar to them and distrust those who are dissimilar. Similarities that promote likability include common interests and language. Immediately, we can see some cause for concern about businesspeople’s perceptions of IT specialists’ trustworthiness. Think about all that acronym-laden jargon that only techno-geeks can understand. And, as for common interests, how many IT specialists can answer correctly the following questions about their companies?

• What must your firm accomplish this year to be considered successful?
• What competitive factors have affected it most strongly in the past two years?
• What are its three most important product lines?
• What are the annual sales of the three product lines, in dollars (within 20 percent)? In general terms, how is this expected to change in two years?5

· Prolonged Interaction.

Generally, trustworthiness takes time to develop and is cumulative (which makes the example in the sidebar all the more impressive). Frequent one-on-one meetings characterize trustworthy relationships. But these interactions must be positive — or at least neutral. How many articles have we read showing that CIOs do not communicate often enough with their internal business customers? And when they communicate, are they listening or just talking? Peter Keen reported:

“The chairman of a Fortune 20 company told me he refuses to hear presentations from his own IS managers because they try to ‘sufflectate’ him, meaning they try to suffocate him with words. They can’t listen — only lecture.”6

• Appropriate Behavior. Behaving appropriately (in light of others’ expectations) builds trust. Behavior that violates norms of acceptability, for instance, in dress, presentation style, language, and so on, results in negative impressions.
• Consistent Behavior. Behaving consistently makes people appear predictable, which can promote trust. Consistency includes a reputation for fulfilling past commitments and for matching deliveries with promises. Trust can be enhanced by announcing a timetable of verifiable actions, performing them as promised, and labeling them as part of the announced schedule. In short, consistent performance in the technical aspects of a job is a factor in building and maintaining trust.

Recent research introduces an additional wrinkle into the credibility equation. If people are trusted to begin with, poor technical performance will not necessarily destroy trust. Trust will survive when a breach of promise or a technical failure is viewed as an isolated incident.

On the other hand, people can be distrusted despite good technical performance. Distrust, it seems, is more than the mere absence or loss of trust. Distrust occurs when people are perceived as having beliefs and values that are incompatible with the organization’s.7 And what factors might signal that IT specialists have incompatible — even incomprehensible — values? Physical distance, differences in dress and language, different beliefs and attitudes about technology, a history of bad experiences with technology and technologists in the past, technologists’ aloofness or disdain for clients, their lack of concern about the business —the list could go on and on.

If IT specialists are distrusted, they will not be credible, no matter how good their expertise and their technical performance. They will not be called on to participate in key business projects. They will learn about their company’s strategic initiatives from the Wall Street Journal. No technical successes can turn this situation around. The only thing that can help is to attack distrust at its roots in perceived incompatibility of values. And that requires IT specialists to build a good relationship with their clients.

A View from the Trenches

Is this view of IT credibility correct? Can IT specialists improve their credibility when it is low? How? Do IT specialists and businesspeople have different views of the IT specialists’ credibility? To answer these questions, we paid close attention to the role of IT specialists in major business process change projects. We found much evidence to support our belief that IT specialists can significantly improve their credibility in business by focusing on the quality of their relationships with managers and users. Here we report some of our data involving two different projects in each of two organizations.

AHS Reengineering Projects

Pressure to control costs has motivated health-care organizations to seek acquisitions and strategic alliances and to reengineer operations. Advanced Healthcare Systems (AHS), a member of several large health maintenance organizations, is a general, acute-care hospital with satellite locations. Like others in the industry, AHS faced these cost-control challenges. In response, to reduce costs and improve patient care, AHS embarked on a program to reengineer the entire hospital around the concept of patient-focused care.

In essence, the idea was to redesign the organization, operations, and physical facilities of the hospital around the patient — forming mini-hospitals or patient centers to serve discrete patient populations. AHS would decentralize many services to bring them closer to the patient’s bedside. Common services (such as admitting, routine chemistry, EKG, and housekeeping) would be duplicated in multiple patient centers; unique services would reside in one patient center. One AHS executive described the patient center concept as “cell manufacturing brought to the hospital.”

The board of directors approved a portfolio of projects to redesign the entire hospital and form multiple patient centers (e.g., cardiopulmonary, critical care, emergency, maternity, oncology, and orthopedics). Each project encompassed the formation of a patient center, including redesigned processes, cross-functional jobs, and new information technologies (e.g., client/server systems, clinical and financial applications, gateways to external mainframes, a bedside computer system, cellular phones, infrared technology for tracking equipment, and “electronic bedboards” for tracking patients.

We studied the projects over several months during an important period. One project (the orthopedic center) had been finished, and other projects (including the emergency room and critical care) were underway. This vantage point gave us a retrospective look at the first project and prospective looks at subsequent projects.

IT Credibility

On our first visit to AHS, we were surprised to learn that the IT organization had not participated in the initial phase of the overall reengineering program —the phase that included planning and conceptual design. The IT director told us:

“We weren’t invited. We actually had to knock on the door, push the door open, and then push our way in. But this time [on the second project], we knocked, and they let us in. Maybe next time we won’t have to knock.”

We asked what they had done wrong before. The director commented:

“A mistake we make is that we don’t listen; we try to drive the process. We need to listen first. If IT is invited to a group discussing new ideas, we’re too strong too early. And we pay for it. We were pulled in three-quarters of the way through the design, so now we’re fixing old systems.”

We asked the executive director, who was responsible for the entire reengineering program, why the IT organization had not been invited to participate. The executive director said the changes were massive — like “riding the tiger.” They had miscalculated the need for IT input. He remarked:

“There was lots of expertise to take care of this [reengineering program]. We wanted to let IT do their thing [maintain the legacy systems] until later. We thought patient-focused care was a process program. It didn’t appear to be related to information flow. Reengineering is promoted as a process change, not a support systems change. This is a big mistake. We didn’t know what we didn’t know, and we were looking to the consultants to tell us. But they only created a conceptual model — a high-level design.”

He gave an example of a patient center that needed x-ray or lab services, but the conceptual model didn’t identify what kind of x-ray or lab services. That’s when managers realized they needed input from different organizations — including IT. The director commented:

“When we assembled a team to make the conceptual design operational, we brought IT in because it turned out that we needed information from multiple systems. And the IT members of the team came up with elegant, workable solutions to the business problems — especially considering how late they started. This process heightened our awareness of the role IT needed to play. Everything IT did, they did well.”

As we talked to managers in different departments, we learned that the perception of the IT organization and the credibility of the IT specialists had improved significantly since the beginning of the reengineering program. One patient center leader, who moved into his new job during the implementation phase, hadn’t worked with IT specialists before. He summed up what we heard from others:

“My perception of the IT organization improved overall. I didn’t deal with them before. The departments I managed had little contact with IT. Now I’m in contact with them every day, and I have a very positive view. I know I can count on them. They do what they say they will do.”

Why Did IT Credibility Change?

The organization was beginning to see IT in a better light, and we wanted to find out why. When we asked supervisors from the IT organization why the credibility had changed, they identified two reasons:

Dazzling new technologies.

According to one supervisor, “The managers in different departments had been exposed to new technologies. Before, all that some of them had ever done was word processing on a dumb terminal. They couldn’t conceptualize the new technologies. We put together an ‘electronic bedboard.’ We put in gateways and remote dial-in for transcriptions. We put in a CD-ROM server-based pharmacy publication. They had access to those systems at their workstations. We gave them a good product and let it sell itself. Now they’re going crazy with this stuff. It’s snowballed. They want more.”

Behind-the-scenes solutions.

Another supervisor remarked, “We have perspectives that others who work in one functional area can’t have. IT can see the business better. We can identify implementation problems before they happen and fix them. For example, in ortho, we anticipated they wouldn’t want to call sterility every time they needed traction equipment. So we set up a system to order traction equipment on-line before it became a problem.”

But when we asked other executives and managers about IT credibility, we didn’t hear any comments about dazzling technologies. We heard about “soft skills.”

Team players.

When IT specialists were brought onto the operational design teams, the managers noted their team participation skills. One vice president observed:

“The IT people worked well on the design teams. They produced lots of information for the designers. That helped us immensely, and it really enhanced their credibility. IT is a lot more than people’s picture of IT.”

Common language.

The transition coordinators were surprised and impressed that IT specialists understood their business and could speak their language. One coordinator explained that IT specialists conducted cross-functional training on a legacy clinical system that was not being replaced immediately:

“The IT people were patient in teaching us the limitations of the clinical system. They explained things in terms we understood. Their credibility really improved. They educated us on the shortcomings of the system and then identified ways for us to work around the shortcomings.”

Another coordinator described how she became comfortable counting on IT specialists:

“During the transition, they were great. The IT people took layman’s words and figured out how to make the system work. The design team had overlooked an important manual system. The IT staff helped us out and came up with an idea that worked. I stopped worrying about oversights — as long as the IT staff was here. Putting in these systems really improved their credibility in my eyes. Just yesterday, we had a big spreadsheet that we were working on, and we lost it somehow. We called IT. They came over right away and got it back for us from the network.”

Gradual acceptance.

The new jobs required cross-trained blue- and white-collar workers. Multiskilled care teams (able to do tasks such as EKGs, IVs, and order entry) within the patient centers were responsible for patients from preadmission to discharge. The transition coaches said the computer was the most difficult part of the training. People felt overwhelmed by the technology, and relationships with IT specialists grew over time. One transition coach explained:

“It took us a while to gain trust. We had to build rapport. The workers were shown how to work everything at once — phones, computers, beepers, new beds. They were asking, ‘Is the button on the bed or the pager?’ And the next day, they got patients! They didn’t know how to clear their pagers. They needed two weeks just to play with the new equipment. But within a month, they were snooping around their computers themselves, looking for new ways to use them.”

One clerk who had never used a multifunction workstation confirmed that she was overwhelmed at first. Four months later, however, she reported that she was comfortable with “her” computer and was eager to learn new applications.

Hand-holding.

Getting comfortable with the technology required some hand-holding. And the transition coaches gave the IT specialists high marks:

“People felt overwhelmed by technology. Fortunately, IT recognized that the transition wouldn’t be smooth; they literally lived — day and night — at the patient center to make sure the staff knew how to work the systems. They sat with the first group after cutover. They stayed with them twenty-four hours a day at conversion to see all shifts.”

The nurses were particularly frustrated with the computers — especially with order entry. Another transition coach praised some clandestine hand-holding:

“Entering orders into the computers was a big challenge. Nurses knew they had backups for IVs, etc., but they were on their own with the computer. The problem was, who do you call? You don’t call IT for on-the-job training. IS training needs to include the equipment. A CRT — what’s that? Does this machine plug into the wall, or does it plug into this other one? IT assumes that people know this stuff, and they don’t. If the toner is low on the printer or the lab printer is out of labels, how do you refill it? But the IT people came through. The night IT staff would change toner, put labels in the lab printer, and say, ‘Don’t tell anyone I helped.’”

Comfort level.

During transition and implementation, managers talked about working with IT specialists every day and becoming increasingly comfortable with them. Two patient-center leaders explained how, over time, they appreciated preemptive problem solving:

“Our view of IT changed greatly — positively. We didn’t have a lot of interaction with them previously. Now we have a very positive view. Support is excellent. They’re so proactive. They help us anticipate problems.”

One IT specialist also commented on prolonged contact, noting that careful error reporting and follow-up over time increased her credibility:

“System printouts showed errors in entering orders. Some errors made it look like patient center workers weren’t doing as much as they actually were. The leaders needed to take entry errors more seriously. They focused on patient care, not data entry. I showed them statistics from other centers. It took a while for them to pay attention, but credibility builds slowly. Now if I say something, they believe me.”

The leader of the emergency patient center even talked positively about ongoing relationships with the IT organization:

“Computerization [specific emergency room software] wasn’t planned initially. We’re looking at packages now. We’re interested in a triage system, patient tracking, and assessments — even though some nurses say, ‘Get me away from the computer!’ I have a lot of trust in IT now. When we went out to look at ER software, we asked them to go with us. I wouldn’t dream of doing this without them now.”

At AHS, we saw that the credibility of IT specialists was low at the beginning. However, the IT people were able to improve their credibility by what they did. But how they scored themselves was not how others scored them. IT supervisors attributed the improvement to impressing managers with dazzling technologies or with behind-the-scenes preemptive solutions. The managers, however, attributed the improvement to some of the “soft skills” like being good team players, using common language, demonstrating patience, and being willing to hold hands.

AEC Projects

American Electronics Corporation (AEC) is a worldwide leader in designing, manufacturing, and marketing advanced electronic systems to industries including automotive, commercial, and telecommunications. To reduce costs and improve profitability, AEC undertook numerous enhancement projects. We studied two projects that involved the IT organization and a downsizing of the human resources (HR) function: an out-sourcing project and a data warehouse project.

The outsourcing project established a new, cafeteria-style benefits program to be headed by a third-party administrator (TPA). The benefit offerings included flexible spending accounts, HMOs, and matching university donations. The technology changes involved implementing a new voice-response system and altering legacy systems to eliminate benefits from the personnel system, send demographic data to the TPA, receive payroll and insurance data from the TPA, process flex allowance and deductions in the payroll system, and modify insurance premium reporting.

The data warehouse project was accomplished along with the reengineering of the interface between corporate and division HR. Division managers could do their own ad hoc querying and reporting using the HR data warehouse. The project included three technical components: a local area network, a graphical user interface access tool, and the data warehouse.

Recurring Themes

The industry, the projects, and the people at AEC were different from those at AHS. We expected to hear very different stories. But the themes were surprisingly similar.

Left out again.

Once again, the IT organization had been left out of the planning and conceptualizing stages of the projects. When we asked the IT specialists why, they couldn’t provide any insights. It was just “par for the course,” implying that the business units always treated them that way. Managers, however, attributed it to IT’s inability to listen. One division manager said that IT specialists would prescribe a solution without first listening to the problem:

“The systems people didn’t listen very well. Everything we needed down in the trenches always ended up on the enhancement list. They loved the dependency relationship. They were free to do whatever they decided to do and charge what they wished. The tail was wagging the dog. But they’ve become better listeners. They realized they would survive only if they satisfied the customers. They have to listen to what the customers need rather than tell them what they want.” The managers also viewed the technical terminology used by IT specialists as “a lot of arrogance.” One division manager equated using technical terminology with hazing: “They put people through a hazing period with a lot of specialized vocabulary that’s just not needed.”

The technology myth.

Similar to the situation at AHS, the credibility of IT specialists improved during the course of the projects. When we asked the IT supervisors why, they ascribed it to their technical expertise — their approach to user acceptance testing was what impressed managers. One IT specialist explained that detailed problem logs demonstrated to managers how competent the IT organization was, especially compared to the TPA:

“User acceptance testing really showed the customer [HR] that we and the TPA have a major difference in philosophy on user acceptance testing. For us, user acceptance testing is there to show that the system is ready. For them, it’s there to find problems. The customer came to appreciate this difference. The problem logs were a visual record. Normally on our projects, we have about ten problems on the logs. On this project, we had over 200 — all related to the TPA!”

The managers, however, never mentioned the problem logs.

Team players.

What the managers did mention was “soft skills” like team participation. They were impressed when IT professionals stepped up to an extra challenge created by the TPA’s shortcomings. A manager commented:

“We took a joint team of IT, finance, and HR people. The IT people led the meetings. We gave the requirements to the TPA and walked through the documents. They missed the boat; they didn’t understand. They couldn’t anticipate how long it would take to do things. Our IT people jumped in and said, ‘Okay, we’ll help do it.’ They took on more and more of the TPA’s side and made it work. Otherwise, it wouldn’t have. It became more ‘we’ than just pointing fingers.”

The IT project manager acknowledged that “IT people grew in their abilities to deal with other people. Our relations with HR improved. They saw how well we do our job.” She went on to say that IT “hadn’t played this visible a role before. We needed face-to-face communications to build trust and establish rapport.”

One-on-one meetings.

Managers frequently cited meetings with IT specialists as enhancing credibility. These meetings established close working relationships. A senior executive described his weekly meeting with the IS project manager:

“Mike and I met every Tuesday morning. We talked in common language. He went over status issues and asked for help. This was my first opportunity to work with IT people. We had a close working relationship. Mike had no HR background and had to learn what we were talking about. He could listen and understand and report to the IT organization. He had a style that could carry it off. He was very effective.”

The IT project manager described the meeting too:

“We met every Tuesday at 7:00 a.m. First we had coffee. I got to know his family and vacation plans. This built up the level of trust. I always had an agenda for the meeting, and I identified the issues. He wanted someone assigned to the project from IT who wasn’t familiar with HR. My lack of HR experience was positive; I asked a lot of questions.”

Understanding the business.

As in the projects at AHS, IT specialists were brought onto the design teams to translate the vision into operational plans within a tight time frame. Managers were impressed with IT specialists’ abilities to “see the whole picture,” not just the IT piece:

“The IT people were outstanding. They got no instruction on how to get there, just the big picture. They didn’t just look at the IT piece; they transcended the boundaries and put it all together. They could see the whole picture at once, diagram the system, and troubleshoot it.”

Thus far, what we had observed at AEC was similar to what we had seen at AHS. The IT specialists were able to improve their credibility over the course of the projects. Again, how the IT specialists scored themselves was not how others scored them. IT supervisors attributed the improvement to impressing managers with their technical competence and performance, whereas the managers noted some “soft skills” like being good team players and using common language. We did, however, find something else.

An Initial Decline in Credibility

We were surprised to learn that IT specialists suffered an initial decline in credibility when they first joined projects. Managers described how IT credibility recovered from an initial decline and then improved over the course of the project. An executive sponsor of the outsourcing project noted that after IT specialists joined the team, the first several months were very difficult. He explained that the IT specialists exhibited animosity and resisted the whole project concept:

“IT people stayed their distance. Initially, there was friction, animosity, and noncooperation. We invited them to education meetings and briefings, which helped get them on board. After six months, their attitudes changed and they jumped on board. After they accepted the change, it became contagious.”

The IT project manager described this period differently. When they joined the project, the IT group reviewed the TPA’s capabilities and testing plans and, justifiably, raised a red flag. They believed the project was at high risk and repeatedly emphasized the risks to the project sponsor. However, they hadn’t established any trustworthiness with the project sponsor, so he interpreted their comments about risk as “not being on board.”

Lessons Learned

Our case studies suggest some tentative conclusions — or working hypotheses — about professional credibility for IT specialists.

IT specialists may have low credibility even when they don’t earn it through poor technical performance. IT specialists may be distrusted for reasons that have nothing to do with them, for example, managers’ past bad experiences with technologists. On the other hand, the cause of the distrust may come from things IT specialists routinely do to set themselves apart from — and above — their clients as experts and technology specialists.

If technical performance is good but credibility is poor, distrust is the real issue. In these situations, stressing one’s expertise and track record early in a new project will not improve credibility; it may even hurt. Instead, an IT specialist should focus first on creating a reputation for trustworthiness, before emphasizing expertise.

To create trustworthiness, IT people should:

• Establish regular, one-on-one meetings with line managers.
• Listen well. Ask questions. Learn the business.
• Use business jargon. Do not use technical jargon that customers do not already use correctly.
• Do not rush to suggest technical solutions. Help customers explore nontechnology options first.
• Be enthusiastic about the projects that clients have decided to pursue, even if the projects seem risky or misguided. Raise concerns about risks gradually and help to make the projects succeed.
• Spend plenty of time with customers when a new application or technology is installed.
• Review project plans thoroughly. Anticipate problems, especially those affecting operations, and help clients plan to deal with these problems effectively.
• Conduct customer satisfaction surveys and implement their suggestions.
• Don’t be defensive about customers’ reactions. Understand it as fear or frustration with technology and act accordingly.

To enhance credibility, once trustworthiness has been established, IT people should:

• Conduct education sessions; for example, explain how legacy systems work.
• Invite customers to go to demonstrations of new systems or technologies.
• Introduce new technical terminology gradually.
• Maintain detailed problem logs and publish summaries.
• Stay in touch with the managers of past projects, even when they move on to other jobs in the organization.

If technical performance is poor and distrust is an issue, IT specialists should not ignore the trust issue while they improve technical performance. If they do, they may not survive long enough to benefit from the improvement. They should immediately begin to work on trust and expertise simultaneously. When IT specialists are left out of important business projects, they should take a moment and think about the situation. If distrusted, they will not be credible, no matter how good their expertise and technical performance.

IT specialists face many technical challenges. But taking care of customers should be their top priority.