Join Doug Rose for an in-depth discussion in this video Answering tough questions, part of Project Management Foundations: Communication.
As a project manager it's inevitable. At some point a stakeholder is going to ask you a tough question. It might be a botched timeline or a question about the quality of the deliverable. More than two-thirds of projects end up missing their deadline, are over budget, or fail to deliver. So project managers are often put in situations where they have to answer tough questions. Your instincts might be to try and sugar coat the answer. You might even try to ignore the question. You should fight these instincts.
I once worked on a web application project for a group of Montessori schools. One of the stakeholders asked me to meet with him about the project. I knew the stakeholder had a demonstration just a few days before. I really enjoyed meeting with the stakeholder because he had a reputation for being very direct. He sat me down and immediately opened up by saying "Why do you think we should fund this project "if the software isn't working?" If you're at a meeting and this happens to you, try to remember the acronym NIECE. N - never get upset.
I - illustrate the question with examples. E - empathize with the stakeholder. C - clarify the question. E - explain your answer. I had been working on this project for over a year. So it was difficult to not get defensive. I still knew to never get upset. I immediately tried to get him to illustrate with some examples. He said he had given a demonstration to a group of Montessori school customers and that the software would not create student accounts.
Using active listening, I tried to get him to clarify the question. So which part of the software wasn't working? Was it just the create student accounts? Be sure to ask for very specific illustrations. You want to focus on the question and not on the stakeholder. You'd never want to say something like "Why do you think the software is not working?" That type of question might make the stakeholder defensive. It might seem like you're pushing back. Remember, it's the question that you're illustrating. You don't want them to illustrate their thought process.
You want to make sure that you understand the question. All of your listening should have empathy. Admit to wrongdoing or mistakes. Understand the stakeholders point of view. You might want to just say, "That's a part of the application that "the customers are most interested in using." That shows that you understand the stakeholder's question. It also shows that you see yourself in the hot seat with them. Now you want to clarify the original question. Are you asking me if we should cancel the project? This part is perhaps the most difficult.
Sometimes it's hard to clarify the question when you don't really want to hear the answer. Remember at this point you're still focused on the question. A lot of times you get to this point and the stakeholder will say, "I'm asking you why we shouldn't cancel the project." When you clarify the question, you have a much better sense of what the stakeholder is thinking. The question actually has a positive vent to it. He's actually asking why you shouldn't cancel the project. Compare that to, "I'm asking you to create a final report "that shows how much money we lost on this project." That type of clarification is much more negative and will most likely mean that your project is already canceled.
After you have the stakeholder clarify the question, be sure to wait for the answer. You wouldn't want to ask for clarification and then immediately assume that your own clarification is correct. You wouldn't want to say, "So we're canceling the project?" The final and perhaps most important part of the NIECE acronym is to explain your answer. When the stakeholder is asking you a question it's usually because they're going to use your answer to deliver to someone else. So a lot of times when the stakeholder asks you a question, what they're really saying is, "Give me the answer to this question." So if you don't give them the explanation, then you're not giving them what they actually want.
So we don't want to say, "No, I don't think we should cancel the project." Instead, give them your full thought process. Something like, "I don't think we should cancel this project "because we decided to develop the software very quickly. "We did this because we knew that the customer "would make a lot of changes. "The downside to delivering it very quickly "is that we will spend more time debugging." Then you should agree that putting buggy software out for the customer is not good for anyone. So after you explain your answer, you want to make sure that you have some suggestions on how to improve the process.
The stakeholder for the Montessori schools decided not to cancel the project. He just wanted to hear my thoughts on why we shouldn't cancel the project. He even used my illustrations and clarifications to explain to the other schools at the next demonstration. Focusing on the question really improved our communication.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Using formal and informal means to communicate
- Prioritizing stakeholder needs
- Listening actively
- Planning project communication
- Understanding leadership language
- Writing clear and concise project reports
- Learning how and when to say "no"<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.