Struggling to Manage Customer Expectations?

The principle I got most wrong in the Seven Principles book was that of "Principle #3: Manage Expectations". Early into our our experiment of running a consulting firm based on the principles, I asked a group of struggling project managers, "Are we not managing expectations?" I didn't need a reply, the blank look on their faces told the story. While they knew the intent of managing expectation, they had no idea how to put it into action, and to be honest, neither did I. 

The truth is, I found Principle #3: Managing Expectations the most difficult principle to formulate and teach. I felt as though I couldn't leave such a well-known consulting principle out of "the seven", yet found it incredibly difficult to provide any substantial tools to manage them better. Could the consulting world's single most popular catch cry be a myth? As it turns out, I think it is; when it is provided in isolation without the rest of the equation.

The reality about trying to manage an expectation, is that the expectation itself, is not yours. So while you can influence an expectation, your ability to "manage" it is limited at best. However, when the expectation is formed by a paying customer who believes that the fee being paid justifies their expectation, the ability to manage it is almost impossible.

The key to managing expectations lies in understanding what you do control; the enforcement of consequence!

 

What I didn't understand while writing the book, was that real-world expectations are managed by the application or enforcement of consequences. For example, given that I can't stop you expecting that those additional requirements will be provided for free, the only thing I can do control is enforcing the consequence of you having to pay for them.

With this in mind, I again took to the web to see if I could find any existing research and "voila", there it was. An incredibly interesting article titled: "When serving customers includes correcting them: Understanding the ambivalent effects of enforcing service rules". While I had to pay to access it, the $35 was well worth it.

The research shows if we do not tell the customer that consequences will be enforced during service delivery, then when we need attempt to do so, we will not only receive a lot of pushback, but if eventually enforce the consequence, their perception of us (or resultant CSAT) is greatly impacted. Given the nature of project delivery, it is almost impossible to maximize a project's profitability without at some point having to enforce some kind of a consequence. This puts almost every project in the dangerous dilemma of having to choose to enforce the consequence or attempt to retain CSAT.

However, the research shows that if we do explain in advance that consequences will be enforced, then two things happen.

1. The customer is more likely to accept the consequence. This preserves project margin.
2. The customer's perception of you is only marginally impacted. This preserves the CSAT score.

This makes "pre-statement of project consequences" an essential part of any service providers service delivery. In context, this is exactly what kickoff is for; isn't it? At kickoff, we should be setting the scene for the impending project and describe how the process will work successfully and what dangers lurk to potentially disrupt that success. Yet, putting a slide up on the screen that says "Project Consequences" probably wouldn't go down too well, so there needs to be a better option.

When putting this into practice, we achieved success by rethinking the "Keys to Success" slide. In essence, this is a positive reframe of "there will be consequences". For example, one of the keys to a successful project is that the project's sponsors must attend the monthly steering committee reviews. This can be clearly stated as a key to success, but we can also add that if this doesn't happen, then we will escalate the issue or potentially have to pause the project. 

With this new information in hand we were emboldened, but yet when executing it in the field, we still noticed an important skill that was lacking in our project managers. The complexity of project delivery and the customer's ability to use leverage meant that our teams did not always know what the consequence of a specific customer action should be. This is because they are not trained in identifying the "natural" consequences of misaligned customer expectation. For example, if a customer wants to just slow a project down because their team is too busy doing other things, what is the natural consequence?

I wrote about this quite a while ago when we developed the PS Principles' Defensible Framework for Professional Services. We now use teach this framework to teams all over the world in our Saying "No" to Customer's class and the response from participants has been fantastic. The framework helps project managers, architects and consultants understand how certain customer expectations impact a project's ability to be successful by impacting the core success measures of budget, time, scope, profitability and the desire for a customer to be a reference.

So, the principle needs to change. It isn't really the principle of Managing Expectations but more of Enforcing Consequences. To make it accurate, the training and certification program has been updated so that the focus is now on both of these elements. It is important that consultants understand the anatomy of an expectation and the importance of managing expectations of a project, however, the "so what?" in this principle is that without the enforcement of consequences, we'll never effectively be able to achieve expectation management. After these changes, I'm finally happy that the principles is both complete and of value to those trying to implement it in the field. Do you agree?