
How can you make sure that you get enough resources to your project? Should you use an optimal plan or a plan with risk buffer? How about asking for extremely much an finally getting what you need? This is called “rejection-then retreat” and it is based on science of persuasion.
In his bestseller book, Influence: Science and Practice, doctor Robert B. Cialdini describes dozens of valuable persuasion tactics in detail. Mr. Cialdini is probably the best known thought leader in the field of persuasion, and together with his science team he has studied a number of powerful tactics.
One of the persuasion tactics Robert B. Cialdini describes is “rejection-the-retreat“, which shortly means “ask extremely much and finally receive what you really need”. Although most of the persuasion tactics are used in marketing and sales, can some of them be applied also in project management. I believe “rejection-then-retreat” tactic fits perfectly well in the toolbox of a project manager.
Estimate what you need and then ask a lot more
I used to plan my projects in optimum way, and after several missed deadlines and milestones I had to figure out a better tactic. I started using a risk buffer. I multiplied all my time estimates by two and later by three, but soon I realized it does not make sense because also the non-risky tasks are multiplied. Next I tried to multiply only the risky ones, but my plan became a chaos..
Few years ago I had a subcontractor who by accident told me that they multiply all their optimal time schedules by seven. At that moment I understood why they had been so expensive. Also I realized that it was risky for them to work with us..
So, why am I talking about time estimates in relation to “rejection-then-retreat”? There are similarities. With a project plan (talking only about time schedule) I ask resources from line management. I know big up-front plans and milestones do not exist in agile projects, but in traditional “old fashioned” industries such as factory automation this kind of plans and milestones are an every day life. So when I go and ask for resources from lines management, I must show my plan with time and resource estimates.
If I show my optimal plan, I most probably get 80% of the resources I need, but sometimes even 100%. Unfortunately software projects are impossible to predict and plan 100%, so most probably my optimal plan fails. Therefore I need to ask more than I need in order to get what I actually need, and by adding this buffer to my project plan I can do this. Does this make sense? Well, If your project is successful after resourcing like this, then I would say yes. Now the trick is to ask a lot more than needed in order to get what is actually needed. All right, but what is the theory behind this?
Let’s see what Mr. Cialdini says.
Suppose you want me to agree to a certain request. One way to increase the chances that I will comply is first to make a larger request of me, one that I will most likely turn down. Then, after I have refused, you make the smaller request that you were really interested in all along. Provided that you structured your request skillfully, I should view your second request as a concession to me and should feel inclined to respond with a concession of my own – compliance with your second request.
A true story of rejection from Calvin and Hobbes
Calvin: Mom, can I set fire to my bed mattress?
Mom: No, Calvin.
Calvin: Can I ride my tricycle on the roof?
Mom: No, Calvin.
Calvin: Then can I have a cookie?
Mom: No, Calvin.
Calvin: She’s on to me.
Shortly said, plan and estimate your resource needs first. Add some risk buffer as you know optimal plans never work. Then multiply your plan by five or what ever figure you see the best. Next walk to you manager’s room and proudly present your plan and resource needs. You most probably will drive him/her nuts, and your request will most probably get rejected. Then make your concession and come up with smaller request that is closer to your real needs. Now you should get what you need. Walk away and be happy.
This is 50% serious, 50% joke. You know what I mean.















Leave Your Response