In my previous role, developing proposals was a breeze. We were in the business of answering our clients’ questions – we used to conduct research as per their requirements. Even if they didn’t know what questions to ask, we would help them with it.
But, with technology, there seemed to be so many unknowns, so many parts of their business that I did not know. A few questions that were running in my head:
- Did they want a highly optimized mobile web version or not?
- Did they want to allow user generated content?
- If yes, how will they manage moderation?
And so, on and so forth. With every exchange, there would be more questions than answers. And the prospect was not very forthcoming.
That’s when I decided to change my perspective and approach. Rather than get the prospect to define everything, I started detailing out how I would get approach developing the project – both functionally and technologically. It then became a matter of getting confirmation of whether, what we detailed, was the right way to go or not.
The oldest, shortest words – ‘yes’ and ‘no’ – are those which require the most thought.-Pythagoras
This helped in many ways:
- For starters, it helped develop clarity on what the requirements and scope of the project are
- Helps provide the technical teams with a basis for developing technical solutions and effort estimates and,
- Most importantly, get the prospective client to decide whether or not they want this. If they don’t it helps determine which parts need rework and provides a mechanism to zero in on a solution that’s agreeable
Of course, it does happen that there’s a prospective client that gets you to make 14 versions of a proposal before deciding that you don’t understand their needs. Though, I did have a client for whom I made more than 20 versions of a proposal before he finally decided to award us the project.
Back to what Pythagoras said – I think it’s a bit easier to get someone to say ‘no’ than a ‘yes’. And, with getting the requirements detailed, it’s easier to do just that.