 Welcome to TechSoup Talks. Today's webinar is Tips and Tools for Technology Planning. Our presenters are Kendra Morgan and Elliot Harmon. My name is Kami Griffiths and I'm the Training and Outreach Manager here at TechSoup. And I'd like to welcome Kendra from Web Junction. Kendra, can you please tell us a little bit about what you do at Web Junction? Sure. My name is Kendra Morgan and I am a Programs Manager here at Web Junction which is an online learning community for libraries. And we provide a great wealth of free resources for libraries. And a big part of what I do is to help libraries use Tech Atlas which is our free technology planning tool. Great. Thank you Kendra. And thank you so much for taking time to put this presentation together. I'd also like to welcome Elliot Harmon, my co-worker here at TechSoup. Elliot, can you tell us a little bit about what you do here at TechSoup? Sure. Hi. My name is Elliot Harmon. I work here at TechSoup Global. I'm a staff writer. I write particularly about nonprofits and technology adoption. You can find me on our Learning Center at TechSoup.org slash Learning Center. Great. Thanks Elliot. Now I'd also like to thank Kevin Moe for helping out with the chat. And again, if you have any questions at all during the presentation, please submit those via the chat. We'll hold those at the very end for about 15 to 20 minutes of Q&A. Before we get started I want to learn. We'd like to know a little bit more about you. So if you wouldn't mind taking a second to click on the most applicable button here to tell us which of these describes you the best. And that helps us understand who is in the audience. And then therefore we can talk to – I'm just watching the numbers increase here. It's great to see so many people out there. And if you hit the other category I'd be curious to see how you self-identify. So feel free to send that in the chat. Okay, another second and skip to results. There we go. So no board members or volunteers but quite a few IT professionals and executive directors. So thanks for that. One last question. We're curious about your IT infrastructure. And so if you could, which of these statements best describes your organization? Take a second to read through those. No tech plan in place. The plan is old or incomplete. You have a working tech plan that's in place or you're not quite sure. Just giving you a few seconds to reply. There we go. So old and incomplete. So we've got a lot of folks who have some plans but you want to update them and send them with no plans at all. So very good. Thank you for that. So quickly I'd like to go through our agenda. We have quite a bit of information that we're going to be going through today. First we're going to start out talking about the value of the tech plan and then what dangers are involved in not having one. And when should we do a tech plan? Who should be involved? We'll spend about 10 to 15 minutes talking about the planning process. Kendra will go over tech outlets and then we'll share a couple of stories from folks in the community that the presenters have worked with. So I'd like to get started by asking Kendra first, why do I need a tech plan and what's the value in having one? So there are a couple of major areas that I think about when people ask me about the work and the effort that goes into creating a tech plan. And one of the main reasons that I encourage people to have one is that it really creates a path to the future and making sure that your organization, whether you're a library or a nonprofit, is going to be able to achieve your mission and vision through technology if that's applicable. The other thing is that it starts to establish expectations for staff, for the resources that you have available to you. It helps to lay out, it's very much in tandem with the first thing, but it helps to lay out that plan and give people a better sense of what's going to be needed to be completed to fulfill the organization's mission and vision. And then finally, it's often a requirement for a lot of people. Libraries that participate in the federal e-rate program are often required to have a technology plan. And that technology plan, the value there for them is often that it helps them to get funding and money to help support their programs. Great. I'd like to toss it over to Elliot to talk a little bit about nonprofits. Great. Thanks a lot, Kim. I guess the one thing that I'd kind of like to add to what Kendra was saying there, all of which is very applicable to libraries and nonprofits, is that your tech plan also makes a big difference in your tech acquisitions. Here you can see on your screen a list of TechSoup's donation programs that are impacted by our July to June fiscal year. And you can find this list yourself by following the URL listed there. One of the biggest complaints, or the biggest pain points that we get from TechSoup users is that they've already requested certain products earlier in the fiscal year, but they didn't take into account that they would have new staff, that they would be embarking on new programs, that they would need certain software for, and now they're stuck essentially waiting until the end of the fiscal year. Here I'm just talking about TechSoup donations, but the same concerns apply in other places too, like Gifts and Kind International has similar restrictions. The point is that the longer you're able to kind of forecast your tech plan ahead, the more it will inform your tech acquisition decisions, and ultimately the more money you'll save. Great. Thanks, Elliot. Let's also talk about the dangers of not having a tech plan. Great. Thanks a lot, Kami. There's three main points that I've identified here as dangers of poor technology planning, and I'm just going to get a quickly touch on each of these. The first one of these is a phrase that you hear a lot, the tyranny of the urgent. This means essentially that if there is not a technology plan in place, then whoever is managing technology at your organization, be it a formal IT department or more of an accidental techie or even a volunteer, whoever it is that's handling that technology, literally all of their time will be taken by these help desk requests. They will be constantly working on supporting and fixing the old broken email server as opposed to researching and finding a better email server to take on, the tyranny of the urgent, and it literally takes up as much time as you allow it to have in your workflow. This is very closely related to what I call small picture focus. Let me show you a chart to kind of illustrate what I mean by small picture focus. At the bottom of this pyramid is infrastructure supporting tech. This is your voiceover IP lines. This is your email. This is your antivirus. This is your backup systems. This is everything that keeps the office running, keeps the lights on, keeps all the computers from exploding. All of that is a foundation and those things never go away. But in order to move to the next step, which I'm calling here mission supporting tech, you need a better tech plan in place. Now mission supporting tech, I will admit is a little bit of a misnomer because of course infrastructure supporting tech is also mission supporting. But putting that aside, here we're talking about the technology that is an inherent part of the programs themselves. We're talking about you using your website for an example, not just as a brochure, but a way to educate people and spread your message. We're talking about you using your own information literacy and turning that into the community's information literacy. And again, none of that is possible if you're stuck at the bottom half of that pyramid only responding to help desk requests. Like I said earlier, essentially treading water. And the other thing that's kind of a big hobby horse of mine is that with a poor technology plan, you're also not ready for natural or man-made disasters. I helped write TechSoup's Disaster Planning and Recovery Guide which you can see the URL for it there. But there's two important parts to disaster planning. One of them is that when a disaster happens, it will negatively impact your organization. So if you didn't have a good business continuity plan in place, it will severely hurt your organization's ability to operate. The other side of that is that those disasters are also the times when your community is hurt the most and when your community most needs your organization. And during those crucial moments, yes, you can spend that time rebuilding your tech infrastructure, but it's better for you to be spending that time rebuilding your community. Great. Thanks Elliott. That's really useful. Now with Tender, can you tell us when the technology plan should be done and how often it should be done? Sure. And this is something that's very dependent on your organization. So it really requires you to sit down and look at what the requirements are for your organization. If you're a library and you're part of a city and county, you might have different requirements. If you're participating in specific grant programs, you may have requirements, nonprofits would fall on the same thing, but it's really understanding what your fiscal cycle looks like. So we encourage you to get all that information together and then decide how often you need to do a complete planning cycle. What we really want to get people to truly understand is that planning and responding to the plan is really a year-round plot process. You can't just do it once, put it on a shelf, and be done with it. You've spent a lot of time invested into writing the goals and objectives, coming up with a budget. And what you want to be doing on a monthly basis really is analyzing how you're doing towards achieving the goals and objectives. So planning is just a year-round activity for most organizations, and it's something that you just want to touch base on. It doesn't need to be hours every month. You may do the complete planning process where you flesh out the goals and objectives and do your budget once a year, but there should be frequent touch points that make sure that your organization is continuing to move in the right direction towards achieving those goals and objectives. Great, and I'd like to throw it back to Elliot to talk about the technology team who should be involved in this process. Great, thanks a lot. It was interesting to see the mix of people in the survey at the beginning. It sounds like we have a pretty good mix on the line of executive directors and people who are working specifically in IT as well as a good number of what we call accidental techies which is a term we'll come back to in a second. But when we talk about assembling the technology team specifically for a tech infrastructure evaluation and rebuilding, it's often more a matter of empowering the team that's already in place and giving them the tools and giving them the access to the right decision makers that they can be successful. And this is where we come to a term that we like here a lot at TechSoup which is the purposeful techie. That's not a term that we came up with. It's a term that we stole from Mark Shaw. But the essential idea is that the accidental techie is the person who one day managed to figure out how to fix the printer and now suddenly is the person everybody comes to with their tech problems. The purposeful techie is the person who one day managed to figure out how to fix the printer and now the organization is listening to that person and empowering them to help play a part in the technology decisions of the organization. And here's a quote from Mark Shaw about this. A major issue the accidental techie has with her responsibility is that they conflict with her core job function. Not everyone has a natural born multitasker but the purposeful techie puts in place parameters that allow her to balance competing needs. Scheduling time and her calendar for maintenance and individual computer user assistance at appropriate intervals in the day, week, or month will bring order to the support role and create boundaries. And that's from a beautiful essay that Mark wrote called The Purposeful Techie and you can see the URL for it there. One thing I would add to that quotation is that this is also about empowering the techie to actually be at the table when new programs are discussed and make recommendations for what will be necessary for technical requirements of those programs and that includes training a lot of the time. Very closely related to this is working with volunteers and consultants and most importantly not wasting their time because their time is the most limited of anyone in the organization. We wrote a working with technical volunteers manual which is there at bit.ly slash techvols. But one quick thing I'd say is that the best way to waste a tech volunteer's time is to force her to spend a lot of her time navigating the intricacies of your organization's human resources chart, having her spend a lot of her time figuring out who the right decision makers are to talk to about different things. Rather than forcing her to do that have a volunteer liaison who has a flexible enough schedule that he or she can work with that tech volunteer and make the right connections to get that tech volunteer talking to the right decision makers within the organization. Don't waste the tech volunteer's time by making them navigate the complexities of your organization. So let's start talking about the process. So I'm going to have Elliott start us off by talking about defining the problem. Great. Thanks a lot. This is in some ways the most obvious step of the tech planning process but it's also a step that I think is the hardest for a lot of the organizations that I've come into contact with. The funny thing is that users are often not very good at reporting problems. They're instead good at reporting solutions. What do I mean by that? I mean if a fundraising person says, hey we need to start using Salesforce, that's not actually the problem. That's a solution. The problem might be we are using a Microsoft Excel spreadsheet to keep track of all of our donors. And this is insufficient for our needs because it does not include X, Y, and Z features. And when you start looking at it that way then you're able to see a much more holistic picture of what's really going on in the organization and what kind of changes are needed in the tech plan. Here's my three quick questions to use when capturing those user stories. What is the current workflow? What need is not met by the current workflow? And most importantly, who is impacted? Is it impacting the end user beneficiaries of the organization? Is it impacting certain staff members? Is it impacting them so much that they can't work? Capture that information and then it's much easier to go from there to building the right solution. Now Kendra, can you walk us through the goals and objectives? Sure. I really like what Elliot was talking about is focusing on that problem and not the solution. And part of that is data gathering and making sure that you understand how it is that your organization is working now. So is it statistics about how your resources are being used and gathering all that content when you go into starting to build out your technology plan? When it comes to the process of creating a plan, this is going to vary a lot depending on the type of organization that you have, how many people you have to work with you on the process. Elliot was talking about involving volunteers, which is a great thing to do if you're a single person operation or you have a very small staff and no one has technical expertise. Find someone in your community that can work with you on that. If you're a library, can you work with your board or a member of your trustees that can help gather the information about what it is your community needs? Have you done surveys to get that type of information so that you truly understand what the problems are and then you can focus on achieving a solution? When it comes to what your plan is going to actually look like when it's printed out, it's really going to depend on what your preferences are. It's very flexible. I've seen technology plans for very small libraries that I've reviewed and approved that were two pages long, and I've also seen them that were 25 pages long. So it's going to depend a lot on what your organization needs. So you may have something like a mission and vision statement, which is a great way to remind the people who are writing the plan about what your organization is looking to achieve in general with your mission statement. And then you can be very specific with your vision statement towards technology. I'm a big fan of historical statements that break down a little bit about the recent history about technology and your organization and the role that it has played. One of the things I frequently ask libraries to include is that if last year they upgraded all of their computer hardware, I would like to know that in the historical statement so that I have a good sense of the fact that they've actually done something very specific about keeping their hardware up-to-date and it just helps to tell the story. The goals and objectives, and sometimes the activities are really the meat of the technology plan. It's the thing that a lot of people struggle with writing so that they're effective goals and objectives. And then finally, a budget, which is the thing people don't like to do because they often don't know how much money they're going to have, which is a common struggle between libraries and nonprofits. And then finally, an evaluation component. How are you going to go about evaluating the success of your plan? One of the things I want to focus on talking a little bit about are the difference between goals and objectives because this is one of the tips that's going to help you actually put the plan together and really get to something that's going to help guide your organization. So goals are different in that they emerge because of what you know about your community or clientele. So when I talked about collecting data and information, and going back to Elliott's point about defining the problems, how can you see where your weak spots are if you don't have the data or anecdotal evidence to help support that? Goals are directed towards a particular clientele or particular topics. They're more specific than a vision statement, and they're different from objectives in that we don't usually connect them to a timeline. So it's going to be more of a high-level picture of something that you're going to achieve. And I'll show you an example and how you're going to work towards that in a little bit. And then finally, we'll talk a little bit about objectives. So how are they different from goals? Objectives are more targeted. They're going to be able to be crossed off when you finish them. They can be very specific to the point of saying who's going to do what and when. So if you have an IT manager and they're responsible for doing X, you can put that in there. They're measurable. There's a timetable for action, so you're going to complete this by a specific date. And while they stem directly from goals, you may have multiple objectives for each of the goals in your plan. One of the best tips that I can give to you when it comes to writing these goals and objectives is to use the SMART acronym. And that stands for Specific, Measurable, Attainable, Relevant, and Time Bound. And what we're encouraging you to do here is that when you write a goal and the accompanying objectives, you want to go back and review it to see if it makes and tells the story of what you're going to be doing. So is it specific? Is it clear what you need to get done? Are you putting something in there that's measurable to help you gauge the success of the project that you're implementing? Is it attainable? Do you actually have the staff time and resources to do what you're laying out? Does it support the library's mission or the nonprofit's mission? And when should it be completed or measured? How are you going to know when you're done? And this is an example of a goal that we have for libraries. And so one of the things we say, it's a pretty common goal is to expand and enhance public and staff access to electronic information through our website. And so the first objective is to replace the library's web server and software by August 2010. So we're saying very specific what it is that needs to be replaced. Some organizations like to break this down into activities, saying an accompanying activity would be we're going to take care of researching, purchasing, invoicing if you want to get that detailed you can. The second one is the outreach coordinator will develop marketing materials and aim to increase site traffic to the site by 20% after six months. This is an example of one that I would actually ask people to stop on because I'm like what are you increasing 20% of what? So what's your baseline number? Make sure you include something there so that it's much more measurable. So going back and reading these and applying SMART, the SMART principle is a good way to make sure that you're covering all of the bases in your goals and objectives because ultimately what you want is a technology plan that someone else would be able to read. It's a path for other people to be able to read about what your organization is trying to accomplish. So if I get a new board member, if I get a new executive director or library director, would they be able to come in and clearly understand what it is that you're trying to achieve? It's kind of making sure you've set the path for anyone else who comes into your organization, and set expectations for the work that needs to get done. The budgeting component is something that's really challenging for most organizations. Things are such in so much flux with what we know we have available at any given time. So I usually ask people to err on the side of only budgeting for one year. As a best practice, I actually like to see a three-year technology plan. I like to see what you're planning on doing now and what you have in the future. And it doesn't have to be specific like you know exactly what you're going to do in July of 2012, but what do you see as high-level plans for the future and just to get some forward thinking around that. In terms of specificity for libraries that are participating in the e-rate program which is especially important, they need to have at least a one-year plan with a budget and with a very clear set of goals and objectives. But as a best practice, I encourage all organizations to do that, to have one complete year, and then every year you come back to your planning process when you get to the complete portion of reevaluation and assessing the success of the plan and what you need to edit. And then you push out another year. So if your original plan was 2010 through 2012, next year your plan is going to cover 2011 through 2013. So you're constantly moving forward. And that helps a lot with the budget aspect of the technology planning. And then I think that Elliot is going to talk a little bit about how you take all this information and actually implement it. Okay, great. Thanks a lot Kendra. So I've put together just a couple of key points about implementing these objectives and implementing them in a way that works with the organization as Kendra was saying toward attainable and measurable goals. And I came up with three guidelines that I think are more or less consistent on any major change in your technical infrastructure, be it a change in your web content management system, be it a change in a collaboration server that you're using. I think that these are going to be more or less constant among most organizations. And the first one of these is a phased schedule. And connected to that is making sure that the staff knows actually what that phased schedule is and what's going to be implemented when. Don't implement many major changes all on the same date. But even more importantly, each time you implement one of these phases, have a complete backup of the way that your entire infrastructure was before that change so that you can roll back to it if need be. Don't build on top of something that is already broken. Don't build your house on the sandy land. Number two is publicize changes, which means a couple of different things. It means publicizing changes within the organization itself, among the staff, volunteers, etc. But also in some cases it means publicizing changes outside of the organization. Now what do I mean by that? I don't mean that you need to include it in your newsletter that you're going to start using SharePoint 2010. But I mean that there are implementations that do make a difference to people outside of your organization, be it major changes in your website, be it changes in your phone system and where people can expect to be seeing your email messages coming from. These kinds of changes do impact people outside the organization in a pretty significant way. And one thing that I think makes the nonprofit world really special is that we have these people who are not on our staff but still have this deep sense of belonging and this deep sense of pride in what our organizations do. And those are the kind of people that you do want to keep in the loop on these sorts of changes because also a lot of the time they're the best evangelists for your cause. P number three is train, oh I know, please train the staff. And this should be the most of a no-brainer among all of these, but unfortunately it's not. I've heard so many different stories of organizations actually making these pretty substantial changes in their tech infrastructure and leaving the staff completely in the dark. Not much better or maybe even worse is implementing the change and using a completely off-the-shelf prepackaged training that's not at all been tailored to the existing workflow. Here I'm actually going to go back to one of Kendra's slides quickly. When you do that, you're essentially sending the message, and it may or may not be true, but it is the message that you're sending that you really haven't connected those objectives of moving to SharePoint 2010, of adopting this new email server of whatever it is that you haven't connected those objectives to the greater goal because you haven't actually connected them to the organization's existing workflow. Now to toss it back to Kendra to talk about evaluation. When I think about evaluation, one of the things that I always encourage people to do that we talked about with that smart principle was that there's always something measurable about your goals and objectives, that there's a way to measure the individual success of those items. But I also encourage people to look at the evaluation of their planning process as a whole, and there are two important reasons for that. One is to identify how you've done, and two is to identify how you can improve. One of the things that people shy away from most kinds of evaluation, whether or not it's our technology plan, or our personal performance review at work, is that it's really hard to reflect back and find the areas that maybe didn't work so well. But what you are doing by taking the time to do that process is really identifying areas that maybe were pain points in the planning process or in the goals and objectives that you defined. And maybe it was the wrong time to try a new type of technology that you were implementing. You gave it a good shot. You decided we're going to start marketing and doing some things on Twitter. And here are all the things that we decided to try and do using this technology to encourage participation with our organization. And we saw really poor response after our six month pilot project. And here are some things we know about that. And the reason I encourage people to collect that information is that if this idea gets revisited in the future, and half the staff who worked on that project have moved on, or the information was never recorded, it's really difficult for the people coming into it to make some decisions if they are missing the whole story. So sharing and making sure you record that information is really important. And there are valid reasons that projects don't really pan out the way we intended. It was just the bad timing. Maybe we didn't have the right staff involved. Maybe we went about it in the wrong way, but kind of having a great breakdown of how everything worked or didn't work is a great way to help ensure that the same mistakes won't get repeated in the future. And it's also a chance to celebrate your successes. It's really important that with all the work that you put into your technology plan that when there is a success to celebrate that you and your team take the time to celebrate that and to acknowledge the work that went into something. And I think people always appreciate being recognized for the work that they've done on projects. And if they're spearheading the technology planning operation to reward them with the recognition that they've done a great job and that it's really helping the organization. Thank you so much. So for those of you who feel like we raced through that, we indeed did race through that. We want to make sure we have plenty of time for Q&A. And remember that we are recording this so you can go back and watch it. Again, we'll be sending you a copy of the PowerPoint along with the link to the recording after this afternoon. So I wanted to also ask Kendra to talk a little bit about Tech Atlas. Sure. So one of the projects that I work on here at Web Junction which is Web Junction is an online community for libraries. And we also work with the Tech Atlas project. And Tech Atlas was originally designed specifically to support nonprofits and some of their planning and inventory management needs. And several years ago we worked with the nonprofit that was running the tool and developed a version for libraries. And we've been working with the Bill and Melinda Gates Foundation on some of their grants and using Tech Atlas. Essentially what it does is to create a container for your technology plan. People will frequently ask me, how can I do this quickly? And unfortunately there isn't a really quick way to do technology planning down and dirty. There's a lot of work that goes into it and I would be lying if I said otherwise. It's rewarding and the results can be extremely beneficial to your organization, but it's a lot of work. So what we've done with Tech Atlas is to create a container for your technology plan. And what we have there are all the areas that you might want to include in your technology plan. There's space for you to enter the mission and vision. There's space for you to enter the members of your team, who's going to be working on this project, an area to enter all of your goals and objectives, and add timelines to them where it's appropriate, add in an evaluation to the objectives where it's appropriate. You can build in a budget. And we also allow you to download this into Microsoft Word. And usually at that point I encourage people to spend a lot of time editing it and making it there. So if you want to add your organization logo, change your fonts, make any adjustments. And you'll see that this version is Tech Atlas for Libraries. I'm actually going to go ahead and put the link in the chat box. This version was developed for libraries. And Elliot took a quick peek at it yesterday and thought it would be, for the most part, the terminology is definitely there and slanted towards libraries. But we've maintained it a bit more than the nonprofit version. So if you're a nonprofit and you're interested in giving it a shot, you can feel free to go ahead and create an account. And the URL is going to be in the chat box to go through. And there's also inventory management tools that if you want to inventory all of the computers that your organization owns so that you have a snapshot of all the resources, it's a great component for disaster planning that Elliot was talking about at the beginning. But one of the things that's important to remember about Tech Atlas is that ultimately it's a tool. So it's kind of like a car in the sense that you can have the car which is the tool that you want, but without the gas and the resources like a map and directions, you're not going to get where you need to go. So you still need to do a lot of work, but Tech Atlas can help get you started in organizing the needs and the content around what your technology plan is going to include. Great. Thanks Kendra. So thanks for those of you who are submitting your questions. Please continue to send those in. I will be asking the presenters these questions in about five minutes. So Elliot, I want you to tell us a little bit about a real example of a nonprofit that you've worked with and how Tech Plan has helped them. Okay, great. Thanks Kimmy. So this is a story, and you can find this whole story at the URL listed there. But this is I think a fantastic example both of the immediate benefits of technology planning and also of the longer-term benefits of technology planning that you don't necessarily take into account when building your plan. The Freestore Food Bank is a network of food banks in the greater Cincinnati area. And their technology infrastructure was very much in need of an overhaul. They had several banks around the city that were all on different systems. Some were Macs, some were Windows. Many were different versions of Windows. And it was very difficult to transfer data or to share records between those locations. There was very little to none in the way of backup. And in terms of email, it was just all of the staff using their own personal web mail accounts, be it Hotmail or Gmail or whatever it is. There was no unified structure for that either. And what they did is they, partially with the help of TechSoup, they underwent a pretty massive evaluation and rebuilding of their entire technology infrastructure. And again, you can find the full story by going to the URL there. But here is a quick quote from that. One of the most critical purchases that we made was the Data Protection Manager software which is available from TechSoup for shadow copy replica backups of our files. This advantage became especially important during the September 2008 windstorms when our Liberty Street location was without power for four days. We were still able to be partially operational because the site's data was protected at another location and was restoreable to another server. To me this is a key example of what I was talking about earlier in the webinar that disaster planning isn't just disaster planning for your organization, it's also for your community. Because they had these backups in place, excuse me, they were able to serve the community at a time when the community needed them the most. I'd also like to ask Kendra if she could share a story also of a library and their use of technology plans. Kendra Sure, one of the libraries that I worked with very early on with Tech Atlas talked about having a tech plan was able to help make her case for installing a new training lab because she had done the planning that was necessary to help prove to someone that they really had put a lot of thought behind it. And they were really successful at being able to present this document as part of their case. And it really goes a long way with people when you say, oh yeah, we're planning on doing that. But it's just kind of not in writing anywhere and there's no proof that they've been putting the thought behind the resources that are actually needed. But when this funder came along and said, what are you interested in doing in the library? She was able to point very quickly to something that was part of her wish list or her bigger plans for success in the library and bringing technology to their patrons. She didn't have the resources for it at the time, but she had drafted out information about what it is she wanted to be able to achieve and their vision for doing that. And it was part of their tech plan and a different library that under the similar vein was that, and she actually sent along this words of advice to everyone, kind of a tip. But she said that she usually starts with the wish list and then pairs it down into the must have and do's and then the want to have and do's in order to meet the budgetary goals. And so that's another way that you could approach your technology planning is to put in all these things as priority things that need to get accomplished. But then you can look and fill in the buckets. If you work through your budget in terms of things that you need to do in order to keep your organization running and to achieve your mission, those would be priorities. And then you look at other things that you know are going to enhance the services that you bring to your clientele or to your community and fill them in as funding opportunities become available. Great. Thank you so much for all that information. I wanted to share some resources that we've collected here at TechSoup. And Ellie, it's going to take a second to go through some of the information on this list. Remember, you'll be getting a copy of this PowerPoint as well as these links will be included in the post-event message that you'll get this afternoon. So Ellie, can you tell us a little bit more about these resources? Sure, no problem. So like Kamie mentioned, these will all be in the email that you'll all get this afternoon. I went through and made these all into short URLs to make them a little bit easier if you wanted to take one of them down now. But again, you certainly don't have to. Our Tech Beginners Guide is a very thorough book length document that we created that goes through many steps of the tech planning process and also includes people who are asking about worksheets and templates. It also includes several of those that you can download and use on your own. Planning for Success. This was a TechSoup for Libraries Cook book, but again, a lot of the information that's in there is just as relevant to the nonprofit community. The Disaster Planning and Recovery Guide, which I mentioned earlier, also be sure to check out our Tech Planning Forum. We've actually created a post in that forum for any follow-up questions. And Kamie will tell you about that later. That last one in that section is just a little blog post that I wrote with a lot of the same resources and a lot of the same ideas we've talked about earlier. There's a couple of things there about IT staffing. One is that essay that I mentioned earlier, The Purposeful Techie. Another is a great essay by some people who work for YMCA about mission alignment and about really making the technology plan catered to the organization itself and not just sort of this separate thing supporting the infrastructure. We have an article about asset management that talks about Tech Atlas as well as some other free solutions out there. We also have some information about total cost of ownership as well as some information from the Foundation Center about grants for technology. And then finally, we have that book that I mentioned earlier about working with technical volunteers. And again, all of this content is available for free. Wonderful. Now we're going to shift to the Q&A. Again, if you have a question, submit it via the chat. We have got a decent amount of time here so we should be able to get through all of the questions. And I'll just be throwing this out to either other presenters. So I will start with Kendra. This question came in through Twitter. What percentage of operating expenses should be set aside for tech planning including purchasing, training, and maintenance? Wow, that's a great question. And I wouldn't really be able to answer that in terms of a specific and what people have set aside. I think it depends a lot. Some organizations need such a little amount of technology to achieve their organizational mission successfully that it would vary so much depending on your organization. Your staffing needs generally take up the vast majority of your operating budget. But in terms of what it would take for technology, it really depends on your organization and how technology is used to achieve your organizational missions. Libraries are unique in a lot of ways because they have to have all these public access computers that they maintain which is different from a lot of nonprofits. So their operating budget is going to rely on a fairly large portion of that technology as opposed to an organization that doesn't have a public-facing presence and doesn't need to support technology for those users. So it really depends on the type of organization that you're working with. This question is for Elliot. Judy's question is, as a CEO, I struggle with how to weigh what we need versus having all the bells and whistles that my IT person may want. So much info, I can get lost. Sorry, may want so much info I get lost in the details. That's a great question. And thanks a lot to the person who asked that question. This is a topic that I kind of enjoy talking about. As I mentioned earlier, a couple of weeks ago I gave a somewhat similar talk at the National Conference on Volunteering and Service. And we had a very interesting kind of pseudo-debate when I was giving that talk as there was this one ED who raised her hand and said something very similar to what this person said maybe in stronger words. I have this tech person who is very insistent that I adopt all of these new technologies, but I don't have time to think about these. And they've not given me any reason to motivate me. They've not given any case for why this particular new technology would improve my workflow at all. And what I would respond actually is you may be right. It may well be that this particular recommendation is out of a kind of geeky desire to have the newest thing. And it's actually not based on any actual need. It's not solving any problem. Where the rubber really hits the road is in challenging that person. And if it is an accidental techie or somebody who also has another job, giving them the time and the resources that they need to actually wrap those recommendations into a thorough tech plan that addresses the real workflow of the organization and actually make the case to you for why those adoptions are necessary. And in some cases you may be right. They may be things that would be nice to have but actually are not mission critical. Thanks, Elliot. This question is for Kendra specific to Tech Atlas. So Mary-Jane is wondering about if Tech Atlas has an evaluation section and if there's a way to archive tech plans. So there is an evaluation component built into Tech Atlas. And what you will see is that when you're building your goals and objectives, there's the ability to tie an evaluation component to each of your objectives. So you can actually type in as part of the objective how it is you're going to evaluate the success of a specific task that you're looking to accomplish. And then there's also a general evaluation section which is similar to what I was talking about before where you're really going to look back and measure the success of the planning process. And you can choose to use those or not. One of the things that's important to understand about Tech Atlas is that it is very a la carte. You take from it the sections that are most beneficial to your organization. Some people, for example, choose not to use the budget in Tech Atlas because they build it in Excel or in QuickBooks or in another resource. So they don't put their budget in Tech Atlas. And the same goes for the evaluation component. If you find that you don't want to use one or the other, you don't have to. But I encourage you to find a way to include the evaluation in some way so that you can clearly measure the success of your programs. And Elliot, this question is from Mike. How do I get users that have positional authority past their emotional attachment to some existing tech that is a hindrance to progress so that they can improve their workflow? Just like I have a soft spot for the accidental techies, I also have a big soft spot for the late adopters. There's a story that a couple of people on this call I've heard before that is actually a colleague of mine used to work on the original QuickTime team, the team that created QuickTime 1.0 for Apple. And one of the programmers on this team did not have email and did not even have voicemail. What he had instead was one of those old fashioned phone answering services like from the 60s. And the cool thing about this is this entire team actually adapted their entire workflow to work with this person. They didn't use email very much. They mainly communicated over the phone. I think that's a neat story and it goes to show that the technology actually isn't the problem. The problem is getting everybody working together using tools that they're comfortable with. And again, the way that I would say it to maybe start to deal with that emotional attachment as you said, or at least kind of start to understand it, is like I said before to really build a case about not why every technology adoption ever is essential, but why this particular tool, why this particular adoption will impact the workflow of the organization. And when you start to frame it that way, you can have a useful back and forth and you can find a tool set and a way of collaborating that works for everybody. So a couple of folks have asked if they could see samples, technology plans, or where they can find sample technology plans. Kendra, can you tell us a little bit about if there's resources available for sample tech plans or if we can provide them with some? Kendra Sure. So one of the things that's been a little bit of a concern for us is that libraries that are required to write technology plans as part of their participation in E-Rate are required to have their technology plan and it can be reviewed by the program administrators who work for the program. And we've been very concerned about providing samples that would possibly end up becoming permanent technology plans in situations where people just take the content and make it their own. We know that there's a lot of general technology goals, especially in libraries that have common missions, but we've kind of strayed away from posting entire documents that are examples of technology plans. We do, however, on Web Junction have examples of writing successful goals and objectives, and there is some example content there, but we've kind of shied away from doing that just to avoid any chance of providing templates that might get a library in trouble. And that's ultimately what we're trying to avoid is to make sure that people individualize their work. So if it ever gets reviewed by this federal supported agency that there aren't any conflicts, but there are lots of examples of how to go through the process and how to write goals and objectives on Web Junction and the URL is webjunction.org-techplan. Great. Thank you. Now Elliott, a question from Jacqueline. Should a statement about risk and failure be in the plan? And what should it address? That's actually a really great question. And if Kendra wants to jump here and add to my answer, I would certainly encourage you to do that, Kendra. I'd say yes, it should. And there's actually, if I remember correctly, there's a section about this in the TechSoup for Libraries Cookbook that we mentioned in the resources. But my short answer to that question is yes. Do you have more that you'd like to add to that, Kendra? Well, I think it's great from a project planning perspective and that it certainly can play a role in the tech plan is that if you need to get all of your servers replaced for a specific reason like you're supporting new software that has to go live July 1, then there is, and if the servers aren't installed by June 1 so that you have time to do testing, then understanding that there's a major cascading impact is really important. And so knowing where those contingencies are in your planning process is really important to ensure that you hit all the things that are required before the deadlines come up on you. And I'm going to ask Alea a second question. Please talk a little bit about how ETs can integrate new vision technology into mission without cannibalizing mission-critical technology. That's a really interesting question. I'm not sure how exactly. I don't think we'll really be able to do it back and forth. This might be a good question to continue in the forums. I think that getting excited about new and emerging technologies is a wonderful thing. And I think as much as possible incorporating those into the broader plan is also hugely important. At TechSoup we talk a lot about social media and we talk a lot about kind of moving beyond just having one community person kind of handling the Twitter and Facebook or a volunteer or something, moving beyond that to actually incorporating those things into a broader communications plan, having a social media policy, and having those experts in the organization who are good at those things be not just the only people using them but be the ones empowering and training the rest of the organization. And this question is for Kendra. Tony's statement question, did I understand correctly that you recommend developing a three-year plan but reevaluating it every year with this help with the rapid growth in change in technology both in hardware and software? Tony, that's exactly what I was getting at is that if you just do one year it's very easy to focus on some immediate needs and things that you need to keep your organization running. The reason that I encourage people to do at least a second year, three if they can, and if it's practical, don't do things that aren't practical or if you know you don't have the information to really do a three-year plan. Don't be compelled to do that. What I really like people to do though is think about, okay, if you achieve everything that you need this year, what are some other things that you'd really like to see happen for your organization that involve technology that are maybe more vision oriented and helping you achieve that vision as opposed to mission critical, which is something we just talked about. And what would you want to see for your organization and include that in your technology plan? That's one of those things. Some organizations are under the gun at the end of the year to implement, to spend money. Something fell through and suddenly there's additional funding available. Having the initial planning in place to be able to support a request that comes in at the last minute is really in your favor. If you're the technologist in your organization, then you want to be able to say, hey, I've already got a plan ready to go, and it's something that we all discussed and included in our technology plan, and I'm ready to get rolling on it now. So that's the reason that I really encourage people to think beyond the one-year planning cycle so that there's some forward planning to go forward in the future, especially if that involves needing to get funds in the future. When you get to the point where you're reevaluating the technology plan at the end of the year, those things that you were hoping that might happen in year two when you come to actually planning that year may drop off entirely. You may find that your needs have changed, that that option is really no longer on the table for you. So then you take it out and you add in whatever is going to be relevant for that year. But at least you've done some of the thinking around where you want to move with your vision. Great. And we've talked a little bit about where you can review tech plans, but is there a place where people can find specific questions that EDs can ask? And Elliot, can you answer this one? Like the list of questions that EDs should be asking of a consultant or of their staff? Okay, that's a really good question. And I like the way that question is framed. It's often about an ED not only not knowing what she needs, but not even knowing exactly what the right questions to ask to get to that are. And I don't mean to blow our own horn at this too much, but I actually think that when you look at TechSoup.org's content, that's kind of one of our core competencies is presenting things in such a way that don't necessarily answer every question, but at least get, for example, the ED and the techie or the ED and the tech consultant and the board member, whoever it is, all speaking the same language and all knowing what the right questions are. So the first answer I would say is read up and research on some of these things for ourselves. And certainly our website is a good place to start with that. And then the second part of that is with that tech person in your organization actually both challenge them and empower them to help you with that and to not only make recommendations, but to educate you some about some of the framework and then it can become much more a decision-making process as equals. Great. Thank you both presenters, Kendra and Elliot, for this wonderful information. And we went through it rather quickly, but we are out of time. So if you have additional questions, please post those to our Tech Planning Forum. I've provided a short URL via the chat and it's on the slide as well. I'll include it in the post event message that you will get in about two hours. And if you're new to TechSoup, there's more that we have to offer than webinars. We have great articles, donated software. Our community farms are a place where you can post questions and read questions and answers from other nonprofits and libraries as well as find upcoming events and conferences. Here's a couple of upcoming webinars that we are offering this Thursday, a webinar on business planning for nonprofits and libraries, as well as Microsoft is offering a webinar next week, what's in Office 2010, what's in it for nonprofits and libraries, and all of our webinars are free. We'd like to thank ReadyTalk. This webinar is made possible by ReadyTalk which has donated the use of their system to help TechSoup expand awareness of technology throughout the nonprofit sector. ReadyTalk helps nonprofits and libraries in the U.S. and Canada reach geographically dispersed areas and increase collaboration through their audio conferencing and web conferencing services.