August 13

Hackcess To Justice

Hackcess to Justice LogoRegular blog readers know that landing my job at Legal Services Corporation, the single largest funder of civil legal aid to people in financial need, was not an accident.  The mission of providing representation to those who need it, but can’t afford it, is one that I targeted for over half a decade before getting this position. I’m passionate about the work of our grantees, because there is something about social and economic injustice that offends me at my core, and I consider it my responsibility and my privilege to be able to do work that attempts to alleviate such injustice.   That’s my best explanation, but you should hear my boss describe the problem. As a lawyer, he makes the case, but he makes it in plain, clear English, and he makes it powerfully.

The setting of this 13 and a half minute speech is completely appropriate for this blog.  The first “Hackcess to Justice” hackathon was held in Boston on August 7th and 8th at the annual American Bar Association meeting. The goal of the hackathon was to create apps that address the needs of people seeking representation or representing themselves in civil courts. The projects are based on the recommendations that came out of the technology summit that LSC held in 2012 and 2013.  The report, linked here, is a good — and not too lengthy — read. And the winners creatively met those goals, with apps that help write wills, determine whether you need legal help, and point you to legal resources in a disaster. Robert Ambrogi, one of the three judges, blogged about the winners, too.

I’m proud to work for an organization that not only thinks strategically about how we use technology, but strategize about how the world can use it to address the problems that we were founded to help solve. And I’m very happy to work at a company where the leadership gets it — technology is more than just plumbing; it’s an enabler.  Deployed correctly, it can facilitate solutions to extremely challenging problems, such as the severe justice gap in the United States.

Jim says it best, and I can’t recommend enough that you take the quarter of an hour (less, actually) to hear what he has to say.

Jim Sandman’s Opening Remarks at the Hackcess To Justice Hackathon, August 7th, 2014

July 31

Why You Should Delete All Facebook Mobile Apps Right Now

fblogoIt’s nice that Facebook is so generous and they give us their service and apps for free. One should never look a gift horse in the mouth, right? Well, if the gift horse is stomping through my bedroom and texting all of my friends while I’m not looking, I think it bears my attention.  And yours. So tell me why Facebook needs these permissions on my Android phone:

  • read calendar events plus confidential information
  • add or modify calendar events and send email to guests without owners’ knowledge
  • read your text messages (SMS or MMS)
  • directly call phone numbers
  • create accounts and set passwords
  • change network connectivity
  • connect and disconnect from Wi-Fi

This is a cut and pasted subset of the list, which you can peruse at the Facebook app page on Google Play. Just scroll down to the “Additional Information” section and click the “View Details” link under the “Permissions” header. Consider:

  • Many of these are invitations for identify theft.  Facebook can place phone calls, send emails, and schedule appointments without your advance knowledge or explicit permission.
  • With full internet access and the ability to create accounts and set passwords, Facebook could theoretically lock you out of your device and set up an account for someone else.

Now, I’m not paranoid — I don’t think that the Facebook app is doing a lot of these things.  But I have no idea why it requires the permissions to do all of this, and the idea that an app might communicate with my contacts without my explicit okay causes me great concern. Sure, I want to be able to set up events on my tablet.  But I want a box to pop up saying that the app will now send the invites to Joe, Mary and Grace; and then ask “Is that okay?” before it actually does it.  I maintain some sensitive business relationships in my contacts.  I don’t think it’s a reasonable thing for Facebook to have the ability to manage them for me.

This is all the more reason to be worried about Facebook’s plan to remove the messaging features from the Facebook app and insist that we all install Facebook Messenger if we want to share mobile pictures or chat with our friends.  Because this means well have two apps with outrageous permissions if we want to use Facebook on the go.

I’ve always considered Facebook’s proposition to be a bit insidious. My family and friends are all on there.  I could announce that I’m moving over to Google Plus, but most of them would not follow me there.  That is the sole reason that I continue to use Facebook.

But it’s clear to me that Facebook is building it’s profit model on sharing a lot of what makes me a unique individual.  I share my thoughts and opinions, likes and dislikes, and relationships on their platform. They, in turn, let their advertisers know that they have far more insight into who I am, what I’ll buy, and what my friends will buy than the average website.  Google’s proposition is quite similar, but Google seems to be more upfront and respectful about it, and the lure I get from Google is “we’ll give you very useful tools in return”.  Google respects me enough to show some constraint: the Google+ app on Play requires none of the permissions listed above. So I don’t consider Facebook to be a company that has much respect for me in the first place.  And that’s all the more reason to not trust  them with my entire reputation on my devices.

Do you agree? Use the hashtag #CloseTheBook to share this message online.

July 11

The Future Of Technology

Jean_Dodal_Tarot_trump_01…is the name of the track that I am co-facilitating at NTEN’s Leading Change Summit. I’m a late addition, there to support Tracy Kronzak and Tanya Tarr. Unlike the popular Nonprofit Technology Conference, LCS (not to be confused with LSC, as the company I work for is commonly called, or LSC, my wife’s initials) is a smaller, more focused affair with three tracks: Impact Leadership, Digital Strategy, and The Future of Technology. The expectation is that attendees will pick a track and stick with it.  Nine hours of interactive sessions on each topic will be followed by a day spent at the Idea Accelerator, a workshop designed to jump-start each attendee’s work in their areas. I’m flattered that they asked me to help out, and excited about what we can do to help resource and energize emerging nptech leaders at this event.

The future of technology is also something that I think about often (hey, I’m paid to!) Both in terms of what’s coming, and how we (LSC and the nonprofit sector) are going to adapt to it. Here are some of the ideas that I’m bringing to LCS this fall:

  • At a tactical level, no surprise, the future is in the cloud; it’s mobile; it’s software as a service and apps, not server rooms and applications.
  • The current gap between enterprise and personal software is going to go away, and “bring your own app” is going to be the computing norm.
  • Software evaluation will look more at interoperability, mobile, and user interface than advanced functionality.  In a world where staff are more independent in their software use, with less standardization, usability will trump sophistication.  We’ll expect less of our software, but we’ll expect to use it without any training.
  • We’ll expect the same access to information and ability to work with it from every location and every device. There will still be desktop computers, and they’ll have more sophisticated software, but there will be less people using them.
  • A big step will be coming within a year or two, when mobile manufacturers solve the input problem. Today, it’s difficult to do serious content creation on mobile devices, due primarily to the clumsiness of the keyboards and, also, the small screens. They will come up with something creative to address this.
  • IT staffing requirements will change.  And they’ll change dramatically.  But here’s what won’t happen: the percentage of technology labor won’t be reduced.  The type of work will change, and the distribution of tech responsibility will be spread out, but there will still be a high demand for technology expertise.
  • The lines between individual networks will fade. We’ll do business on shared platforms like Salesforce, Box, and {insert your favorite social media platform here}.  Sharing content with external partners and constituents will be far simpler. One network, pervasive computing, no more firewalls (well, not literally — security is still a huge thing that needs to be managed).

This all sounds good! Less IT controlling what you can and can’t do. Consumerization demystifying technology and making it more usable.  No more need to toss around acronyms like “VPN.”

Of course, long after this future arrives, many nonprofits will still be doing things the old-fashioned ways.  Adapting to and adopting these new technologies will require some changes in our organizational cultures.  If technology is going to become less of a specialty and more of a commodity, then technical competency and comfort using new tools need to be common attributes of every employee. Here are the stereotypes that must go away today:

  1. The technophobic executive. It is no longer allowable to say you are qualified to lead an organization or a department if you aren’t comfortable thinking about how technology supports your work.  It disqualifies you.
  2. The control freak techie.  They will fight the adoption of consumer technology with tooth and claw, and use the potential security risks to justify their approach. Well, yes, security is a real concern.  But the risk of data breaches has to be balanced against the lost business opportunities we face when we restrict all technology innovation. I blogged about that here.
  3. The paper-pushing staffer. All staff should have basic data management skills; enough to use a spreadsheet to analyze information and understand when the spreadsheet won’t work as well as a database would.
  4. Silos, big and small. The key benefit of our tech future is the ability to collaborate, both inside our company walls and out. So data needs to be public by default; secured only when necessary.  Policy and planning has to cross department lines.
  5. The “technology as savior” trope. Technology can’t solve your problems.  You can solve your problems, and technology can facilitate your solution. It needs to be understood that big technology implementations have to be preceded by business process analysis.  Otherwise, you’re simply automating bad or outdated processes.

I’m looking forward to the future, and I can’t wait to dive into these ideas and more about how we use tech to enhance our operations, collaborate with our community and constituents, and change the world for the better.   Does this all sound right to you? What have I got wrong, and what have I missed?

June 18

Telecommuting Is About More Than Just The Technology

We’ve hit the golden age of telework, with myriad options to work remotely from a broadband-connected home, a hotel, or a cafe on a mobile device. The explosion of cloud and mobile technologies makes our actual location the least important aspect of connecting with our applications and data. And there are more and more reasons to support working remotely. Per Reuters, the state of commuting is a “virtual horror show”, with the average commute costing the working poor six percent of their income. It’s three percent for more wealthy Americans. And long commutes have negative impacts on health and stress levels. Add to this the potential cost savings if your headquarters doesn’t require an office or cubicle for every employee. For small NPOs, do you even really need an office? Plus, we can now hire people based on their absolute suitability to the job without requiring them to relocate. It’s all good, right?

Well, yes, if it’s done correctly.  And a good remote work culture requires more than seamless technology. Supervisors need to know how to engage with remote employees, management needs to know how to be inclusive, and the workers themselves need to know how to maintain relationships without the day to day exposure to their colleagues.  Moving to a telework culture requires planning and insight.  Here are a few things to consider.

Remote Workers Need To Be Engaged

I do my best to follow the rule of communicating with people in the medium that they prefer. I trade a lot of email with the people who, like me, are always on it; I pick up the phone for the people who aren’t; I text message with the staff that live on their smartphones. But, with a remote employee, I break that rule and communicate, primarily, by voice and video.  Emoticons don’t do much to actually communicate how you feel about what your discussing.  Your voice and mannerisms are much better suited for it.  And having an employee, or teammate, that you don’t see on a regular basis proves the old adage of “out of sight, out of mind”.

 In Person Appearances Are Required

For the remote worker to truly be a part of the organization, they have to have relationships with their co-workers.  Accordingly, just hiring someone who lives far away and getting them started as a remote worker might be the worst thing that you can do for them.  At a minimum, requiring that they work for two to four weeks at the main office as part of their orientation is quite justified.  For staff who have highly interactive roles, you might require a year at the office before the telework can commence.

Once the position is remote, in-person attendance at company events (such as all staff meetings and retreats) should be required. When on-site isn’t possible, include them via video or phone (preferably video). On-site staff need to remember them, and not forget to include them on invites. Staff should make sure that they’re in virtual attendance once the event occurs.

Technical Literacy Requirements Must Be High

It’s great that the remote access tech is now so prevalent, but the remote worker still needs to be comfortable and adept with technology.  If they need a lot of hand-holding, virtual hands won’t be sufficient.  Alternatively, the company might require (and/or assist with) obtaining local tech support.  But, with nonprofit IT staffing a tight resource, remote technophobes can make for very time-consuming customers. Establishing a computer-literacy test and making it a requirement for remote work is well-advised; it will ease a lot of headaches down the road.

Get The Policies In Place First

Here’s what you don’t want: numerous teleworkers with different arrangements.  Some have a company-supplied computer, some don’t.  The company pays for one person’s broadband account, but not another’s. One person has a company-supplied VOIP phone, the other uses their personal lines. I’ve worked at companies where this was all subject to hiring negotiations, and IT wasn’t consulted. What a nightmare! As with the office technology, IT will be much more productive if the remote setups are consistent, and the remote staff will be happier if they don’t feel like others get special treatment.

Go Forth And Telecommute

Don’t let any of this stop you — the workforce of the future is not nearly as geography bound as we’ve been in the past, and the benefits are compelling.  But understand that company culture is a thing that needs to be managed, and managed all the more actively when the company is more virtual.

Category: Management, nptech, software, strategy, techcafeteria, tools | Comments Off
May 21

Why I Hate Help Desk Metrics

image
Photo: birgerking

Tech support, as many of you know, can be a grueling job.  There are a huge variety of problems, from frozen screens to document formatting issues to malware infestations to video display madness.  There are days when you are swamped with tickets.  And there are customers that continually broaden the scale from tech-averse to think-they-know-it-all. I’ve done tech support and I’ve managed tech support for most of my career, and providing good support isn’t the biggest challenge.  Rather, it’s keeping the tech support staff from going over the edge.

In our nptech circles, it would be natural to assume that having good metrics on everything help desk would assist me in solving these problems. Good metrics might inform me regarding the proper staffing levels, the types of expertise needed, the gaps in our application suites, all that good stuff that can support my budgeting and strategy. But once I start collecting them I open myself up to that imminent threat that someone else in management (my boss, the board, or whomever) might want to see the metric, too. They want to see are metrics like:

  • Average tickets and calls per day
  • Number of open tickets
  • Average time to resolve a ticket

Their idea is that these numbers will tell them how productive the tech support staff are, how efficient, and how successful they are at resolving problems.

Every one of these is a unreliable metric.  Alone or together, they don’t tell a meaningful story. Let’s take them one by one:

Average daily tickets: This is a number that is allegedly meaningful as it rises and falls.  If we have 30 tickets a day in January, and 50 a day in February, it means something.  But what?  Does it mean that IT is being more productive?  Does it imply that there are more issues popping up? Is it because more people are feeling comfortable about calling the help desk?  If we drop to 15 in February, what does that mean?  That IT has stabilized a lot of problems, or that the users have figured out that others in the org are more helpful than IT?

Number of open tickets: The standard assumption is that fewer is better.  And while that is generally true, it can be deceiving, because the nature of tickets varies dramatically.  Some require budget approvals and other time-consuming delays.  An assumption that tickets are open because the technician hasn’t gotten around to resolving them is often wrong.

Average time to resolve a ticket:  This one is deadly. Because it is commonly used as a performance metric, and that’s based on the assumption that the quicker all tickets are closed, the better service IT is providing.  The common scenario I’ve encountered where this metric is shared with management is that the tech support staff grow so pressured to close tickets that they regularly close them before the issue is truly resolved.  It creates tension with staff, as the real power of a help desk ticketing system is in the communication that it enables, not the communication that it cuts off when staff are not geared toward taking a communicative approach to issue resolution.

Worse, it takes away the technician’s ability to prioritize.  Every ticket must be closed quickly in order to look efficient, so every ticket is a priority.  But, in fact, many tickets aren’t high priority at all.  People often want to report computer problems that they aren’t in a hurry to get resolved.  When every ticket is treated like a fire to be put out, staff, naturally, start getting resistant to shouting “fire”, and stop reporting that annoying pop-up error that they get every time they log in.  They start living with all of the little things that they have inconvenient but bearable workarounds for, and as these pile up, they grow more and more annoyed with their computers — and tech support.

So what might useful metrics to assess the effectiveness of tech support entail? Here’s what I look for:

  • Evidence that the techs are prioritizing tickets correctly. They’re jumping when work stoppage issues are reported and taking their time on very low priority matters.
  • Tickets in the system are well-documented. We’re capturing complex solutions and noting issues that could be reduced with training, fine-tuning or a software upgrade.
  • Shirts are tucked in, hair isn’t mussed, nobody is on the verge of tears. High stress on support techs is usually plain to see.

The type of person that gravitates to a tech support job is a person that likes to help. There are egos involved, and an accompanying love of solving puzzles, but the job satisfaction comes from solving problems, and that’s exactly what we want our support staff to do. Creating an environment where the pressure is higher to close tickets than it is to resolve them is a lose-lose scenario for everyone.

Category: Management, nptech, software, strategy, techcafeteria | Comments Off
May 14

Working With Proposal Requests Collaboratively

Okay, I know that it’s a problem worthy of psychoanalysis that I’m so fascinated with the Request for Proposal (RFP) process. But, hey, I do a lot of them. And they do say to write about what you know.

The presentation that I gave at NTEN’s conference in March focused on the process of developing and managing RFPs. I made the case that you want to approach a vendor RFP very differently than you would a software/system RFP. I pushed for less fixed bid proposals, because, in many cases, asking for a fixed bid is simply asking for a promise that will be hard to keep. ROI involves far more than just the dollars spent on projects like CRM deployments and web site revamps.

In the session, I learned that Requests for Information (RFIs), which are simpler for the vendors to respond to, can be a great tool for narrowing a field.  It’s important that clients are respectful of the fact that vendors don’t get paid to respond to proposals; they only get paid if they win the bid, and showing respect on both sides at the very glimmer of an engagement is a key step in developing a healthy relationship.

Since the conference, I’ve gotten a bit more creative about the software that we use to manage the RFP process, and I wanted to give a shout-out to the tools that have made it all easier.  There are alternatives, of course, and I still use the Microsoft apps that these have replaced on a daily basis for other work that they’re great at. But the key here is that these apps live in the cloud and support collaboration in ways that make a tedious process much easier.

Google Docs is replacing Microsoft Word as my RFP platform software. The advantages over Word are that I can:

  • Share the document with whomever I choose; the whole world or a select set of invitees. Google’s sharing permissions are very flexible. With Word, I had to email and upload a document; with Google Docs I only have to share a link.
  • I can share it as a read-only document that they can comment on. This simplifies the Q&A portion of the process, while maintaining the important transparency, as all participants can see every question and response.

We recently did an RFI for web development (it’s closed now, sorry!) and here’s what it looked like, exactly.

Smartsheet is replacing Microsoft Excel as my response matrix platform.

Example of a Smartsheet matrix

The first step upon receiving responses to a request is always to put them all in a spreadsheet for easy comparison.  Smartsheet beats Excel because it’s multi-user and collaborative. Since Smartsheet is a Spreadsheet/form builder/project management mashup app, I can add checkboxes and multiple choice fields to my matrix.

For simple proposals, you can also easily use Smartsheet to collect reviewer comments and votes. Just add a few columns (two for each reviewer). This puts the matrix and evaluation criteria all in one place, that can easily be exported to spreadsheet or PDF in order to document the decision.

Surveymonkey has replaced Excel for cases when the evaluation criteria is more complex than a yes/no vote. Using their simple but sophisticated questionnaire builder, you can ask a number of questions with weighted or scaled answers. The responses can be automatically tallied and, as with Smartsheet, exported to Excel for further analysis or published as charts to a PDF.

Consultant Selection Chart

As I’ve ranted elsewhere, making a good investment in software and vendor evaluation has a big impact on how successful a project will be.  Working with staff who are impacted by the project in order to choose the partner or technology increases buy-in and the validity of the initiative in the eyes of the people that will make or break it. And a healthy process insures that you are purchasing the right software or hiring the right people.  These tools help me make that process easier and more transparent.  What works for you?

Category: 14ntc, Management, nptech, software, strategy, techcafeteria, tools | Comments Off
April 26

Debating Proper Project Management Discipline

I just had a fun, spirited debate on Twitter about the definition of a project. It started when a friend of mine tweeted this:

Now, my team at Legal Services Corporation recently finished a project (at least, that’s what I call it) to redesign the Find Legal Aid lookup on our website.  I blogged about that effort, which was kickstarted by the DC Legal Hackers, on LSC’s tech blog.  A few things about this:

  • There was no deadline.
  • It was something that we could have outsourced completely, but we wanted to learn the underlying technologies.
  • It was low priority, and my lead developer had a lot of more critical, time-sensitive  projects on his plate.

So we didn’t set a deadline. We pitched the project to management with clear goals (a charter).  After the initial development was done at the DC Legal Hacker’s first hackathon, we identified the four person team that would work on it internally. We reported on it weekly, during our project review.  And we rolled it out when it was finished.

On seeing Norman’s tweet, I challenged the notion that a deadline is a required element of a project. Mind you, many agile programmers work with the bias that iterating until it’s done correctly is more important than meeting a deadline. I doubt that they can actually sell that to their internal or paying clients often, of course.

So I threw my two cents in:

— Peter Campbell (@peterscampbell) April 24, 2014

which brought this reply from someone that I assume is, unlike me, a certified Project Manager, and therefore better versed and disciplined in the best practices:


So, here I am, coming off of a highly successful development and rollout of our little webapp, being told that it wasn’t a valid project.  The entire tweetstream is copied below, but here are the points that I want to make that go a bit beyond Twitter’s 140 requirement.

  • The Project Management Institute (PMI) awards Project Management Professional (PMP) certification to those who complete the requisite hours managing projects and pass the test. I’ve completed their requisite hours, and I’ve taken most of the test prep classes, but I’ve never gotten around to taking the test. So I agree with Rebel that their definition of a project requires a deadline. But I don’t agree with their definition.
  • As with many certifications, what you have to say to pass the test is not always what is going to work in the real world. My first career was working as a cook/sous chef, which I did through most of my very late teens and twenties.  As with technology, I was mostly self-taught. I’ll never forget one day, when working in a French restaurant in Cambridge, Mass., a fresh graduate of the Culinary Institute of America came on board. He didn’t last his first night on the job.  This guy could make some wonderful, complex recipes, but he was overwhelmed when he hit 15 to 20 orders on the wheel. I get the PMI reasoning, but I’ve adapted it over the years in my nonprofit environments where we don’t have the staff or budget to do things to the letter.
  • I absolutely value the governance of a project management discipline.  I firmly believe that you need to recognize targets and milestones if you want to push forward. My tolerance for “no deadline” is in rare cases like the one above. In particular, I need to have work schedules so that large projects don’t end up piling on top of each other.
  • But the trick to successfully getting a lot of things done well in what we call “a constrained resource environment” (e.g. any nonprofit and most of everything else) is to not let the governance get in the way of getting things done. So I take or leave parts of it, being more formal when there’s more at stake and absolutely informal when it doesn’t threaten our outcomes.

I might get that PMP certification someday, although, at this point, it might be when I retire.  But, with a few exceptions, I have a good track record of overseeing some great accomplishments in my career, and I expect that to continue until the day that I can retire.  And I’ll do it by applying appropriate standards and bucking them when they get in the way of the end goal.

Here’s the tweetstream:

 

April 17

Three Ways To Make Sure that Your Next Big Software Project Is A Success

This post also appeared on the Cloud for Good Blog today.

Buying a new fundraising CRM or replacing your finance and HR systems are big investments with critical outcomes. These are the types of projects can have a huge impact on your ability to accomplish your mission. Poorly planned, chosen and deployed, they will do the opposite. If you’re grasping for a cautionary tale, just look at the recent Healthcare.gov rollout, or the worse related stories in Maryland and Oregon. But successful implementations happen every day as well, they just don’t grab as many headlines.

How can you make sure that big software projects succeed?  Here are three recommendations:

1. Know what you need

All too often, the decision to replace a system is based more on frustrations with your current system than identified improvements that a new system might bring.  And, far too often, those frustrations aren’t really based on the capabilities of your existing system, but, instead, on the way that it was configured.  Modern software is highly configurable.  In nonprofit environments, where administrative staffing is low and people are juggling multiple priorities, the proper investment in that configuration is sometimes skipped. It’s important that you take the time to thoroughly catalogue your current processes and goals; clearly identify your reporting needs; and establish your core requirements before you embark for this sort of project.

Technology automates processes. If you automate bad processes, you get bad technology.  So making an investment in business process mapping, and taking the time to streamline and enhance the way you work with information today will insure that you know what your new system should be doing for you as you configure it.

2. Be prepared to change the way you do things

Ideally, you’ll invest in software that does exactly what you want it to do for you. In reality, there will be limitations in the way that the software was programmed, or the way that it has to be configured in order to integrate with your other applications, that will be out of sync with your preferences. Software doesn’t have a mind of it’s own; instead, it inherits the assumptions and biases of the developers that created it. They might assume, for instance, that you collect donations from individuals and have no need to recognize households in your system. Or they might assume that your average employee turnover is less than 20%, whereas, at a workforce development agency that hires its clients, 50% is more on the mark.  If the best system you can find suffers from some of these limitations,. you will have to either work around them, or buy the second best system, if it requires fewer workarounds, because you do want to minimize them.

Regardless, you’ll want to understand the underlying assumptions in the application and have a strategy for working around them. Some companies will go so far as to commission or design their own systems (commonly called “build” vs “buy”), but you need to weigh the cost of having a supported system vs. a homegrown one, because, unless what you do is truly unique, those will not be worthwhile trade-offs.

3. Hire a consultant for their expertise and compatibility, not their billing rate

We all want to get these projects done for as little money as possible. So there’s a tendency to hire consultants based on the lowest bid. I’d caution against this. major system configuration projects are generally open-ended — determining the exact configuration and number of hours that it will take to get there before the project starts is akin to inviting the whole city to a dinner party and determining the number of plates that you’ll require before anyone RSVPs. So you want to work with consultants who are very efficient at their work, and very conversant with your needs. What you don’t want to do is hand your project to a consultant who doesn’t really understand your requirements, but has their own idea as to how it should be done.  You could well be left with a system that met the budget, but not your needs, or one that exceeded the budget while being reworked to satisfy your requirements. A good consultant will work closely with you.  they’ll spend more time meeting with staff to learn about your needs then they will setting up the project, but they’ll set it up quickly and correctly based on their thorough understanding of your goals and needs. The hourly rate might be double the low bid, but the total cost could be equivalent, resulting in a usable system that will compensate for the initial dollar outlay all that much faster.

Here are slides that I developed for a talk/discussion on creating Requests for Proposals that vendors will appreciate at the recent Nonprofit Technology Conference.  These include some key strategies for making sure that you hire the right person or firm.

In conclusion, how you go about a software project has far more to do with how you conduct your business than it does with the actual technology.  Make sure that you’re investing wisely by taking the time to understand your needs, know where you can compromise, and hire the best partners.

Category: 14ntc, Management, Miscellany, nptech, software, strategy | Comments Off
May 31

Everything That You Know About Spam Is Wrong

Image: Vince LambImage: Vince Lamb

At least, if everything you know about it is everything that I knew about it before last week. I attended an NTEN 501TechClub event where Brett Schenker of Salsa Labs spoke on how the large mail services identify Spam emails.  It turns out that my understanding that it was based primarily on keywords, number of links and bulk traits is really out of date.  While every mail service has their own methods, the large ones, like GMail and Yahoo!, are doing big data analysis and establishing sender reputations based on how often their emails are actually opened and/or read. You probably have a sender score, and you want it to be a good one.

Put another way, for every non-profit that is dying to get some reasonable understanding of how many opens and clicks their newsletters are getting, Google could tell you to the click, but they won’t.  What they will do is judge you based on that data.  What this really means is that a strategy of growing your list size could be the most unproductive thing that you could do if the goal is to increase constituent engagement.

As Brett explained (in a pen and paper presentation that I sadly can not link to), if 70% of your subscribers are deleting your emails without opening them, than that could result in huge percentages of your emails going straight to the spam folder.  Accordingly, the quality of your list is far more critical than the volume. Simply put, if you send an email newsletter to 30,000 recipients, and only 1000 open it, your reputation as a trustworthy sender drops.  But if you send it to 5000 people and 3500 of them open it, you’ve more than tripled the engagement without soiling your email reputation.

I know that this goes against the grain of a very established way of thinking.  Percentage of list growth is a simple, treasured metric.  But it’s the wrong one.

Here’s what you should do:

  • Make sure that your list is Opt-In only, and verify every enrollment.
  • Don’t buy big lists and mail to them. Just don’t! Unless you have solid reasons to think the list members will be receptive, you’ll only hurt your sender score.
  • Put your unsubscribe option in big letters at the top of each email
  • Best of all, send out occasional emails asking people if they want to keep receiving your emails and make them click a link if they want to.  If they don’t click it, drop them.
  • Keep the addresses of the unsubscribed; inviting them to reconnect later might be a worthwhile way to re-establish the engagement.

Don’t think for a minute that people who voluntarily signed up for your lists are going to want to stay on them forever.  And don’t assume that their willingness to be dropped from the list indicates that they’ll stop supporting you.

Even better, make sure that the news and blog posts on your web site are easy to subscribe to in RSS.  We all struggle with the mass of information that pushes our important emails below the fold.  Offering alternative, more manageable options to communicate are great, and most smartphones have good RSS readers pre-installed.

One more reason to do this?  Google’s imminent GMail update, which pushes subscriptions out of the inbox into a background tab.  If most people are like me, once the emails are piling up in the low priority, out of site subscriptions tab, they’ll be more likely to be mass deleted.

March 15

Google Made Me Cry

Well, not real tears. But the announcement that Google Reader will no longer be available as of July 1st was personally updating news.  Like many people,  over the last eight years, this application has become as central a part of my online life as email. It is easily the web site that I spend the most time on, likely more than all of the other sites I frequent combined, including Facebook.

What do I do there? Learn. Laugh. Research. Spy. Reminisce. Observe. Ogle. Be outraged. Get motivated. Get inspired. Pinpoint trends. Predict the future.

With a diverse feed of nptech blogs,  traditional news,  entertainment, tech, LinkedIn updates, comic strips and anything else that I could figure out how to subscribe to,  this is the center of my information flow. I read the Washington Post every day,  but I skim the articles because they’re often old news. I don’t have a TV (well, I do have Amazon Prime and Hulu).

And I share the really good stuff.  You might say, “what’s the big deal? You can get news from Twitter and Facebook”  or “There are other feed readers.”

The big deal is that the other feed readers fall in three categories:

  1. Too smart: Fever
  2. Too pretty: Feedly, Pulse
  3. Too beta: Newsblur, TheOldReader
“Smart” readers hide posts that aren’t popular, assuming that I want to know what everyone likes, instead of research topics or discover information on my own. There’s a great value to knowing what others are reading; I use Twitter and Facebook to both share what I find and read what my friends and nptech peers recommend.  I use my feed reader to discover things.
Pretty readers present feed items in a glossy magazine format that’s hard to navigate through quickly and hell on my data plan.
The beta readers are the ones that look pretty good to me, until I have to wait 45 seconds for a small feed to refresh or note that their mobile client is the desktop website, not even an HTML5 variant.

What made Google Reader the reader for most of us was the sheer utility.  My 143 feeds generate about 1000 posts a day.  On breaks or commutes, I scan through them, starring anything that looks interesting as I go.  When I get home from work, and again in the morning, I go through the starred items, finding the gems.

Key functionality for me is the mobile support. Just like the web site, the Google Reader Android app wins no beauty contests, but it’s fast and simple and supports my workflow.

At this point, I’m putting my hopes on Feedly, listed above as a “too pretty” candidate.  It does have a list view that works more like reader does.  The mobile client has a list view that is still too graphical, but I’m optimistic that they’ll offer a fix for that before July.  Currently, they are a front-end to Google’s servers, which means that there is no need to export/import your feeds to join, and your actions stay synced with Google Reader (Feedly’s Saved Items are Google’s Starred, wherever you mark them).  Sometime before July, Feedly plans to move to their own back-end and the change should be seamless.

July is three months away. I’m keeping my eyes open.  Assuming that anyone who’s read this far is wrestling with the same challenge, please share your thoughts and solutions in the comments.