about google sites

kami: welcome to techsoup talks this webinar is about, how much should a website cost? we would like to thank readytalk for sponsoring this webinar series. and i would like to introduce allen gunn, the executive director of aspiration. welcome gunner. gunner: thank you. kami: and can you tell us a little bit about aspiration, and what you do there? gunner: i would be delighted to. aspiration is a nonprofit corporation 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 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'd love to chat. so if you have got questions or anything we can be useful to you for, please feel free to give us a ring. kami: great, thank you very much. i just want to quickly thank becky wiegand and suzi grishpul for monitoring the chat questions during this webinar. if you have any questions submitted via the chat,

we will either answer them immediately, or hold them to the very end. we'll we have about 15 minutes for q&a at the very end. and so again, i am kami griffiths, and i am the training and outreach manager here, and i will be facilitating this conversation with gunner. so quickly gunner, why don't you go through the agenda today. gunner: sure. we call this, what should a website cost? but there is a larger arch of discussion to get to the answer to that question. so we will start with an overview of what you might mean by "doing a website." we will then talk about how to really make sure you are getting all the input in your process

to make it successful. and then we will talk about questions to ask, where to start, and what to do once you've started, and how to move it forward. we will 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 will talk briefly about the relevant technologies. aspiration certainly has strong opinions on what are the most appropriate website technologies, and i will be glad to dish my strong opinions on this webinar. we will 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 will talk about the staff's time commitment, because that is one of the hidden costs when organizations go to budget for doing website upgrades and website designs and deployments. kami: okay, great. let's get started. what are we trying to get done? gunner: well, there are several different things you might mean when you say "we want to do a website."

in a perfect world you are working tabula 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 is not happy that you don't want their website anymore. just as often, you are dealing with an existing site you want to take to a new place. and there are sort of two extremes there. in a perfect world, if you 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, all the way back to fresh website, that is an important determinant on costing. the common factor across the spectrum is that costing in the world of graphic design that is the widest variant in websites, because different organizations describe different amounts of "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, 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. kami: and so when you are ready to move forward, who should you involve in the process? gunner: well, one of the things that we like to say -- it is 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 if you will, a 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.

we believe that instead, you want to model the website development process as a very transparent process that's 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 where you blog about progress on the website overhaul. but make sure that you have a way of keeping anyone who is interested in the dialogue knowing what is going on, because one of the biggest cost escalators in website work is getting a website "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 it's best to really proactively engage all your stakeholders, and front-load what i would lovingly call the "high maintenance" discussions. that said, many organizations make the tragic error of leaving website tasks to "techies," and we are adamant that this 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. and that is a very important frame, again, for managing cost over time. just delivering a site that is something that a stakeholder has to "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 work flows? that may sound like fancy jargon, but it is 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. kami: it's amazing how much you know. okay, so now that you have this figured out, what do you want to discuss with these folks? gunner: well, the first thing, and this is the big part of the organizational development. one of the things that we find repeatedly,

and i say this with all due respect to all of 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 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 communication's 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 communications 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 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 sense internally about 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 are an environmental organization, the climate people might describe it differently than the tree hugging people, that might describe it differently than the oceans people, even though you are all working on the same 501(c)(3) payroll. so that said, let's hope you 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 the site is being designed to serve and to reach? 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 of highest priority are other activists, other campaigning organizations. and depending on the organization that is having this discussion it is a really difficult distillation to really come to alignment on who are the primary and secondary audiences. once you have worked through that process you really want to understand -- and this is critical --

what value or benefit you are providing to each of those identified audiences that is going to get them to come to your site, because the great misconception 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 have 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 authoring 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 are a nonprofit, grass roots, 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 have discussed

on these two slides. because it is 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 rollout the site. kami: excellent. so now, with all of that information which in and of itself is a huge task, once that has been gathered, what is the next step? gunner: 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 on the final bullet here, at some point in this list you will realize, unless you are yourself a very technical nonprofit, you will 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 pen -- is to sketch out what is called

the "information architecture." that is fancy language for, what does your top level site navigation look like? there is 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 this position, having the content, 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 e-mail 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 are 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 the site around these user stories.

and one of the sort of normalization tasks is that 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 are 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 block diagrams of how you think your new home page, or your new second-level pages might look and these can be rudimentary, but again, as an organization before you have 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 is a work in progress, it is input to a larger model, but taking the time to do that work before you engage external consultants at rather substantial hourly rates, it puts you in control of the process. but as i mentioned at the beginning, somewhere in this idealized website pre-process, you get to a point where you are like, you know what, we need some external help. and that is when you need to move on to the next step. kami: okay, great segway. what's next? gunner: what's next? well, we are 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 is 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 have your project goal be, "do a website." that is 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 is 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 is a good idea of a concrete goal. you want to put those in your rfp. then, if you believe in what we have said so far, and you have done your homework, and you have 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 wire frame 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 is a nice segway 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 to 100 page super verbose rfps. and because we work with all the stakeholders in the spectrum, we know that the 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 a 100 page rfp, because it is simply an overwhelming task with a relatively low probability of return on that time investment. in other words, if i take the time to respond to a 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.

kami: great. so once it is ready, where should it go? gunner: well, one of the things -- and again, we model virtually everything we advise around community oriented processes. 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 "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 are 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 a 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 a recommendation? 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 the spaces that you travel. from there, the number is arbitrary, but we think a good first pass is to select 2 to 4 vendors that you directly engage. and find 2 to 4 vendors that you can give the rfp to. some will say we're 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 rfp in earnest. but go ahead and look for 2 to 4 vendors that will take a serious sniff at your rfp, and ask them for short clean responses with the idea being, it's not really good form in our opinion to make a vendor over engineer a response when you are 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 rfp response. and as you look at those you can figure out which vendors 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 them for creating. good vendors respond initially with questions, and those questions clarify your intentions and let them give you a more precise response. and as we have mentioned before, look 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 site 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 -- you know, 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 is a complex interplay of those two factors, it is 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. kami: okay, so once you have picked someone, what happens then? gunner: well, it is critical to agree with them on what process milestones look like.

and so this is kind of a superset. i'll just move through this quickly. if you are 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 value 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, is outside of the scope of this webinar, but i mention it for completeness. most of the time, once you have gone to an implementer to create a website

you will start with the creative design process. what is 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 are 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 are 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 nonprofits, and not outsourced to the vendor. it drives costs 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 rfp, that is a red flag. because if they don't include training as explicit steps,

they really don't understand what it means to do a successful hand off. and know what their terms of support are. do they have a monthly [indistinct] 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. kami: that's good. so what would you recommend for managing the ongoing relationship? gunner: first and foremost, websites rarely turn out the way you plan them in the beginning.

so we think one of the most critical factors to managing cost is to have a 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 the associated costs that increases,

you have made a big boo-boo, because you are 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 is an insecurity syndrome with nonprofits. so like well, we are 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 confusions. 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 are 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 is 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 costs, because you want to know what you are getting charged for as it is happening, not in some nasty surprise at the end. and if you are doing granular invoicing and granular billing, you are seeing their billing patterns. you're seeing if they are billing you for things that didn't appear on the original proposal, and you are able to address that early in the process and to put a stop to that, or at least write that off as acceptable

before it gets to be a big cost escalator. kami: so now let's talk about the actual technology that you would recommend. gunner: 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 a very personal decision for each organization. that said, we have a completely overarching, completely awkwardly overly general statement which is we generally believe that when you have the option, a nonprofit should always use an open source content management system.

now i say "always," 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 is 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 "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've put yourself in the best position for long-term flexibility. when you go with a proprietary vendor, when you go with coldfusion, when you go with a custom platform designed by your implementer -- and by the way, that is 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 is 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 [indistinct] 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 prenuptial 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 2 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. kami: you are too funny! so what should we expect to pay? gunner: okay, here is the good gossipy stuff. and just so you know, aspiration spends a lot of time surveying costs in the nonprofit market place. so we really, really, really like to ask people what they have paid for websites, and what they are planning to pay for, or they are planning to charge in the case that they are vendors. okay, somebody's got a phone ringing on this call.

and if you were in the same room we would give you a virtual noogie. so then, what kind of site are we talking about? so there are many different kinds of websites. so the numbers i am about to quote are based on the following site profile. it is a simple site, what we lovingly call "brochure-ware with a growth path," an electronic online brochure version of your organization, but on 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 e-mail sign up feature, so that on every page people can provide an e-mail address

and get e-mail updates or e-mail newsletters from your organization. the site has an online donation feature, so people can give money using credit cards or paypal or whatever, but 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 are about to talk about, should be maintainable by organization staff using just their web browser

and maybe an image editing tool like photoshop or picasa. and in addition, site traffic statistics should be produced by the site that is deployed. and that is 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 is part of the delivery package. so as i said, this is "brochure-ware with a growth path." let's talk about what that might cost. so costs vary widely, but we know people that can absolutely do very basic wordpress sites for $500-$1000.

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-$1000 if you know the right people. and that said, the main answer to the question of what should you expect to pay

for this brochure-ware website, $2000-$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 consistently the price range that we get back is $2000-$10,000. above $10,000 for the brochure-ware site that we have just described, make sure that 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 with [indistinct] 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 is 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 $5000 or $4000 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 have surveyed over the last five years. 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 is going to drive up your costs. if you want your website to talk to a crm like salesforce, or democracy in action, or civicrm, that is 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 set up in place can cost $10-$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 in 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, if you want an events calendar which is a very nice thing to have, and if you want integration with things like google -- you know, 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 are 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 are doing. you can get it done for $75-$120 an hour. and good shops often have a multi-tiered rate where they have got a lower rate

like $80-$90 an hour for just standard web work, and a higher rate like $120-$130 an hour for custom code development. and we think that is 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-$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 are being charged for the vendor's reputation. you are being charged for the fact that they had something to do with obama, or they got a big gig with united way, or they are otherwise sort of brand empowered to act like they are 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 are paying over $150 an hour, call us, and we will be glad to tell you some people that will charge you less unless you have 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 that this is someone who has worked with people like you, and has delivered quality work consistently. that so not to be taken for granted.

a couple other comments, graphic design shops will often give you flat rates. we can do your top level template, and two second-level templates for x-thousand dollars. in general we tend to find that is 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 that they gave you for a flat rate, is by making them tweak things ten 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 rates, and we know lots of great shops that can give fairly good flat rate,

or a flat range which is to say this will be $4000-$6000, and not to exceed $6000, those kinds of quotes. that tends to work pretty well. beware of flat rated sites. good vendors can tell you this is a $3000 site. this is a $6000 site. and if you check their references, and if they have done that consistently in the past; great, you are in a good situation with manageable, knowable costs. but many times what happens with flat rated sites is 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 estimate. so if you are 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 quoted flat rate and the site is not fully done. kami: excellent. so what are the ongoing costs? gunner: so there are a bunch of them. one of the things we really want to make sure people know, most nonprofits unless you are happily at some extremely high web traffic, can get their monthly hosting done for $10-$20, at 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,000 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 am not trying to trivialize those, but if you are just hosting a brochure-ware website, and you are seeing 1000 or 2000 visitors a day, you can put that on a hosting for $10-$20 a month that meets your needs. if on the other hand, you have 10,000 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 $100 or $200 a month. anybody who is paying network solutions, or register.com, or any of those other robber barons $35 a year for domains, should seriously think 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 have just been using them since 2002. we manage about 150 domains with them. they aren't perfect, but they are 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 go daddy 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, avoid register.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 are using a democracy in action action platform,

if you are using a vertical response e-mail newsletter tool and you are not on the nonprofit c-plan, you should be if you are a 501(c)(3). 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 am not trying to tell you how to spend your budget. there is also variable maintenance. one of the things that organizations post in 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, but you should go promptly, because upgrades are synonymous with better security and more robust functionality. 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 you should try to anticipate

and allocate a little bit of variable maintenance cost to. how much am i talking? you know, $1000, $2000, is certainly plenty of money to get a lot of nice incremental features added. and last but not least, if you are getting new graphic assets created, if you need a new banner for an e-mail 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. kami: and what are the ongoing staff time commitments?

gunner: 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 [indistinct] time commitment, and you have an awareness of the frequency and the complexity of the updates that you are 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 home page, it is creating content that is actually the larger cost.

the actual maintenance of the website, the time commitment to posting it 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 data base of corporate malfeasance,

these are all things that will drive up staff time commitment, but it is a very clean and a 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. kami: that is a great segway into the question-and-answer. i am going to jump over your resources for now, and go to a question that is related to forums. you said you don't recommend using forums. can you explain why? gunner: i think many organizations feel like forums are a great way to engage their online community. unfortunately, what they really are are 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 fit 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. kami: so there are some questions regarding, what is the difference between cms and crm. and another question that is related to dreamweaver, and would you recommend using dreamweaver and updating your website that way versus using a cms? gunner: great question. well, first of all i want to apologize for the acronym fumble. i should have expanded crm. so i am flagellating 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. examples of good crm tools include civicrm 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, strictly managing a website and the website's presence on the internet.

so they are a lot like two parts of a larger building, so they need to coexist well. they need to be designed to operate when people give you their e-mail 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 e-mail 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 plone, and many other great open source platforms available, there really is a fantastic set

of options that are available for nonprofits to use. there are 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 an unsolved problem. while there are great tools out there, and specific tools that meet organizational needs, there is still no really slam-dunk crm solution. we continue to work with different crm vendors including salesforce and civicrm to really work towards a happier future, where the crm products are both lower cost and higher functioning to meet 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 "up" to the internet, you up loaded 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. dream weaver 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 gotten 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 a yahoo mail, or a hotmail account, you log into a webpage, and then you click a button that says "create new message" or "compose new message" and you get a webpage with a field called "subject" and a field called "body." modern content management systems let you add new content, or edit the existing content using web based forms just like a web mail forms, a little bit more complicated but the same idea. 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 off line 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-o-hurt moving forward. kami: 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? gunner: 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 theme you will go straight there. click on the "i feel lucky" button. and in the wordpress themes gallery there are between 1000 and 1500 predefined wordpress themes. there's a banner picture. there is a set of navigation links. there might be a little calendar. there might be an archive button. there are all kinds of features, and you can mix and match those themes to a live edit design that you like at minimal cost, because the majority of the coding has already been done. and while you would need someone technically proficient involved, the customization and the tweaking are incremental and [indistinct] complicated.

other platforms have mature template libraries, and so it depends on what platform you are looking at as to whether or not there are these sort of prefab templates available. but it is an excellent cost savings to see if you can live actually with a prefab template. in general, the answer is no. you tend to want something that really represents your organizational brand, but it is 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 are some ugly ones in there,

but there are also some really clean and professional ones. kami, what was the other question there? i went on too long and my brain overflowed. kami: about google sites. gunner: oh, great question. i'll answer this two different ways, and i will sounds like any 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. 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 have 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 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 -- but google has ceased development on google groups. so if you are on a google group or multiple groups, you may have recently seen an up-tick in the amount of really annoying spam,

and its individuals that 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 are just in a maintenance mode in 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 we stick around with this technology that has moved into its end-of-life phase, or do we get on to another platform where spam is not going to be an increasing problem,

and where we really can know that we have longer-term control of our destiny. google sites is a classic example of "the first hit is free." it is low-cost to get into google sites, but you don't know how long google is going to maintain that offering. you don't know if they will ever start charging for it. and just as importantly, you don't know what google has [indistinct] about you when you host your site at google. if you are people for the ethical treatment of napkins you probably don'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 are hosting your website at google, you have no idea what website traffic data is being used for and whether or not it is being subpoenaed under the patriot act. and while the patriot act can get server log data on any server, giving it to google is tantamount to saying we absolutely yield our fourth amendment expectation of 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 are nice, i would recommend 99 times out of 100, think about going with a hosted wordpress solution instead.

kami: thanks a lot. well, i am going to wrap up with the last question. it has to do with what conferences could you recommend that people go to to learn more about this. gunner: absolutely. well, if you get on the aspiration mailing list we will tell you about all the events we run. in particular, we are running an event on the 8th and 9th of february. we are just about to announce, managing nonprofit technology projects, in washington dc. and we are partnering on that with citi dc which is a great implementer in the citi dc area. we absolutely encourage you if you want to learn more about managing web projects, managing database projects, managing crm projects to think about joining us

for that two day event. kami: great. and are there other conferences that you can recommend to the audience? gunner: other conferences that i can recommend to the audience, i think on website design nothing is jumping to my mind in the first half of 2010. i think it is really a question of what are your goals? but the main thing that i recommend the audience do, many people don't think about a 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 nosey, and gossipy. and whenever you are with your peers and peer organizations, ask them what they are using for their website. ask them who did it. ask them if they're happy. ask them if they will tell you what it cost. because by doing this collaborative 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. kami: fantastic. thank you so much gunner.

and we are not going to spend any time on these additional slides that list resources, because everyone will get a copy of this power point, and they can look at the resources and click through the links, and do more research on their own. so i am going to jump right to our conclusion. we had about 50 questions that weren't answered. there are so many good questions. and i know this is a very complicated and complex project, and there is a lot to think about. and gunner, thank you so much for spending the time to put this all together. but additional questions that anyone has, please go to this tiny url. it will bring you to our community forums. post your questions there. and gunner, or some other really wise person out in the ether

will answer those questions to the best of their ability. and if you are new to techsoup we have more than just webinars. we have articles, and online forums, and donated software. so checkout more of what techsoup has to offer. and we would like to thank readytalk for sponsoring this webinar series to make it free for our audience. and this is our last techsoup talk for the year. we don't have any more scheduled at the moment. but checkout our website, or e-mail me, call me if you have questions about our webinars. happy to keep having them come once a week ongoing for free, hopefully.

and again, thanks gunner so much for your contribution, and also suzie for answering chat questions, and becky, and everyone out there who participated. have a great day. gunner: right on! kami: thanks. bye-bye. gunner: bye.