Managing customer needs and expectations

Project Management—A Techno-Managerial Perspective

Stakeholder analysis is extremely important in all projects. Identifying whom to satisfy is perhaps the most difficult challenge for a project manager, writes Pradeep Pendse

“The customer is the king” is an old adage. I may add that “the customer has several expectations”—one of them is that the project team should fulfil the commitments. This is indeed a loaded statement.

It implies that the word “expectations” covers much more than mere requirement specifications.

Indeed considerable work has been done in the area of requirements management by way of formal tools and techniques such as the ISO Reference on Requirements Management, UseCases, OO-AD, UML, etc. Despite this, most project managers continue to struggle to meet both requirements as well as expectations of their clients.

My own submission however is that mere tools and techniques are not enough to cope with the problem of requirements and expectations. It requires:

• The ability to elicit as well as observe and sense customer needs;
• Ability to grasp concepts and see the big picture;
• Patience and perseverance in understanding and analysing;
• Sharpness and the sixth sense of an auditor or investigator;
• Personal warmth and energy to get cooperation and support;
• Ability to influence the direction and the scope of a solution;
• The assertiveness to say ‘No’ when justified;
• The ability to close issues—the killer instinct.

In this article, I have therefore tried to bring out some of the challenges in the area of managing needs and expectations and various technical and behavioural approaches to managing them.

CSFs—to indentify goals and expectations

We have seen in a previous article how the Critical Success Factor (CSF) Method as applied to the relevant work function helps us in defining goals for a project. Equally important is to note that the CSF of a function subserves the CSFs of the organisation as a whole.

Let me explain what this means. The table below gives some basic expectations from every process working in the banking and manufacturing (made-to-order) environments.

A project manager developing even the simplest of software has to check if these underlying expectations have any bearing on his software. For instance, he may design a new banking product which works well by itself. But the project manager later discovers that the bank’s customer is upset about receiving several separate monthly statements for each product.

This happens since the project manager has forgotten that his solution has to align to a fundamental requirement, which is to ensure that the customer gets one single view of the bank. When the bank suggests that this be implemented, the project manager sees this as a ‘change request’, not realising his failure in identifying these critical success factors.

Organisational philosophy

In one of the articles I have discussed the case of Mrs Fields Cookies. The IT systems in this organisation were implemented keeping in mind two basic philosophies:

• Keep people free to do people-oriented tasks and let computers do the remaining repetitive, analytical work.
• Technology is organisationally neutral, that is, one can use technology either to ensure compliance or to generate commitment. The top management and the IT management must articulate whether they wish to have commitment orientation or a compliance effect through systems they design.

The case emphasises the need to have a philosophical basis for implementing systems across the enterprise. The project manager must discover this philosophical basis and clarify it while defining project goals. Equally, he must ensure that this philosophy is embedded in the design of the solution.

Behavioural side of mapping stakeholders

Stakeholder analysis is extremely important in all projects. Identifying whom to satisfy is perhaps the most difficult challenge. Various factors such as departmentalisation, strict or some times unclear reporting relationships and structures, power equations, ownership for the project, and other business pressures result in missing out on a few stakeholders who may have a bearing on the project.

The ability of the project manager to get a formal ownership, organisation for the project at the customer’s end and the ability to bring visibility to the project can address some of these issues.

A systematic mapping of stakeholders and their needs, vigorous follow-up and the visibility of the resulting needs would definitely help.

In a book titled 7 C’s of Consulting, the author mentions about five distinct people who can impact the scope and success of any assignment. He calls them the Ace, Queen of Hearts, The Kingmaker, the Knave and the Joker. The Kingmaker is one who influences through a remote control. You need to be aware that the person whom you are interacting with is actually a mere voice for the powerful Kingmaker who stays in the background. The Queen of Hearts is like a sidekick to a key executive. The executive consults him for all matters before taking a decision. Identifying this person and convincing him can help in getting things done your way.

Many times in a project you come across a very ordinary person such as a clerk or even a typist. This person has worked in that function for many years and knows the business well. The executive would ask the analyst or the project manager to get all requirements as well as signoffs counterchecked by the Knave.

The project manager must therefore learn to identify key people in each functional area—people who know their business and have a voice. The Joker is usually a like a wildcard. All of sudden midway into a project you find a name starts appearing in all conversations, meetings and communication, the author refers to him as a Joker.

The person could be an auditor or an external management consultant or a newly joined corporate executive who seems to have a temporary but significant influence in all areas.

The last and perhaps the ideal person to have on the customer’s side is the Ace. This is a person who is respected and has knowledge and the power to take decisions.

Success at managing requirements and expectations and indeed success at managing the project depends on the project manager’s ability to identify such Aces within the client organisation and in getting their involvement in the project.

Compartmentalisation

I have seen many end-user managers who insist that the project manager only focus on the requirements of his/her department and not worry about others for the moment.

I was once developing a ‘stores’ system for a manufacturing company. The head of stores was a senior, dominating and competitive person who wanted to steal a lead in the process of computerisation, thereby scoring a few brownie points for himself. He therefore insisted that I look at only his needs and implement them. Later, I discovered that the data generated in stores could be used by the stores accounts department who were to do the stock accounting and valuation function.

In most cases the project manager must identify all direct and indirect users and insist they participate and be heard while defining goals and requirements.

Balancing requirements and goals/end purpose

Software they say is a “wicked problem” i.e. it defies an accurate and precise description and it is difficult to know when you have reached your destination. This means that one needs to find out ways to correctly and completely express requirements and criteria to judge whether the goals have been met. Such a document would become a touchstone throughout the lifecycle.

Unfortunately, this attempt to define requirements tends to generate a technically complex and almost legalistic document which we call a requirement specification. Further, most users would either refuse to sign such a document or if they do they do it in blind faith leaving the onus on you for its correctness—since as they say you are the IT expert.

(To be continued...)

Pradeep Pendse is Senior Associate Dean—Systems & E-Business, Welingkar Institute of Management Development and Research. E-mail: pendse_pradeep@yahoo.com