Tag Archives: tech support

Creating A Tech-Savvy Nonprofit Culture

This article was originally published in NTEN Change Magazine in June of 2015.

TechSavvy

What kind of challenge does your organization have supporting technology? Below are several scenarios to choose from:

  • Little or no tech staff or tech leadership: We buy inexpensive computers and software and rely on consultants to set it up.
  • Our IT support is outsourced: there is no technology plan or any staff training.
  • We have a tech on staff who does their best to keep things running: no staff training, no technology planning.
  • We have a tech on staff and an IT Director, but no technology plan: IT is swamped and not very helpful.
  • We have staff and IT leadership, but strategic plans are often trumped by budget crises. Training is minimal.
  • IT Staff, Leadership, budget, and a technology plan, but executive support is minimal. IT projects succeed or fail based on the willingness of the departmental managers to work with IT.

What do all of these scenarios have in common? A lack of a functional technology plan, little or no staff training, and/or no shared accountability for technology in the organization. While it’s likely that the technical skills required in order to successfully perform a job are listed in the job descriptions, the successful integration of technology literacy into organizational culture requires much more than that. Here are some key enabling steps:

Technology Planning: If you have a technology plan, it might not do more than identify the key software and hardware projects planned. Technology planning is about much more than what you want to do. A thorough plan addresses the “who,” the “why,” and the “how” you’re going to do things:

  • A mission statement for the technology plan that ties directly to your organizational mission. For a workforce development agency, the tech mission might be to “deploy technology that streamlines the processes involved in training, tracking, and placing clients while strategically supporting administration, development, and communications”.
  • A RACI matrix outlining who supports what technology. This isn’t just a list of IT staff duties, but a roadmap of where expertise lies throughout the organization and how staff are expected to share it.
  • A “Where we are” assessment that points out the strengths, weaknesses, threats, and opportunities in your current technology environment.
  • A “Where we need to go” section that outlines your three to five year technology vision. This section should be focused on what the technology is intended to accomplish, as opposed to which particular applications you plan to buy. For example, moving to internal social media for intra-organization communication and knowledge management” is more informational than “purchase Yammer.
  • Finally, a more technical outline of what you plan to deploy and when, with a big disclaimer saying that this plan will change as needs are reassessed and opportunities arise.

Training: Training staff is critical to recouping your investments in technology. If you do a big implementation of a CRM or ERP system, then you want your staff to make full use of that technology. If you’re large enough to warrant it (50+ staff), hire an in-house trainer, who also plays a key role in implementing new systems. This investment will offset significant productivity losses.

Smaller orgs can make use of online resources like Khan Academy and Lynda.com, as well as the consultants and vendors who install new systems. And technology training should be part of the onboarding process for new hires, even if the trainers are just knowledgeable staff.

In resource-strapped environments, training can be a hard sell. Everybody likes the idea, but nobody wants to prioritize it. It’s up to the CEO and management to lead by policy and example – promote the training, show up at the training, and set the expectation that training is a valued use of staff time.

Organizational Buy-in: Don’t make critical technology decisions in a vacuum. When evaluating new software, invite everyone to the demos and include staff in every step of the decision-making process, from surveying them on their needs before you start defining your requirements to including staff who will be using the systems in the evaluation group. When staff have input into the decision, they are naturally more open to, and accountable for, healthy use of the system.

Executive Sponsorship: With technology clearly prioritized and planned for, the last barrier is technophobia, and that’s more widespread than the common cold in nonprofits. Truly changing the culture means changing deep-rooted attitudes. This type of change has to start at the top and be modeled by the executives.

True story: At Salesforce.com, every new employee is shown the “Chatter” messaging tool and told to set up a profile. If a new user neglects to upload a photo, they will shortly find a comment in their Chatter feed fromMarc Benioff, the CEO of Salesforce, saying, simply, “Nice Photo”. That’s the CEO’s way of letting new staff know that use of Chatter is expected, and the CEO uses it, too.

Play! One more thing will contribute to a tech-savvy culture: permission to play. We want to let staff try out new web tools and applications that will assist them. The ones that are useful can be reviewed and formally adopted. But locking users down and tightly controlling resources – a common default for techies, who can trend toward the control-freakish side – will do nothing to help establish an open-minded, tech-friendly atmosphere.

Overcoming Tech Aversion: We all know, now, that technology is not an optional investment. It’s infrastructure, supplementing and/or taking the place of fax machines, printers, photocopiers, telephones, and in more and more cases, physical offices. In the case of most nonprofits, there isn’t an employee in the company that doesn’t use office technology.

But there are still many nonprofits that operate with a pointed aversion to technology. Many executives aren’t comfortable with tech. They don’t trust it, and they don’t trust the people who know what to do with it. A whole lot depends on getting tech right, so enabling the office technologist – be it the IT Director or the accidental techie – is kind of like giving your teenager the keys to the car. You know that you have to trust them, but you can’t predict what they’re going to do.

Building that trust is simply a matter of getting more comfortable with technology. It doesn’t mean that management and staff all have to become hardcore techies. They just have to understand what technology is supposed to do for them and embrace its use. How do you build that comfort?

  • Have a trusted consulting firm do a technology audit.
  • Visit tech-savvy peers and see how they use technology.
  • Go to a NTEN conference.
  • Buy an iPad!

Building a tech-savvy culture is about making everyone more engaged, accountable, and comfortable with the tools that we use to accomplish our missions. Don’t let your organization be hamstrung by a resistance to the things that can propel you forward.

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.

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.

Accidental Technology

This article was originally published on the Idealware Blog in February of 2011.

There’s been a ton of talk over at the NTEN Blog this month about Accidental Techies.  I had a few thoughts on the phenomenon.

If you don’t know, Accidental Techie is an endearing and/or self effacing term for someone who signed up for a clerical, administrative or other general purpose position and wound up doing technical work.  Many full-blown techies start their careers accidentally like this.

The NTEN discussion has wonderfully run the gamut.  Robert Weiner, a well-known NPTech consultant, started things rolling with “Going From Accidental Techie To Technology Leader“, a piece that wonderfully explores the gaps between those who do the tech because nobody else is and those who have the seat at the planning table, providing good advice on how you get to that table.

David Geilhufe then jumped in from an entirely different perspective with “Professionalism in Nonprofit Technology: Should My Techies be Accidental?” — that of a software grant provider who has seen how difficult it is to deal with organizations that don’t have seasoned technology practitioners in place. While his piece wasn’t a screed against accidental techies (ATs), it threw a bit of cold water on any org that thinks that technology can be successful without professional input and planning.

Fellow Idealware blogger and nptech consultant Johanna Bates posted “A Rant About Accidental Techies“. Her post, based in part on her own AT origins,  is full of insight on how the ‘accidental” appellation can be a crutch, She also shines light on the sexual politics of accidental techieism (reflected, unsurprisingly, in NTEN’s bloggers, two of whom are male, non-ATs, and two are female former ATs).

And Judi Sohn wrote “An Ode To The Accidental Techie“, reflecting on her experience as one (as well as VP of her org!) and reflecting on the attributes that make Accidental Techies great.

I am not, and never was an Accidental Techie, although my career path was very similar.  I started doing tech work in a small law firm where my title was “Mailroom Supervisor” and my duties included everything from database maintenance to filing to reception. We had a part-time tech who had installed a five node, token-ring IBM LAN that the legal secretaries, one attorney and I shared. When he quit, I was offered the Network Admin promotion and  a hefty pay raise.  The difference here is that, like a lot of ATs, I was in a clerical position and I had an aptitude for technology.  But, unlike an AT — and this is my big point — I worked for people that anticipated the needs for technology management and support.

There is nothing wrong with Accidental Techies; quite the contrary: they tend to be people who are sharp, versatille, sensitive both to organizational needs and the opportunities to create organizational efficiencies.  Most of all, they’re generous with their knowledge and time. But there’s something wrong if the technical work they do is unheralded and unpaid.  It’s wrong if it isn’t in their title and job descriptions.  The circumstances that create accidental techies, instead of promoting people with those traits to tech positions, are routinely those where management doesn’t have a clue as to how dependent on technology they actually are, or what resources they need to support it.

And you can bet that, in a business environment that creates the conditions for Accidental Techies to flourish, there’s no technology plan.  There’s no CIO, IT Director, or person who sits on the planning  and budget committee whose job is to properly fund and deploy computer and software systems. They’re winging it with infrastructure that can make or break an organization.  And they’re extremely lucky to have proactive people on staff who do see the gap and are breaking their backs to fill it.

So the NTEN blog quartet is required reading for anyone who even suspects that they might be an Accidental Techie. Read Johanna’s first, because she cuts to some core assessments about who you are and why you might be in this role.  Read David’s next, because it’s harsh but true, and it illustrates well the dangers that your org is facing if they don’t have proper IT oversight baked into their system.  Read Judy’s third, because she’ll remind you that, despite the last two reads, it’s still cool — and you’re cool for being someone with heart and talent.  And read Robert’s last, because he’ll tell you how to get from where you are to where you and your organization should be.

How to Send an All Staff Technical Email

This post was originally published on the Idealware Blog in April of 2009.

I had big plans for another insightful, deep, break-down-the-walls-of-the-corporate-culture-that-diminishes-use-of-technology post today, but I think I’m gonna save it for a rainy day and write something a bit more useful, instead.  I have a big nonprofit technology conference coming up this weekend, as you might, as well, and I think we should all be resting up for it.

The most important skill for any IT staff person to have is the ability to communicate.  All of the technical expertise in the world has little value without it, because, if you can’t tell people what you’re doing, what you’re doing won’t be well-received.  And there is an art, particularly with tech, to telling people what you’re doing, whether it’s taking the system down for maintenance of upgrading staff from Notepad to Office 2007.

Here are my five rules for crafting an technical email that even my most computer-phobic constituents will read:

  • Let no acronym go unexplained

The simplest, worst mistake that techies regularly make is to tell people that

“The internet will be down while we reconfigure the DHCP server” or

“The database will be unavailable while we replace the SCSI backplane”.

Best practice is to avoid the technical details in the announcement, if possible.  But if it’s relevant, speak english: “In order to accommodate the growth of our staff, we need to reconfigure the server that assigns network resources to each system to allow for more connections.”

  • Be clear, concise and consistent in your subjects

Technical messages should have easily recognizable subjects, so that staff can quickly determine relevance.  If your message is titled “Technical Information”, it might as well be titled “You are getting sleepy…”  But, if it’s titled “Network Availability” or “Database Maintenance Scheduled”, your staff will quickly figure out that these are warnings that are relevant to them. Don’t worry about the Orwellian aspect of announcing system downtime with a message about availability.  The point here is that using the consistent phrasing will grab staff’s attention far more effectively than bolding, underlining and adding red exclamation points to the email (see rule 4).

  • Keep it short and simple

It’s about what the staff needs to know, not what you’d like to tell them.  So, the network maintenance email should not read:

“The systems will be down from 4:30 to 9:00 tonight while we replace drives in the domain controllers and run a full defrag on the main document server”

It should read:

“The network will be unavailable from 4:30 pm until 9:00 pm while we perform critical maintenance”.

If it’s only a portion of the network, but something useful will be up – as when the file servers are being repaired, but email is still available, make a note of that: “While the main servers will not be available, you will still be able to send and receive email”.

  • No ALL CAPS, no exclamation points!!! and go sparingly on the bold

System downtime might be urgent to you, but it’s never urgent to the staff.  It’s a fact of life.  A reply from the Director of Online Giving that the downtime will jettison a planned online campaign is urgent; not your routine announcement.

  • Tell the whole story

…even if this sounds like it conflicts with rule 3.  Because there are two types of people on your staff:

  1. The majority, who want simple, non-techie messages as described above
  2. The rest, who want the gory details, either so they can rest easy that you aren’t making anything up, or because they’re actually interested in what you’re up to.

My approach is to do the simple message and, below it type, “Technical Details (optional reading)”.  In this section I might explain that we’re replacing the server that processes their network logins (I won’t use “DHCP” or “Domain Controller” if I can help it) or that we’re upgrading to the new version of Outlook.

The key concepts here are consistency, simplicity, and a focus on what impacts them regarding what you’re doing.  Stick to it and, miraculously, people might start reading your all staff emails.

The ROI on Flexibility

This post originally appeared on the Idealware Blog in April of 2009.

Non Profit social media maven Beth Kanter blogged recently about starting up a residency at a large foundation, and finding herself in a stark transition from a consultant’s home office to a corporate network. This sounds like a great opportunity for corporate culture shock. When your job is to download many of the latest tools and try new things on the web that might inform your strategy or make a good topic for your blog, encountering locked-down desktops and web filtering can be, well, annoying is probably way to soft a word. Beth reports that the IT Team was ready for her, guessing that they’d be installing at least 72 things for her during her nine month stay. My question to Beth was, “That’s great – but are they just as accommodating to their full-time staff, or is flexibility reserved for visiting nptech dignitaries?”

The typical corporate desktop computer is restricted by group policies and filtering software. Management, along with the techs, justify these restrictions in all sorts of ways:

  • Standardized systems are easier, more cost-effective to manage.
  • Restricted systems are more secure.
  • Web filtering maximizes available bandwidth.

This is all correct. In fact, without standardization, automation, group policies that control what can and can’t be done on a PC, and some protection from malicious web sites, any company with 15 to 20 desktops or more is really unmanageable. The question is, why do so many companies take this ability to manage by controlling functionality to extremes?

Because, in many/most cases, the restrictions put in place are far broader than is necessary to keep things manageable. Web filtering not only blocks pornography and spyware, but continues on to sports, entertainment, politics, and social networking. Group policies restrict users from changing their desktop colors or setting the system time. And the end result of using the standardization tools to intensively control computer usage results, most often, in IT working just as hard or harder to manage the exceptions to the rules (like Beth’s 72, above) than they would dealing with the tasks that the automation simplifies in the first place.

Restricting computer/internet use is driven by a management and/or IT assumption that the diverse, dynamic nature of computing is either a distraction or a problem. The opportunity to try something new is an opportunity to waste time or resources. By locking down the web; eliminating a user’s ability to install applications or even access settings, PC’s can be engineered back down to the limited functionality of the office equipment that they replaced, such as typewriters, calculators and mimeograph machines.

In this environment, technology is much more of a controlled, predictable tool. But what’s the cost of this predictability?

  • Technology is not fully appreciated, and computer literacy is limited in an environment where users can’t experiment.
  • Strategic opportunities that arise on the web are not noticed and factored into planning.
  • IT is placed in the role of organizational nanny, responsible for curtailing computer use, as opposed to enabling it.

Cash and resource-strapped, mission-focused organizations only need look around to see the strategic opportunities inherent in the web. There are an astounding number of free, innovative tools for activism and research. Opportunities to monitor discussion of your organization and issues, and meaningfully engage your constituents are huge. And all of this is fairly useless if your staff are locked out of the web and discouraged from exploring it. Pioneers like Beth Kanter understand this. They seek out the new things and ask, how can this tool, this web site, this online community serve our sector’s goals to ease suffering and promote justice? More specifically, can you end hunger in a community with a widget? Or bring water to a parched village via Twitter? If our computing environment is geared to stifle innovation at the cost of security, are we truly supporting technology?

As the lead technologist at my organization, I want to be an enabler. I want to see our attorneys use the power of the web to balance the scales when we go to court against far better resourced corporate and government counsel. In this era of internet Davids taking down Goliaths from the RIAA the the mainstream media, I don’t want my co-workers to miss out on any opportunities to be effective. So I need the flexibility and perspective to understand that security is not something that you maintain with a really big mallet, lest you stamp out innovation and strategy along with the latest malware. And, frankly, cleaning a case of the conflickr worm off of the desktop of an attorney that just took down a set of high-paid corporate attorneys with data grabbed from some innovative mapping application that our web-filtering software would have mistakenly identified as a gaming site is well worth the effort.

Flexibility has it’s own Return on Investment (ROI), particularly at nonprofits, where we generally have a lot more innovative thinking and opportunistic attitude than available budget. IT has to be an enabler, and every nonprofit CIO or IT Director has to understand that security comes at a cost, and that cost could be the mission-effectiveness of our organizations.

Here with the Wind

Techcafeteria landed on it’s third (or fourth, if you count the ibook I developed it on) web host this week. I have hope that this is one that won’t merge with a bigger, awfuller company or forget to tell me that they regularly overload their servers to the point where my web sites go down. I’ve had a run of bad luck. I host seven or eight domains, including a couple of sites for friends, so I like to get a decent reseller’s account.

I was with Dotable, a nice outfit out of Australia run by a guy named “Aussie Bob”, and it was a good place to be – decent pricing, really responsive support, mostly stable. I recommended Dotable often because the problems were minimal in relation to the great communication and supportive attitude of the staff.

A few months ago Bob announced that he was retiring and handing over management to another company. In short order, the new service deleted a (dormant) Drupal site off of one of my domains without telling me; and changed my mail records to point to a new spam filtering service, without informing me. Since one of my “client” domains routes his mail through EasyDNS (on my recommendation), this resulted in two days of mail being completely lost. During the crisis, every support ticket I put in got a “we’re forwarding this to our admin” answer. The admin had a backlog, I bet, because I wasn’t getting responses for days, and the responses I got were not helpful, and ducked the ones like “why did you change my MX record without telling me?”

Anyway, my friend/client is active on Green America’s forums (they used to be Coop America), and he’d heard very good things about Canvas Dreams, an Oregon hosting service with a wind-powered server farm and the exact plans and setup that I was looking for. So I made the move, and Techcafeteria,NPTech.info and Krazy.com, along with my other projects, are all a bit greener and happier today. And it does seem to me that this server is faster than the one I was on with Dotable. Those of you who actually visit the site (I assume that most of you simply subscribe) might have noticed some weirdness this morning as I adjusted a few things, but the blog came over without a noticeable hitch.

So, welcome to the same site, at it’s new green home.

Help for the Helpers

This post was originally published on the Idealware Blog in January of 2009.

If you’re in a job that involves supporting technology in any fashion, from web designer to CIO, then the odds are that you do help desk. Formally or not, people come to you with the questions, the “how do I attach a file to my email?”, the “what can I do? My screen is frozen”, the “I saved my document but I don’t know where”. Rank doesn’t spare you; openly admitting that you can do anything well with computers is equivalent to lifetime membership in the tech support club.

A full time tech support job is, for the most part, an extended roller coaster ride with more down slopes than up. People who are drawn to this work are generally sharp, eager to assist, and take pride in their ability to debug. The down side is that, day after day, it’s grueling. There’s always a percentage of people who would just as soon smash the machine and go back to their trusty Selectrics. They aren’t always happy or polite with the friendly tech who comes to help them.

But the most debilitating aspect of the work is that support techs don’t manage their workload. It’s randomly and recklessly assigned by the varying needs of their co-workers and the stability of their systems. They never know when they’re going to walk in the office to find the donor database is crashed, or the internet line is down. The emails come in, the phone rings, and, to the people calling, everything is a crisis. Or it certainly seems that way. The end result is that career support techs often develop a sense of powerlessness in their work, and the longer it goes on, the less able they are to take proactive action and control of their jobs.

So here are two complimentary actions that can be taken to brighten the life and lighten the load of the support tech.

1. Deploy a trouble ticket system. And make sure that it meets these specifications:

  • Incredibly easy for staff to use. Web-based, linked from their desktop, with, ideally, three fields: Name, priority and problem. The software has to be able to grab additional information automatically, such as the time that the ticket was submitted, and, optimally, the user’s department, location and title, but the key point is that people won’t use the system if the system is too annoying to use.
  • Every update is automatically emailed to the user and the tech. This is critical. What an automated trouble ticket does best is to inform the customer that their issues are being addressed. Without this communication in place, what stands out in user’s minds are the tickets that haven’t been resolved. Confirmations of the fixes, sent as they occur, validate the high rate of responsiveness that most help desks maintain.
  • Be clear that the scope of the problem will influence the response time. Fixes that require spending or input from multiple parties are not slam dunks. This communication might warrant additional checkboxes on the submission form for “requires budget” or “requires additional approvals”, but formalizing this information helps the customer know that their issue hasn’t just been dropped by the tech.
  • Have a default technical staff view that puts open tickets on top. In environments where the telephone is the primary support funnel, things get forgotten, no matter how good and organized the tech is.

There’s more to it – good ticket systems feed into, and include links to additional support resources. And they don’t replace the telephone – IT has to be readily available. But there should be an understanding that users follow up phone calls with tickets. These are the key strategies that help the seemingly unmanageable stream of support calls fall in line.

2. Allow the support staff to breathe. There has to be an understanding, primarily understood by the support tech, but reinforced by his or her manager, teammates and staff, that only emergencies demand emergency response times. In fact, treating every call as an equally important, must be fixed immediately situation is a strategy for failure. Support Techs need to do effective triage, and put aside time to analyze and act proactively to solve user problems. If they deal with the same questions over and over, they have to write and publish the solutions. If the calls indicate a common problem that can be solved with a better application or an upgrade, they need to be able to step back and assess that. Smart managers will enforce this measured approach. At first, it will go against the grain of service-oriented staff, but it’s a must, because the measured response begets the more comprehensive solution to any problem.

Biting The Hand – Conclusion

This article was originally published on the Idealware Blog in October of 2008.

This is the final post in a three part series on Microsoft.  Be sure to read Part 1, on the history/state of the Windows operating system, and Part 2, on developing for the Microsoft platform.

Two More Stories – A Vicious Exchange

In late 2006, I moved an organization of about 500 people from Novell Groupwise to Microsoft Exchange 2007.  After evaluating the needs, I bought the standard edition, which supported message storageup to 16GB (Our Groupwise message base took up about 4GB).  A few days after we completed the migration, which included transferring the Groupwise messages to Exchange, an error popped up in the Event Viewer saying that our message store was larger than the 16GB limit, and, sure enough, it was – who knew that Microsoft messages were so much larger than Groupwise messages?

The next day, Event Viewer reported that our message store was too large and that it would be dismounted at 5:00 am, meaning that email would be, essentially, disconnected.  Huh?  I connected remotely the next morning and remounted at about 5:10.  I also scoured the Microsoft Knowledgebase, looking for a recommendation on this, and found nothing.  I called up my vendor and ordered the Enterprise version of Exchange, which supports a much larger message store.  A couple of days later, same thing.  My new software hadn’t arrived yet.  The next day, the message changed, saying that our message store was too large and would be dismounted randomly! What!?  This meant that the server could go down in the middle of the business day.  The software arrived, and I tossed the box on my desk and scheduled to come in on Sunday (which happened to be New Year’s Day, 2007) to do the upgrade. But when I opened the box, I discovered that my vendor had sent me Enterprise media, yes, but it was for Exchange Server 2005, the prior version.  I was hosed.

Frantic, I went to Google instead of the knowledge base and searched.  This yielded a blog entry explaining that, with Exchange Server 2007 Service Pack 2 (which I had applied as part of the initial installation), it was now legal to have message stores of up to 75GB.  All I had to do was modify a registry entry on the server – problem solved.  Wow, who woulda thunk?  Particularly if this had been documented anywhere on the Microsoft Knowledgebase?

But here’s my question: What Machiavellian mind came up with the compliance enforcement routine that I experienced, and why was my business continuity threatened by code designed to stop me from doing something perfectly legal under the Service Pack 2 licensing?  This was sloppy, and this was cruel, and this was not supportive of the customer.

Cheap ERP

In early 2007, I hired a consultant to help with assessing and developing our strategic technology plan.  This was at a social services agency, and one of our issues was that, since we hired our clients, having separate databases to track client progress and Human Resources/Payroll resulted in large amounts of duplicate data entry and difficult reporting. The consultant and I agreed that a merged HR/Client Management system would be ideal. So, at lunch one day, I nearly fell off my chair laughing when he suggested that we look at SAP.  SAP, for those who don’t know, is a database and development platform that large companies use in order to deploy highly customized and integrated business computing platforms.  Commonly referred to as Enterprise Resource Planning (ERP) software, it’s a good fit for businesses with the unique needs and ample budgets to support what is, at heart, an internally developed set of business applications.  The reason I found this so entertaining was that, even if we could afford SAP, then hiring the technical staff to develop it into something that worked for us would be way beyond our means.  SAP developers make at least six figures a year, and we would have needed two or more to get anywhere in a reasonable amount of time.  It’s unrealistic for even a mid-sized nonprofit to look at that kind of investment in technology.

So Microsoft holds a unique position — like SAP, or Oracle, they offer a class of integrated products that can run your business.  Unlike SAP or Oracle, they’re pretty much what they are – you can customize and integrate them, at a cost, but you can’t, for instance, extend Microsoft’s Dynamics HR package into a Client Management System.  But, if you have both Dynamics and Social Solutions, which runs on Microsoft SQL Server, you’d have a lot more compatibility and integration capabilities than we had at our social services org, where our HR system was outsourced and proprietary and the client management software ran on Foxpro.

Bangs for the Buck

So this is where it leaves me – Micosoft is a large, bureaucratic mess of a company that has so many developers on each product that one will be focusing on how to punish customers for non-compliance while another is making the customers compliant.  Their product strategy is driven far less by customer demands than it is by marketing strategy.  Their practices have been predatory, and, while that type of thing seems to be easing, there’s still a lot of it ingrained in their culture.  When they are threatened — and they are threatened, by Google and the migration from the desktop to the cloud — they’re more dangerous to their developers and customers, because they are willing to make decisions that will better position them in the market at the cost of our investments.

But Microsoft offers a bargain to businesses that can’t — and shouldn’t – spend huge percentages of their budget on platform development.  They do a lot out of the box, and they have a lot of products to do it with.  Most of their mature products — Office, Exchange, SQL Server — are excellent.  They’re really good at what they do.  The affordable alternative to the commercial ERP systems like SAP and Oracle is open source, but open source platforms are still relatively immature.  Building your web site on an open Source CMS powered by PHP or Ruby on Rails might be a good, economical move that leaves you better off, in terms of ease of use and capabilities, than many expensive commercial options.  But going  open source for Finance, HR and Client Tracking isn’t really much of an option yet.  The possibly viable alternatives to Microsoft are commercial outsourcers like NetSuite, but how well they’ll meet your full needs depends on how complex those needs are – one size fits all solutions tend to work better for small businesses than medium to large ones.

Finally, it’s all well and good to talk about adopting Microsoft software strictly on its merits, but, for many of us, it has far more to do with the critical, non-Microsoft applications we run that assume we’re using their products.  For many of us, considering alternatives like Linux for an operating system; Open Office or Google Apps for productivity; or PHP for our web scripting language are already nixed because our primary databases are all in SQL Server and ASP.  At the law firm where I work, we aren’t about to swap out Word for an alternative without the legal document-specific features that Microsoft richly incorporates into their product.  But it leaves me, as the technology planner, in a bit of a pickle. Windows XP, Office 2003/2007, Exchange 2007, SQL Server 2007, and Windows Server 2003 are all powerful, reliable products that we use and benefit from, and the price we paid for them, through Techsoup and their charity licensing, is phenomenal.  But as we look at moving to web-based computing, and we embark on custom development to meet information management and communication needs that are very specific to our organization, we’re now faced with adopting Microsoft’s more dynamic and, in my opinion, dangerous technologies.

This would all be different if I had more reason to trust the vendor to prioritize my organization’s stability and operating efficiency over their marketing goals.  Or, put differently, if their marketing philosophy was based less on trying to trump their competition and more on being a dependable, trustworthy vendor.  They’re the big dog, just about impossible to avoid, and they make a very compelling financial argument — at first take — for nonprofits.  But it’s a far more complicated price break than it seems at first glance.