The traditional approach to ensuring the quality of software emphasizes the properties of software deliverables, including code, documentation, design documents, and use case, while using a standard paradigm of quality derived from the manufacturing process. This dimension of software quality is called the functional dimension. But viewing software quality from the perspective of software professional services involves a significant change in the standard paradigm, adding the relationship dimension. Key aspects of the software professional services perspective include:
- Client satisfaction. The ultimate reward—and measure of quality—is more contracted work with the current client and good references for use with potential future clients.
- Working relationships. The quality of the working relationship between client and service provider is as important as the quality of the deliverables in determining overall quality.
- Sales cycle. When the service provider secures the initial engagement with a client, the client has no “product” to examine; the sale depends largely on the relationship established during the sales cycle, along with the service provider’s qualifications. References from other clients are often critical to winning the business.
- Interaction. Each interaction between service provider and client updates relationship quality. Functional quality is updated as deliverables are delivered. Moreover, in response to declining quality, a client can terminate an engagement at any time.
- Multiple measures. Because each constituency on the client side has its own special needs, many different measures of quality must be achieved.
Firms in the software services industry develop custom software systems to solve business problems on behalf of their client organizations. Clients contract service providers to understand their business issues, define solutions, then implement them. Notable providers include Accenture, EDS, and IBM.
The basic approach to ensuring software quality, which can be traced back to [1, 3], has been applied to the software domain by a number of authors and was recently summarized in [2]. The paradigm was extended to apply to IS quality in [4]. Quality is determined by the customer through a high level of satisfaction with the product. This satisfaction is driven by the presence of features that fulfill customer needs and the absence of defects that interfere with the fulfillment of these needs. The features and defects are properties of the product itself and influence customer feelings of satisfaction with products and hence how customers judge their quality. This model, outlined in the figure here, applies to software directly and has been used to ensure software quality.
Measures of Satisfaction and Quality
Quality is a state of mind and cannot be measured directly. It can, however, be inferred by the service provider by either observing critical behaviors or asking pertinent questions about a client’s state of mind. Satisfaction is indicated by four operationally oriented measures: new engagements or follow-on engagements with the same client; unsolicited referrals to other potential clients; solicited references to prospective clients; and timely payment of bills. All bring positive financial benefits to the service provider, as would be expected from satisfied clients. Another way to measure satisfaction is to solicit new engagements and references in a hypothetical framework from clients.
One way to detect client dissatisfaction is to ask evocative questions, including: Would you award the follow-on work to my firm if you were making that decision today?, and May I use you as a reference in a future sales opportunity? Dissatisfaction with service providers is also indicated by three other behaviors: unsolicited warnings by clients of their dissatisfaction; nonpayment of bills; and being terminated by clients. All require quick response by service providers. While being terminated is usually final, a quick, sincere, informed response represents the only chance of reversing the situation; this is also the case for unsolicited warnings from clients. Finally, the quick detection of and an aggressive effort to uncover the reasons for nonpayment of bills accelerate identification of satisfaction issues.
More formal measures of satisfaction and dissatisfaction include: client satisfaction surveys administered by third parties; client satisfaction questions to clients from service providers’ senior management, quality partners, or other nonproject team source; and client satisfaction questions directly from project team members. Effective quality programs monitor these measures actively and often during engagements to ensure the quick detection of lapses in quality, then follow up with an action plan.
Our observations of client behavior indicate there are two major dimensions of software service quality: the quality of the explicit deliverables of the engagement, namely functional quality; and the quality of the relationship between the service provider and the various client constituencies. Clients attach as much if not more importance to the relationships they have with service providers than they do to the functional quality of the deliverables. Satisfaction and hence quality is thus dominated by the relationship quality dimension rather than the functional quality dimension. This is not to say that functional quality can be ignored. However, high relationship quality means there is an opportunity to improve weaknesses in functional quality and eventually gain additional business or referrals for new business. On the other hand, if relationship quality is low, the client often terminates the engagement and seldom awards additional business. Table 1 outlines the outcomes of the tradeoff between relationship and functional quality.
Given the importance of relationship quality, software professional services companies establish an explicit position, usually called client partner or client relationship manager to focus on this dimension and champion the client’s perspective. This responsibility contrasts with the engagement/project management position, which focuses on the quality, cost, and timeliness of software deliverables. There is often significant conflict between these positions, indicating that an easily overlooked tradeoff between functional quality and relationship quality may be threatening to undermine an otherwise solid business relationship. Managed constructively, however, such conflict often leads to significant improvement in overall quality.
Finally, even though this experience is from the professional services sector, IS organizations can also derive important lessons from this view of quality. In particular, there is a tendency by IS organizations to overinvest in functional quality relative to relationship quality. Since the attributes of functional quality are internal to IS, and hence more controllable, this tendency and the attitude driving it is understandable. However, incremental investment in functional quality is no longer cost effective since the incremental investment put into relationship quality has a much greater effect on outcomes.
Clients attach as much if not more importance to the relationships they have with service providers than they do to the functional quality of the deliverables.
Relationship quality, which fits the standard software-quality paradigm, is determined by the presence of relationship features that meet the relationship needs of clients and the absence of defects that prevent meeting the relationship needs of clients. Relationship features include:
- Communication that is concise, timely, and informative;
- Meeting clients’ ad hoc requests (when reasonable);
- Dependability (when something is promised it happens);
- Fitting in with clients’ corporate cultures and norms;
- Interest in clients as people; and
- Working diligently for the client.
The opposites of these features can be characterized as relationship defects.
To create truly effective relationship quality the features must be adapted to the specific needs of the client. For example, some clients want frequent, in-person communications, while others prefer a more formal approach. Some clients want to know the moment a problem arises and be part of the problem-solving effort, while others just want to know the problem has been solved. To provide relationship features, teams must be trained to be able to determine the relationship needs of clients and consequently how to adapt their behavior to deliver the features that meet their clients’ needs. Quality reviews of engagements must inspect and measure whether the team provides relationship features that meet relationship needs. Moreover, corrective action must be recommended and implemented as needed.
To date, managing client-provider relationships has been largely an art, but further research could help put it on a more rigorous basis. An excellent starting point is SERVQUAL [5], a tool for measuring service quality. Customer relationship management software can also be used to help manage relationship quality, providing a way for service-provider teams to document needs, record activities to meet these needs, and maintain logs of all interactions with clients.
Quality Reviews with Every Interaction
Since relationship quality is affected by every interaction between a service provider and its clients, and since client needs change over time, quality must be monitored throughout the life cycle of each engagement. Though all measures of satisfaction and dissatisfaction might be thresholds to be measured, the service provider must carefully watch three key ones:
- Referral. If quality is above this level, clients award other engagements or give positive references to prospects for the service provider;
- Satisfaction. If quality is above this level, bills are paid on time and clients are generally satisfied with the work; referrals may, however, be on hold pending further progress on the project; and
- Terminated. If quality falls below this level, clients seriously consider terminating engagements and pursuing alternatives.
Quality starts above the referral threshold, since starting work implies a decision to hire the service provider in the first place and is a strong self-referral by the client. Quality usually goes down from this point during the life cycle of the project and may stay below the referral level. Declining quality is due to inevitable challenges and conflicts during an engagement. The goal during the engagement is thus to avoid the quality level falling below the satisfied threshold, never to the terminating threshold, while usually being above the referral threshold. Quality that falls below the satisfied level needs to be detected (a nontrivial problem of inspection and measurement) and addressed promptly. Allowed to go unnoticed and not addressed, the relationship dimension erodes rapidly and may prove to be unrecoverable. The goal at the end of an engagement is for quality to be above the referral threshold.
Client Constituencies and their Needs
So far we have assumed there is a single client and hence one set of relationship and functional needs. One client and one set of needs is, however, rarely the case; at least four major constituencies must be considered:
- Business-problem owner. Has a business problem the software is intended to solve;
- Payer. Gets the bills and must approve for payment to occur; usually the person(s) who selected the service provider;
- Client project team. The set of people on the client side who are part of the overall team developing and deploying the software solution; and
- Users. Use the software once it is deployed.
Business problem owners are, for example, the executives who own the parts of the operation with the problem/opportunity the software solution is designed to address. They are not usually in the IS organization but perform a direct operational role. They focus on the business and expect communication to be succinct, business-oriented, and timely. Their relationship need is high during the engagement, and the business results delivered by the deployed solution are critical to their satisfaction. Users usually work in their organizations, so user needs collectively become part of the problem owners’ needs.
Payers are usually senior IS executives with overall decision-making responsibility about the engagement, including payment approval and the ability to terminate a project. They also make decisions and recommendations about hiring professional services firms.
Members of the client project team are employees of the client, assigned to participate in the project. They usually focus on requirements, project oversight, and deployment issues; however, in some cases they may be fully integrated into the service provider’s team. Their performance depends on the project’s overall success, but they must be sensitive to the satisfaction of both the payer and the problem owner.
Users are employees of the client who will use the deployed system to do their work. They usually work in the problem owner’s operational area. They are heavily involved at the requirements stage and later in the pilots and deployment. Their ultimate acceptance of the solution is essential for success.
Each of these constituencies views the importance of relationship quality and functional quality differently (see Table 2). Note that only the users place greater importance on functional quality than on relationship quality. Even so, relationship quality is still important and has a spillover effect into functional quality. For example, if relationship quality is high at the beginning of a project’s deployment phase, the software is much more likely to be accepted and used in spite of its flaws in functional quality.
Effective quality programs include relationship features tailored to each constituency, along with ways to measure their satisfaction levels. Moreover, the constituencies on the service provider side need to be deployed properly against those on the client side. The key service-provider-side constituencies are the senior executive and client partner/business development people responsible for the client, as well as project managers who run the project and the team itself. The senior executive and the client partner take the lead in facing off with both the problem owner and the payer. The project manager on the service provider side focuses on the payer, client team, and users; the service provider team simultaneously focuses on the client team and the users.
Conclusion
Viewed from the perspective of a professional services firm, the standard paradigm of software quality has been refined and enhanced. But several areas involved in quality management need further research to extend our observations into detailed relationship-quality models. In particular, for each of the four categories of client constituencies, the following must be developed:
- A quantitative model of the relationship between relationship quality and software quality;
- A more formal way for determining (early in the engagement) the relationship needs of the various individuals on the client side;
- The relationship features that meet these needs and how the team can deliver them (the process component of the quality paradigm);
- More effective inspection and measurement tools to ensure delivery of relationship features and satisfaction of the client relationship; and
- A set of measures of relationship quality over a project’s life cycle.
Finally, our aim is to provide a strong foundation for building practical industry-based programs to produce relationship quality and hence improve business results.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment