As I look towards the end of the semester, I can’t help but think about what’s ahead. It’s time for us to dust off our strategic plan and think about activities for Fall even as the echoes of unfinished projects and initiatives that seemed like a good idea a few months ago still linger. We’ve recently been on a technology shopping spree where we’ve steadily been adding new toys and gadgets to our ever increasing stash of Go Pro’s, 3D printers, HTC Vive, and a myriad of chargers, microphones, and accessories.
We’ve offered both internal and external training, and most of our equipment is well used thanks to our outreach efforts. But there is still the sense that we don’t have a great plan for how to deploy these tools and we deal with requests for assistance on an ad hoc basis at best. In reading about strategic planning for technology, I ran across an interesting model, technology mapping.
According to Marie Garcia and Olin Bray in their paper entitled “Fundamentals of Technology Roadmapping”, technology mapping allows an organization to identify the needs that will drive technology selection and implementation keeping in mind that there is no certain way to predict what the next “hot” area of interest might be but allowing for a flexible and forward-thinking planning process in several iterative and interrelated steps, much like design thinking or similar model.
Phase 1
- Develop the context for the roadmap which explains why the roadmap is needed and how it will be used
- Identify the problem that the roadmap can assist in solving as well as potential partners and stakeholders who can help
Phase 2
- Identify the product, service, or resource that will be the focus of the roadmap and what critical requirements are needed in order to achieve success, whether it be in the form of hardware, software, personnel, or other area
Phase 3
- Develop an implementation plan, assess, review, and update as needed
While this process may not seem different than other strategic planning models, a few things strike me as interesting. First, the entire roadmap is based both on user and library needs. Too often I’ve been involved in a process that seems to be very removed from either of these areas and while broader institutional goals are taken into account, it feels like a very unilateral way of dealing with what should be an organic and effective way of determining where the library is headed. This idea of stepping back allows for a (hopefully) accurate snapshot of what problems users are having as well as establishing a frank dialogue about the library’s capacity and willingness to solve them. The library may truly want to address all of the issues that are uncovered, but if there is no staffing or funding to do so, it seems like a pointless venture. Alternatively, this can also open up the discourse with institutional administration so that if a need seems compelling enough from the library perspective and a case is made that it should be resolved, it might be supported exactly because it has been brought to the forefront in a thoughtful manner whereas it might not have been uncovered had this initial needs assessment been conducted.
Second, I also really 
like the way in which this process forces the discussion about priorities and what specific tool or service will be their focus. I think sometimes we get caught up in buying the latest and the greatest simply to say we have it only to be left wondering how we are going to support it once the excitement is over. But if we cannot articulate how exactly we are going to make this technology successful as part of those larger library and institutional goals, chances are it will become another forgotten fad locked away in a closet for someone to find years later.
Finally, I like the element of the operational merged with that of impact. I’m guilty of this “we’ll figure it out later” attitude myself, but it’s much more productive to know how you will accomplish your goal from the start rather than piecemeal a solution later down the road. I think this also helps address the question of “what” in a process that is really more focused on the how. In thinking about strategic directions and goals, we’re great at saying we will do x by this time, but the details are very much in question until it comes time to implement that goal and no one truly knows where to start.
Whatever your technology strategic planning process looks like, it’s important to keep in mind that there are other models to try and that technology planning is quite different from its more “traditional” counterpart. Just realizing there is a difference makes, well, a difference and knowing how to structure the process so that it provides a meaningful result can help prevent you and your institution from feeling like you have to have a crystal ball to know what’s coming up.