I got a call a few days ago from one of the founders at Global Syons, a development outsourcing startup. He wanted me to help analyze their presales process in light of the fact that they were bumping into a number of problems during the execution of their projects. Most of them had to do with the selective interpretation of requirements on behalf of the client.
This is rarely new. Possibly the first wheel ever invented was square because caveman #1 wrote the requirements while caveman #2 built the actual thing.
In my friend’s case all problems were a direct result of incorrect requirement specification in their work statements.
There is an implicit advantage for clients when discussing the gray areas a loosely written requirement entails. As a client I hold the advantage in the interpretation because as the client I’m always right (i.e. I’m paying the bills so you better not antagonize me.) Yet, if the ground work is properly done outsourcers can shift the advantage to their side.
The problem lies not in writing and estimating the most comprehensive list of requirements when creating the statement of work, but rather a comprehensive enough list. When estimating in an early stage, more often than not, requirements are vague and there are basically two ways to reduce uncertainty: ask or assume.
The trick lies in mastering the art of deciding when to use one and when to use the other, and to not overdo either one of them:
- If you ask too much then the client will tend to add tons of new features but will not readily accept the new cost. More so if your competitors estimated without asking too much and hence presented low prices.
- If you assume too much the scope can be ludicrously small and either the client will detect it or the project will become tangled in so many change requests that it will be unmanageable.
As a for instance let’s say a client asks you to develop a registration form. You might come up with the following complexity scenarios:
- Very low complexity: Fields for e-mail address and password. Basic validations (length, e-mail format).
- Low complexity: Fields for e-mail address, password, user name, name and last name. Basic validations.
- Medium complexity: Fields for e-mail address, password, user name, name and last name. Complex validations (password strength, confirmation mail)
- High complexity: Multiple page form with all personal information (phones, addresses, credit card info, hobbies, etc) and complex validations.
You need to decide what your complexity target is in order to build a competitive proposal in terms of price but that will also allow you to execute the project properly. Once you figure it out, then you need to figure out what is the correct amount of questions and assumptions that will allow you to get there.
Whatever you do not specify as in scope, that you know the client will eventually request, will haunt you later. Be warned: Assumptions do not eliminate trouble, they just finance it. You are purposely kicking trouble forward to a time when the damage is less, or at least different.
In other words: It’s one problem to have no business because you failed to turn in a competitive proposal and a completely different problem to have a bumpy project because you have specified an incomplete set of requirements.
Once you understand that no project is trouble-free I believe you will prefer the second.
Shuje
On my next post: A raft for mice, a Frisbee, a sushi plate and 97 other good uses for your iPad. Have any good requirement stories? Comment below or e-mail them to shuje@holoom.com
The actual issue is the gap between the Client´s conceptual model and what the specifications say.
The gap size depends on the functional analyst´s work.
For example if the FA has a working knowledge on the applications domain the gap will be small, and in some cases the specifications might actually exceed the Client´s expectations. This contributes to raise the Client´s value perception of the offering.
A skilled FA will have less cranky Clients. Much less.
In practice he will need to ask less questions, and his assumptions will be more accurate.
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.
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.
Right, a skillful FA (or whoever that is covering that role during presales phase) will make a HUGE difference. As everybody knows, FA seniority is closely related to domain knowledge, and domain knowlegde is, in my humble experience, most important tool you have when making assumptions.
However, a domain knowledge doesn’t necessarily need to live IN the FA. It might be spread in different members of the team, specially in more technical projects. Again, internal communication will be vital when it comes to come up with scenarios (a very good example is mentioned in the article, by the way).
I totally agree with Juan on that smart assumptions are likely to drive projects to exceeding clients’ expectations… even though they seldom recognize it.
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.
I personally prefer to ask as many times I can, before the due date of the proposal submission. So basically every un-answered question will turn into an assumption. It’s only a matter of timing and availability of the prospect.
Asking questions not only shows interest, it also builds trust. I’ve never seen a prospect pissed off at receiving 20 questions about the business; they are happy, even more if it’s a start-up.
In the company I work now we don’t have an FA role and client’s do not complain about noticing a gap. Yet, I think presales consultants need to be an FA as a background.
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.
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.
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.
I agree with Juan that the key is in the gap between the client’s conceptual model and the specification, and this gap needs to be eliminated or at least reduced.
The point here is in the time that we need to reduce that gap, and this is why we need an FA with a deep knowledge. Other way we will need meetings and meetings before to find out the real requirements (time means cost) or in the worst case we will not define them and we will pay that during the project.
The balance between specifications and assumptions will allow us to keep down the pre-sales cost while going in the right direction to the client’s conceptual model.
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
If your relationship with the client is one of trust, always ask. Assuming won’t render any real value to the customer. The gap between the business people (customers) and the development team is bridged by continuous conversation in a collaborative environment. (how you win the bid is another issue I have no clue about though)
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.
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
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