Tag Archives: management

13 Lessons On Building Your Nonprofit Technology Culture

This article originally appeared on the Exponent Partners blog on December 19th, 2014. It was written by Kerry Vineburg, based on a phone interview with me.

EXPONENT PARTNERS SERIES: SMART PRACTICES

Is your nonprofit thinking about implementing a large database project like Salesforce? Nonprofit and technology veteran Peter Campbell, CIO at Legal Services Corporation, recently shared his valuable insights on how to prepare your team and culture for long-term success. His organization, the top funder of civil legal aid for low-income Americans in the country, is developing Salesforce as a data warehouse for their grantee information and document management. 

We asked Peter to tell us more about what practices he uses to help ensure a successful technology implementation. As you’ll see, it’s just as much about working with people! 

Embarking On Your Project

1. When beginning a technology project, agree on the problem you’re solving, that all staff can relate to. Organizational readiness is critical. I’ve worked at organizations that didn’t recognize that their casual approach to data management was a problem, and they weren’t looking for a solution. If your staff don’t understand why they need an application, then you’re in danger of installing something that won’t be utilized. When starting a new organizational project, I identify 2-3 core bullet points that will explain the goals of the project, and repeat them often. For example: “The new system will provide one-step access to all information and documents related to a grantee.” That’s the high-level goal. It should be something where the product users all agree, “Yes, I need that!”
2. When planning technology upgrades and projects, schedule the changes. Plan for gradual change. Early in my career, I had to deal with the Y2K bug and replace every system at a mid-sized law firm in a short period. It led me to this philosophy: replace only one major system each year. It’s a myth that people hate change — people hate disruption. Change is good, but needs to be managed at steady level. If you’re doing regular implementations every year, people can get used to that pace. If you do nothing for 3 years, then switch out everything: 1) you’re putting too much of a burden on your implementers to achieve everything at once and 2) you’re making too big of an imposition on staff. Suddenly, everything they know is gone and replaced.

Getting Buy-In

3. Gain full executive sponsorship. There’s a common misconception that a new system will just work for you once it’s installed. To fully realize the benefits of a CRM requires cultural change. Every level of the organization needs to buy into the project. You’ll need to harness a lot of attention and energy from your team to develop requirements, manage the project, learn the new system and adapt processes. Otherwise, you’ll invest in a big database implementation and only one or two people will use it.
The importance of a major system upgrade should be set by the executive director and/or board. Everyone should know that the system is a priority. At nonprofits, our executive directors are often better at fundraising than managing a business, and many are somewhat technophobic. They don’t need to be technology gurus, but they do need to understand what the technology should be doing for them, and to take ownership of those goals. The last thing that I want to hear from my boss is, “Here’s a budget — go do what you think is best.” Without their interest in my projects, I’m bound to fail.
4. If one buy-in approach needs help, try a combo. If you can’t convince your executive director or other leadership to be regular active participants, power users can sometimes help convince your team. I’m not recommending an either/or approach, there should be some of both, but power users can engage staff in cases where management isn’t setting clear expectations. For any project that impacts staff, I will invite key users to be on our evaluation team, help with product selection, and potentially be on our advisory committee during the project. For example, we have a grants department liaison, who is charged with getting the right people in the room when we need input from the staff that know much better than we do what the system should ultimately do for them.
5. Incorporate perspectives from around the table. In addition to power users, I also want feedback from “standard” users. Maybe they don’t love technology so much, and maybe they wouldn’t volunteer for this. But they have an important perspective: you need to understand their reactions and what they’re going to find difficult. As the IT director and CIO, I know important things about managing a project. The users know important things that I don’t. If we don’t have views from multiple sides of the table, the project will fail.

Working With Good People

6. Look for partners (vendors and consultants) who understand your mission, not just the technology. In the ideal situation, you want people who not only get database and programming work, but also really understand your mission and business priorities. I’m blessed to have developers on my team who not only understand grants management but are also sympathetic to what the people coming to them are trying to accomplish. When they get a request, they can prioritize with a good understanding of our organization’s requirements. They’re able to answer, “How can I make the most out of what this person needs with my available time?” while being skilled enough to capably choose between the technical options. Getting people that have a broader mindset than just technology is really important.
7. Vary your team and role strategy with your size. At nonprofits, we don’t usually have big internal teams. Someone becomes our accidental techie/database guru. Even large nonprofits are hurting for staff. It’s always been less “here’s the best practice and ideal way to staff this,” and more “let’s see what budget and people I have, and make it work as well as I can.” Not many nonprofits have developers on staff. Hiring can be challenging. It’s a popular skillset, and won’t be cheap. If you’re tiny, you probably won’t hire full-time, you’ll outsource to consultants. But if you have 30 people or more using the CRM, you might benefit from in-house expertise, even if it’s a half-time role.
If you already have developers on staff, that’s great. If they don’t have experience with, say, Salesforce, but they do know database design and a programming language or two, it’s not hard to pick up the concepts. You’re modeling a database, designing it, and then scripting on top of it in a similar language. They can probably adapt.
8. Practice good compensation and retention strategies for your technically savvy (and/or newly trained) staff. I’ve seen a trend over the past 10 years. A nonprofit decides to use a solution like Salesforce and they charge their accidental techie with the task of implementing. The accidental techie gets the implementation done, becomes a guru on it, trains all the users, and then because the organization is paying them an entry-level salary, they leave and go get a much higher paying job as a consultant! It’s a valuable skillset, so don’t be short-sighted about compensating them for what they do for you. You need to be careful and invest properly. Give them raises along with the skillset, to make sure they are fully motivated to stick with you.

Project Management

9. Avoid surprises with good communication. My rule of IT management now is: “No one should ever be surprised by anything I do.” From experience with good mentors, I learned important lessons about communication: if you’re going to make a change, communication is critical. Say it 3 times in 3 different mediums (in email, on the internet, on flyers on the wall on every floor!). Be sure staff know how the technology contributes to the well-being of the organization, rather than being a time-waster, so they are motivated to keep working with it. Communicate well.
10. If possible, hold out for the right team. I put off projects to have the right people in place, rather than hold tight to a project deadline with the wrong people in place. See above for how to find and keep the right people.

Training and Baking The Technology Into Your Culture

11. Don’t reinvent the wheel; take advantage of the ecosystem. It can be really common for staff not to reach out for help. They may feel like their job is to learn the technology on their own. They should know there are many resources available to them! For example, with Salesforce, I recommend making use of peer support in the community, the Power of Us Hub, and local user groups. When they do seasonal updates, they do a lot of webinars and are good about providing information about how the app is growing. Salesforce also offers training (the Salesforce Foundation discounts by half) and every consultant I’ve spoken with is capable of doing some customized training. I know that other technologies offer resources like this also. It also behooves anybody on staff to know the specific implementation that you’ve done.
12. Allocate a training budget. I always push to have a staff training budget. For my organization, we even hired for a role of training and implementation specialist. We wanted to have a person on staff whose full-time job was training and strategizing how users use software and how to involve them in the implementation process. This should be part of your budget. I can’t emphasize enough how important it is to have people in your organization who know how to train on your applications.
13. Engage staff and help them understand the big picture of the technology. It’s good to get your team working with the database early on in the process, learning what it’s capable of and what it looks like. Engage your users: get people involved in every step of the process, from selecting products to implementation to training and rollout. Make the product demos big group activities, so that everyone can envision how similar systems work and what they might do with the product beyond what they’re doing today. Beta-test your implementations, giving staff lots of opportunities to provide input. Take an Agile approach of regularly showing what you’re developing to the people who will be using it, and adjusting your development per their feedback.
With a committed team that understands your mission, great communication, well-allocated resources, and gradual change, your organization can lay the foundations for a successful solution that will actually be adopted!
Thanks to Peter Campbell for these great insights. Peter also blogs at techcafeteria.com
For even more strategies on ensuring that your culture is ready for your system, check out our free report Nonprofit Technology Adoption: Why It Matters and How to Be Successful.

– See more at: http://www.exponentpartners.com/building-your-nonprofit-technology-culture#sthash.QPFll78h.dpuf

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.

It’s Time For A Tech Industry Intervention To Address Misogyny

News junkie that I am, I see a lot of headlines.  And four came in over the last 30 hours or so that paint an astonishing picture of a  tech industry that is in complete denial about the intense misogyny that permeates the industry.  Let’s take them in the order that they were received:

First, programmer, teacher and game developer Kathy Sierra.  In 2007, she became well known enough to attract the attention of some nasty people, who set out to, pretty much, destroy her.  On Tuesday, she chronicled the whole sordid history on her blog, and Wired picked it up as well (I’m linking to both, because Kathy doesn’t promise to keep it posted on Serious Pony).  Here are some highlights:

  • The wrath of these trolls was incurred simply because she is a woman and she was reaching a point of being influential in the sector.
  • They threatened rape, dismemberment, her family;
  • They published her address and contact information all over the internet;
  • They made up offenses to attribute to her and maligned her character online;
  • Kathy suffers from epileptic seizures, so they uploaded animated GIFs to epilepsy support forums of the sort that can trigger seizures (Kathy’s particular form of epilepsy isn’t subject to those triggers but many of the forum members were).

The story gets more bizarre, as the man she identified as the ringleader became a sort of hero to the tech community in spite of this abhorrent behavior. Kathy makes a strong case that the standard advice of “don’t feed the trolls” is bad advice.  Her initial reaction to the harassment was to do just what they seemed to desire — remove herself from the public forums.  And they kept right after her.

Adria Richards, a developer who was criticized, attacked and harassed for calling out sexist behavior at a tech conference, then recounted her experiences on Twitter, and storified them here. Her attackers didn’t stop at the misogyny; they noted that she is black and Jewish as well, and unloaded as much racist sentiment as they did sexist.  And her experience was similar to Kathy Sierra’s.

These aren’t the only cases of this, by far.  Last month Anita Sarkeesian posted a vblog asking game developers to curb their use of the death and dismemberment of female characters as the “goto” method of demonstrating that a bad guy is bad. The reaction to her request was the same onslaught of rape and violence threats, outing of her home address, threats to go to her house and kill her and her children.

So, you get it — these women are doing the same thing that many people do; developing their expertise; building communities on Twitter, and getting some respect and attention for that expertise.  And ferocious animals on the internet are making their lives a living hell for it.  And it’s been going on for years.

Why hasn’t it stopped?  Maybe it’s because the leadership in the tech sector is in pretty complete denial about it.  This was made plain today, as news came out about two events at the Grace Hopper Celebration of Women in Computing conference running this week. The first event was a “White Male Allies Plenary Panel” featuring Facebook CTO Mike Schroepfer; Google’s SVP of search Alan Eustace; Blake Irving, CEO of GoDaddy; and Tayloe Stansbury, CTO of Intuit.  These “allies” offered the same assurances that they are trying to welcome women at their companies. A series of recent tech diversity studies show that there is a lot of work to be done there.  But, despite all of the recent news about Zoe Quinn, Anita Sarkeesian, etc., Eustace still felt comfortable saying:

“I don’t think people are actively protecting the [toxic culture] or holding on to it … or trying to keep [diverse workers] from the power structure that is technology,”

Later in the day, Satya Nadella, CEO of Microsoft, stunned the audience by stating:

“It’s not really about asking for the raise, but knowing and having faith that the system will actually give you the right raises as you go along.”

Because having faith has worked so well for equal pay in the last 50 years? Here’s a chart showing how underpaid women are throughout the U.S. Short story? 83% of men’s wages in the best places (like DC) and 69% in the worst.

Nadella did apologize for his comment. But that’s not enough, by a long shot, for him, or Eric Schmidt, or Mark Zuckerberg, or any of their contemporaries. There is a straight line from the major tech exec who is in denial about the misogyny that is rampant in their industry to the trolls who are viciously attacking women who try and succeed in it. As long as they can sit, smugly, on a stage, in front of a thousand women in tech, and say “there are no barriers, you just have to work hard and hope for the best”, they are undermining the efforts of those women and cheering on the trolls.  This is a crisis that needs to be resolved with leadership and action.  Americans are being abused and denied the opportunity that is due to anyone in this country. Until the leaders of the tech industry stand up and address this blatant discrimination, they are condoning the atrocities detailed above.

Postnote: The nonprofit tech sector is a quite different ballpark when it comes to equity among the sexes.  Which is not to say that it’s perfect, but it’s much better, and certainly less vicious. I’m planning a follow-up post on our situation, and I’ll be looking for some community input on it.

 

It’s Time To Revamp The NTEN Staffing Survey

cover_techstaffingreport_2014_smallNTEN‘s annual Nonprofit IT Staffing survey is out, you can go here to download it.  It’s free! As with prior years, the report structures it’s findings around the self-reported technology adoption level of the participants, as follows:

  • Stuggling orgs have failing technology and no money to invest in getting it stabilized. They have little or no IT staff.
  • Functioning orgs have a network in place and running, but use tech simply as infrastructure, with little or no strategic input.
  • Operating nonprofits have tech and policies for it’s use in place, and they gather input from tech staff and consultants before making technology purchasing and planning decisions.
  • Leading NPOs integrate technology planning with general strategic planning and are innovative in their use of tech.

The key metrics discussed in the report are the IT staff to general staff ratio and the IT budget as percentage of total budget.  The IT->general staff metric is one to thirty, which matches all of the best information I have on this metric at nonprofits, which I’ve pulled from CIO4Good and NetHope surveys.

On budgets, an average of 3% of budget to IT is also normal for NPOs.  But what’s disturbing in the report is that the ratio was higher for smaller orgs and lower for larger, who averaged 1.6% or 1.7%. In small orgs, what that’s saying is that computers, as infrastructure, take up a high percentage of the slim budget.  But it says that larger orgs are under-funding tech.  Per Gartner, the cross-industry average is 3.3% of budget.  For professional services, healthcare and education — industries that  are somewhat analogous to nonprofits — it’s over 4%.  The reasons why we under-spend are well-known and better ranted about by Dan Palotta than myself, but it’s obvious that, in 2014, we are undermining our efforts if we are spending less than half of what a for profit would on technology.

What excites me most about this year’s report is what is not in it: a salary chart. All of the prior reports have averaged out the IT salary info reported and presented it in a chart, usually by region.  But the survey doesn’t collect sufficiently detailed or substantial salary info, so the charts have traditionally suffered from under-reporting and averaging that results in misleading numbers.  I was spitting mad last year when the report listed a Northeastern Sysadmin salary at $50k.  Market is $80, and the odds that a nonprofit will get somebody talented and committed for 63% of market are slim.  Here’s my full take on the cost of dramatically underpaying nonprofit staff. NTEN shouldn’t be publishing salary info that technophobic CEOs will use as evidence of market unless the data is truly representative.

I would love it if NTEN would take this survey a little deeper and try and use it to highlight the ramifications of our IT staffing and budgeting choices.  Using the stumble, crawl, walk, run scale that they’ve established, we could gleam some real insight by checking other statistics against those buckets. Here are some metrics I’d like to see:

  • Average days each year that key IT staff positions are vacant. This would speak to one of the key dangers in underpaying IT staff.
  • Percentage of IT budget for consulting. Do leading orgs spend more or less than trailing? How much bang do we get for that buck?
  • In-house IT Staff vs outsourced IT management.  It would be interesting to see where on the struggling to leading scale NPOs that outsource IT fall.
  • Percentage of credentialed vs “accidental” techs. I want some data to back up my claim that accidental techies are often better for NPOs than people with lots of IT experience.
  • Who does the lead IT Person report to? How many leading orgs have IT reporting to Finance versus the CEO?

What type of IT staffing metrics would help you make good decisions about how to run your nonprofit? What would help you make a good case for salaries, staffing or external resources to your boss? I want a report from NTEN that does more than just tells me the state of nonprofit IT — that’s old, sad news.  I want one that gives me data that I can use to improve it.

 

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?

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.

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.

Career Reflections: My Biggest Data Fail

This article was published on the NTEN Blog in February of 2014.  It originally appeared in the eBook “Collected Voices: Data-informed Nonprofits“.

Peter Campbell of Legal Services Corporation shares his biggest data fail, and what he’d do differently now.

This case study was originally published along with a dozen others in our free e-book, Collected Voices: Data-Informed Nonprofits. You can download the e-book here.

Note: names and dates have been omitted to protect the innocent. 

Years ago, I was hired at an organization that had a major database that everyone hated. My research revealed a case study in itself: how not to roll out a data management system. Long story short, they had bought a system designed to support a different business model, and then paid integrators to customize it beyond recognition. The lofty goal was to have a system that would replace people talking to each other. And the project was championed by a department that would not have to do the data entry; the department identified to do all of the work clearly didn’t desire the system.

The system suffered from a number of problems. It was designed to be the kitchen sink, with case info, board updates, contact management, calendaring, web content management, and other functions. The backend was terrible: a SQL database with tables named after the tabs in the user interface. The application itself had miserable search functionality, no dupe checking, and little in the way of data quality control. Finally, there were no organizational standards for data entry. Some people regularly updated information; others only went near it when nagged before reporting deadlines. One person’s idea of an update was three to five paragraphs; another’s two words.

I set out to replace it with something better. I believed (and will always believe) that we needed to build a custom application, not buy a commercial one and tweak it. What we did was not the same thing that the commercial systems were designed to track. But I did think we’d do better building it with consultants on a high-level platform than doing it by ourselves from scratch, so I proposed that we build a solution on Salesforce. The system had over 150 users, so this would be relatively expensive.

Timing is everything: I made my pitch the same week that financial news indicated that we were diving into a recession. Budgets were cut. Spending was frozen.  And I was asked if I could build the system in Access, instead?  And this is when I…

…explained to my boss that we should table the project until we had the budget to support it.

Or so I wish. Instead, I dusted off my amateur programming skills and set out to build the system from scratch. I worked with a committee of people who knew the business needs, and I developed about 90% of a system that wasn’t attractive, but did what needed to be done reasonably well. The goals for the system were dramatically scaled back to simply what was required.

Then I requested time with the department managers to discuss data stewardship. I explained to the critical VP that my system, like the last one, would only be as good as the data put into it, so we needed to agree on the requirements for an update and the timeliness of the data entry. We needed buy-in that the system was needed, and that it would be properly maintained. Sadly, the VP didn’t believe that this was necessary, and refused to set aside time in any meeting to address it. Their take was that the new system would be better than the old one, so we should just start using it.

This was where I had failed. My next decision was probably a good one: I abandoned the project. While my system would have been easier to manage (due to the scaled back functionality, a simple, logical database structure and a UI that included auto-complete and dupe-checking), it was going to fail, too, because, as every techie knows, garbage in equals garbage out. I wanted my system to be a success.  We went on with the flawed original system, and eventually started talking about a new replacement project, and that might have happened, but I left the company.

Lessons learned:

  1. If I’m the IT Director, I can’t be the developer. There was a lot of fallout from my neglected duties.
  2. Get the organizational commitment to the project and data quality standards confirmed before you start development.
  3. Don’t compromise on a vision for expediency’s sake.  There are plenty of times when it’s okay to put in a quick fix for a problem, but major system development should be done right.  Timing is everything, and it wasn’t time to put in a data management system at this company.

How I Learned To Stop Worrying and Love The RFP

This article was originally posted on the NTEN Blog in January of 2014.

Requests for Proposals (RFPs) seem like they belong in the world of bureaucratic paperwork instead of a lean, tech-savvy nonprofit. There’s a lot that can be said for an RFP when both sides understand how useful a tool an RFP can be – even to tech-savvy nonprofits.

Here’s a safe bet: preparing and/or receiving Requests for Proposals (RFPs) is not exactly your favorite thing. Too many RFPs seem like the type of anachronistic, bureaucratic paperwork more worthy of the company in Office Space than a lean, tech-savvy nonprofit. So you may wonder why I would pitch a 90 minute session on the topic for this year’s Nonprofit Technology Conference. I’d like to make the case for you to attend my session: Requests for Proposals: Making RFPs Work for Nonprofits and Vendors.

The problems with RFPs are numerous, and many of you have tales from the trenches that could fill a few horror anthologies regarding them. I’ll be the first to agree that they often end up doing more harm than good for a project.  But I believe that this is due to a poor understanding of the purpose of the RFP, and a lack of expertise and creativity in designing them. What a successful RFP does is to help a client assess the suitability of a product or service to their needs long before they invest more serious resources into the project. That’s very useful.

The mission of the RFP is two-fold: a well written RFP will clearly describe the goals and needs of the organization/client and, at the same time, ask the proper questions that will allow the organization to vet the product or consultant’s ability to address those needs. Too often, we think that means that the RFP has to ask every question that will need to be asked and result in a detailed proposal with a project timeline and fixed price. But the situations where we know exactly, at the onset, what the new website, donor database, phone system or technology assessment will look like and should look like before the project has begun are pretty rare.

For a consultant, receiving an RFP for a web site project that specifies the number of pages, color scheme, section headings and font choices is a sign of serious trouble. Because they know, from experience, that those choices will change. Pitching a  fixed price for such a project can be dangerous, because as the web site is built, the client might find that they missed key components, or the choices that they made were wrong. It does neither party any good to agree to terms that are based on unrealistic projections, and project priorities often change, particularly with tech projects that include a significant amount of customization.

So you might be nodding your head right now and saying, “Yeah, Campbell, that’s why we all hate those RFPs. Why use ’em?” To which I say, “Why write them in such a way that they’re bound to fail?”

The secret to successful RFP development is in knowing which questions you can ask that will help you identify the proper vendor or product. You don’t ask how often you’ll be seeing each other next spring on the first date. Why ask a vendor how many hours they project it will take them to design each custom object in your as yet un-designed Salesforce installation? Some information will be more relevant — and easier to quantify — as the relationship progresses.

At the RFP session, we’ll dive into the types of questions that can make your RFP a useful tool for establishing a healthy relationship with a vendor. We’ll learn about the RFPs that consultants and software vendors love to respond to.  We’ll make the case for building a critical relationship in a proactive and organized fashion.  And maybe, just maybe, we’ll all leave the session with a newfound appreciation for the much-maligned Request for Proposal.

Don’t miss Peter’s session at the 14NTC on Friday, March 14, 3:30pm -5:00pm.

Peter Campbell is a nonprofit technology professional, currently serving as Chief Information Officer at Legal Services Corporation, an independent nonprofit that promotes equal access to justice and provides grants to legal aid programs throughout the United States. Peter blogs and speaks regularly about technology tools and strategies that support the nonprofit community.