The decision to take on a project like a new website is daunting enough. Often coupled with that decision is another that is make-or-break for an organization, do we build the new site in-house or hire it out? There are a lot of great reasons for each extreme of this decision. There are also some real dangers for each. I have to admit, in our years of working with clients and prospects, seldom do we see an internally developed site that comes in on time, on budget and supporting industry best practices. This is not to say it can’t happen, and great if it does. I’ts just not that common. Why is that?
First a quck case study. An Internet marketing client of ours, very progressive and intelligent group, leaders in their industry and well recognized nationally were operating a 6 year old ecommerce site that had just become ungainly. Too many add-ons to the database, too many demands that were unanticipated at time of build and too many new generations of marketing people and IT had taken it’s toll. So, the right decision? Build a new site. Off the shelf? No way, too many special needs. Custom but reusing exisitng platforms, yeah, that’s an option. Bids for the new site from our team and competitors came in between $30k to $60k. Expensive? Maybe.. but for a web content management system that is customized for the exact business needs of a mission critical element, probably worth it.
For several reasons, the “build it here” syndrome, paying for services when you have staff etc… the decision was made to go internal. Result?
- If this had been an outsourced project with a forecast at the high side at $60k to the high bidder, timelined to take six months to complete and consume approximately 200 hours of the client’s staff time (say at $100k with full load). You have six months of disruption and $160k out of pocket for internal and external.
- As an internal project it took 2 years to build, consumed a full-time developer and a great deal of IT, web design and marketing team assistance and still didn’t result in the responsiveness that marketing needed. That calculates into well over $350k of internal costs and a delay of an extra 18 months in getting to market. I’d like to say that this is an exception but it is not. This kind of experience seems to be more common than you would think.
Does that mean that it is not possible for a firm to build their website internally as well or better than using an agency? No, absolutely not. Plenty of horror stories exist for the alternative path. Planning, resource selection and scope definition are needed on every project. With that in mind, either way, inside or out, there are few things you need to consider if you are planning to replace your site. Let me share.
- The first issue is to determine, “Who is this site meant to serve?” in other words, “Who is the customer?” In too many organizations there is still a turf struggle between IT and web marketingstaffs. If your website is a mission critical piece of your marketing, then I am sorry to point out that the marketing department must be the customer. (IT staffers please insert “groan” here.) The needs for content updates, product promotion, advertising and line extension has got to be where it starts. Your firm will be at a tactical disadvantage if every change, especially content changes and image changes, has to go through IT. Truth is, most IT staffs really do not want to make the changes. They just don’t want to clean up marketing’s errors. What they tell me is that: “We would rather do it than fix it.” Can the non-techy marketing team mess up a website? Absolutely, but with the right platform and training, this won’t disrupt the server side of the equation. In most enterprise focused WCMS platforms you can build in the proper level of authorities with enough containment to be certain that your content is fresh while the site maintains it’s integrity. Most also have a life preserver allowing you to roll back to a recent correct instance and just do the changes again.
- Second thought is, “What technology choice do we make?” In some cases there is no choice. Your infrastructure is in place and you will select an approach that fits. In a cloud environment or SaaS though your choices are wide open. How about, static or CMS? It has been a long time since anyone argued the value of a static site over a CMS. I think that debate is settled for any major player.
- Who will maintain the site once it’s built? That issue is sometimes, “Which CMS to use?” I personally have no issue with open source IF a firm has the in-house expertise to maintain a Joomla or .NetNuke site with redundant developers or IF you sign a maintenance contract with the agency that developed your site initially. Your call. I will remind you though that there is not a corporate body with open source that is obliged to keep your personalized code and customization in step with new releases and or required web-wide advances. Once you pull a version off the shelf then it is an obligation of your team or your development partner to keep things running through all of the changes that move the web forward. Is there a fee for that? Sure but you are either paying that fee as a service expense or payroll expense anyway. Your new site will need fixed, debugged and modernized. That’s how it is. Plan on it. If up time is critical then you need a resource. 24/7 support? Inside or outside is up to you.
- Hardest point of all, “Do we build it here or partner?” The build-it-here approach is admiarable but usually not a great argument for ROI. The other questions linger about skill sets, priorities and redundancy. The solution very well could be to perform all functions in-house if that effort does not challenge other customer centric or high priority projects. Without redundant and comparable skill sets then you have to ask, “Who gets the B team?” – your clients, your other internal projects or your new website. Part two of this question is to make certain that the bench strength will be in place in case your ace developer, artist… gets hit by the proverbial bus or a superior job offer. A sudden change in business fortune can also change your priorities. If that dreamy project for your top customer finally gets signed you may have a new dilemma, pull your web development team or hire into the new project. It happens. Who carries the ball if any of these events come to light?
- Often overlooked as well is, “Who manages the project?” someone has to hold numerous feet to the fire or deadlines fall onto a to-do list next to ‘turn in my expense report’. I have seen several projects falter because it is not the high priority of a critical task holder.
- Is partial partnering an option? Could your creative team hand off designs to an outside web development team working in an environment that your IT team has proposed? We do it all the time, and I’m sure other firms do as well. Your look, feel, branding and functionality requirements built to your specs don’t necessarily require a 100% custom back-end to still give you the responsive machine you want developed in a stable platform that IT will approve and maybe even later support. How about content and page population? Often we will build out a sample set of pages and train the client’s marketing team how to populate the rest. This combines some real hands on training with just in time creativity and also transfers the project ownership to your team pre-launch.
- Finally, remember that you are building the site for a purpose. It needs to bring traffic, develop leads, generate sales and build you brand. All of your post-launch requirements have to be in place. Can you do the SEO? Can your team determine and your developer build testing oriented calls to action? Will your analytics be built in? Site map prepared for the search engines? Having a great looking site that no one sees , or even worse, no one converts on, is not the reward for a long project like this. Who makes sure that the new site is built for driving trafffic, improving conversion and testing for improvement?
So, I’m already over 1400 words and haven’t explored all the possibilities. Just remember that as you embark on a new site, there should be a set of KPIs you hold the project members accountable for, whether internal or external. Speed to market, usability, platform stability, ease of support and marketing effectiveness cannot be written off because it was an internal job. Hold your project to a higher standard. Then decide who to hire.