Comments on: When to ask and when to assume http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/ A holistic commentary on all things IT. Sun, 05 Sep 2010 14:09:29 +0000 hourly 1 http://wordpress.com/ By: Matias http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/#comment-139 Matias Tue, 16 Feb 2010 00:09:33 +0000 http://holoom.com/?p=212#comment-139 Puzzling post, and popular indeed :) Inevitably many interesting subtopics may arise only from the post title "When to ask and when to assume", which in fact happened along all your comments. Though, I will restrict mine to the post main idea: "When to ask and when to assume" at a sales stage. In my experience, when quoting for a project you will find an endless list of situations, among them: - Clients who want to hear vendors with full knowledge of their business domain. - Clients who prefer highly tech skilled vendors with a poorer business domain, being the former willing to transfer such knowledge. - Clients who do not care at all about how much you know of their business domain or how capable you are of learning it, but about how fast you can escalate and deal with their constantly changing requirements. - Clients who are only looking for a vendor able to integrate with their build process. - Clients who do not care any of the above but how fast you can deliver a productive dummy app for them to counter their business pressures. - And I could continue until my beloved Racing Club wins the World Cup again... The truth is that it is really unlikely that you will have enough time, people and client's support to pay attention to all aspects of a proposal. So, what a vendor should keep in mind in my opinion is identifying the winning factor within a proposal request process. Is it price, time to market, business knowledge, tech expertise, methodology, response time, innovation, track record...??? A mix of them?? Once you make sure you've caught that success factor from the client's mind, I suggest to direct all your efforts in writing a proposal that says what the client wants to hear, hides but contains the minimum you need to negotiate during the execution, and most important of all... has a good price and profit margin for you not to care even about negotiating during the execution (if low price is not the success factor, obviously :)). Bottom-line of my comment: there will be times when you should not even assume or write detailed requirements, but sell a highly priced project for you to deal with an expected number of valid scope claims from the client (based on your experience), or place enough execution/commercial rules that enable you to negotiate for example. And yes... you will need Operations to understand the spirit of the won proposal. Cheers. Matias Puzzling post, and popular indeed :)

Inevitably many interesting subtopics may arise only from the post title “When to ask and when to assume”, which in fact happened along all your comments. Though, I will restrict mine to the post main idea: “When to ask and when to assume” at a sales stage.

In my experience, when quoting for a project you will find an endless list of situations, among them:
- Clients who want to hear vendors with full knowledge of their business domain.
- Clients who prefer highly tech skilled vendors with a poorer business domain, being the former willing to transfer such knowledge.
- Clients who do not care at all about how much you know of their business domain or how capable you are of learning it, but about how fast you can escalate and deal with their constantly changing requirements.
- Clients who are only looking for a vendor able to integrate with their build process.
- Clients who do not care any of the above but how fast you can deliver a productive dummy app for them to counter their business pressures.
- And I could continue until my beloved Racing Club wins the World Cup again…

The truth is that it is really unlikely that you will have enough time, people and client’s support to pay attention to all aspects of a proposal.

So, what a vendor should keep in mind in my opinion is identifying the winning factor within a proposal request process. Is it price, time to market, business knowledge, tech expertise, methodology, response time, innovation, track record…??? A mix of them??

Once you make sure you’ve caught that success factor from the client’s mind, I suggest to direct all your efforts in writing a proposal that says what the client wants to hear, hides but contains the minimum you need to negotiate during the execution, and most important of all… has a good price and profit margin for you not to care even about negotiating during the execution (if low price is not the success factor, obviously :) ).

Bottom-line of my comment: there will be times when you should not even assume or write detailed requirements, but sell a highly priced project for you to deal with an expected number of valid scope claims from the client (based on your experience), or place enough execution/commercial rules that enable you to negotiate for example. And yes… you will need Operations to understand the spirit of the won proposal.

Cheers.
Matias

]]> By: Juan Lanus http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/#comment-137 Juan Lanus Sun, 14 Feb 2010 16:56:18 +0000 http://holoom.com/?p=212#comment-137 It happens that Dilbert is following this blog ... http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/80000/1000/600/81610/81610.strip.print.gif It happens that Dilbert is following this blog …
http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/80000/1000/600/81610/81610.strip.print.gif

]]> By: shuje http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/#comment-136 shuje Thu, 11 Feb 2010 20:04:47 +0000 http://holoom.com/?p=212#comment-136 Gloria, Thanks for bringing the client perspective to the table. I'm not saying there is a measure or formula here (e.g. 50.2 grams of question per kilo of assumptions =) Good analysts find the balance. You were happy, so Fran must have done the right thing. He found the right dosage. Gloria,

Thanks for bringing the client perspective to the table. I’m not saying there is a measure or formula here (e.g. 50.2 grams of question per kilo of assumptions =)
Good analysts find the balance.
You were happy, so Fran must have done the right thing. He found the right dosage.

]]> By: Gloria http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/#comment-135 Gloria Wed, 10 Feb 2010 23:30:41 +0000 http://holoom.com/?p=212#comment-135 I'm pro asking! As a client we rely a lot in the developer and usually assume a lot. We think some things are obvious and then we are very disappointed when the result is not what we expect. I valued very much Francisco's questions witch helped me re think things. And don’t worry, then I made sure all the other proposals consider the additional functionality. I’m pro asking! As a client we rely a lot in the developer and usually assume a lot. We think some things are obvious and then we are very disappointed when the result is not what we expect. I valued very much Francisco’s questions witch helped me re think things.

And don’t worry, then I made sure all the other proposals consider the additional functionality.

]]> By: Juan Lanus http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/#comment-134 Juan Lanus Tue, 09 Feb 2010 14:40:12 +0000 http://holoom.com/?p=212#comment-134 Yes! Thus the need for a talented FA. One that can do it well at the first try. When he does not (do it well up-front) is when you need to ask so many questions, questions that undermine the Client´s trust, about things one should know: "What is a web server?" (too silly). On the opposite, some times I asked questions to make the Client know that I'm aware of important issues of their trade. Back to the point, asking questions might enhance the Client´s trust instead of undermining it, and it depends on the talent and knowledge of the FA. The worst scenario is when the Client realizes that they are educating us. Yes! Thus the need for a talented FA. One that can do it well at the first try.
When he does not (do it well up-front) is when you need to ask so many questions, questions that undermine the Client´s trust, about things one should know: “What is a web server?” (too silly).
On the opposite, some times I asked questions to make the Client know that I’m aware of important issues of their trade.
Back to the point, asking questions might enhance the Client´s trust instead of undermining it, and it depends on the talent and knowledge of the FA.
The worst scenario is when the Client realizes that they are educating us.

]]> By: shuje http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/#comment-133 shuje Tue, 09 Feb 2010 00:48:21 +0000 http://holoom.com/?p=212#comment-133 Trust can help in so many ways. In the bidding process, a good relationship with your client, can help you assess a winning proposal even before delivering it. Remember I wrote this from the sales standpoint, not the developer. :) Trust can help in so many ways. In the bidding process, a good relationship with your client, can help you assess a winning proposal even before delivering it. Remember I wrote this from the sales standpoint, not the developer. :)

]]> By: shuje http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/#comment-132 shuje Tue, 09 Feb 2010 00:46:32 +0000 http://holoom.com/?p=212#comment-132 That is indeed the spirit of the post. It's very hard to wear both hats (sales and project execution) at once. We might need a new breed of people here :) That is indeed the spirit of the post. It’s very hard to wear both hats (sales and project execution) at once. We might need a new breed of people here :)

]]> By: shuje http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/#comment-131 shuje Tue, 09 Feb 2010 00:43:52 +0000 http://holoom.com/?p=212#comment-131 It's a very valid technique Fran. And it DOES build rapport with the client. But my point is: Do it to the extent that it will not hurt your chances of winning the project. It's not an exact science of course. You need to do a lot of winging here. It’s a very valid technique Fran. And it DOES build rapport with the client. But my point is: Do it to the extent that it will not hurt your chances of winning the project. It’s not an exact science of course. You need to do a lot of winging here.

]]> By: shuje http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/#comment-130 shuje Tue, 09 Feb 2010 00:41:08 +0000 http://holoom.com/?p=212#comment-130 Marcelo, smart assumptions are definitely the way to go. However keep in mind if you assume an all-in scenario, and then some more, you will have to execute it within a competitive price. Often the price you can charge is set by what your competitors are willing to charge. Marcelo, smart assumptions are definitely the way to go. However keep in mind if you assume an all-in scenario, and then some more, you will have to execute it within a competitive price. Often the price you can charge is set by what your competitors are willing to charge.

]]> By: shuje http://holoom.com/2010/02/08/when-to-ask-and-when-to-assume/#comment-129 shuje Tue, 09 Feb 2010 00:38:05 +0000 http://holoom.com/?p=212#comment-129 Juan, remember this post is written wearing a sales hat. FA work during presales should be coordinated so as to end up with a specification that helps win the project over in terms of time and budget. Over-asking could be harmful because all clients will want whatever you suggest. That said... No doubt a more skilled FA will help in any circumstance. Juan, remember this post is written wearing a sales hat. FA work during presales should be coordinated so as to end up with a specification that helps win the project over in terms of time and budget. Over-asking could be harmful because all clients will want whatever you suggest.

That said… No doubt a more skilled FA will help in any circumstance.

]]>