EvoBloggito

Disconnected: Honey, I deactivated the Facebook account.

Author: Ray Gulick; Published: Aug 23, 2010; Category: Zeitgeist; Tags: Business, social media; No Comments

I’ve never been a huge fan of Facebook, once I got over the initial curiosity and connected with a few friends. I really don’t care that much about what people I haven’t seen for more than 30 years are doing with their spare time. Some of whom I barely knew 30 years ago.

There’s no question that Facebook is valuable for some businesses, IF a large part of their market uses it. I have clients, such as Zooniversity, for whom being in front of their market on Facebook is very important. But that’s not the case with my business. If you’re a client of mine and Facebook is important to your business, I’ll see that your website supports and promotes your Facebook page. Other than that, I’m done with Facebook.

Frankly, when someone from high school whose name I barely recall—who I’m sure I didn’t know well enough to say “Hi” to in the hall—wants to “friend” me, and four other people from high school (none of whom I was close to) send messages recommending that I friend this person, I’m starting to feel just a little intruded upon. I know, I can adjust my privacy settings. But every time I look at the settings panel, I surrender to an overwhelming desire to go get a beer instead. Each and every time that happens, I feel like I’ve made the right choice.

There was a time when I tried to look people up on Facebook. That stopped when so many of the people I found turned out to be fans of Sarah Palin, or into doing some kind of “Farmworld” thingy, or just plain telling me more than I wanted to know. And everyone looked so old! There’s a reason I left my hometown, I’ve decided.

There’s actually a term for what I’m experiencing: social media fatigue (google it and you’ll find a lot of material). As far as I can tell, the term has been used for at least 2 years. But I think more and more people are starting to tire of being so connected, and feeling compelled to participate. Social media can be valuable and rewarding, but you have to be selective about how and where (and if) you participate. After careful evaluation (and a beer), it’s “so long, Facebook” for me.

So, if anyone from my distant past, recent past, or even immediate future wants to connect with me, just send me an email. But please, don’t tell me you’re a Sarah Palin fan.

Why We Don’t Respond to RFPs: There’s a Better Way

Author: Ray Gulick; Published: Aug 7, 2010; Category: Design/Development; Tags: Business, Design/Development, LinkedIn; One Comment

Recently I got into a discussion on LinkedIn about Requests for Proposals (RFPs) and what makes a “good” RFP for web design and development. My position, basically, is that there is no such thing as a good RFP for web design and development, at least not following current “best practices” RFP models.

Why? Because successful websites are the result of collaborative efforts between clients and web developers. RFPs usually preclude collaboration by treating the process as furnishing a defined set of deliverables in a scope of work, with the vendor bound to furnish the deliverables as defined. Alternative (and often better) approaches are routinely dismissed in the interests of “comparing apples and apples.”

RFPs are a problem for everyone involved.

The problem for people writing RFPs is that few people or organizations are capable of defining deliverables in a scope of work in a way that allows for better solutions than they themselves had imagined, because they are rightly concerned with controlling costs. But defined deliverables usually means defined solutions, sometimes ruling out less expensive or more efficient alternatives. Things change rapidly in web development, and what was a good solution 12 months ago can be a decidedly inferior solution today. Even web developers scramble to stay abreast of changes, with varying degrees of success.

Further, few people and organizations are capable of evaluating proposals to sort out meaningful information from BS or fluff. If the best web developer/designer is selected for the project, it’s almost by accident.

The problem for those of us responding to RFPs is that preparing a proposal can easily consume 30-60 hours, depending on the scope of the project. We put some thought into addressing the specific items in the RFP, rather than making a few quick modifications to a standing proposal, and it takes time. Frankly, it’s time that could be spent more productively.

There’s a better way for both website owners and website developers.

Again, all successful website design/development is the result of collaboration between client and designer/developer. Aside from their ability to do the job, the most important thing you’re looking for in a designer/developer is someone you can collaborate with. I believe the following outlines a better way to find a collaborator and establish a collaborative relationship, one in which both parties work for a successful website within the agreed budget and timeline.

Figure out what you want to accomplish with your website. What are your goals? What are the goals of the people who might visit your website? What kind of functionality is necessary to meet those goals?

Figure out who your “audience” is (substitute “market” or “community” if more appropriate) and why they are interested in what you have to offer. Think about what kinds of online interaction with them would further your and their goals.

Figure out your budget. Bigger isn’t necessarily better, but some solutions are precluded by a budget that is inadequate to support them.

Look at websites similar to what you want. Contact the site owners and ask about the designer/developer. Would they recommend working with him/her? Include some local designer/developers in your research; often they will be more invested in your success (if your audience is primarily local, consider restricting your research to local designer/developers). Soon you’ll develop a shortlist of web people you want to talk to.

Call or email each of the designer/developers on your shortlist. Invite them separately to your office or a local coffee shop (or schedule a phone meeting, if they are not local) to discuss your project.

During your meeting, share your goals for your website (and describe functions you believe you need to meet those goals), what you know about your audience, and what your budget is. If they’re not taking notes and asking questions during this part of the meeting, you might want to cut it short. A good collaborator will be engaged and interested in this part of the process, and may even offer suggestions or observations that hadn’t occurred to you.

IF they took notes and asked lots of questions, find out more about them. Ask how they would go about helping you meet your goals within the budget you’ve described. Discuss timeline and try to get a sense of how focused they will be on your website. Ask them to walk you through a couple of websites they’ve launched, describing how they arrived at various solutions or solved design or technical issues. Ask about their business: not just how long they’ve been in business, but who their clients are, how they handle payments, what kind if ongoing support they provide, and what they feel separates their services from their competitors’ services. It wouldn’t hurt for you to take notes for this part.

If you feel you can collaborate with them, invite them to submit a written proposal. The short proposal (no more than two or three pages) should include a description of the project as they understand it, recommendations for a general approach (project phases, technical platform, etc.), an estimate for both time and cost, and contact information for at least three clients who you can call to talk about their experience in working with the designer/developer. Do NOT skip talking with their clients.

When you’re done evaluating proposals (and checking out client references), you should have a pretty clear idea of who you can work with best. Once you make your selection, schedule a project meeting in which you and the developer map out a project plan.

On an ongoing basis during the project, you make decisions together about the best options to help you meet your goals; the developer as trusted advisor, you as final decision-maker. You are now on the path to a great website.