Technology for your Mission

I’ve written a great deal about various aspects of non-profit technology. As a result, I was surprised at the difficulty I had writing a more comprehensive article. In the end, I discovered that I needed to spend most of my time defining the non-profit and its mission. In fact, 80% of the article dealt with how non-profits work and only 20% actually involved technology. I suppose I’m not really surprised; I’ve long realized the importance of understanding how an organization works before attempting to implement anything related to technology.

The article, Technology and Non-Profits, begins with defining a non-profit and continues through non-profit funding sources and the non-profit culture. Then it discusses the importance of a mission-statement and techniques for  connecting technology projects to an organization’s mission. I think this is a good overview of the issues facing technology in non-profit organization.

Read it here.

Getting a nonprofit organization to spend more than 1% of their annual budget on IT is like pulling teeth. It’s up to us professionals to help them understand their IT Infrastructure in terms of their mission, perhaps encouraging them to make the right decision.

But what about the nonprofit organizations that are actually poor — that honestly can’t afford to spend 1% of their budget on IT. We can’t just dismiss them.

Providing support for the nonprofit world isn’t a one-size-fits-all model.

Just getting funding doesn’t work either — even if you can find a funder for what is now considered operational expenses. The problem is what to do after you’ve put in the server. It’s not news, but it bears repeating: Technology investment doesn’t end at implementation; it requires ongoing support to be effective.

And here is where the choices get hard. Do you, as the IT professional, recommend and implement a solution that gives an organization functionality that they need, that they demand? We know that the system’s ongoing support is unlikely, that it is certainly not best practice, that it might cause more trouble than it’s worth.

What about organizations that can pay for support, but they can’t afford to pay for the up front implementation costs?You know who you are — local machines acting as file-servers, linking sites with $30 wireless access points, 1.5Mb/s DSL connections for 50 users. These systems break constantly, causing aggravation for everyone, often directed at the IT professional that consented to cobbling it together.

Finding the balance is tough. We can’t afford to turn away nonprofits that don’t fit the mold — they all need our help. But where do you draw the line? Where does “not best practice” become “I’m sorry I can’t help you.”

Well, it’s been a while since I posted. The for-profit version of the Pennsylvania Governor’s School of Excellence for Information, Society, and Technology (PGSIST) is in full swing and that plus work has kept me pretty busy.

Last night I attended a talk hosted by phillyCHI that inspired me to actually write something down. Jared Spool, a UX research of some note, spoke of intuitive and embraceable design (the graphic to the left is his). He attempted to define what makes a design intuitive and embraceable. All of what he said was entertaining, and much was useful, but one part stuck with me.

An intuitive design, he said, is unobtrusive. The user’s attention never wavers from the task at hand to the interface itself. Now, this isn’t a particularly novel concept. I’ve heard it several dozen times by now, and it is considered Canon in the UX world. It is, however, a concept with enormous ramifications, and a concept that has direct application in the world of Information Systems as a whole.

Information Systems exist to let the user get their work done. They should be unobtrusive, they should be unnoticeable. Their use should be autonomic. Technology should never exist for the sake of technology. If a user needs to take time out of their work to bridge the gap between their current knowledge and the knowledge they need to use the system, the system is not intuitive and needs to be addressed.

This means that system designers need to minimize the knowledge the system requires the user to know. It also needs to find a way to imperceptibly coach the user along the gap between their current knowledge and the needed knowledge. System designers also need to hide everything the user doesn’t need to know — the technical stuff — to avoid confusion.

Again, none of this is new. But it is a lesson that Systems Designers — as opposed to interface designers — have yet to learn.

I like to take a holistic approach to technology. Technology isn’t just the servers and desktops — it’s the software, it’s the databases, the website, the people, the processes, the training, and so on. This isn’t exactly a new idea, but it is one I’ve taken to heart.

Actually looking at technology in this way is difficult. The human mind isn’t particularly good at viewing things as a whole, it has a (usually beneficial) tendency to categorize and break problems down. This is exacerbated by the complexity of Information Systems; it is impossible for any one individual to have detailed subject knowledge about every aspect.

The trick is to cheat. Instead of looking at the system as a whole and then break it down, look at the components, put everything together, and plaster over the cracks. At NPower, we use The House. It’s a little ridiculous, but it works. What is part of the house and what we call each section changes project to project depending on the scope, but the idea remains the same. When doing a strategic technology plan or technology audit we address each part of the house separately through interviews and on-site investigation. As part of this process we examine the interaction between each of these pieces. Finally, everyone comes together to discuss and recommendations informed by the whole are made.

This last part is the most important, and the most difficult. The ability to synthesize massive amounts of information and dozens, sometimes hundreds, of seemingly unrelated gaps is difficult to learn. It requires as much business acumen as technical know-how. What emerges isn’t technical recommendations; it is the huge, business altering ideas. At NPower PA we call them Strategic Initiatives, they are ideas that fundamentally change how you think about technology. Strategic Initiatives are the top-down approach to Information Systems.

In today’s world this top-down approach is crucial. We can’t afford to think of an Information System as discrete components. Take a look at the picture in this post. It’s been making the rounds recently, and is a drawing of the first steamboat (it didn’t work very well). It is intended to illustrate that simply adding technology to a current system or process (like emailing out a pdf copy of a newsletter) fails to fully grasp the potential of technology. Doing so is the bottom-up approach.

Strategic and transformative ideas are the paddle boats. They shift the question from fixing problems through technology to creating new opportunities. Things like websites that integrate internal data sources, online communities, social networking, problem-based learning, open api’s, and open source software all illustrate this concept. Start with what technology can do and then decide how it can help your organization.

Not just anyone can do this. The individual looking for these opportunities needs a somewhat technical background, needs to have excellent management skills, and needs the ability to be both detail and big-picture oriented. And they need to be within the organization, at the level of senior management. Only by having someone inside and invested in an organization, and having the decision making capabilities of senior management can understand the organization and be as proactive as necessary. The solution, unsurprisingly, is to hire a Chief Information Officer.

If your organization can’t afford such an individual, there is always the option to hire a consultant, or to educate senior management about technology. Of course, the unique combination of skills that makes a good CIO are impossible to replicate by non-technical individuals or individuals who aren’t personally invested in the organization.

Fundraising for technology really isn’t such a mystery. Follow a few simple rules and you are likely to succeed:

• Relate it to your mission
• Talk about the project in client-centric ways
• Have a clear plan for implementation
• Set aside money for long term maintenance
• Get recommendations from a professional
• State it as a capital investment

This last is the subject of today’s post. Non-profits need to make it clear that any external funding will be supported down the line by operational costs that are provided by stable revenue streams. This isn’t particularly difficult to do with “traditional” technology projects. It costs $X to design a website, $X to buy and install a file server, $X to purchase and customize an off-the-shelf database solution. Long term support and maintenance for the entire infrastructure is generally a tiny percentage of implementation costs and, in my experience, represents less than or about equal to 5% of the organization’s budget.

But “traditional” technology isn’t what nonprofits need. They need on-demand computing. They need services based in the cloud. The need databases that are customized as needed and sold as a service. They need to be as agile and connected as possible. SaaS, cloud computing, and similar consumption based services are the future. The problem is, they make capital investments operational costs. This is great for for-profit enterprises. Spreading large costs over a number of years has obvious benefits when you are paying for it yourself anyway. But the same does not hold true for non-profit organizations.

Donors just don’t won’t to fund operational, long term, costs. From their perspective it makes perfect sense — even a nonprofit organization should be self sufficient. Money should be reserved for increasing the reach and breadth of services offered, not for paying for office supplies and basic support. SaaS often does help organizations achieve their mission and increase services — and it can do it at a lower cost and with greater efficacy — but how can we communicate this change with investors?

And even if we can convince investors, the perceived risks of moving to a hosted solution may prevent nonprofits from doing so. After all, capital investments can be seen as more flexible. A server can limp along for five or six years after its scheduled replacement date, and support can (and, trust me, is) easily dispensed with in tough economic times. On the other hand, hosted systems have definite expiration dates. The amount of money may be the same either way, but up-front costs are often more attractive to the risk-wary non-profit.

I’m not sure what the solution is, but it is clear that education must begin soon if non-profits are going to jump on-board with the reliability, cost, and efficacy benefits SaaS can provide. We need to work with funders to help them understand the risks and benefits of a new kind of computing.

A coworker of mine likes to say that clients pay consultants to tell them what they already know. I would agree, with one small change. Clients pay us to help them understand what they already know.

Our clients already know they need a new server. They already know their database isn’t tracking the data they need. They know no one is visiting their website. But they don’t understand it. They don’t know why, and they certainly don’t know how to go about fixing it. And frankly, telling them what they need to do in the form of a document isn’t going to help.

A few years ago I volunteered at a community center in west Philadelphia. There I taught basic computer skills to under-privileged adults as part of job training. If there was one thing I learned, it was that having them memorize a set of steps to save, or print, or italicize, just wasn’t helpful. As soon as something went wrong, they were out of luck. Instead, I had to teach them the process. Explain context menus, tool bars, contextual editing. I had to teach them how a computer worked. Only with this knowledge could they figure things out on their own. Not that I was particularly good at it, teaching this kind of thing proved very very difficult.

Creating a Strategic Technology Plan is no different. You can explain the steps needed to gather requirements and implement a database as much as you want, but it isn’t going to do them any good. You have to help them understand the process, the reasons for doing things in a particular way. They have to understand how metrics drive fund raising drives implementation projects. They need to understand why long term budgeting is important.

The deliverable is a piece of paper that will be shown to the board once and put on a shelf. The valuable part is the lesson. This is what our clients pay us for.

At NPower PA we provide a Strategic Technology Planning service. Organizations pay us to work with them to create a large document and ancillary reference materials that outlines a 3 year planning horizon for technology within their organization. This document is designed to interface with, but does not replace, a traditional strategic plan.

So, the obvious question to ask is, where does technology end and the rest of the organization begin. This is a particularly difficult question for me to answer since I don’t really believe that there is a difference between technology use and the organization as a whole. What that said, I am being paid to help them plan their technology use, so concessions must be made.

Obviously computers, servers, and networking equipment are related to technology. I think most will agree that the IT support structure also is. What about the processes that determine how people use technology? Databases that directly determine how work is done in the office? Budgeting procedures? Staffing? Training? The way they communicate? Technology touches every aspect of an organization, making it difficult to talk about in a clear way.

At NPower PA we use the “house.” This somewhat ridiculous diagram breaks technology down into discrete components that can be discussed separately. We can then color-code the parts of the house to show the health of the organization at a glance. Sort of like kindergarten, but it has proven surprisingly effective. To the right you can see the parts that I am using now. They seem to change with every project depending on the organization’s needs.

The “pillars” of the house are the most substantive portions of the document. They cover all the hardware, operating systems, databases, websites, and communication processes and software packages used by an organization. The rest covers policies and procedures within the organization, including BCP, planning, budgeting, support, training, etc. I’ve found this to be the easiest way to explain the impact of technology within an organization, but I’m sure I’ll be tweaking it far down the road.

The hardest part is figuring out how the client thinks about technology. Previous iterations seperated workstations from servers or combined databases and operating systems. This kind of document needs to be client-centric, not IT centric.