"Can I adjust my feature set and specifications as we go?"<p>Client: "Now, this TODO list app is great, but we want something more like Facebook and Linkedin combined"<p>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.<p>"Can I meet and work directly with the designers and developers on my project?"<p>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.
Some of this is awfully bad advice - why is it useful to work directly with multiple designers/developers rather than a single point of contact/project manager? isn't this pushing the project management onto the clients side?<p>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?
This comes across as quite naive.<p>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?<p>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?<p>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.<p>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.<p>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.<p>[1] <a href="http://en.wikipedia.org/wiki/Ute_(vehicle)" rel="nofollow">http://en.wikipedia.org/wiki/Ute_(vehicle)</a> (reference for non-Australians)
Ownership of the source code is a stupid thing to want. It means the developers will have no interest in making your code any good (they can't reuse it) and unwilling to incorporate code they own into the project rather than reimplementing everything from scratch.<p>Complete access to and an unlimited, unrestricted license to make use of is probably what you want.<p>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 <i>love</i> our codebase, and now we love it even more because we'll be able to use it on future projects.
When I was consulting as a contract cto for a startup they were pushing to hire a us consultancy that was outsourcing to China. So I had the meeting with the rep from the consultancy. Being a technical person that codes I wanted to be able to work directly with the developers. The sales weasel from this firm told me with a straight face that we could not do that for our own protection. Then said weasel proceeded to describe a waterfall dev process and told me that they were a agile shop.<p>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.<p>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.
I think the points raised in the five questions would mostly come up in underfunded projects. Sure, you can have everything you're willing to pay for. Especially things like<p>> Can I adjust my feature set and specifications as we go?
I've had good success with clients in letting them see the application come to life. I'll release a working something on week 1 ('something' can be very, very minimal) on a staging site and push updates to it a few times a week.<p>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.<p>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 see what you’re doing on my project on a daily or weekly basis?<p>- Can I adjust my feature set and specifications as we go?<p>- Can I meet and work directly with the designers and developers on my project?<p>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).