My early years in project management coincided with the IT revolution in the US. This resulted in technology professionals and sectors replacing construction and engineering disciplines as the most prevalent consumers of project management capabilities. I saw first hand how the PMI membership was transformed over a short period of years by this, not by the decline of engineering talent in its ranks but by the overwhelming growth of IT. At that time project management concepts were difficult to explain in the context of IT due to the shortage of examples and case studies. We have come a long way since then and with the continued emphasis of technology advancements there are a lot more case studies in the project management profession related to IT lessons learned. The rate of adoption has also increased and some might argue that projects are more likely to succeed as a result of it.
I recently encountered a situation that made me reflect on those days when I first finished my graduate program and entered the ranks of project management. Back in those days a couple of the organizations I worked with had staff members who were convinced that the IT teams were far better at identifying requirements that the business users. I would take part in project team meetings where I would hear statements from business managers that were something along the lines of “why am I here, the IT team knows what I need, they can tell you.” While in principal back then this could have made sense, I challenged it and said if that where the case, why is it that several of our projects were not able to achieve success. It was true that the business and IT teams had worked together for a while but they collectively were not able to address projects in a systematic way to deliver on business results.
This type of situation I observed occurs also between organizations and their vendors and consultants. Furthermore, this attitude also extends beyond IT where clients expect their service providers to know what they what and service providers often make too much of an assumption that they indeed know the customer’s needs.
This quickly gets to an impasse when it eventually becomes clear that what the vendor, consultant, or the internal service provider delivers a “product” that does not address the needs of the customer. There are a variety of reasons for this type of situation but they are typically underpinned by a lack of effective communication to enable proper requirements definition. Additionally, this becomes frustrating when the service provider determines that they do indeed know better than the customer what the true requirements are. Often this is also complicated by the fact that the service provider then switching roles to becoming an advocate for a certain point of view.
I have encountered this particular challenge on a few projects where I find myself in a very dangerous position of having reached the conclusion that I know more about the customer’s needs than the client themselves. Sadly while many of us may relate to this point of view as we may have been in it a few times, the bottom line is your knowledge, capabilities, and skills, are irrelevant if you are not aligned with your client. Additionally the timing for advocacy has to be right otherwise when your are advocating at an advanced stage in the project, this will likely create an unwanted headache for stakeholders.
A few years ago I was preparing a proposal in response to an RFP. As my team was reviewing the RFP we determined that the client’s requirements did not make sense and in fact conflicted with each other. I requested a meeting with the client to explain this to him. The response was swift and the client told me that this ship has sailed. The time for advocacy was over and there was no point in engaging in consultative selling. As a result we had to make a decision of whether we could live with what was expected or not and in our situation we ended up passing on the RFP.
Over the years I have switched roles in my project management career from a customer to a service provider and back so I am generally sensitive to the needs of vendors and consultants when I find myself in the shoes of the customer. I know how difficult it is to achieve success in sales in professional services especially, and how challenging it is to extract proper requirements. So I try to exercise some patience because I know I will likely be in the vendor or consultant’s shoes the next time around and would hope that I have someone who is understanding on the other side. This stance that I have adopted did not come naturally to me. It came as a result of some tough lessons both earned and learned. In one situation my client even challenged me by asking what was I hoping to achieve but convincing them that they are wrong because if I succeeded in demonstrating their incompetence the best I could hope for is to be thrown off the engagement.
Shortly after this experience I developed some basic rules of engagement to help remind me what it means to be customer/client centric. It is not about “the customer is always right” which I know some will challenge as a fallacy, so I wont go there. The rules of engagements are about paying attention to chart a path for success on projects. They include four simple steps.
- listen. Make sure you stop talking and stop thinking while the client is talking. Try to understand what they are asking and don’t put words in their mouth. Don’t assume that you know what they want even when they are telling you something different. Listen with an intent to understand and not with an intent to respond.
- Assess. Once you take in everything that the client has to offer in terms of requirements, inputs, and feedback, take time to assess what this information means. Can you as a service provider, consultant, project manager, or vendor deliver what the client is asking for? Does the client offer realistic expectations?
- Mitigate. Now that you understand the requirements and have a point of view following your assessment, you should be able to identify the gap between those requirements and what you are able to offer in your solution, product, consulting deliverable, or project scope. This should enable you to come up with risk mitigation to address those gaps, including the possibility in some cases to influence the client’s thinking.
- Act. Once your mitigation plan is in place and you’ve finished potentially influencing stakeholders, now is the time for action. Either you decide to move forward on delivering your product/service as part of the agreed upon scope, or you decide to bow out because you believe you are not positioned for success. It is most dangerous to assume that you can proceed forward and change the customer/client’s mind later once they get to know you better or could trust you more. It is better to step away from the get go if that is the working assumption you intend to start with.
In the end the most important element that leads to success on projects is an alignment of expectation based on a common understanding of requirements and objectives. Some vendors and consultants are better at advocating than others, however, once you are about to conclude your journey the customer (no matter what their unrealistic expectations may be) better be satisfied or you are likely to encounter continued trouble.