The Old Joel on Software Forum: Part 4 (of 5)

Indecent Proposal

At the end of the day, it is: give them what they want.

So, what's a proposal? This is the third time I've been told that this client expected more of technical details in the proposal we submitted. He's willing to give it to us but he compares the technical gravity of the content of the proposal we submitted vis-a-vis competetive bidders and points out the gray area. He contends the rest of the two bidders had laid down data structures, tables and the whole <astro_speak>architecture</astro_speak> where our proposal talked at length about the the business of the client without the automated system, identified the current processes undertaken at the business of the client, segueing to how the proposed system would benefit the business, how it would be physically deployed (number of terminals, locations, hardware etc.) defined the technology in terms of tools (programming language, middle tier such as DCOM/Winsock etc.) we'd use, the underlying platforms it would run on and broad features and design goals, along with detailed schedule (tabulated as well as a CPM) and the cost of development.

What surprised me was that this was the third client who complained. I wasn't informed directly but one of my superiors put the word in my ears. We had *just one sitting* with the client, all of us bidders, in which the client described to us how their business worked, how they currently consolidated data, what their data needs were and what they wanted from us. We hadn't gone into the nitty gritties of the *actual pieces of data* that would need to be collected from the environment, those that would form the input of the computer system and the pieces of data they would need as output (reports). More than the output, the crucial thing would have been to tell us about the input, which would inturn be the most decisive in determining data structures.

Since I'd prepared the proposal, my missive was, "but this was a proposal, and not a technical specification", as I'd said on the earlier two occassions.

My dilemma is bi-dimensional:
(1) I find it, strange more than doubtful, that a bidder could prepare a database design without the knowledge of the *actual pieces of data* to be collected, since we didn't go into that level yet. We had just one meeting with the clients.
(2) More importantly, am I wrong in maintaining that a proposal need not furbish a database design, which is best left to a technical specification. A technical specification of the product or software must present the data structures out of many other low level details.

Besides, we were hardly knew much to be going there.

Brings me back to an obvious question: What's a proposal? I've written a lot many. I've written software specs too, but where do you draw the line. I have my own religion in that, which has just been questioned. What's the consensus?

PS: Not every client I've written and developed for have come back with this. Most sophisticated clients were really happy with the way I went about and I did carry out projects for them successfully. The two other occassions this happened, we lost one and got one of the projects. But this time, when I heard the words for the third time in my career, this question I had reserved in mind the last two times sprang up to the forefront of my memory.

Sathyaish Chakravarthy
Wednesday, March 3, 2004

If somebody creates data structure, architecture into a proposal he make it as part of their sales. The client usually do not know much about when it's a good time to create architecture.

The client will think that those guys are way ahead of you because after 1 meeting they can visualize the system. You cannot, but it's your problem.

You cannot draw a hard line here. I work for a company who do the same and it really works. After (or even on the first meeting) we do a lot of pre-activity, do photoshop screens, etc then the client only need to change this bit or that. Could be very effective. Especially if you put their logo on some of the screens, print in color, they love it.

Wednesday, March 3, 2004

If I remember, in _The Deadline_ DeMarco said "If it doesn't specify the inputs and the outputs, then it isn't a specification."

Christopher Wells
Wednesday, March 3, 2004

"Especially if you put their logo on some of the screens, print in color, they love it."

So true!!

Tapiwa
Wednesday, March 3, 2004

The client of my current project has three large sub-groups, and we're at the preliminary stage of determining what the differences are between the three.
"Oh, no, you can't talk yet to these guys, we'd first like you to give us an estimate of how much can be reused from one group to the other."
I quickly realized that explaining the need for gathering information before spitting out an estimate would be an exercise in futility with them, so I gave them a wild-assed guestimate and in tiny print below it "Estimates can vary by at least 300%".

Now the discussions are more interesting:
"Oh, no, you can't talke to these guys, we'd first like you to give us an estimate on how much can be reused from one group to the other."
"You have it right there before you".
"Oh. (pause) But it doesn't even take into account that Foo group has no Bar support!"
"Interesting you mentioned that, I wanted to ask you about that..."

So yes, if you recognize that this is the type of client who you'll be bidding for, definitely make a database schema drawing (in MS Paint for all you care), UML diagrams and whatnot, that'll please the PHBs to no end. Don't forget to add the little print "subject to change as specs become clearer" in case somebody who knows what they're talking about reads your offer.

Yves
Wednesday, March 3, 2004

Maybe they are fishing for a free spec? Its been known to happen!

Bill Rushmore
Wednesday, March 3, 2004

I think you all are right. They feel secure seeing some tech stuff even if they don't quite understand what it means. So it's really horses for courses. I'd expect it from this client since it's an end-user organization and the IT guys in the end-user organizations (hey, I am not pointing at you, dude, if you're in one of them. You're family. Just some of them as a ageneralization) are mostly those who couldn't make it as programmers. Mostly.

Sathyaish Chakravarthy
Wednesday, March 3, 2004

Sathyaish, you randy scoundrel you, don't be trying to proposition other developers here! <jk>

Robert Bedford
Wednesday, March 3, 2004

In the world that I work in, engineering/construction companies do designs of the thing the end user wants to be built as part of the proposal. They do the design as cheaply as possible basically as a way to make the sale.

If the get the project, the throw away the design in the proposal and do it properly.

I suggest that you do whatever it takes to get the sale including filling the proposal with mindless details, buzzwords, etc. And then do a proper design once you have the contract.

pdq
Wednesday, March 3, 2004

This is a major reason I use ORM, I can record business facts and produce a data model. Its not complete and I'd never pretend it was but it does show that I understand their business, how it works and it gives the basis of a technical specification.

Simon Lucy
Wednesday, March 3, 2004

See, the engineer in me agrees with the original poster. It's a proposal, not a stinkin' spec. Anyone who offers up an architecture complete with database design based on a single client meeting is probably just blowing smoke.

..then the business owner in me says it's not uncommon to do that because the client is likely to be "ooh'ed and ahh'ed" with a slick presentation. Even if the technical details are completely off-base.

There's nothing wrong with putting an initial technical spec in a proposal, but I'd be wary of selling it as 100% complete, wrapped up design.

Mark Hoffman
Wednesday, March 3, 2004

The goal is not to have the perfect spec outlined in a proposal.

The goal is to get the business of the client.

How do you do that ?

In building trust.

So:

- show that you know how to visualize the architecture
- show that you understand the processes
- show that you understand the domain (model it a bit)
- show that you can make a candidate WBS and planning (document the assumptions of course)

Show your thinking. This will help you in securing a good rate. And keep the competition at bay. It works for me.

Phil
Wednesday, March 3, 2004

"Sathyaish, you randy scoundrel you, don't be trying to proposition other developers here! <jk>"

"Bedford". Cute! ;-)

O did I forget to mention the million coins on offer. Any takers? Girls only please! Chea! No "chick" on this thread!! Too bad. :(

Sathyaish Chakravarthy
Thursday, March 4, 2004

Wonderful! Wonderful replies. So then it is as I thought at the begining of the thread. Give them what they want to see. And what they want to see depends on who they are.

"..then the business owner in me says it's not uncommon to do that because the client is likely to be "ooh'ed and ahh'ed" with a slick presentation. Even if the technical details are completely off-base."

What a joy. Beautiful!

Thanks, guys.

Sathyaish Chakravarthy
Thursday, March 4, 2004