Have you ever purchased a new house, only to later discover that the contractor cut some corners? And that buck or two savings for the contractor now translates into thousands of dollars of extra cost for you? Unfortunately, many website developers have taken a page from the building trade, and are cutting corners as well. Clients who only see a shiny new website – or a lower bid price – will never know until it’s too late.
After building 100’s of sites over the years, and repairing just a few too many cut corners, we’ve seen just about everything. In this two-part blog post, we’ll explore two key questions: Why do they do it – and what can you do about it.
Four key reasons developers cut corners:
1) The developer is under extreme pressure to bid the project at the lowest cost possible. Competitive RFPs and policy-bound purchasing departments, for example, always reward the cheapest bid price: this means that work effort must be squeezed out of the project somewhere in order to even appear “competitive”. Mitigation: buyers (and purchasing departments) must work more collaboratively with web developers before the selection is made – and become more educated about the web development process. While price is clearly important, it must be evaluated from a “total cost of ownership” perspective: the project cost is not just a function of the build price.
2) The developer is inexperienced (or shifty). In this situation, the developers are ignorant of (or ignore) certain time-consuming development tasks, so the work-effort for these tasks doesn’t even factor into the project budget. For example, developing the site to reduce the client’s ongoing maintenance effort, or adding robust security, may not even figure into the project plan: corners are cut through ignorance. Even worse: unethical developers who purposefully omit key parts of the development process to produce a budget that is initially lower, but will be increased through a later scope change. Mitigation: Examine the assumptions used by the web developer, especially if there is a wide cost range amongst competitive proposals. It could very well be that the most expensive proposal is actually the cheapest. (Or, that they may be the best partner, but their assumptions are out of sync.) Ask references about work quality and responsiveness, particularly near the end of the project.
3) The developer wants to improve their margins. The less work that gets booked on any given project, the higher their profitability. Profit isn’t actually a dirty word: it pays for recruiting top talent, training, investments in technology, and rent. Mitigation: Check out their offices, and consider whether their “gold-plated” facilities are why they need to have excessively high margins. If you’re willing to shoulder the risk yourself, pay for the work on a time-and-materials basis.
4) The high cost of responding to an RFP (Request for Proposal). Onerous RFP response requirements, contractual terms that are completely one-sided (and must be agreed to as a condition of submitting a response), and RFPs that are sent to dozens of potential suppliers, all set up a future relationship where the web developer must somehow find a way to recoup their proposal response investment – not just pay for the work done on the job. Mitigation: Flip the selection process upside down: conduct screening interviews over the phone (and by reviewing potential suppliers’ websites), and then send a much simplified RFP to a select pre-qualified few. Reducing the cost of participating in a bidding process (and improving their chances of winning) sends a clear message of partnership, and allows for more substantive conversations throughout the selection process. More importantly, it sets up a relationship that doesn’t promote short-cuts.
This week’s action plan: Are there factors in your purchasing process that encourage cutting corners? If so, how might these factors be removed for your next project? Finally, an offer: if you are considering a selection process, we would be happy to share some additional insights on how to structure the process. Please reach out: 416-256-7773 x101.
Next week’s action plan: Trust but verify. Read next week’s post on 15 ways web developers cut corners, and how to protect yourself against them.
Editorial comment: We have seen some RFPs that contain clauses that border on the ridiculous, and do no credit to the organizations that have sent them out. From an RFP that we won: the supplier must take out general commercial liability insurance naming the client on the policy, and that the policy must be in place for three years after the engagement has been completed. From one that we lost: that the winner commit to a ten year warranty – when the site updates after launch are 100% the responsibility of the client… and the expected life of the site is only 3-4 years. Each time we participate in a selection process, we do so knowing full well the investment that we will need to make, and that the process, imperfect as it is, is the process we will need to follow. This post (and the next one) have been written to improve the outcome of a project, both for web developers, and their clients.
