Non-Technical Questions To Ask When Hiring A Development Firm(blog.mojotech.com)
blog.mojotech.com
Non-Technical Questions To Ask When Hiring A Development Firm
http://blog.mojotech.com/post/38636893783/5-non-technical-questions-to-ask-when-hiring-a
29 comments
Actually the only answer to feature creep regardless of project size is "we'll get back to you with a new quote". Simply because you dont know how much effort is involved on the spot.
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.
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.
I've been handling offering flexibility in fixed big projects by sharing my Pivotal Tracker story board w/ feature estimates and letting them choose which features to axe to get their new priority scheduled.
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.
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.
I'd consider it a positive thing if a client asks if they can change specifications mid-project. I could explain to them how the price will also need to be flexible and possibly talk them into doing the project using an agile methodology.
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.
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.
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?
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?
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?
Exactly. At one of my previous companies, every time a client was allowed to bypass my project manager, it ended up doubling my workload and cutting in significantly to my development 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.
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.
This comes across as quite naive.
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)
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)
People increasingly do ask these sorts of questions of lawyers and especially doctors. It's an inevitable march based on access to information. Informed customers are a good thing; it forces professionals to stay on top of their game to survive and enables transparency as you mentioned. Some number of micromanaging customers are also inevitable; perhaps the goal is to bring in enough business to fire the bad customers?
The article actually advises clients what questions to ask, and this advice is appropriate, because a client that is reading this kind of article in the first place is probably tech savvy enough to be involved in the development process. I've once even worked with a client with more actual technical and programming experience than we had, but they simply outsourced the work to us because they had too many concurrent projects and they also just moved up the food chain. Just dont try to do things by the "one-size-fits-all" mindset. Even having a legal guy to make very personalized and very different contracts for different clients is good if you can have it this way.
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.
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.
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.
Ownership of software is, as said before, not what you actually want.
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.
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.
Well said — non-compete clauses etc. all make sense, but insisting on owning everything per common law is actually counterproductive.
Why would you slack on writing good especially if you'll be handing it off? Once it's theirs they can do whatever they want with it including showing off your shoddy work. Even if the project is successful, it's unlikely they'll come back to you with more work in the future.
In practice, software is assessed by its functionality not its underlying quality. This applies in spades to the target of the advice proferred.
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.
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.
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.
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
> Can I adjust my feature set and specifications as we go?
> Can I adjust my feature set and specifications as we go?
Most project budgets for SMEs and startups are guestimated by a business development team, therefore underfunded.
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.
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.
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.
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.
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.
"Work for hire"? .. no thanks
Current court president states that WFH rules under the USC does NOT apply to most software works.
Correct. That's why a contract mentioning WFH should include a clause that if this work isn't considered a WFH, then there is a rights assignment.
What is your objection to having the work deemed work for hire?
It gets sticky depending where you are, but the sort of copyright law that works for commissioning marketing materials is a lot different than the sort of arrangement software developers should be looking for. You can otherwise get in a position where you're not able to reuse your own code across multiple projects.
What are the chances you're writing a piece of software that is so useful and cross project that you're not releasing as open source or a Gem? I don't think 37Signals would be doing any better today if they had kept Rails to themselves. You can worry about this mythical case but it's incredibly unlikely to happen and will more likely hurt your ability to do work.
No need to deal in probabilities, just use an MSA that makes sense--it will cost exactly the same amount as one that doesn't.
How so?? I see no issues with that at all.
If you need a "yes" answer to all or most of these questions, you should be hiring an in-house development team.
Is hiring a development firm the best option?
- Can I see what you’re doing on my project on a daily or weekly basis?
- 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).
- 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).
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.