Competitive Prices for Aggressive Website Designs
One of the biggest disadvantages of being in the Web site design industry is that as an industry, we're all still figuring out how things should work.
Even though the business has matured somewhat over the last decade, the practices still aren't anywhere near as cut and dry as they are in the
traditional advertising industry. Nowhere is that more apparent than in the Web development request-for-proposal (RFP) process.
In the ad industry (or construction, chemical procurement, or just about any other business that's been around for a while), the whole RFP process
is fairly standardized. Companies looking to hire a vendor for a project generally know what questions to ask so they can get the data they need to make
their decisions. Vendors, knowing that they're being asked the right questions, know how to respond in such a way that the potential clients get the
information they need. Sure, there are always plenty of creative showdowns and backroom politicking is inevitably involved, but generally everybody
knows what to expect. Because they know what to expect, they're free to expend their energies on being creative.
But when it comes to Web development...watch out! Because clients don't know what to ask, they often don't get the answers they need to make intelligent
decisions. Because the potential vendors don't get enough information, they're forced to guess, and they come up with responses that don't help the prospect.
The result? Everyone goes home unhappy, and clients end up with vendors that are too expensive, too inexperienced, too mismanaged, too big, or too small for the job.
In the meantime, all the vendors who bid on the job and didn't get it wasted inordinate amounts of time responding to something they had no chance of getting in the first place.
What to do? The answer will come from understanding—clients understanding what Web developers need to respond, and Web developers understanding the needs of their
potential clients. Better understanding equals better responses equals better matches equals happier clients. It's a simple equation that equals "win" for everyone.
So, dear client, what do we developers need from you to make sure you are comparing the proverbial apples to apples? Here are 9 humble suggestions that'll make everyone's lifeeasier:
- Budget. Yes, budget. Money. As in, "How much are you willing to spend"? In a large percentage of RFPs, there's no indication of how much
the client wants to spend or the indication is significantly off the true number. The result is a little like playing "Battleship." The developer guesses blindly as to the client's needs.
The client responds with a "Hit!" when the number is somewhere within the magical range, or a "Miss!" when it's too high (proposed budget numbers are rarely
too low). Why does this happen? Many clients have the mistaken perception that since Web development doesn't involve a tangible "product," the price is
infinitely variable and that, given a number, all developers will inflate their prices to reach that number. Baloney. Things take time. Software costs
money. People have salaries that need to be paid. You'd be surprised at how similar most companies' rates are. The only way to have an understanding
of how much stuff to propose is to know how much money the client has to spend which translates to the level of sophistication your project ultimately undertakes.
- Scope. If you don't feel comfortable saying how much you have to spend, at least take the time to sketch out the scope of the project.
To use the old hackneyed analogy, we're like homebuilders. If you tell us you want a house, we'd at least like to know if you want a shack or a mansion. And if
you don't know the scope, that's fine, too. Make a requirements phase the first item on your wish list so that the company you pick can do some research to tell you what you need.
- Technical requirements. If your company has a religious commitment to Microsoft products, say so. Likewise, if your company worships at the
altar of Linux, be open about your preferences. If you need database integration with a certain back-end database, tell us what kind of database system you
have. It doesn't do anyone any good to play the technical requirements guessing game. If you let your potential vendors know what you need, you'll be sure to get
answers you can compare accurately.
- Marketing versus IT. Which is more important? If your IT department has the upper hand in picking the vendor based on technical expertise,
say so. If the marketing department is running the show and wants a more strategic focus, make sure that this is something that your potential vendor
knows—and one you know yourself. Self knowledge about this issue is vital in putting together the short list of vendors. Don't ask systems integrators
that focus on back-end issues to bid against high-end, flashy design shops. You'll have a very hard time comparing the responses.
- Content development. Do you plan to reuse all the content on your existing site (basically just doing a face-lift), or do you
want to start from scratch? Are you looking for a Web developer that has professional writers on staff, or are you planning to write content yourself?
- Maintenance and a long-term relationship. Who's going to keep the site up and running once it's launched? If you're planning to maintain content, are you interested
in a content management system? If you want an agency to work with you on a long-term basis, how do you want the relationship structured?
- Third-party software. Where do you stand on third-party software? Do you want custom applications or off-the-shelf solutions? Do you own
licenses for the software you want to reuse? If you don't want custom apps, say so. It doesn't do anyone any good to guess about this. If you don't mind custom
apps, do you want to own them outright or license them?
- Outsourcing. Where do you stand on outsourcing? Does the company you pick perform all work in house? Many Web companies these days
are much smaller than they market themselves as and rely on outside consultants to perform a bulk of if not all of their work. You should never work with
a vendor who outsources and let potential vendors know that in house capabilities are a condition of the contract. Make your primary vendor ultimately
responsible. Many will state they perform work in house, however visit their office to verify it for yourself. Do they have a policy on outsourcing?
- Know thyself. Finally, take a good hard look at your company and make sure that you communicate any idiosyncrasies that
you may have. If you know that any development process will involve a lot of time in committee meetings, don't be afraid to say so. If you know
that certain key dates have to be met (board meetings, conferences, etc.), lay them out so that you can get a development schedule proposal that works
with your dates. You'll end up with responses that address your issues and schedules that work with your key dates.
Follow Us: