Risk assessment of remote assistance project with high expectations

Question

This question is about fixed priced projects where one or more of the following characteristics are part of the project description:

1. The entire project needs to take place over a form of remote screensharing or remote desktop application (teamviewer, or other remote desktop applications )
2. The entire project is to be carried out on the client's server, where code can only be uploaded (maybe even through FTP or SFTP), there is no SSH access
3. The client specifically mentions in his project description: "Please do not bid on this project if you've never done this before" . In addition, documentation online is scarce or just absent (in any form) for the kind of problem the project is asking to solve
4. A step-by-step procedure is required as a deliverable (so documentation)
5. The following expectation is provided as part of the project description: "This should be very simple for someone who knows what they're doing"

(Item [5] seems to be a common expectation for most projects)

I recently read one project description where items [1],[3],[4] in the above list are present. The project asks for the installation of a component where the official vendor installation process is known to be either wrong, outdated or incomplete. So the component clearly does not install as advertised, and work needs to be carried out to fix, troubleshoot or debug said component (it might even require patching the code, or rebuilding some binaries).

In view of item [3] being present, to me it seems there's an expectation that the freelancer has a private ready-made solution, that's ready to go. But from my reading, it's the kind of project where in order to achieve it, it requires additional work.

Here are a few questions I have about this project:

• How do I figure out if a client is actually interested in this project, or if it's the kind of thing they don't really need or care about, but if it is available, they would be interested in it. In other words, how do I measure if there's high or low interest on their side ?
• Should I bother to explain to them that the project is more involved than they think, or just avoid bidding on it altogether ?
• Because requirement [4] is present, it would make [1] superfluous/unnecessary, yet both are present and I'm wondering why
• In view of [1], and the fact that this is not just an installation/configuration project (it requires additional troubleshooting/debugging) I'm trying to understand the requirement of using Teamviewer to do all of this. I understand doing Teamviewer meetings for an initial meeting to discuss project requirements, or at the end of a project where deliverables are being presented or tested in a demo meeting, but it seems like this is different, in this particular project description that we're talking about, all work is to be performed in a Teamviewer session. So my question here is if I'm right to assume this looks risky, especially because this is a fixed-priced project and a solution needs to be built during the Teamviewer sessions whereas the description reads as though the solution exists prior to the Teamviewer meetings
• I also find that in this particular case [5] is actually not true. If the project was very simple, then the project wouldn't have been posted in the first place due to simplicity. So I'm actually wondering about the meaning of item [5], or is it simply just low-balling ?
• My overall conclusion is that this entire project is actually meant for an hourly-rate instead of a fixed-price. Is this a fair thing to say, and if so what would be a good way to communicate that?

---

UPDATE: Some additional questions:

• If the client has high interest in getting the project done, why don't they contact the vendor that made the component from which they could obtain maintenance and support services? Maybe the vendor has high prices? It just seems like the more I read this project description, the more contradictions I see..
• Also item [3] puts the project completion date in the past, rather than the future. It makes it equivalent to the well-known tongue-in-cheek "The project needs to be done by yesterday" which means the project is already overdue before starting. This implies that the freelancer who will take this project is somehow already responsible for the project being already overdue (which if that's the case, is a false assumption to begin with) even without having had any ties with said prospective client

UPDATE: The potential client replied back stating the budget for the project is very low ( 1/17 of my quote to them ). This coincides with my feeling about the project. It's also in line with this remark about risks for fixed-priced projects. This other answer also outlines the big risks involved. I promptly informed them that we won't be working together.

Answer 1

In my experience, the only times I have made money on a fixed price contract were when I had built a solution for that problem already and I only needed to tweak it for a new client. I had to price the solution about 7 times what it cost me to tweak in order to make money. I cannot do custom development on fixed price.

Clients like fixed price. They want to know what it will cost before hand. Clients have the same problem with estimating costs that junior programmers do with estimating how much time it will take to do it - typically estimating only 10-25% of the actual time and costs.

The problem comes from a client who has had strong opinions about the cost and was burned by someone going way over the initial estimate. What you describe is typical for such a person who is trying to control their costs.

We cannot measure the prospect's real interest. All we can do is to state how we will operate if hired and let them make the decision.

Personally, if I saw a post like this on a freelancing job board, I would pass on it as "this client will be too much trouble for me to enjoy working with". I want a client who is able and willing to spend what ever it takes to solve the problem.