It’s always tough to buy services from someone who does necessary, mysterious, and technical things — especially when it costs lots of money. Hiring a web developer is almost as scary as paying for a car mechanic, home insurance, or a dentist. You might be intellectually aware that you need their expertise (it’s what you’re paying for after all).
We want to trust the people we hire. We want to be confident that they will get the job done competently, and that they won’t take advantage of us. One way to do that, of course, is to ask them the right questions in the first place, and give them a clear explanation of what you want to achieve. These suggestions will get you started on the project — but not far beyond that. Explaining your software requirements is just the beginning of the project. To make sure that the project is a success, you need to keep your attention on three things — none of which are technical.
Expect the developer to ask questions.
To learn your needs, the developer may need to spend a non-trivial amount of time with you. Do not be offended. This is a good sign: He wants to learn from you, so he can reflect those requirements in the application he builds.
Developers are not expected to know everything about your business or department or its needs. You are the expert at your job; the developer knows her technology. To create the best possible software for you, she needs to understand how your business works — and she can only do that if she asks a bunch of “obvious” questions to learn all about those tasks.
Bringing in a specialist doesn’t mean you won’t need to have lots of conversations with the developer. But it should imply that the business-specific developer knows more about your type of business than a technology- or solution-specific developer.
Good software is iterative. Expect and encourage regular communication.
The communication shouldn’t be only up-front. Unless your software needs are very simple (and “simple” isn’t measured by budget alone), it’s likely that your project will be released in multiple phases. These might be defined by functionality (that is, “First, we’ll get the inventory system working; then we’ll connect it to the e-commerce features”), or they may be broken up with other criteria.
Throughout the entire project, you should expect that the relationship includes frequent communication. “Call it Agile, call it iterative; the labels don’t matter. The point is to collaborate with each other throughout the process, with multiple checkpoints to review and ensure you’re on the same page — from idea to requirements to prototype to functional product to finished product.
Because most software is done in phases, expect features to emerge based on the priority list you work out with the developer. Always keep in mind the business goal you set, way back at the beginning. Is that goal being met?
Get it in writing.
At some point, you and the developer will decide that you both understand what is to be done.
But in even the most trivial cases, it’s important to create some sort of a written agreement that states what the result will look like, what phases will happen, who is responsible, and the expected budget. The document might be called a “statement of work” or “software requirements” or “business proposal” but it could have another name entirely. Read it. Compare what-is-delivered against this document at every project phase.
I must repeat that: read it. If the developer presents any documentation, including a design, for review and approval, review it carefully and ask any questions that may arise. If the documentation or design is unclear, say so. Realize that approving the design is giving the final go-ahead to build the product, and changes will be very difficult to make after this point. And if it is difficult, it always mean expensive.
The design docs that the developer produces describe what he is supposed to give you in the end. Make sure that you actually check them against your needs and expectations. If you change your mind midstream, if you ask for any feature not agreed to beforehand, if you want something not in the design docs; you will have to tell the developer about it and accept that such changes may require the sacrifice of other features to meet the budget/timeline or may require an extended budget/timeline.
Both you and the developer need to be wary of new tasks or requirements that get bolted onto the original design. Expect that any change or suggestion or “oh one little thing…” will cost time and money.
The root issue in a project’s success is almost always communication and, specifically communication in relation to scope. Every project has three things — schedule, scope, and budget — that have to be managed to be a success. The high failure rates tend to be measured in the project being delivered late or running over budget, but inevitably the root cause is because the understanding of the scope was off.