Difficult Customers, A tactic to tame and reduce the risk on our projects - Part I

[You can also watch on YouTube. Click here]

 

We all, particularly  PM’s and Scrum Masters, face times when the success of a project is threatened by some behavior of a difficult client. Here is a series of three articles titled Difficult Customers, A tactic to tame and reduce the risk on our projects, looking at the phenomena and giving some practical advice to mitigate its impact on the project.

In this first article, we take a deeper look into the general character of the software customer of today, in an era witnessing lots of shifts in the old business paradigms. Actually, I coined my slogan “Business as Unusual” to tag that all by one referential phrase. Doing so will certainly help in dealing with any hazardous situations that can break out of the lack of such an understanding to today's software clientele. 

So, Let’s get down to business!

Well, A Customer, or A Client, is the one who pays our salaries at the end! Peter Drucker, the business and management legend in the 20th  century,  puts creating customers as the first target of any business at all times. Their satisfaction is considered a success on its own. Let’s not forget that to start.

Let me align some terms with you first, there is a little difference between the two words, client and customer:  Actually a client is one served not necessarily for economical reasons. However, I use them interchangeably as most people do.  By the way too, the clientele is a community of customers/clients.

So, what about the software customer?

Though it’s not possible to generalize, we can see quite some apparent  commonalities in today’s software clientele. These are:

First - Customers have become more self-conscious than ever, this even sometimes escalates to arrogance. That is mainly caused by the effect of competition in the software, and the computing market in general, further augmented by alternative low-cost computing models, represented by the advent of two major new players:

  • Open source movement: with applications covering almost all organizational needs, and
  • Clouding, particularly SaaS: Software as a Service applications.

Actually, we are witnessing a shift of market power to the customer’s side. It has not become unusual that you see a customer trying to exceed scope, and keep looking for additional functionality that goes beyond his initial set of requirements.

No wonder, thus, to see Demanding clients, sometimes Over Demanding.

Second - customers tend to Change their initial views, or requirements, as they start to see what they once thought to be their needs. This is particularly true when the application is new and has no predecessor. As you proceed with a new product, people start to touch and feel how far that goes with their initial expectations. This is actually the nature of any Development process, as you go from ideas in minds to functionality on the screens. Coupled with that, is the nature of the business environment we are all operating under, which,  with its tendency to change becoming more evident than ever, faster than ever. This reflects on requirements and sometimes even endangers development projects when the project spans are extended for one reason or another, due change in requirements, or redoing cycles due to some misunderstanding in the initial customer expectations. 

Therefore, you can say that tendency to change, has become more often than ever before by customers, when things come to requirements.

Third -  Customers are sometimes Reluctant. New software is by definition a change in the daily work of people. It’s normal that it gets met with some resistance, especially when that entails some additional burdens on people who will undertake the change process. This may take many forms, indeed. They might be reluctant to do their parts in a project like design reviews, giving some feedback, or data provisioning. There are situations where they are even totally resentful to the idea of changing a current work system, for instance from the “no system” state to a system, or from an existing system to a new replacement. Interestingly enough, some customers use change in requirements to beat the idea of change of systems! I’ve seen cases where the customer is resisting a new system by producing a stream of change requests along the way, just to keep the end of the new project far away. What a tactic!

In conclusion, as you can see, and in a notable number of projects, our customer in the software business could probably sometimes represent, so to say, one of the risks on his project, in varying impacts and probabilities, of course. In many cases, we are in front of a challenge, facing pressing needs, hazy targets and less effortful fulfillment of commitments by a principal stakeholder in the development process, our customer. How to mitigate that? The rest of this article series will shed lights on some tactics to mitigate or lessen the impact of such  customer-related risks on the development process.

Finally, let me admit that you can’t just generalize this short treatise to all customers in software market. Instead, it is intended to help you watch for these characteristics in your stakeholders, and get ready for the hazards down the way.

To complete the picture, let us remember that software customers in today’s market can show some variances depending on a number of factors, namely:

  • Their business cultures, their fields of application: Telecom, Media, Manufacturing, Educators, … all have their different mindsets,
  • Degree of knowledge in technology, and
  • Previous history with computing represented by success or failure experiences they may have encountered.

 These factors can add or subtract from the customer related risks in the software process. We look at that, as well as mitigation tricks in the rest of this series.

Stay tuned.