We have a client with whom we have a relationship of delivering proofs of concepts only. But when it comes the time to demo they expect an early version of what would be the solution. They want databases populated with real data, look-and-feel of a finished product and other things (including features) which are trivial and no way contribute towards proving the concept.

What do you do with that? How do you handle such a situation? (I'm the developer as well as the person who will be talking to the client along with other non-developers.)

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
If this question can be reworded to fit the rules in the help center, please edit the question.

1

isn't this is an Agile methodology. every step you have to have a segment ready to demonstrate.
–
krioAug 29 '11 at 8:46

1

You have a relationship with a client who has asked for actual data previously. When asked to do another POC you don't provide any data?
–
BenAug 29 '11 at 8:48

@Ben: It's a different database altogether. We populate the database with real-sounding fake entries (which hardly matters because the point is to prove such a thing can work).
–
Jungle HunterAug 29 '11 at 8:52

3

@101 sounds like you need a more watertight contract / service level agreement then so you can tell them straight out that they haven't paid for real data in the database or the coding of additional features.
–
BenAug 29 '11 at 8:55

@Ben: I'm not aware of the actual contract. Put thanks for the tip, I'll see if there's someone who can look into that.
–
Jungle HunterAug 29 '11 at 8:57

Excellent analogy. I'd say that a PoC isn't even a scale model, but more like a feasibility study. You might build a prototype to show that it's possible to meet the requirements, but at the PoC stage you haven't even nailed down the design. Still, your analogy makes the point perfectly, and opens the way to say: "Just as an architect could put running water in a scale model, we can put real data in this PoC. But it's going to take more time and cost you more money, and it doesn't seem to add much value."
–
CalebAug 30 '11 at 20:56

Who should be managing expectations here? Chances are someone should be telling the client, "You agreed to only this, so that is what you are getting," and ensuring this is acceptable. Would you expect a gourmet hamburger from McDonald's? I know I wouldn't and this is because of what brand McDonald's has spent years promoting and building. What is your company's image when it comes to this stuff and what kind of precedent has been set? If the client has done this numerous times then it may be quite painful and difficult to change now.

If I didn't see someone step in to manage expectations I would take that as a major red flag and find somewhere else to work.

It sounds like your client is trying to squeeze you and/or whoever will do the real implementation. The more your prototype looks and works like a finished product, the less perceived value there is in what the developer implements. The client can say: "The design and UI are already done -- all you need to do is to hook it up to a production server." At the same time, they'll tell you: "This looks nice, but it's only a prototype, isn't it? We can't actually use this."

I always try to make my prototypes to have a strong "prototype look" to avoid confussion to the extent possible. Recently I have started to use Expression Blend with Sketchflow, it is a great tool because it produces a UI that looks like this:

If your client still thinks that this is the final product... well, tell him "yes, it is", take the money and run! :-)