 Welcome to TechSoup Talks. This webinar is about how much did a website cost? We'd like to thank GradyTalk for sponsoring this webinar series. And I'd like to introduce Alan Gunn, the Executive Director of Aspiration. Welcome Gunner. Thank you. And can you tell us a little bit about Aspiration and what you do there? I'd be delighted to. Aspiration is a nonprofit organization, and I'm going to actually jump ahead two slides, get a little out of order here. Aspiration is a nonprofit organization whose mission is to see better software created for nonprofits and to help nonprofits make more effective use of technology. And we work with all stakeholders in the nonprofit software ecosystem. So we work with developers, with the folks that implement and deploy the software, and most importantly with the end users to understand gaps and to help to build capacity. We love to do strategic consulting, both with people creating tools, trying to help them target those appropriately, but also with those trying to adopt tools and helping them to create sustainable processes for adoption and for long-term success in their use of technology. We love to train and mentor folks in a range of nonprofit software skills, and we are best known for running very user-driven collaborative technology events. We run tech events where the user is king or queen or other royalty, and the techies are invited to shut up politely and listen. You can find out more about us at www.aspirationtech.org and we love to chat. So if you've got questions or in any way, anything we could be useful to you for, please feel free to give us a ring. Great. Thank you very much. And I just want to quickly thank Becky Wiegand and Susie Gishpo for monitoring the chat questions. During this webinar if you have any questions submitted via the chat, we'll either answer them immediately or hold them to the very end. We have about 15 minutes for Q&A at the very end. So again, I'm Kami Griffiths and I'm the Training and Outreach Manager here, and I'll be facilitating this conversation with Gunnar so quickly. Gunnar, why don't you go through the agenda today? Sure. We call this what should a website cost, but there's a larger arc of discussion to get to the answer to that question. So we'll start with an overview of what you might mean by doing a website. We'll then talk about how to really make sure you're getting all the inputs in your process to make it successful. Then we'll talk about questions to ask, where to start, and what to do once you've started and how to move it forward. We'll talk about best practices for how to actually engage the people that will do your website, presuming you cannot do it in-house, and when to get them involved. We'll talk briefly about the relevant technologies. Aspirations certainly have strong opinions on what are the most appropriate website technologies, and I will be glad to dish my strong opinions on this webinar. We'll also talk finally about what I think folks might have actually signed up to hear, which is what we think are appropriate rates and prices and costing models for nonprofit websites as well as what we consider to be the most common cost escalators. And finally, we'll talk about the staff time commitment because that is one of the hidden costs when organizations go to budget for doing upgrades to website designs and deployments. Great. So let's get started. What are we trying to get done? Right on. Well, there are several different things you might need when you say we want to do a website. In a perfect world, you are working tabular rasa and getting to build a website from scratch. You have no legacy website. You have no legacy data. You have no legacy development shop that's not happy that you don't want their website anymore. Just as often, you are dealing with an existing site that you want to take to a new place, and there are sort of two extremes there. In a perfect world, if you've used a good content management system and a good templating system, you can often layer a new look onto existing content at a not large cost level. But often, if you are really moving your website forward, you need to do a complete overhaul of your existing site. So as you think about sort of where you fall on this range of completely redo, I'll go back to fresh website. That's an important determinant on costing. The common factor across the spectrum is that costing will graphic design that is the widest variant in websites because different organizations describe different amounts of quote-unquote value to the quality of the graphics associated with the organization, to the amount they invest in branding, and so forth. And the bad news is that overhauls, you know, a site upgrade can often be more expensive than doing a whole new site, in part because you are dealing with legacy content, legacy data, and integration with other legacy systems. So these are sort of important questions to know the answer to before you move forward. So when you are ready to move forward, who should you involve in the process? One of the things that we like to say, and it's a truth that just bears itself out repeatedly, technology projects in general and web projects in particular are organizational development opportunities in disguise. Many times there is a, if you will, pizza delivery mentality with websites. Let's assign somebody to go pick up the website and deliver it piping hot to our server for deployment. And we believe that instead you want to model the website development process as a very transparent process that is visible to the whole organization. And in particular, and this is something that I think strikes people as a little bit odd, we recommend that before you really get going, you have an internal communication strategy. That might be a mailing list for anyone who is interested in the website process. That might be an internal blog or you blog about progress on the website overhaul, but make sure you have a way of keeping anyone who is interested in the dialogue knowing what's going on because one of the biggest cost escalators in website work is getting a website quote unquote designed and then having a bunch of people say, hey, I was not consulted. I can't believe I'm not represented in this website design. So best to really proactively engage all your stakeholders and front load what I would lovingly call the high maintenance discussion. That said, many organizations make the tragic error of leaving website tasks to quote unquote techies and we are adamant that that is a mistake. Website processes should be driven by people doing program work, by people that are in senior management, by people that understand the organization's communications and strategic goals, and not the techies. We love techies. We are techies. But techies do not make good websites, they make techie websites. So we strongly encourage you to get all stakeholders in the mix and make sure you know the right stakeholders are driving the process. Interview stakeholders to understand how the site should support their work. That's a very important frame again for managing cost over time. Just delivering a site that is then something a stakeholder has to quote unquote learn how to use is a much less effective strategy than understanding before the fact how the stakeholder would like the site to serve them in their work. And I mean that in terms of how is an event announcement done? How is a newsletter published? How is any new type of content put on the website and how does that fit into what we call publishing workflows? That may sound like Sancti jargon, but it's the idea that you think of the act of publishing organizational content as a sequence of steps and you understand cleanly how the website supports that sequence of steps. It's amazing how much you know. Okay, so now that you have this figured out, why do you want to discuss with these folks? Well the first thing, and this is the big part of the organizational development. One of the things we find repeatedly, and I say this with all due respect to all the wonderful orgs we work with, many organizations really don't know how to describe themselves. They really have not done an up-to-date assessment of how they describe the organization, how they describe the work that they do, and they also haven't discussed about control dynamics inside the organization. Who is empowered to speak on behalf of the organization both through an approval process but also in an ad hoc fashion? And also what is the process for approving externally published content? How many yeses do you need to get before you can send out a message or post a newsletter to the website? Those of you that work in the communications field will recognize this list of questions as a subset of what we all know to be a good organizational communication strategy, but rather than dropping the phrase communication strategy in this webinar, I just distilled down what we consider to be the essential questions that you have to have an answer to before you go out to create or update a website. And again, because this seminar is called What Should A Website Cost, we see the organizations that go into web projects that retain implementing organizations early without answers to these questions, they pay more because those implementers, those shops that do websites and do graphic design end up serving in what we lovingly call group therapist roles to help organizations figure out how they describe themselves, how they explain their work, and so forth. So we recommend organizations wrestle with this issue internally and get to some kind of a disposition before engaging external resources. Once you have a students about internally your alignment, and the fact that you can more or less agree on how the organization describes itself, and I will make the comment that in social justice circles it is very difficult to get all the people inside an organization to agree on how the organization represents itself. If you're an environmental organization, the climate people might describe it differently than the tree hugging people might describe it differently than the oceans people, even though you're all working on the same 501c3 payroll. So that said, let's hope you've got that internal alignment then you need to turn to the external questions. One of the steps many organizations do not spend enough time wrestling with is who are the primary and secondary audiences that the site is being designed to serve and to reach. And again, the classic debate that happens internally in organizations, the fundraising department thinks that external audiences should be prioritized in the direction of funders, whereas campaign and program staff think that the external audiences that are highest priority are other activists, other campaigning organizations. And depending on the organization that's having this discussion, it's a really difficult distillation to really come to alignment on who are the primary and secondary audiences. Once you've worked through that process, you really want to understand, and this is critical, what value or benefit you're providing to each of those identified audiences that's going to get them to come to your site. Because the greatness conception of all websites in all sectors, profit, nonprofit, entertainment, etc., is rare if ever is the, if you build it, they will come website. We invite people to think transactionally and first and foremost about value that is delivered to audiences that would cause them to visit the site more than once. In parallel with that, you do of course have your own organizational goals for what you want visitors to do on the site and to take away from the site, and you want to have those enumerated per audience again before you start developing the site. And last but not least, if you've answered the foregoing questions, that leads to an inventory task, which is what content needs to exist to support answers to all of the above. And we recommend, even if you don't get final versions, to sketch out that content before actually starting down the website path because the act of offering that content tends to raise additional questions about representing and communicating the organization and its work. A critical, critical step in all of this. Many people have a siege mentality in website design. They bunker down and inside the walls of the organization, they fixate on how the website could best look to the outside world, and they forget that they're a nonprofit, grassroots, social change organization with passionate external stakeholders. We strongly recommend that in any web design or web redesign process, you have a non-small stakeholder group of external audience members, people from your funder community, people from your campaign audiences, people who have attended your events, and invite them into the process and ask them to give you brutally honest, constructively critical feedback about your website plan and about the answers to all of the questions that we've discussed on these two slides. Because it's in getting that external reality check and in getting a set of eyes on the plan that are not, if you will, within the organizational reality distortion field that you can really get to some real clarity about how best to convey the organization and its work when it comes time to roll out the site. Excellent. So now, with all of that information, which in and of itself is a huge task, once that's been gathered, what's the next step? Well, this is what we call the fairy tale slide. This is the slide where it would be perfect if things actually worked this way. But in all seriousness, we recommend that organizations try to get as far through this set of steps as they can on their own before engaging external help. But as we say in the final bullet here, at some point in this list, you will realize unless you are yourself a very technical non-profit, you'll realize that you want to bring in external help. So step one is to answer the internal and external questions that we just enumerated and in short, to know your overall goals for the website that you are creating or upgrading. The next thing you want to do, and this may sound like fancy language, but anybody can do it with a piece of paper and a pen, is to sketch out what is called the information architecture. That's fancy language for what does your top level site navigation look like. There's probably an about link. There might be an our programs link. There might be a take action link. There might be a visit our gallery link. But you as an organization want to take a first pass at guessing or sketching out what you think the organization of your new site might be and start, again, marshaling content to support that vision. You think of it as a work in progress. You know that it will change, especially when you engage external implementers, but you want to go into the relationship with the external implementers having a disposition, having a context, having an attitude about how you think it ought to be done and a readiness to be counseled and encouraged to evolve that vision. One other concept that we think organizations should really, really do before they get down to the business of implementing their website is to draft what are often called user stories. And these are just very short one or two sentence descriptions of how members of each intended audience will use the site. And so you might have an audience called General Public. And user stories would say General Public Member can sign up for email alerts. General Audience Member can donate money. General Audience Member can browse upcoming events. And by enumerating these in terms of actions that users of the site can take to achieve some value or some outcome, you really get to a user focused sense of what you're designing. So instead of thinking of your website as a big old electronic megaphone, you think of it as some sort of an information vending machine. You think of it as some sort of a resource that people coming to your website will expect to find things of value or of utility to them, and you design a site around these user stories. And one of the sort of normalization tasks is to make your user stories correlate with the information architecture that you have defined, with the site navigation and site map layout that you have defined. If you're feeling ambitious, if you have a sensitive artist on staff or if you just like playing with pen and paper or electronic draw programs, you can sketch out wire frames which are simply blocked diagrams of how you think your new homepage or your new second level pages might look. And these can be rudimentary, but again, as an organization before you've ever paid a technologist a nickel, you can start sketching out what you think you might want your website to look like. And again, it's a work in progress. It's input to a larger model, but taking the time to do that work before you engage external consultants at rather substantial hourly rates puts you in control of the process. But as I mentioned at the beginning, somewhere in this idealized website preprocess, you get to a point where you're like, you know what, we need some external help, and that's when you need to move on to the next step. Okay, great segue. What's next? What's next? Well, we're big fans of writing RFPs. And I apologize that I didn't expand that acronym, but I was almost out of space on the slide. And RFP stands for Request for Proposal. And what you do with a good RFP is you provide essential information to someone who might potentially offer you services. So certainly it's good to put in background on both the organization and the work that the organization does. Explicit definition of project goals. We encourage people not to have your project goal be do a website. That's a fairly vague goal. So coming up with more explicit goals is really, really useful. We would like to launch a new website that allows our activist audiences to communicate with targets to really let them know how they feel on important issues. That's a good example of a goal. We would like to create an interactive website that allows our online community to help us shape our programmatic focus. That's a good idea of a concrete goal. You want to put those in your RFP. Then, if you're believing what we've said so far, and you've done your homework and you've answered those rather daunting questions, both internal and external questions, you want to provide a distillation of what we know so far. You don't want to be verbose. You don't want to include every wireframe sketch. You don't want to include every user story. But you do want to give a succinct summary of what is known to date about the project. And from there, that's a nice segue into saying in your RFP what explicitly desired deliverables and needed services you are seeking help on. What would you like the person responding to your request for a proposal to provide you costing and other information about? We are big fans of short and clean RFPs. We have seen many 50-100-page super verbose RFPs. And because we work with all the stakeholders in the spectrum, we know that likelihood of response is inversely correlated to length of RFP. Rare is it that a large number of organizations will beat a path to respond to 100-page RFP because it is simply overwhelming task with a relatively low probability of return on that time investment. In other words, I take the time to respond to 100-page RFP, and I don't get the gig. That's a lot of time I wasted. So we recommend an iterative process where your RFP puts the essential information out there. You get that out to people to give you estimates, and you drill down on the details from there with the people that seem most promising rather than over-publishing in the first phase of putting out the RFP. Great. So once it's ready, where should it go? One of the things, and this is again, we model virtually everything we advise around community-oriented processes. And so the first thing we recommend you do with an RFP is not to show it to implementers or vendors, but to show it to peers, show it to board members, show it to organizations like you, show it to, quote-unquote, web people that are friends of yours, and get them to reality check it. Is it clear enough? Is it clear what you want? Is it clear what you know? Is it clear what you're wanting done? These are the kinds of questions you can ask your external allies to validate and vet for you before you slide it across the table. In parallel with that, we recommend a social network approach to finding vendors. Ask your allies. Ask organizations like you, friends that you meet at the coffee shop, anyone that is in a related field where this kind of implementation work might be something they have experience with. Ask those people who they use, and are they happy with those people. In addition, you can use relevant mailing lists. If you are on a mailing list around your areas of practice for your nonprofit work, you can post the question there saying, who has had a website done lately that they really liked the work and would recommend the vendor? You can also use Facebook and Twitter. These are fantastic uses of Facebook and Twitter. Update your status to say, looking for a great web development shop who has got some recommendations, or tweet the very same thing, but use your networks, both real human networks and online virtual networks, to seek out vendors who have already developed a reputation in spaces that you travel. From there, the number is arbitrary, but we think a good first pass is to select two to four vendors that you directly engage, and find two to four vendors that you can give the RSP to. Some will say we are too busy, some will say it doesn't look like a fit, and you don't even get to the step of giving them the RSP in earnest. But go ahead and look for two to four vendors that will take a serious sniff at your RSP and ask them for short, clean responses. With the idea being it's not really good for them in our opinion to make a vendor over-engineer a response when you're probably not going to use them or when the odds are 1 in 4 that you will use them. So we recommend a model that says get them to give you a short 3, 5, 7-page RSP response. And as you look at those, you can figure out which pairs you might want to drill down on and get more detailed costing, but it lets the process go faster and it's more fair to the vendors to not have them over-preparing documents that you will not in the end compensate for creating. Good vendors respond initially with questions, and those questions put out your intentions and let them give you a more precise response. And as we've mentioned before, for experience with orgs like you, look for vendors that have worked with other nonprofits, you never want to be somebody's first nonprofit website date. That's a bad call. So you want to work with people that have done nonprofit websites, understand nonprofits, understand how things roll in that regard. And we recommend that instead of people are often like, we would like a Drupal shop. We would like a WordPress shop. Our recommendation is pick a relationship. And that is to say work with people that you feel comfortable and feel strongly about, have a good trust vibe with, and let that inform your platform decision because while it's a complex interplay of those two factors, it's the relationship that you really want to make sure is functional. Because when you pick a vendor, you are picking a long-term ally, whether you like it or not. Okay, so once you've picked someone, what happens then? Well, it's critical to agree with them on what process milestones look like. And so this is kind of a super set, and I'll just move through this quickly. If you're doing a fancy website, and by that I mean it has interactive features, it's actually more like a web application. You are in some way creating interactive values for the user like letting them find toxic waste sites in their zip code, or letting them submit their dietary habits and telling them how green their diet is. That kind of interactive functionality requires some system architecture work. And strictly speaking, it's outside of the scope of this webinar, but I mentioned it for completeness. Most of the time, once you've gone to an implementer to create a website, you will start with the creative design process. What's this website going to look like both graphically and in terms of the site map, the information architecture. From there, you complete your overall site design. You know what you're building, you have a sense of what the pages look like and how they are organized. Then you move to implementation and deployment. You actually have the implementer code this thing, and they actually put it up somewhere where you can test it and test it a lot before it goes live. As you are testing it, you are also doing what is called content placement or content migration, where you're putting the content into the pages that you want on the site. And we strongly recommend that that be a task that is done by the nonprofit, not outsourced to the vendor. It drives cost up to have your implementer populate your content, and having your staff populate your content is a fantastic way to have your staff learn how to actually operate the website before it goes live. And last but not least, never forget the training and the support. Any implementer that does not include training in a response to an IFP, that's a red flag, because if they don't include training as explicit stuff, they really don't understand what it means to be a successful handoff. And know what their terms of support are. Do they have a monthly inner fee? What is their hourly support fee? How is support handled? You want to get that conversation had before you launch. So that is an idealized process, and we mention it because when a response to an RFP comes in, you want to see these milestones called out in the RFP. Excellent. So what would you recommend for managing the ongoing relationship? First and foremost, websites rarely turn out the way you planned them in the beginning. So we think one of the most critical factors to managing cost is that they really well-defined change process. And we wrote here, verbal is not such a one on purpose. Many people think they can just make a phone call and say, hey, you know what, we decided to add a new part of the website called background info or archive. Can you just add that to the template? And the vendor or the implementer will say, sure, no problem. If there is not a time and cost estimate document exchanged, describing the new features and describing associated cost increases, you've made a big boo-boo because you're going to get a bad, bad surprise when the invoice comes and that archive section costs you extra thousands of dollars. So the two things you want are any time you change the original plan, you want to get time and cost estimates immediately before authorizing the additional work, and you want your vendor to notify you immediately when cost overruns are occurring. We really encourage people. There's an insecurity syndrome with nonprofits. They're like, well, we're not technical. And we kind of feel awkward asking dumb questions of our implementer or of our vendor. Do it. Ask questions. Tell people about your confusion. Convey to your vendor that you want to discuss things. We really encourage you to talk before walking because once the implementation process has started, once the website has rolled out, you are in a rather difficult to break vehicle and you really don't want to start that thing rolling down the hill until you really know where you're pointed. So when in doubt, let it out. Ask questions. Convey confusions. Make sure you understand what your vendor is telling you and make sure they speak to you in your language. Vendors who speak in technical language are vendors who should not really be retained by nonprofits. That's a strong bias that we have. A vendor that cannot speak to you in your vocabulary is not a desirable vendor. And last but not least, we really recommend granular billing and granular invoicing as another way to manage cost because you want to know what you're getting charged for as it's happening, not in some nasty surprise at the end. And if you're doing granular invoicing and granular billing, you're seeing their billing patterns. You're seeing if they're billing you for things that didn't appear on the original proposal and you're able to address that early in the process and to put a stop to that or to at least write that off as acceptable before it gets to be a big cost escalator. So now let's talk about the actual technology that you're recommending. Right on. And this is where we get into our extremely opinionated persona. There are many different technologies that you can use to publish a website. And the answer to which technology you should select is a very complicated and very personal decision for each organization. That said, we have a completely overarching, completely awkwardly overly general statement which is we genuinely believe that when you have the option a nonprofit should always use an open source content management system. Now I say always in quotes because if you are a 100% Microsoft shop and you've got SharePoint and Exchange Server and every other piece of Microsoft real estate running it's not quite as obvious a choice to go with an open source content management system. If you have legacy systems that dictate your choices that will also constrain your ability to make quote-unquote the best choice. But we genuinely believe that the best of breed web publishing platforms are the open source tools like WordPress, Drupal, Joomla, and Plone. They are state-of-the-art. They are as good as anything out there. And you have the best long-term flexibility when you go with a robust open source tool that has a very vibrant community. And especially these four platforms that we list all have extremely vibrant nonprofit communities associated with them. You put yourself in the best position for long-term flexibility. When you go with a proprietary vendor, when you go with cold fusion, when you go with a custom platform designed by your implementer, and by the way that's a worst practice, never ever ever ever do a website in 2009 or later on a custom content management system maintained by the vendor. That is code language for please put me in a hostage situation and hold a gun to my head. I like it that way. So we really, really encourage you to know that your technology decision is a marriage relationship and you need to plan for breakup, divorce, or other relationship evolution. Additional points on that, you want to minimize any custom code you create. There's always a temptation when you do a website to add a bell or add a whistle. Don't do it. Show restraint. Any custom code you create drives up costs, most especially around maintenance, upgrades, and future migrations. Avoid any technology with a lock-in contract. When I hear that people like Cantera make people sign multi-year contracts, I get all hot and bothered and my face turns red because any vendor that wants to lock you into a contract is a vendor that does not have your best interests in mind and does not have the confidence in themselves to know that you will renew of your own volition month to month. So avoid any technology that has a long-term lock-in contract. And like I said, have that divorce conversation. Have a pre-nuptial agreement in place. If I can burden the metaphor, know your migration options in advance. Ask your vendor. Ask your implementer. If this is not the right platform for us in two years or X years, what are our migration options? Have those breakup conversations before you sign the contract and understand what your options are before you get into a technological cul-de-sac. You are too funny. Okay, so what should we expect to pay? Okay, here's the good gossipy stuff. And just so you know, aspiration spends a lot of time surveying costs in the nonprofit marketplace. And so we really, really, really like to ask people what they've paid for websites and what they are planning to pay for or what they're planning to charge in the case that they're a vendor. So okay, somebody's got a phone ringing on this call. And if you were in the same room, we'd give you a virtual nougie. So anyway, what kind of site are we talking about? So there are many different kinds of websites. And so the numbers I'm about to quote are based on the following site profile. It is a simple site, what we lovingly call Brochure Wear with a growth path. An electronic online brochure version of your organization, but a platform where you can add features and add functionality as the site matures. So let's imagine 25 to 50 pages of content, an email sign-up feature so that on every page people can provide an email address and get email updates or email newsletters from the organization. The site has an online donation feature so that people can give money using credit card or PayPal or whatever, but that there is minimal additional interactivity. So the site doesn't let you find toxic waste sites in your neighborhood. It doesn't let you calculate the greenness of your diet. It just tells you about the organization and lets you donate and follow the organization, maybe has links to your social network websites as well. Critical aspects are that this site, the one that we're about to talk about should be maintainable by organization staff using just their web browser and maybe an image editing tool like Photoshop or Picasso. And in addition, site traffic statistics should be produced by the site that is deployed. And that's a very important thing to make sure is agreed upon at the beginning. You can use many free tools like Google Analytics to do site statistics, make sure that's part of the delivered package. So as I said, this is brochureware with a growth path. Let's talk about what that might cost. There we go. So costs vary widely, but we know people that can absolutely do very basic WordPress sites for $500 to $1,000. These are people that do it cheap because they are in value solidarity with nonprofits. They are not making any money at these costing levels, but WordPress has become such a fantastic entry-level platform and any organization thinking about deploying an initial website should take a long look at WordPress because it is very cost-effective and very high-functioning. But a rudimentary non-ugly WordPress site based on a predefined design template, based on a template that comes from the WordPress library of templates can be had for as little as $500 to $1,000 if you know the right people. That said, the main answer to the question of what should you expect to pay for this brochureware website, $2,000 to $10,000 is the cost in 2009. And this is based on dozens of data points. We ask this question at every event we do. We ask this question every time we talk to a vendor and consistent the price range we get back is $2,000 to $10,000. About $10,000, the brochureware site that we just described, make sure you know why it costs more than $10,000 because it probably shouldn't. And if you are paying above $20,000 for anything resembling this, guaranteed you should be raising red flags because you are paying for somebody's reputation or for the fact that you haven't gotten enough responses to your RFP. That said, the great disclaimer is sweeping cost generalizations is that what you invest in the graphic design, what you invest in your branding treatment and in other graphic elements such as your page design, your logo design, image selection, color selection, font selection, the overall visual feng shui of your online identity, that's the biggest cost escalator in these numbers we've seen organizations pay $10,000 for a website where over half of that was graphic design cost and only $5,000 or $4,000 was actual implementation and deployment. Your mileage is guaranteed to vary. There are many variables that can make these numbers not valid but I put them up there with some confidence because of the number of data points that we've surveyed over the last five years. Okay, so now let's talk about cost escalators because this is where you get outside of those numbers. If you have to do integration and you often have to do integration, that's going to drive up your cost. If you want your website to talk to a CRM like Salesforce or Democracy in Action or Citus CRM, that's going to add some costing to this and that costing can be on the same order of magnitude. A good integration with a CRM can cost thousands and thousands of dollars. In fact, as some people on this call may know, just getting your Salesforce setup in place can cost $10,000 to $20,000 so integrating with Salesforce is going to be an additional cost on top of that. If you have legacy databases, if your old website had that database of toxic sites in your zip code or the mercury and fish calculator these are the kind of things that will drive up costs because the new site needs to be integrated with those legacy applications and legacy databases. And finally, if you want your site to be more interactive if you want discussion forums, which we don't recommend if you want a chat feature, which we rarely recommend on an events calendar, which is a very nice thing to have and if you want integration with things like Google, Google has a lot of services that you can integrate with your website. These are all things that you can expect to drive up the cost of this idealized website that we've described. That said, the other question people always ask us is what should we be paying for in terms of hourly? And our read on the sector in 2009, and I will preface this by saying that the economy has created downward price pressure. So there are people working for less than these numbers now and they are good people. But what we see in general is that there are plenty of great shops that do open source content management system work that charge between $75 and $120 an hour and give you everything you need. These are top-flight technicians, top-flight professional business consultants, people that really know what they're doing. You can get it done for $75 to $120 an hour. And good shops often have a multi-tiered rate where they've got a lower rate like $80 to $90 an hour for just standard red work and a higher rate like $120 or $130 an hour for custom code development. And we think that's a really, really fair model because custom code development does require a higher level of skill on the part of the implementer. So charging you at a sort of, if you will, commodity rate for your main website and getting that done for $80 to $100 an hour, and then charging you at a higher rate, $120, $130, $140 an hour for custom code development, which did I mention, we don't recommend unless you have to. That's a really good two-tiered rate model that we think indicates that a vendor is really mature and understands how to price their services. Our cynical opinion is that if you are paying more than $150 an hour, you're being charged for the vendor's reputation. You're being charged for the fact that they had something to do with Obama or they got a big gig with United Way or they're otherwise sort of brand empowered to act like they're when we just don't think it's worth it for the most part. The caveat there is that there are people that will lighten your load for $150, $200, $250, even more per hour in strategy services. That is a more fair rate for strategy consulting if that's a small, well-defined strategy component. But for actual web work, for website development, if you're paying over $150 an hour, call us and we'll be glad to tell you some people that will charge you less unless you've got very specialized needs. Last but not least, no matter what the consultant is going to charge you, check references, check references, check references, check references, because you want to make sure this is someone who worked with people like you and has delivered quality work consistently. That is so not to be taken for granted. A couple other comments. Graphic design shops will often give you flat rate. We can do your top level template and two second level templates for X thousand dollars. In general, we tend to find that's a good model, but you need to be mindful if you go that way to be sensitive about what are called round trips on design. The way that you drive graphic design shops crazy and the way that you run over the estimate they gave you for a flat rate is by making them tweak things 10 times when you should have just gotten it right in three round trips. But graphic design is something we feel comfortable having people quote at flat rate because we know lots of great shops that can give fairly good flat rate or flat range, which is to say this will be four to six thousand dollars and not to exceed six thousand dollars. Those kinds of quotes, that tends to work pretty well. Beware of flat rated sites. Good vendors can tell you this is a three thousand dollar site. This is a six thousand dollar site. And if you check their references and if they've done that consistently in the past, great. You're in a good situation with manageable knowable costs. But many times what happens with flat rated sites is that if there are unforeseen circumstances, if there are changes in the middle of the process, you get to an empty gas tank. You run out of the allocated money and vendors don't always behave totally nicely when you get to the limit on what they estimated. So if you're going to go with a flat rate site, make sure that you have the conversations about what cost overruns look like, what it looks like when you get to the end of the quote at flat rate and the site is not fully done. Excellent. So what are the ongoing costs? So there's a bunch of them. One of the things we really want to make sure people know, most nonprofits unless you are happily out of some of extremely high web traffic can get their monthly hosting done for $10 to $20 of tops $50 a month. It is only for high volume sites. It is only for sites that are serving thousands and thousands of pages a day, perhaps as many as 8 or 10,000 pages a day that you really need to get to the higher cost solutions. And again, there are many variables that determine what your hosting requirements are and I'm not trying to trip my stones. But if you're just hosting a brochureware website and you're seeing 1,000 or 2,000 visitors a day, you can put that on hosting for $10 to $20 a month that meets your needs. If on the other hand you've got 10 or 20,000 visitors a day, which is a wonderful problem to have, then yes, you should get a dedicated server and expect to pay $1 or $200 a month. Anybody who's paying Network Solutions or Register.com or any of those other robber barons, $35 a year for domain should think seriously about moving to a real domain registrar. The one that we have absolutely no business relationship with but we adore is Domainsite.com and I've just been using them since 2002. We manage about 150 domains with them. They aren't perfect, but they're damn good. The other org that we rail against, we really detest GoDaddy. GoDaddy is all about putting ads in your face and really taking your domains hostage. If anybody on this call has ever tried to migrate a domain away from GoDaddy or Network Solutions, you know of what I speak. They fight tooth and nail to keep you from migrating your domains away from them. So we recommend avoiding GoDaddy, avoid Network Solutions, avoidRegister.com, avoid Verisign, go with good registrars like Domainsite.com, Name.com, really good people out there that really have reasonable prices, you know, $8, $9, $10 a year. Finally, on the fixed hosting costs, you have to remember that if you've got a CRM, that's going to cost you money. If you're using a Democracy in Action action platform, if you're using a vertical response email newsletter tool and you're not on the non-profit free plan, it should be if you're a 501c3. But if you have these hosted tools that interrelate with your website, you probably want to think of those as fixed hosting costs as well, though I'm not trying to tell you about your budget. There's also variable maintenance. One of the things that organizations post an incredibly ill-advised budgetary strategy is when your content management system has a new version, you want to upgrade to the new version in a timely fashion. You don't need to go immediately, you should go promptly, because upgrades are synonymous with better security and more robust functionality. And so organizations that are three major versions behind on their Drupal or their Joomla or their WordPress should really be quite concerned about that and should budget to upgrade to the current version on a regular basis. You should also anticipate the need to add features. You might suddenly decide that you want a new subsection of your site. You might suddenly decide that you want to add a cool new calendar widget to your functionality on your website. These are things that you should try to anticipate and allocate a little bit of variable maintenance costs to. How much am I talking? A $1,000, $2,000 is certainly plenty of money to get a lot of nice incriminal features added. And last but not least, if you're getting new graphic assets created, if you need a new banner for an email campaign, if you need a new visual for some other part of your website, that can be a big cost center and make sure that you budget for new graphic assets as part of your ongoing cost modeling. And what are the ongoing staff time commitments? Well, this is one where you hit right back with the rhetorical question, what is your communication strategy? Regular site updates can be done in just a few hours per week by a competent staff member without really impacting their overall role provided the content is well developed by them or someone else in a separate sort of time commitment and you have an awareness of the frequency and the complexity of the updates that you're requesting. But if you just have a simple website and you just want to be posting new content once or twice a week on the homepage, it's creating content that's actually the larger cost. The actual maintenance of the website, the time commitment for posting that on the website is the smaller of the time allocations. That said, if your website has interactive community features, if you allow commenting on your articles or blog posts, if you've made the mistake of publishing discussion boards and need to respond to comments or other misbehavior, if you are allowing user participation. So if you are letting your users vote on your programmatic focus or letting your users contribute knowledge to a database of corporate malfeasance, these are all things that will drive up staff time commitments, but it is a very clean and well-defined boundary when you move into these interactive features and you want to make sure as you move into them that you have the hard discussions about the associated staff time. That's a great segue into the question and answer. I'm going to jump over your resources for now and go to a question that's related to forums. You said you don't recommend using forums. Can you explain why? I think many organizations feel like forums are a great way to engage the online community. Unfortunately, what they really are is spam magnets and a great place to lose control of organizational message. So if you are people for the ethical treatment of napkins, and you have a discussion board, and somebody gets on that discussion board and is like, let's cut down all the trees in the world. I hate trees. Let's pave the planet. You have a couple of really complex decisions to make. Do you edit their comments, or do you honor the plurality of opinions in your discussion arena? And when that turns ugly, if they start using profanity or being confrontational or showing disrespect, how do you deal with these kinds of behaviors and how does it reflect on your organization? What we recommend as a much more maintainable alternative to discussion boards in 2009 is run an organizational blog. Have an organizational blog where you have control of message. You can have guest bloggers. You can have guest voices. You can invite other people to post. But what you do is you post most of the content, and you can control the comments. You should allow commenting to be sure, but comments that don't sit your editorial guidelines are easy to delete, and you don't tend to see the same kind of flame wars and spam break out as you do with discussion boards. This is of course predicated on having the right spam filters and the right community process in place, but it is with things like blogs and comments that you get to a much higher functioning community engagement model than you will with discussion boards, which end up being like gardens that you ambitiously plant in the spring, and you can't believe what that patch of weeds looks like in your backyard come September. So there are some questions regarding what's the difference between CMS and CRM. And another question that's related to Dreamweaver, and would you recommend using Dreamweaver and updating your website that way versus using CMS? Great question. Well first of all, I want to apologize for the acronym fumble. I should have expanded CRM so I am slagulating myself at this end of the line and feeling bad that I dropped an acronym bomb. CRM is Constituent Relationship Manager. It is the program that manages your list of donors and supporters and media contacts and everybody that is in any way connected to your organization. And examples of good CRM tools include CivicCRM, which is a great open source alternative, Salesforce.com, which is a great hosted and free alternative. And to some degree tools like Democracy in Action have CRM features, but they are not CRMs strictly speaking. CMS is a content management system. A CMS is strictly for publishing web content, strict managing a website and a website's presence on the Internet. So they are a lot like two parts of a larger building. And so they need to coexist well. They need to be designed to operate. When people give you their email address on your website, ideally that ends up in your CRM system. When you do things with your CRM like query, who are your most passionate supporters, you can hopefully use that data to email them and drive them back to your website to look at new content. But CMS and CRM are complementary acronyms. The CS problem is something we consider to be well solved. With WordPress, Drupal, Joomla, and Plum, and many other great open source platforms available, there really is a fantastic set of options that are available for nonprofits to use. There's still plenty of cost involved in getting them deployed, but the systems themselves are free and open and they are best of breed. CRM is a climate solved problem. While there are great tools out there and specific tools meet organizational needs, there is still no really slam dunk CRM solution. We continue to work with different CRM vendors including Salesforce and CIDDCRM to really work for a happier future where the CRM products are both lower cost and higher functioning to the needs of nonprofits. The second question was about Dreamweaver. So first and foremost, it's a great question. Dreamweaver in its original conception is websites done the old way. Dreamweaver back in the day, you managed an image of your website locally on your computer and Dreamweaver was used to edit the pages and when a page had been updated to push that page quote-unquote up to the Internet. You uploaded an edited page to the website that was live on the Internet using FTP, the file transfer protocol. We adamantly recommend that you run screaming from anything that smacks of a Dreamweaver web maintenance model. Dreamweaver is still very useful for designing templates and for doing the actual creation of your site graphic design. Dreamweaver is still a fantastic drawing tool for laying out your website for designing your pop-up menus, for making the functionality of your website templates really, really beautiful. But once you have got the website template defined, once you have edited the code that is going to run the website, you absolutely want to be managing your website using a web browser with a modern content management system. So WordPress and Drupal and Plone and Joomla all work in a fashion that is analogous to the way that you do web mail. In the same way that if you have a Gmail or Yahoo Mail or a Hotmail account, you log into a web page and then you click a button that says Create New Message or Compose New Message and you get a web page with a field called Subject and a field called Body. Modern content management systems let you add new content or edit existing content using web-based forms just like web mail forms, a little bit more complicated but the same idea. And so people that are using Dreamweaver are still operating in an old and outdated paradigm that causes you no end of trouble. And I could elaborate offline if people want any sort of additional geeky details, but we adamantly recommend that you not stay in a Dreamweaver-maintained website world. That will cause you world-oh-hurt moving forward. Thanks for that. And several people are asking about free templates and what do you think about Google Sites. What are your thoughts on that? Cool. Well, let's start with the free templates question. Different platforms, every single platform has its own templating paradigm, its own templating model. The most successful templating universe is WordPress. And you can go to the WordPress.com Themes Gallery. I forget the exact URL, but if you just Google WordPress Themes, you'll go straight there. Click on the I Feel Lucky button. And in the WordPress Themes Gallery there are between 1,000 and 1,500 predefined WordPress Themes. There's a better picture. There's a set of navigation links. There might be a little calendar. There might be an archive button. There's all kinds of features and you can mix and match those themes to arrive at a design that you like at minimal cost because the majority of the coding has already been done and while you keep someone technically proficient involved, the customization and the tweaking are incremental and by no means off-puttingly complicated. Other platforms have mature template libraries and so it depends on what platform you're looking at as to whether or not there's sort of prefab templates available. But it's an excellent cost savings to see if you can live with a prefab template. In general, the answer is no. You tend to want something that really represents your organism brand, but it's always worth asking that question. So that is what I'm talking about when I refer to template libraries. Take a look at WordPress Themes if you want to see an example. And I apologize in advance. There's some ugly ones in there, but there's also some really clean and professional ones. Can we move to the other question? I went on too long there and my brain overflowed. About Google Sites. Oh, great question. I'll answer this two different ways and I'll sound like a Luddite before I sound like a useful answerer. We really encourage people to be circumspect about Google. We consider Google to be the heroine of the Internet era and Google's whole game is to get you addicted. And so Google Sites is a relatively high-functioning, hosted site solution. And if you are on organizational Gmail and if Google Docs is the way that you do your collaborative work and if you've already sort of drunk the Google Kool-Aid, Google Sites is a pretty adequate solution. That said, Google Sites is a classic example of a program, of a platform where you do not control your long-term technology destiny. And as an example, I would point out, I don't know how many people know this, Google has ceased development on Google Groups. So if you are on a Google Group or on multiple groups, you may have recently seen an uptick in the amount of really annoying spam. Learn this individual. I want to show you their sexy video or sell you some real estate in the Ukraine. And that is because Google has stopped development to a large degree. They're just in maintenance mode on Google Groups and they are not trying to solve the problem because the architecture of the Google Groups platform is sufficiently archaic that they can't solve the spam problem. So people that have adopted Google Groups are now stuck with a conundrum. Do you think about how with this technology that's moved into its end-of-life phase or do we get onto another platform where spam is not going to be an increasing problem and where we really can know that we have longer-term work destiny? Google Sites is a classic example of the first hit is free. It's low cost to get into Google Sites, but you don't know how long Google is going to maintain that option. You don't know if they'll ever start charging for it. And just as importantly, you don't know what Google has stuck about you when you host your site at Google. If you are people for the ethical treatment of napkins, you probably won't worry about the privacy of your audiences. But if you are a social justice organization doing human rights work with Pakistan, working with Palestine, and you're hosting your website at Google, you have no idea that site traffic data is being used for and whether or not it's being subpoenaed under Patriot Act. And while the Patriot Act can get server log data on any server, giving it to Google is tantamount to saying we have to yield our Fourth Amendment expectation privacy. So I'm starting to rant like a liberal here, but I really encourage people to think about the implications of trusting Google with your data. And while Google Sites is nice, I would recommend 99 times out of 100. Think about going with a hosted WordPress solution instead. Excellent. Well, I'm going to wrap up with the last question that has to do with what conferences could you recommend that people go to to learn more about this? Absolutely. Well, if you ask me on this, we'll tell you about all the events we run. And particularly we're running an event on the 8th of February. We're just about to announce Managing Nonprofit Technology Projects in Washington, D.C. And we're partnering on that with Citi D.C., which is a great implementer in the Citi D.C. We absolutely encourage you if you want to learn more about Managing Non-Projects, Managing Database Projects, Managing COM Projects to think about joining us for that two-way event. Great. And are there other conferences that you can recommend to the audience? Other conferences that I can recommend to the audience. I think the website design, nothing's jumping in my mind in the first half of 2010. I think it really is a question of what are your goals. But the main thing I recommend the audience do, many people don't think about website until it comes time to do one. And what we recommend you do, if it might be your responsibility in your organization to solve the website problem when it comes to the front burner, we strongly recommend that you be curious and nosy and gossipy. And whenever you're with your peers and peer organizations, ask them what they're using for their website. Ask them who did it. Ask them if they're happy. Ask them if they'll tell you what it cost. Because by doing this collaborative, social, human social networking to really educate yourself on options and what your peers are doing, you really put yourself in the strongest position to follow best practices when it comes time to do the inevitable and make your website new again. Fantastic. Thank you so much, Gunnar. And we're not going to spend any time on these additional slides that list resources because everyone will get a copy of this PowerPoint and they can look at the resources and click through the links and do more research on their own. So I'm going to jump right to our conclusion that we had about 50 questions that weren't answered. There are so many good questions. I know this is a very complicated, complex project and there's a lot to think about. And Gunnar, thank you so much for spending the time to put all this together. But additional questions that anyone has, please go to this tiny URL. They'll bring you to our community forums. Post your questions there. And Gunnar or some other really wise person out in the ether will answer those questions to the best of their ability. And if you're new to TechSoup, we have more than just webinars. We have articles and online forums and donated software. So check out more of what TechSoup has to offer. And we'd like to thank ReadyTalk for sponsoring this webinar series to make it free for our audience. And this is our last TechSoup talk of the year. We don't have any more scheduled at the moment, but check out our website, or email me, call me if you have questions about our webinars. Happy to keep having them come once a week on Going for Free hopefully. And again, thanks Gunnar so much for your participation and also Susie for answering chat questions and Becky and everyone out there who participated. Have a great day. Right on. Thanks. Bye-bye. Thank you. Bye. Thank you.