The Art of Saying “YES”
My experience in the service industry taught me a few things about customer service. However, over the years, I have seen many differing levels of customer service depending on the department and position I was in or those I interacted with at the time. No other time in my career has this been more prevalent than when working in Information Technology and Project Management.
I teach a course at the University of South Florida as part of their continuing education project management certificate program. The course is called Leading & Influencing Projects and is focused on the psyche of project management. Topics that are covered include stakeholder analysis, understanding personalities, communications and building high performance teams. I love teaching this course as it gives me an opportunity to convey best practices I have learned on the change management component of projects I have been involved in.
Every class offers a rather diverse group of people who are from many different industries. However, despite their differences, many of the same questions come up. One of the most common questions is how to manage expectations when end users ask for changes or management continues to pile on the projects. Typically, the IT answer to anything out of scope or out of reach is just to say no, or we can’t, or impossible or whatever. The customer side of that equation leaves unhappy, frustrated and results in instant friction with the IT and/or Project Management department. Having experienced the very same scenarios in my career, I have developed a few techniques for dealing with these situations. Just say YES!
People naturally don’t like to hear the word “no” when it comes to changes to projects or new projects. Especially if they feel they have no control over the decision-making process. The best way to combat this behavior is to put the power back in their hands. I always ensured my project management team were mere conveyors of facts. This allows those who need the facts to make the appropriate decisions. Reversing the decision components allows the requestor to make an informed judgement on whether their request still has merit and whether they are willing to go to bat to get the resources needed. Instead of spending your energy on saying no, spend your energy on what it takes to say yes.
Making this happen is a relatively simple process. The same thought that most people go through to come to a “no” conclusion will help you come to a “yes” answer. Most project managers think first about the triple constraint; time, money and resources. These are the primary factors when considering scope increases or new projects. These same factors are considered when formulating your ”yes” answer. Compile the information you need provide what it takes to say yes. Figure out the costs, other project impacts, scope and timeline impacts then present the information back to the requestor and allow them to decide how to move forward with the change or new project.
Essentially, a conversation could go like this “In order to accomplish your project under the given timeline you have provided, I will need 5 additional resources at a cost of $150,000. If you can move your timeline into the future by 8 weeks, I can accomplish your project with only 2 additional resources at a cost of $25,000. Which option would you like us to proceed with?” This puts the decision squarely back onto the requestor who is then responsible for acquiring authorization for budget and resources.
At the end of the day, saying yes is much more fulfilling than saying no all the time. Additionally, the exercise enables customers and end users the ability understand the ramifications of their requests and ultimately helps both parties become better at communicating their needs. The word “no” should not exist in your vocabulary, only “YES!”
What do you think? Feel free to comment on your own experiences or post a question.
This is probably the complete opposite of one of the articles I published a long while ago: how to say no. I like your strategy though of throwing the decision making on the requestor.