Monthly Archives: November 2014

Why I’m Intrigued By Google’s Inbox

Google Inbox logoHere we go again! Another communication/info management Google product that is likely doomed to extinction (much like recent social networks I’ve been blogging about), and I can’t help but find it significant and important, just as I did Google Wave, Google Buzz, and the much-loved Google Reader. I snagged an early invite to Google’s new “Inbox” front-end to GMail, and I’ve been agonizing over it for a few weeks now.  This app really appeals to me, but I’m totally on the fence about actually using it, for a few reasons:

  • This is either a product that will disappear in six months, or it’s what Gmail’s standard interface will evolve into.  It is absolutely an evolved version of recent trends, notably the auto-sorting tabs they added about a year ago.
  • The proposition is simple: if you let Google sort your mail for you, you will no longer have to organize your mail.

I’ve blogged before about how expensive an application email is to maintain, time-wise. We get tons of email (I average over a hundred messages a day between work and home), and every message needs to be managed (deleted, archived, labeled, dragged to a folder, etc.), unlike texts and social media, which you can glance at and either reply or ignore. The average email inbox is flooded with a wide assortment of information, some useless and offensive (“Meet Beautiful Russian Women”), some downright urgent (“Your Aunt is in the Hospital!”), and a range of stuff in-between. If you get 21 messages while you’re at an hour-long meeting, and the first of the 21 is time-sensitive and critical, it’s not likely the first one that you are going to read, as it has scrolled below the visible part of your screen. The handful of needles in the crowded haystack can be easily lost forever.

Here’s how Inbox tries to make your digital life easier and less accident-prone:

  • Inbox assumes (incorrectly) that every email has three basic responses: You want to deal with it soon (keep it in the inbox); you want to deal with it later (“snooze” it with a defined time to return to the inbox); or you want to archive it. They left out delete it, currently buried under a pop-up menu, which annoys me, because I believe that permanently deleting the 25% of my email that can be glanced at (or not even opened) and deleted is a cornerstone of my inbox management strategy. But, that nit aside, I really agree with this premise.
  • Messages fall in categories, and you can keep a lot of the incoming mail a click away from view, leaving the prime inbox real estate to the important messages. Inbox accomplishes this with “Bundles“. which are the equivalent to the presorted tabs in Classic GMail.  Your “Promotions”, Updates” and “Social” bundles (among other pre-defineds) group messages, as opposed to putting each incoming message on it’s own inbox line. I find the in-list behavior more intuitive than the tabs. You can create your own bundles and teach them to auto-sort — I immediately created one for Family, and added in the primary email addresses for my immediate loved ones.  We’ll see what it learns.
  • Mail doesn’t need to be labeled (you can still label messages, but it’s not nearly as simple a task as it is in GMail classic). This is the thing I’m wrestling with most — I use my labels.  I have tons of filters defined that pre-label messages as they come in, and my mailbox cleanup process labels what’s missed. I go to the labels often to narrow searches. I totally get that this might not be necessary — Google’s search might be good enough that my labeling efforts are actually more work than just searching the entire inbox each time. But I’m heavily invested in my process.
  • Highlights” act a bit like Google Now, popping up useful info like flight details and package tracking.

One important note: Inbox does nothing to alter or replace your Gmail application.  It’s an alternative interface. When you archive, delete or label a message in Inbox, it gets archived, deleted or labeled in GMail as well, but Gmail knows nothing about bundles and, therefore, doesn’t reflect them, and not one iota of GMail functionality changes when you start using Inbox.  You do start getting double notifications, and Inbox offered to turn off GMail notifications for me if I wanted to fix that. I turned Inbox down and I’m waiting for GMail to make a similar offer.  😉

So what Inbox boils down to is a streamlined, Get Things Done (GTD) frontend for GMail that removes email clutter, eases email management, and highlights the things that Google thinks are important. If you think Google can do that for you reasonably well, then it might make your email communication experience much saner. You might want to switch to it.  Worse that can happen is it goes away, in which case Gmail will still be there.

I have invites.  Leave a comment or ping me directly if you’d like one.

If you’re using Inbox already, tell me, has it largely replaced GMail’s frontend for you?  If so, why? If not, why not?

 

Should You Outsource Your IT Department?

This post was originally published on the MAP Techworks Blog in November of 2014. 

agreement-303221_640For a nonprofit that’s reached a size of 25 or more staff, a key question revolves around how to support technology that has grown from a few laptops and PCs to a full-blown network, with all of the maintenance and troubleshooting that such a beast requires. Should you hire internal IT staff or outsource to a more affordable vendor for that support? I’d say that the key question isn’t should you — that’s more a matter of finances and personal preferences. But what you outsource and how you go about it are critical factors.

The IT departments that I’ve worked on provided a range of services, which I’ve always broken down into two broad categories.  The first is the plumbing: computer maintenance, installation, database input, training, and tech support.  These functions can, with a few caveats, be successfully outsourced. The caveats:

  • You can’t just hire the outsourced IT firm and expect them to understand your needs after an initial meeting and walk-through.  They should be micro-managed for the first month or two.  Their inclination will be to offer a generic level of support that may or may not work for your application mix or your company culture. Orient them; set clear expectations and priorities; and check their work for a good while. If you don’t, your staff might immediately lose faith in them, setting up a situation where they don’t use the service you’re paying for and, when they do interact, do it begrudgingly.  The outsourced staff should be on your team, and you need to invest in onboarding them.
  • Everyone has to remember that it’s your network. Don’t give the outsourced service the keys to your kingdom.  You should keep copies of all passwords and they should understand that changing a system password without your prior knowledge, consent, and an updated password list is a fire-able offense.  And be ready to fire them — have a backup vendor lined up.

The other bucket is strategic tech planning. In-house infrastructure or cloud. Data management strategy. How tech integrates into a broader strategic plan and supports the mission.  How tech plays into the strategies of our partners, our clients, and our communities. These components can benefit from the advice of a good consultant, but are too integral to the work and culture of an organization to be handed off to outsiders wholesale.

Outsourcing your tech strategy can be a dangerous gamble.  If you have a great consultant who really cares about your mission, they can offer some good advice. But, in most cases, the consultants are more interested in pushing their tech strategy than developing one that works well with your organizational culture.  I find that my tech strategy is heavily informed by my understanding of my co-workers, their needs, and their ability to cope with change.  To get all that from outside of an organization requires exceptional insight.

Let me make that point another way — if you don’t have a tech strategist on your internal, executive team, you’re crippled from the start. These days, it’s as essential as having a development director and a finance person. Consultants can inform and vet your ideas, but you can’t outsource your tech strategy wholesale to them. It’s core to the functionality of any successful nonprofit.

The right outsourcer can be cost effective and meet needs. But be very thorough in your selection process and, again, do some serious onboarding, because your dissatisfaction will be tied completely to their lack of understanding of your business and your needs. There are a number of NP-specific vendors (Map for Nonprofits, former NPowers and others, like DC’s CommunityIT) that get us and are better choices, in general, than the commercial services.

Does Your Request For Proposal (RFP) Ask The Right Questions?

This post was originally published on the Community IT Innovators Blog in November of 2014.

foler-29373_640Requests for Proposals (RFPs) are a controversial topic in the nonprofit sector. While governmental and corporate organizations use them regularly as a tool to evaluate products and services, their use in our sector is haphazard. I spoke recently about the RFP process and how it could work for us at the 2014 Nonprofit Technology Conference. My slides from that talk are here, along with this blog post outlining my key arguments in favor of RFPs. But a recent conversation on NTEN’s DC community list really summed up the topic.

A member posted an RFP for CRM consulting and asked why he was getting scant responses from the vendors. I looked over the RFP, and saw that it requested a fixed bid quote for work that was not well defined. I popped back into the forum with some comments:

“This five page RFP contains about a tenth of the information that a decent consultant would need in order to propose a meaningful bid for the work. If you’ve received any such bids already, I would advise you to throw them out, because those bids are wild guesses, and you will either be paying more than you need to, or setting yourself up for a combative relationship with a vendor who is angry that the project is taking far more hours than they guessed that it would. Decent consultants are passing on the RFP because it lacks so much specificity. There are two ways you could address this problem:

  1. Significantly beef up the RFP. If I were to go this route, I might hire a consultant to help me write the RFP, because they can better communicate the requirements than I could.
  2. Stop asking for a fixed bid. Query their expertise in the areas that need it, and request ample examples of work they’ve done. Also, ask for their hourly fees by role. The RFP can provide a fairly high-level overview of the project, as you won’t be asking them to generate a meaningful estimate. Instead, do reference checks and ask specific questions about their billing in order to vet that they are honest and sensitive to nonprofit budgets.

Many consultants would pop in here and say “forget the RFP – let us come talk with you and get a sense of the project and we can go from there.” As a customer, not a consultant, I wouldn’t go for that. A good RFP, sent before any face to face meetings, can tell you a lot about the professionalism, insight and care that a company will bring to your project.  Rapport and relationship are also critical, but assessing those elements is the second step. (And when it comes to that step, insist that you are meeting the people who you would almost certainly be working with). An RFP response can also be attached to the contract to make sure that the vendor is obliged to live up to their claims.

I do fixed-bid quotes for phone systems and virtualization projects, where I can tell them exactly what the project would entail. I don’t for websites and software development, because not only do I not know what the ultimate product will look like or require, I shouldn’t – a lot of learning takes place during the project that will shape the requirements further. Once I’ve hired a good consultant, we can do a defined discovery phase that will allow them to provide a fixed quote — or reasonable range — for the rest of the work.  It’s a much better way to set up the relationship than by basing it in unrealistic projections.”

Subsequently, a consultant posted a reply suggesting that RFPs are a pain, and they should really just hire a consultant they like and see if it works out, perhaps after doing a small Request for Information (RFI) to learn more about the consultants available. I replied:

I did say that consultants will often dis the RFP process and say, “just hire us and see if it works out.”  It certainly is easier on the consultant. As Clint Eastwood would say, the question is, “do you feel lucky?” Because if you feel lucky, then you can just find a suitable-looking consultant and hope that they are ethical, not over-booked (and therefore liable to under-prioritize your project), experienced with the technology that they’re deploying, etc, and do a discovery phase that will cost you x thousands of dollars, and then find out if they are the right consultant for you. Or you can do an RFP, throw out the responses that clearly don’t match your requirements, throw out the ones that don’t seem interested or well-resourced enough to respond fully, and interview the two to four consultants that look like good matches. It’s more work up front than hiring someone and hoping they’ll work out, true, but, here’s what it gets you:

  1. Focused. Just writing the RFP gets you more in touch with the goals and requirements for the project.
  2. Informed. The RFP review and interviews are a chance for the project team to explore the project possibilities with various experts.
  3. Confident. Without investing thousands of dollars into a “vendor test,” you will know who has the right experience and a compatible approach. For me, it’s often less about the skill and experience than the approach (e.g., we want a collaborative partner that would teach as they go, rather than experts to outsource the work to).
  4. Accountable. The RFP can be a contractual document, so if the vendor lied about what they can do, they can be held responsible for that lie. And, not all consultants lie, but some do. I’ve caught them at it.  😉
  5. Documented. In the future, after you’ve left the organization, your successors might wonder why you selected the partner that you did. The RFP process leaves a knowledge management trail for key organizational decision making.

And finally, RFI vs RFP is a question of scale.  For smaller projects, without much associated risk, RFI. The investment in doing a full RFP does have to be justified by the cost and complexity of the project. For big projects, doing an RFI in order to identify who you want to include in an RFP can be helpful.

——————–

Community IT Innovators are a DC consulting and outsourcing firm located in Washington, DC.  Their blog is a great source of good tech advice, with similar themes (but more expert advice, less over-indulgent opinion) as mine.