Here are posts from a small sampling of bloggers I regularly read:
- Holly Ross shows her geek cred in a great post about DNS. I love Holly’s approach to technology.
- Amy Sample Ward let’s us know how to give green. Amy is a great source for nptech tips of all types.
- Beth Kanter asks whether or not we can add some more steps to Chris Brogan’s fabulous 50 steps to create a social media presence. Beth is, of course, THE web 2.0 and social network guru for the nptech community.
- Allan Benamer talks about Convio’s new big client, Susan G. Komen for the Cure, for their Salesforce-based application formerly known as Aikido, presently known as Common Ground. I trust Allan’s gut instincts about CRM technology.
- David Geilhufe ponders how technology solutions split communities, and issues of a lack of strategic vision. It’s a great, thoughtful post. David is always a great source for thoughtful insights about open source.
- Michele Martin talks about developing a personal learning plan. I read her blog for great tips on professional development and technology.
This week, it is my pleasure to host the Carnival of Nonprofit Consultants. This week, I asked the question: What is the biggest mistake a nonprofit can make with their website. I got some interesting answers:
- Ken, at the Nonprofit Consulting Blog, talks about transparency, and how it’s a big mistake not to be transparent. He has some good ideas and suggestions about how to be transparent as an organization through the website.
- Kivi in her Nonprofit Communication’s blog suggests that a website needs to be about the visitor and not about the organization: “The biggest mistake that a nonprofit can make with its website is to use it as an old-fashioned brochure, where you immediately hit the visitor with your long, jargon-filled mission statement, right at the top or smack in the middle of the home page, followed by bulleted lists of ‘projects’ or ’services.’” She gives some great suggestions and examples
- Joanne Fritz talks about three big mistakes – outdated information, insufficient contact information, and outdated design. She makes some great points, and gives good tips to make changes.
- The Hack Artist suggests that it’s important to marry direct mail efforts and a web presence.
- James Young, on the Connection Cafe, suggests that we think about constituent empowerment when we think about organizational websites.
- And, since I’m the host, I get to add a couple of bonus mistakes. I think one of the biggest mistakes that an organization can make with its website is to promise more than it can deliver – make sure that the resources to create that blog, or podcast, or photo gallery, or whatever bells and whistles that you promise on your website, are there when the website goes live.
- I do think the biggest mistake an organization can make in the re/creation of its website is to go with the vendor with the lowest bid. It’s a lot more than price – it’s quality of work, whether you like their previous work, their overall reputation, as well as their fit with you as an organization.
I had a startling realization a few days ago. I seem to spend inordinate amounts of time responding to people (proprietary software vendors, to be specific) harping on the idea that “open source software is free” is a myth, and blathering on about how it’s not really free, because you have to hire a geek to install it, and maintain it, and blah blah blah.
No credible nonprofit technology open source advocate has ever suggested that open source software was free to implement. In fact, we all go out of our way (like in the open source primer) to talk about total cost of ownership, and how cost-wise, implementation of open source software is sometimes a wash with proprietary, etc. I’ve been caught using the “free as in kittens” metaphor many more times than once. We talk much more about the value and values that free and open source software bring to the table.
My realization was this: the myth is entirely of the making of these proprietary vendors who claim it is a myth. There would be no myth if it were not for them. No one would think that anyone thought that implementing open source software was without cost.
And from now on, instead of writing some long-winded response, I’m just going to put in a link to this post.
I finally had the reason to begin to more completely articulate my theory of practice. My theory of practice is different than my consulting philosophy. They certainly are consistent with each other, but they are distinct. A theory of practice, in my mind, outlines the methods and ideals behind how I get work done with clients. This theory includes the following elements that I think are key to my work:
- Listening. Listening, both at the beginning, and consistently through an engagement, to their goals, ideals, “points of pain”, and points of confusion.
- Educating. One of the most important roles I play is educating clients about the technology that they will be engaging with, based upon what I’ve heard while I’ve listened. This is also an ongoing process.
- Intermediation. The role I play most often currently is providing a clear and understandable avenue between the client and a technology vendor (such as web or database development shop). The client is quite knowledgeable about their organization, mission, and goals for a project, but often not knowledgeable about technology. The vendor is expert at what they do, but cannot always provide a channel of communication that the client can really work with. I provide that clear channel, so both sides benefit.
- Learning. Those first three elements make up the communication arm of my practice. The other arm is learning. I can’t do what I do without being a technology expert. And I can’t stay a technology expert without continually learning. Reading, research, collaborating with others, getting my hands dirty with servers and code, playing with new applications and new APIs – all of those things keep my technology expertise fresh.
More specifically, what methods do I use to help clients make their way through the entire process of a technology project:
- Qualitative and Quantitative (where appropriate) assessment of requirements and needs, including surveys and interviews with internal (and/or external) stakeholders
- Research – both standard internet research as well as outreach and interviews with relevant people
- Writing – writing requirements, RFPs, documentation
- Project management – keeping a project on track
- Evaluation – evaluating projects as they are happening, and when they are done.
This is old news, but I’ve been busy. What’s kind of funny is that I was quoted on the press release, which was out 3 weeks ago or so, but it’s taken me this long to blog it. Bad Blogger! (I think my clients thank me for being a bad blogger.)
So what’s the news? MPower Open is now on Sourceforge, they released their product under the GPL v3. These are good steps forward. This is what I said (in what I think is my first quote for a press release):
By adopting a well-regarded license, joining the SourceForge platform, and launching its community, MPower is making great strides in creating an open source community around its application,” said Michelle Murrain, Principal, MetaCentric Technology Advising, and Coordinator, Nonprofit Open Source Initiative (NOSI). “I look forward to the growth of this community, and the ongoing development of the MPower solution as an open source alternative CRM for nonprofit organizations.
So my hope is that they really begin to use the platform. So far, there is basically no activity in the forums and mailing list. It’s going to take some real elbow grease of reaching out to people who might begin to form the kernel of a development community to get that going. “If we build it they will come” only works in the movies.