Client: "Now, this TODO list app is great, but we want something more like Facebook and Linkedin combined"
This is exactly how you get feature creep and is a really bad idea for fix bid projects. But of course it depends on how big a pivot it is and how big a contract it is.
"Can I meet and work directly with the designers and developers on my project?"
Sure, you can meet and get advice from them, but you may not work directly with them. There are some pretty crazy clients out there, and it is the management's job to keep them from driving developers insane. That is why management gets the "big bucks". They have to deal with the crazy.
People who buy things from you know how to screw things out of you as a rule and this is a well known tactic usually disguised as ignorance.
In addition I've also been offering a fixed amount of "freebie points" for 'not yet discovered features'. That helps define that yeah, I'm going to do a couple extra things not defined in the scope, but it's fixed amount and when you've used them up, there's none left.
That's one thing that's difficult with fixed bid projects is that you often have to resort to BDUF with client sign-off on everything in order to protect your own butt. Even though agile may be much better for some projects. Clients are understandably squirrelly about open-ended prices.
As a developer do I really want the client being able to dominate all my time when I have multiple projects on the go at the same time?
Even worse, some clients would try to get me to agree to things (e.g. "minor tweaks" at no additional cost) that really weren't up to me to decide, sometimes after the project manager already told them no. It always put me in an awkward position, making it even harder to get my actual work done.
Why is it that people see software developers as tradies? As plumbers who drive around in a ute[1]? As guys you look over their shoulder while they fix the drain when they're in your house?
When you hire a developer you're hiring this person for their knowledge and experience, much like when you hire a laywer or when you go see a doctor. Would you ask these questions to lawyer or a doctor?
A lot of clients are simply not capable of working like this with their developer. For this kind of transparency a client needs to have certain knowledge and experience about the development process. If they don't, they will simply be a nuisance and they will make everything much more difficult.
E.g. I build websites for a living. The amount of time that I've wasted over the years dealing with clients who were going to reinvent how to navigate a website is simply astonishing. As an expert I know what is right for their website but will they take my advice? Of course not. When clients are involved in your project on a micro level they will be in a state of mind where everything in new to them so every decision is a new discovery that needs to be analyzed. When all avenues have been discovered they end up at what you suggested to them in the first place.
My advice. Unless your client is savvy enough to be involved, keep 'm out of the development process and black-box everything as much as possible.
[1] http://en.wikipedia.org/wiki/Ute_(vehicle) (reference for non-Australians)
Complete access to and an unlimited, unrestricted license to make use of is probably what you want.
To give a wonderful counterexample — the project I'm working on right now is Federal government. During a recent code review we discussed standard headers for source files (it's all JavaScript) and the client said "we'll want to make it all public domain, since this is the work of the government". We love our codebase, and now we love it even more because we'll be able to use it on future projects.
The reason isn't necessarily that people won't do a good job. The reason you don't want it is because it is (should be) a lot more expensive to 'own' the copyright to the code.
A programmer who, for example, uses Ruby on Rails, will most likely not write just one application, but multiple applications in Rails, using a lot of the same code in most of them. Think things like user management, etc.
If you, as a customer, 'own' the software, he suddenly can't use things like `<%= render 'user_bar' %> or something anymore, he will have to rewrite it for every client. This is nonsense, because you don't WANT to own this bar. On top of this, you shouldn't want this because you want a programmer who can deliver high-quality code quickly. So him reusing his best code between clients is what you want him to do, not reinventing the wheel every time.
What you ACTUALLY want is to own the application, the problem that it solves, not the code. The success of an application is not (just) the source code, it is the problem scope, the design, the concepts behind it, the way it performs, the usability, etc.
What I'd want as a client is for my programmer to not resell the same app to someone else in the same industry/competing industries. What do I care if some programmer uses the same trial account code in 20 different apps? As long as he doesn't sell others the same product I am ok with it.
On top of this I want to be able to use the code I get however I want within my own scope. I should not have the right, without paying extra, to sell the code to people outside of my industry. I do want to have the right to sell the whole company however, or the part of my company that 'has' the code.
I strongly recommended to this firm not to hire them and had a lot of long frustrating conversations about why. The kicker was that the snake oil salesman was trying to get the sale by offering a moneyback guarantee. The price he was too low and too good to be true. In the end I fired this customer.
At the end of the day you need to know enough to know what is happening. If you are in a startup you need to be able to communicate your vision to your developers. And if you pay peanuts you get monkeys.
> Can I adjust my feature set and specifications as we go?
You'd be VERY lucky as a firm to be communicating with a technical, who has an actual idea about scope and the time it takes to iterate a "small feature", if they're coming to you for a project.
If you can do this, it takes a world of anxiety off the client. Their biggest fear is that despite everything you are saying, their project isn't really making progress. Such a high percentage of software projects fail; fear of investing money and the project not being delivered on time and on budget will be in the back of their head.
The way I am able to push out regular, small updates (and not push crashes to staging) is by using BDD on each new feature so that I can pile up new feature development without getting majorly sidetracked by regressions or getting majorly delayed by diving into writing some major application code that's not directly solving the present feature.
- Can I adjust my feature set and specifications as we go?
- Can I meet and work directly with the designers and developers on my project?
This is called Agile development. If you are not doing Agile in web or mobile project, you are doing it wrong (some exceptions might apply).
