Julian Egelstaff, Technical Architect, Freeform Solutions

Who are our IT role models? Where do our ideas about IT come from?

In the nonprofit sector, we have some big challenges in this area. The IT industry is overwhelmed with companies and courses and products aimed at the commercial world. Most examples we have of successful IT practices would likely fail in a nonprofit context, though. 

Nonprofits face unique challenges that commercial enterprises often don't face: you have no IT staff, no IT budget, uneven levels of technical skills in staff, high turnover and volunteer staff, distributed teams with only the internet connecting them, no long term IT planning or vision, and project based funding models. 

When faced with this list of challenges, I've seen some nonprofits try and find a life-raft in the IT ocean by following what larger commercial or government organizations do. After all, those organizations must know what works when it comes to IT -- they spend a lot more time and money on it.

Trying to follow the example set by a commercial company, just in a nonprofit way, probably won't work, but there are lessons to be learned. Because of the challenges nonprofits face, they need to be at least as cognizant of the planning process as larger, more well resourced organizations.

To begin with, nonprofits need to recognize three different roles that emerge during any IT project:

• The engineer role: someone who designs and implements systems
• The user role: someone who has the IT need, and is the "subject matter expert"
• The executive in charge: someone who plans for meeting the organization's overall needs, and takes on the risks

There is often overlap in those roles. Sometimes the user/manager and executive are the same person. Sometimes the engineer and the user/manager are the same person -- if a small organization is using some open source tool by themselves to build a website, for example. Often, the engineer role is filled by an outside developer, consultant, or firm.

A lot of IT failures happen when people focus too much on one issue at the expense of another. Defining the different roles helps avoid this. Each role has different things they need to be conscious of, and they need to champion those issues so that important things don't get ignored as the project unfolds. 

This is especially true when the engineer role is filled from outside the organization, as will happen often in the nonprofit context. 

You have to find a way to make sure your own needs don't get lost in the process of implementing the solution. Too many systems have been delivered over the years, to the underwhelming response, "Well, it's good, but that's not what I had in mind."

I prepared a handout summarizing these points for a presentation I did awhile back, but let's dive in to the details.

Being a good engineer

Engineers should focus on creating flexible, expandable systems that use open standards and file formats. 

This is very important for nonprofits, because the piecemeal way that IT inevitably gets dealt with means the tool you build today for one reason will have to talk to another tool in a year or two that you -- or your consultant -- haven't even thought of yet. You don't have the budget to do a lot of retrofitting to bring everything together. You need to make sure that whatever you're using is as open and flexible as possible, so it can support all kinds of unanticipated needs. Nonprofits tend to have more unanticipated needs than other organizations because of the general lack of IT planning that goes on.

Open source software is often an important ingredient for the engineers to consider, and not just because of the low acquisition cost. Proper use of open source software can make systems easier to expand and integrate with others. Using open source also means you should actively participate in the communities that exist around your open source software. It's not like buying something off the shelf and then it works, or it doesn't work. Open source is all about bending the tools to your will, and you can't do that effectively if you're not an active participant in the relevant open source communities.

We also advocate strongly for agile development practices. Agile practices emphasize delivering working pieces of a system in small increments, instead of planning the entire development effort and then trying desperately to avoid feature-creep and schedule slippage. By taking on a project in bite-sized chunks, it helps ensure that real features are delivered, instead of everything ending up only 80% done when the budget runs out. It also creates transparency, by giving the entire project team a chance to evaluate what's going on regularly, and to re-prioritize work based on what they've learned as the project unfolds. This is important when initial requirements are poorly understood -- which is the case in many commercial IT projects, let alone with under-resourced nonprofits.

Standing up for user needs

In every project, the most important people are the ones who are actually going to use the system. They're the ones who understand best how it will fit into the organization and how it will change people's jobs. These are the "subject matter experts" who the engineers should rely on to explain what really needs to happen.

Because they're so close to the action, as it were, we've found that users have an overwhelming desire to prescribe solutions instead of seeking help with problems. Users know the IT problems and shortcomings they face very well; they've probably thought about them a fair bit. They often have ideas about what they think will make their lives better. But jumping to the solution is getting ahead of yourself.

It's up to the engineers to provide the solutions. It's their job to know what the landscape of possible solutions is, and what might work well in a given situation. If users focus too much on solutions (ie: "We need a blog now!") instead of on the underlying IT problems (ie: "We have a really hard time keeping up to date with our stakeholders."), they run the risk of implementing systems that only partly address the real needs.

Users should help the engineers understand the problems, and collaborate with them on determining the best solutions. Someone inside the organization needs to have the vision for why the project is happening and what it needs to accomplish. They can't be fixated on the technology, or else they risk losing sight of the prize. If they don't stand up for what the organization needs, then there's a good chance it could get lost in a mixture of technology hype and buzzword euphoria.

Executing on an IT vision

Sometimes, the users themselves, or a senior person among them, hold the vision for the IT project. Sometimes that vision is held by the executive director. In general, the higher up the vision is held, the better. IT is an ongoing process, and there needs to be some stability and longevity in the approach an organization takes to managing it.

Whether they have the vision for a project or not, the executive is the one who's probably signing the checks. The buck literally stops with them, so one of the most important things they can do is budget adequately. A general guideline in the commercial world is that you should spend 5% to 10% of your operating budget on IT, in order to remain as efficient as possible. Few nonprofits achieve this -- under investment in operations is a chronic problem in the sector, thanks to the nonprofit starvation cycle. Nonetheless, setting out some budget, as part of your overall operation, not simply on a project-by-project basis, will help lay the groundwork for a real IT infrastructure that can support you into the future.

When treated as a resource to be spent effectively, instead of overhead to be consumed, IT resources can improve how an organization gets its work done. This requires planning (not just budgeting), and the process can be messy and complicated. 

There's no off-the-shelf solution for most of the really important things you need help with, but if you plan for it and have good technology partners who listen to what's important to you, then IT can literally change how your organization meets its mission. 

This is another reason we strongly recommend agile practices. The bite-sized approach to dealing with IT projects can help teams uncover those possibilities, since you can react to what you've learned and experienced before the whole project budget is spent.

Learning the hard way

When we founded Freeform Solutions, the idea was to create a nonprofit that was itself a technology solution provider -- a by-the-sector, for-the-sector approach to IT. In the beginning, like most technologists, we had a lot of faith in the transformative power of technology itself. After all, we all know that even something as simple as a blog can have a big effect on how an organization communicates and the networks it operates in. We were bold and optimistic. Our unofficial slogan was “Doing the impossible is really hard.”

Now, after many highs and lows, through all kinds of projects, we've seen time and again how the technology problems are rarely at the heart of the matter. Even that simple blog is not so simple. It's a lot of work figuring out what to say, when to publish, how to keep a regular stream of visitors coming back to your site, and so on and so on. (Never mind the more esoteric issues like how you'll handle tagging, and having good search support.)

We still believe technology can help create change. But IT is a process, not a product, and using the technology well is more important than just having it. 

P.S. There's a bullet point in the summary handout that says “Beware of RFPs.” In my experience talking to people about these issues, that's the area that generates the most discussion. I'll simply say that RFPs are, in my opinion, the most widely imitated, and poorly understood, of all the techniques that nonprofits try to copy from larger commercial and government organizations. If you want to know why, check out http://www.freeformsolutions.ca/en/we-dont-hate-rfps

Julian co-founded Freeform Solutions after holding a variety of positions in project management, documentation, and tool development at Corel, Cognos, and Actua. Julian has 10 years experience in PHP development and is a Zend Certified Engineer. He holds a Bachelor's degree in Journalism and Philosophy.