I am an external project manager. The internal staff at a clients business have started making comments to the effect that "this requirement will be easy to deliver". Such comments are damaging our relationship with the client. The comments are completely unfounded as the people making them have no expertise in the relevant areas. Nonetheless the comments are creating unrealistic expectations in the client's mind regarding the speed of development. I don't want to make an enemy of the staff saying the things are wrong but also want to stop the staff creating unrealistic expectations. I have told the people that such comments are unhelpful and wrong but they still persist. Do you have any suggestions on how to manage this situation?
-
1My, politically incorrect, response would be that if the work were really that easy, they wouldn't need me, because they could do it themselves in between their other work.– Bart van Ingen SchenauOct 5, 2018 at 6:26
-
Does not really help with the fact that I said I don't want to make an enemy of them.– BrettOct 5, 2018 at 8:06
-
1Why exactly is saying "this is easy" damaging your relationship?– ErikOct 5, 2018 at 10:55
-
@Erik the comments are harmful because they are creating unrealistic expectations in the client's mind– BrettOct 7, 2018 at 2:52
Add a comment
|
6 Answers
The first counter to 'this requirement will be easy to deliver' should always be ask politely to list down the risks involved. Such unfounded claims are done by people who want to boast or want to challenge the team off a cliff.
The art of war in such situation is to transfer/overload ownership by asking counter specific (not open-ended) questions to the point where they have no answers. The point is to ask questions that will test their knowledge and not questions that have generic answers.
"It seems you are well aware of the design as well as low level implementation involved to achieve this requirement. Can you please list out the design considerations we need to make so that it can be achieved as easily as you mention?"
"So what are the risks involved in implementing this?"
"So you're saying there is no risk involved since it's fairly easy to implement? In our current system/application can you show us a similar risk-free implementation?"
"How closely have you worked on functionalities that deal with the integration part of this requirement?"
"Can you please guide/elaborate on the integration/testing effort involved and how you propose to overcome the challenge of ___________ ?"
"What are the architectural components that will be impacted by this implementation?"
If they counter with a question, simply be surprised and say
"WE were hoping you would answer that since you found the requirement to be easily implementable." ...or... "WE thought your expertise was in such implementations and you would guide us all."
And then immediately, steer the discussion or conclude with that statement that
"I believe there are still few unanswered questions and risks to identify, so this requirement estimate needs to be reconsidered. I'm not saying it's easy or difficult or impossible, all I'm suggesting is that we take a measured approach to understand the risks involved, have discussions necessary, get X, Y and Z involved and then proceed."
By saying so, you set yourself at a neutral mature position, establish control over defining the estimates and the direction of the conversation.
The aim is to deter future claims and by counter questioning detailed level aspects of implementation, you corner individuals who make baseless claims. Continue to relentlessly question them until they back down from making such claims.
-
I'm curious - why are the first two 'we' and not 'I'? Seems to me that you're speaking for someone else, there.– SarovOct 18, 2018 at 13:16
-
When you use 'We' it creates a the argument considering with the presumption everyone agrees to what you are saying unless someone challeges/opposes you. Also you want the person who is making baseless claims to perceive the statement as him/her opposing the team's views instead of just your view. Another reason 'we' is important is because you are taking responsibility and speaking in the best interest of the team and not just yourself. Oct 18, 2018 at 22:26
What you need to uncover is the driver behind the 'this will be easy' rhetoric. Is it innocent optimism? Is it designed to keep sponsors interested in funding this project? Or is it designed to insulate themselves against a risky project such that they can point to another group or individual--such as you--when and if the project goes south?
No matter the drive, communication is your ally here and what and how you communicate will depend on the driver of this statement. If optimism, use it to your advantage. Optimism has a lot of benefits. Frame your risks and issues you are facing in such a way that keeps this optimism a live. If they have a sponsor issue, then you need to frame the risks and issues you face in such a way that sponsors do not get scared and back off the project. You need to support your client with messages that the team can weather these storms. And if it is the latter, then you need to communicate early, often, very clearly, and non emotionally the facts of what's going on, the risks you are predicting, the issues you are experiencing, and your plans to mitigate and recover. And you need to document everything so as to insulate yourself if fingers start pointing in your direction.
answered Oct 5, 2018 at 11:38
What's easier? To eat an elephant or a hamburger?
It doesn't really matter, as you eat both one bite at a time. The difference is how many bites you have to take to accomplish each task.
So, break down your project into specific tasks, identifying the parts of the work that will be more complex that the client might have overlooked. Stress the external dependencies you might have and the pitfalls that could convert silly tasks into weeks long work. The client may be requesting an Iceberg implementation, make sure he's aware of what's down the water.
Bottomline: A single task has different points of view. Put yourself where the client stands and explain the work in the background he's not seeing.
answered Oct 6, 2018 at 9:06
on agile scrum , having easy/moderate/difficult sort user stories is indica-tion from clients on regular meetings. A product owner will having quick answer for these sort queries with onshore stakeholders .
-
at our latest project OEM activation having short easy , mid size moderate , long difficult stories point . that will a clean direction from project manager to stakeholders on these sort queries . Oct 7, 2018 at 14:50
Some of these clients might not be having any intent of challenging you or your decisions. It might be just because they are actually ignorant and genuinely think that it is possible to get it done quickly. I have faced this situation a lot. A project manager also need to be a good people manger. In these kind of situations give your client representative the benefit of doubt. Here is what has always worked for me positively. I usually subdivide the task at hand into multiple sub tasks and assume the hours needed for each sub task and share it with the client. If at that point of time i am not aware of what goes into it, i politely tell them "I will look into it and get back to you with the specifics..Lets hope we can easily wrap it up". Client are humans who pay us, which gives them the feeling of superiority. Lets let them keep their ego high and milk the cow slowly.
The first and foremost way to handle this situation is to explain the development effort in a proper way. Nothing is easy unless a brilliant effort is put into development. My thought is to share the development effort involved with highlighted QA , analysis and development costs.
