A Framework for Making Successful Technology Decisions The Steps

These two core concepts are carried through the full process of decision-making, using specific steps and tools to guide your team’s thinking. Whether using design thinking, systems engineering, or both, the intent of building your agency capacity is to increase your team members’ sense of ownership in the process and its success, think critically about solutions, and contribute to a complex project.

Specific steps for agency capacity-building consist of the following:

Engage all stakeholders early in the process, establish a solution-space owner, put the solution-space owner and other affected staff in decision-making roles, leave the solution-space owner in a leadership role during procurement and the project’s implementation.

To ensure that your project maintains a systems-level view, these organizing tools can help everyone work in concert. It’s not necessary to use all of these tools every time, but it’s important to have them available to you and your team when they can help. Organizing tools; Design thinking, systems engineering, risk management matrix, RACI matrix.

Phase 1: Define and Rank Problems

One of the hazards transit agencies face is that problems don’t present themselves as clearly as a burned-out light bulb does. You have to know what problem you’re trying to solve before you start solving it.

During this phase, start by making a list of pain points across your operations, whether or not they currently relate to an automated/electronic form of technology. People know what they don’t like, making it an easy entry point that keeps attention on unmet needs. There will be time to fully inventory all the technologies that you use later. As many people in the agency as feasible should contribute to this list. Pain points are essentially observations, and they don’t have to have a particular structure or format. You’ll take each observation and convert it to a problem statement, which is more targeted and must meet specific criteria. Finally, you’ll evaluate each problem statement based on the risks it presents. This phase borrows from the cybersecurity-focused work of the National Institute of Standards and Technology and others and applies it to today’s transit context.

Cast a Wide Net to Identify Pain Points

The first step in identifying what isn’t working is to cast a wide net. That means including as many people from as many parts of your organization as possible in conversations about pain points. Once a pain point is identified, it’s essential to gather information from the people most affected by it; you want to be able to evaluate the severity of the situation and fully define what the problem means throughout your operations. You may even decide to go outside your organization, to access someone else’s domain expertise and/or personal experience with your services. In this paper, we won’t prescribe who should be on your team, and for simplicity’s sake, we will speak in terms of “your organization” and “your staff”, although you may be working with external partners and stakeholders, too.

Questions you can ask include:

• How much time a week do you spend doing X?
• What do you think are some other ways we could accomplish this?

Front-line staff may not be used to thinking about other ways to get a task done (although you may be surprised!). By asking questions about their experiences, you are not only gathering information and possible solutions, you’re also increasing your chances of success later on. This early engagement is the first step in the framework’s capacity-building process. It builds the foundation for staff becoming stakeholders who are invested in making the eventual solutions successful.

Capacity Building Step #1 Engage all stakeholders early in the process.

At this point, you are focused on making observations about what isn’t working well, without emphasizing solutions or broader implications.

What Your Problem Statements Should Cover

After gathering information from throughout your organization, it’s time to turn your list of pain points into a list of problem statements. Problem statements have two important qualities:

When rewriting your pain point list into problem statements, check for considerations like the ones below. You should keep asking questions (these or your own) until you have a problem statement that can be directly connected to a technological issue that is getting in the way of achieving all or part of your mission.

Because of this problem, are we:

• Falling short on any of the core expectations⁶ that make transit useful?
• Getting out of alignment with the agency’s approach to the ridership-coverage tradeoff?
• Feeling the effects of inefficiency?
• Suffering from growing pains?
• Stuck with aging tools that no longer work?
• Putting the safety of our staff and/or riders at risk?
• Hurting the morale of our staff?
• Facing an existential threat (“If we don’t do this, we lose relevance.”)?

Figure 3 shows examples of pain points, along with draft and final problem statements.

⁶ See Chapter 2 of Human Transit by Jarrett Walker. A summary of the core expectations can be found at https://humantransit.org/2011/12/outtake-on-endearing-but-useless-transit.html.

Ranking Problems by Risk

When it comes to managing risk, it’s helpful to look at two dimensions:

• What’s the level of impact of this problem/situation, especially on service reliability?
• How likely is it to occur?

This risk management matrix provides one way to organize a set of potential risks along these two dimensions.

Organizing Tool Risk Management Matrix.

You can place all of your problem statements within a matrix like this to help you set priorities. Your matrix will undoubtedly look different (and it should!); this example includes issues beyond technology and isn’t tied to your agency’s particular situation.

This matrix is particularly useful as a reminder to look ahead at implementation and maintenance; it’s never too early to think about these phases of a technology project.

When ranking your problem statements, it’s also helpful to be as specific and as quantitative as possible when describing the costs associated with each problem. Estimates are fine, and in many cases, they’re unavoidable.

Phase 2: Develop Potential Solutions

Assemble Your Team(s)

You’ve already tapped into the expertise of your organization’s staff about what isn’t working well. Now it’s time to involve your staff in exploring ways to fix what’s broken or tweak what could be better.

We suggest forming a team or teams to investigate problems and possible solutions. A team should incorporate people representing as many roles and perspectives as possible. It’s okay if not everyone (or even if no one) feels confident about technology. Having a “beginner’s mind” can be helpful, because even a little bit of knowledge can result in blind spots. Coming to this process relatively unburdened by preconceived notions can be an advantage. We’ve written this paper envisioning agencies that don’t have dedicated IT staff, in fact.

If you are one of the valiant information technology staff serving a small transit agency (thank you!), you are probably the only in-house technologist. Your perspectives and knowledge will be essential to this process. Being involved in a team like this will help you increase your understanding of how to present a technology issue in a way that a non-technical person can better understand. And your non-technical counterparts will likely gain a greater understanding of what makes your work challenging and valuable.

Capacity Building Step #2 Establish solution-space owner.

For each problem statement, establish a “solution- space owner”, who will manage the exploration process and the selection and implementation of the eventual solution. Distributing these leadership roles among staff will increase the agency’s overall capacity to make good decisions. It’s crucial to make sure these people have the time to do this work, and if a leadership role is new to them, create a supportive environment for them to ask questions about their challenges.

Understand Your Systems

Your agency is aiming to end up with a successful technology portfolio, which is essentially a collection of systems that interrelate in a thoughtful and sustainable fashion.

To understand where you’re starting from, your team should map out all systems currently in place, for every aspect of your operations. You might be thinking that this should have happened earlier, prior to identifying problems. That’s certainly a reasonable thought. We put it later in the process so that your team’s first task isn’t overwhelming. It can be daunting to dig deep into the details of your operations, and we recommend beginning with pain points instead.

Consider systems in the following areas, and add others specific to your situation.

• Scheduling and dispatch
• Customer tracking
• In-vehicle technology: computer-aided dispatch and automated vehicle location (CAD/AVL); internet connectivity (routers, Wi-Fi, etc.); camera systems; stop annunciators; automatic passenger counters (APCs); headsigns; fare systems
• Reporting: for operations (for example, NTD, hours, miles, ridership) and finances
• Fleet management
• Other asset management
• Connectivity: telephony, internet at facilities, and mobile network or radio in the field

For each system, document the available budget, staffing, and existing infrastructure. It’s also a good time to assess each system’s reliability, usefulness, and time frame for mandatory replacement.

Take the time to examine the workflows for each system. These steps can be so routine that it may be hard to articulate them. Writing down each step in your current processes will help you later on, when you are evaluating the impact of a new technology on your existing workflows.

As you build this map, you’ll undoubtedly identify systems that you’d like to have, even if it’s in a vague way (“better scheduling” for instance). You’ll also want to think about what kind of budget, staffing, and infrastructure would be needed to support these new systems. In thinking about the budget, keep in mind that grants are great for purchasing and implementing, but your budget needs to account for the full life of any purchase. Be clear-eyed about what resources are available for long-term maintenance and staff training. At this point, you may not know enough about new technologies to make accurate forecasts of necessary resources; that’s fine. Any information gaps can become part of your research priorities.

Build Knowledge by Casting an Even Wider Net

A solution team’s main task is to gather information that will build the agency’s collective expertise. Whether team members are working in unison or individually to build knowledge, we recommend going outside your organization to learn more.

No matter who you’re talking to, take every opportunity to ask about costs and what others are getting or producing for that cost. You’ll be able to form better cost estimates as a result.

Above all, expect and plan for this stage to take time. You’re investing in this process so that you ultimately have solutions that meet your specific needs. Below, we’ve shared four potential sources of information and support.

Reach Out to Vendors, Peers, and Aggregators

You’re not alone! Even though your agency might feel unique in terms of the mix of services, funding sources, or other constraints, you have access to a large number of people who run transit agencies who have felt the same way about technology, whether that’s skeptical, reluctant, overly optimistic, overwhelmed, or some combination that we haven’t thought of. Even if they haven’t solved the same problem that you have, in the same way that you will ultimately implement locally, you have peers who have moved from having a problem to incorporating some kind of technology to solve it.

Getting advice and guidance from people who’ve been part of technology implementations can help you build your expertise in making technology decisions. You can do this by reaching out to peers that you know have done something similar to what you are planning, contacting knowledge aggregators like the National Center for Applied Transit Technology, National Rural Transit Assistance Program, Federal Transit Administration, National Center for Mobility Management, and your state DOT and/or issuing a Request For Information (RFI) prior to releasing a more formal Request For Proposals.

Issuing an RFI is usually not required in a procurement process. You should choose to develop an RFI only if you see a clear need for one and if you have the capacity to implement the process. You could also take an even less formal route, by reaching out to vendors you already know about or asking for recommendations from your network.

Whether you call it an RFI or not, this optional action has several advantages when it comes to building your expertise with technology decision-making.

We admit to having a preference for RFIs over Requests for Qualifications (RFQs), simply because an RFI is open to input from other agencies and groups like N-CATT, too. It’s helpful to hear from people who use technology as well as those who sell it. Building your expertise in terms of what’s on the market and what other agencies have already done may help you refine your understanding of your problem.

Learn from Other Industries

The wide net you’re casting can also stretch outside the world of transit agencies. Other industries have problems that are similar, if not the same, as transit organizations. Any industry that manages a fleet of vehicles has probably thought about in-vehicle cameras and asset management. Logistics companies, for instance, are close cousins of transit.

Going to a Conference? Map Out Your Strategy

Conferences can present a dizzying array of learning opportunities. When you’re trying to gather knowledge related to a specific problem area for your agency, it’s a good idea to have a conference game plan. Before you go, make lists of whom you want to talk to, whether that’s a hallway conversation with an agency peer or a chat at a vendor’s booth.

Have a clear research agenda. Be ready to ask vendors the questions that matter to you about their products, maintenance/support services, and overall costs. Vendors are most likely to send members of the sales team to a conference, but sometimes their engineers also attend. Regardless of who you’re talking to, your goal should be to get a good sense of their product’s capabilities, using strategic questions such as:

• What do your most successful product implementations have in common?
• Who do you think your ideal client is?
• Where does most of your business come from? (This could be in terms of geography, agency size, type of service—however they choose to answer.)
• When have you seen clients get stalled in implementing your product?
• Where do clients stumble as they use your product?
• What do you think a client should have in place before they adopt your product?

You will likely hear a lot about the strengths of their product, so much so that you may wonder if there are any flaws at all. However, as you listen to their answers, look for what they didn’t say. For instance, if they primarily serve fixed-route service providers and your primary need is for demand-response scheduling, that’s an area of potential mismatch. If you’re able to make these connections in the moment, fantastic; if you need to take some time after the fact to reflect, that gives you a starting point for a follow-up email or phone call with the vendor.

Do You Need a Consultant?

Knowing whether to bring in a consultant can be tough. How can you know if you’ll realize any return on the investment, both in terms of the contracting cost and your time? If you’re starting to think about seeking consulting support, consider reaching out to your peers or staff at technical assistance centers like N-CATT, National RTAP, NCMM, or your state DOT. These resources can provide a reality check about whether you need an ongoing outsider perspective, and they may have suggestions about where to turn.

There are at least three situations where we’ve seen consulting services present clear advantages:

Though procuring consulting services can be its own painful process, the combination of industry expertise and fresh perspectives can make the difference when the path forward is unclear.

Set Priorities

As your team wraps up its knowledge-gathering activities, it’s time to review what you’ve all learned. Revisit your risk management matrix to see if your assessments have changed. Fill in anything that wasn’t previously accounted for, whether that’s a more informed cost estimate or a new risk you hadn’t thought about.

As you match possible solutions to the risks, an outline of your priorities should begin to emerge. It may be tempting to address all the most important/highest risk areas right away, but it’s very important at this point to think about your agency’s capacity to implement. Most of the time, you’ll do well to work in phases, starting with the most important or foundational elements first. Consider that unplanned staff turnover or other risks may happen, and think through the steps you’d take to mitigate these risks.

Comparing Your Options

At the same time that managing transit is inherently complex, small urban and rural transit occupies a small niche in the overall mobility landscape. Although we dearly want plug-and-play solutions, oftentimes, those are not currently available for our industry. As a result, we have to be exceptionally rigorous when we examine different options available to us.

Know What’s Most Important

Costs and benefits don’t always translate directly to dollars or any other quantifiable numbers. The impact of rider-facing amenities is often stated in qualitative terms, which brings a good deal of subjectivity into the picture. Your cost-benefit analysis is going to come down to saying, “This is how important x is relative to all our other concerns.” An agency strategic plan is the first place to turn for that kind of prioritization; if none is available to you, seek to align your ranking of different options with priorities that your agency has already set as much as possible.

You need to be ready to rank different options—and to be ruthless every time. This diligence will keep you focused on what’s truly most important to meeting your ultimate goal of improving the rider experience at a sustainable pace. Be sure to keep the costs and benefits of the status quo in the running as a real option so that change for change’s sake doesn’t get an implied boost in the analysis.

Take care to consider both a technology’s public visibility and its value to the service your agency already provides, and be clear about what you are trying to accomplish. Are you intent on converting non-transit riders? Are you aiming to meet the needs of an agency’s core rider population? It’s important to be explicit about your goal.

It can be an uphill struggle to prioritize investments that substantively support the rider experience when there are flashier projects that garner more attention from the non-riding public. This is especially true with technology investments. In recent years, venture capital-funded ride-hailing businesses have exerted a great deal of influence on the general public and policymakers alike, resulting in a significant overweighting of the value of mobile device apps and the types of services that rely on them.

To help them better understand the nuances of rider-centered technology investments, it may be useful to take the time to share a “Transit 101” overview for your board and other key decision- makers. This can include topics outside of technology decision making. You may want to cover issues like:

• Why service reliability matters more than almost anything else—and what can be done to increase it
• Why using smaller buses won’t save money, and where the real costs of transit are
• Why some improvements enhance agency scalability and others do not

Remember: Technology Wasn’t Necessarily Built with You in Mind

You’ve already spent a good deal of time articulating the problem you want to solve. It’s complex, but you are convinced that the tech companies must have already accounted for everything. It’s all built in already, so all that’s necessary is finding the right vendor who will Solve All the Problems.

Well, maybe. It’s true that there is a lot of software out there that seeks to automate workflows, for instance. But every organization is different, and so you have to dig into the assumptions that the software makes about how your organization works. Earlier in the process, your team mapped out your existing workflows, and now it’s time to compare them to the workflows that were assumed during the software design process.

To get a sense of what this workflow comparison process would look like, consider what it was like for you to switch from a flip phone to a smartphone or to help someone else make that transition. You had a piece of technology that you knew how to use, even though it had its limits. Then you replaced it with one that could do everything that your flip phone could do and so much more. You needed to relearn the steps for making a call, sending a text message, saving someone’s contact information, and taking a photo, among other things. You probably moved from pushing manual buttons to a touch screen. You didn’t have the option to replicate the actions that you were used to taking to accomplish a task. You had to learn the new workflows that were built into your new phone.

The same kind of transition will be necessary for any new transit technology you adopt, but at an organizational scale. If you opt to go with an existing product, be aware that you will need to adapt to the workflows that come along with it. When you commit to a vendor, prepare for the organizational change that entails. By engaging a broad cross section of your staff in the overall process, you’ve set yourself up for a greater chance of success if new workflows are necessary.

It is likely that a vendor can make adjustments for your type of operations, but that adds to the cost and complexity of your project. Like everything else, customization has its costs and benefits to weigh carefully, and you’ll need to understand the amount of necessary customization in order to make that analysis.

What Can You Commit to Maintaining?

As you look at costs and benefits, don’t forget to assess the complexity of what you’re considering when it comes to maintenance. Of course, it’s important to think about your implementation plan and all the potential disruption of a technology transition will cause. But the main limit around technology is less about what we can implement. Rather, it’s what we can maintain. Talk to other agencies that use the product or products you are considering about their experiences. How much time does the specific technology you’re interested in require as far as maintenance goes? What steps are involved? Take the time to work backward from the resources that will be available to you once everything’s in place, and evaluate your ability to maintain each option that you’re considering over time. If you can already foresee that one of your options will take too much time or money to maintain, cross it off your list.

A common misconception is that a new system will need less time for maintenance—or even that it will be maintenance free. As soon as possible, confront this line of thought with a reality check. New technology is more likely to change how time is spent rather than save time. You may gain efficiency in one area of operations, but that will likely be at least partially offset by additional maintenance requirements. It’s up to you to assess whether that trade-off is worthwhile in your situation.

Term to Know: Software as a Service

As you consider your options, you may encounter the acronym SaaS (pronounced “sass”), which stands for software as a service. SaaS products represent a different method of getting access to software. In the past, software would be “locally hosted”—installed directly to your workstation and/or your on-premises server. You’d pay for the software licenses as capital expenses. The software “lived” on your computers, and whenever the software company developed a new version, you were responsible for manually loading the upgrades, probably from a disk, CD, or other physical storage device.

With SaaS, the software lives on servers at a remote data center, not on any of your hardware. It’s “web hosted”, rather than locally installed, and you access it via the internet. The software company is responsible for making sure the software on the remote server is up to date. Rather than paying a one-time purchase price, you pay a subscription fee to have access to the latest version of the software. You’ve probably seen notifications on your computer along the lines of “The system will be down from 1 a.m. to 3 a.m. on date X for a version upgrade”. The next time your computer restarts, it will have all the latest features and bug fixes for that program. No CDs required!

Chances are good that any software you purchase today will be provided under a service-based model. If you currently have locally hosted software, it’s likely that the software vendor will at some point stop providing support for it, if they haven’t already. When you make the transition to SaaS, you’ll need to consider some operational issues.

One risk with SaaS is that if your internet connection is down, that means you can’t access your software—which can paralyze scheduling and dispatch, among other critical operations. Since implementing SaaS usually results in some cost savings over locally installed software, a good use of those dollars is to build redundancy into your network, either through a system that automatically switches to a second wired connection (available in many urban areas) or to cellular service (often the only other option in rural areas).

Another risk with SaaS comes from the SaaS provider itself; their systems can go down, too. Any SaaS provider should be able to provide information about their “uptime” history and how they will communicate with you about service disruptions. These issues should also be clearly addressed in their service-level agreement (SLA), in terms of the guarantees they provide regarding uptime and the compensation given when those guarantees aren’t met.

How Well Do Existing Technologies Serve Your Needs?

After gathering information about potential solutions to your high-priority concerns, it’s time to step back and review them. This is where two tools for systems thinking come into play.

Organizing Tool Design Thinking

Design thinking allows you to be flexible and iterative when considering multiple options and how they might fit together. It’s also a good method for testing out whether you can minimize the use of new technology; maybe you have a pencil-and-paper system for scheduling that’s actually working better than any electronic system would, given your situation. As a fairly open- ended process, design thinking can be difficult to use when a project involves a set budget or timeline, however.

There are cases when design thinking alone isn’t going to be enough. You’ll need additional tools if:

• You reach the conclusion that the current marketplace simply doesn’t address your problems;
• You see that your needs can only be met by chaining together a series of independently produced technologies; or
• You are coordinating across several agencies to unite different technologies in a way that should be seamless for riders.

Organizing Tool Systems Engineering

These situations benefit from systems engineering. Whether and how much engineering to do is a key decision-point. Your team should consider the following questions carefully:

• Are there any off-the-shelf solutions?
• How much new engineering is truly needed, and why? (e.g., there’s no solution in the marketplace, required integration with legacy systems, etc.)
• What are the ways to minimize new engineering and instead rely on the prior engineering work of vendors?
• What are the mature or developing standards you can lean on?
• If the goal is to forge new ground or address an as-yet unmet technology need, who can be your strategic partners? Who are the potential peers, coordinating bodies, funders, or other players who can team with you?

Systems engineering isn’t for everyone. It requires considerable agency capacity, and it’s only worth doing if your project demands it and if you can devote time and money to do so.

If your task is complex enough to require systems engineering, it’s worth considering whether you want to build a solution that neighboring agencies could use to address common issues. Pooling resources can help offset some stresses, and, perhaps, reduce expenses, but it requires considerable time for coordinating efforts. Asking yourself whether teaming up with your peers is a good question for your analysis; just remember that you need to take the same hard-eyed approach to assessing the associated costs and benefits.

Design thinking and systems engineering can complement each other. For example, engineered elements can be procured one by one according to an iterative master plan. The plan can then be refined after each successive piece is put into place.

Use Standards and Advocate for More Standards

Having data in standard formats is incredibly powerful; it allows us to share information across agencies. One of the most important applications of data standards is trip planners that pull in information from multiple transit providers. Thanks to General Transit Feed Specifications (the oldest and most mature standard in transit) and its extension, GTFS-flex (which deals with demand-response transit), it’s possible for independent agencies to present a seamless interface to riders for trip planning.

What does this mean for your decision-making process? You should always ask vendors about their products’ standards compliance. Emphasizing standards and interoperability between engineered components allows for gradually adjusting how pieces connect or swapping out of components. It’s not quite a plug-and-play solution, but standards will help you get closer to that.

In the case of a mature and public-facing standard such as the GTFS, it’s important to require that a product support the standard in a high-quality way. For example, it’s essential to confirm that a product’s GTFS output will represent your agency’s services accurately when they appear in Google Maps or other tools.

GTFS and GTFS-flex are powerful, but they don’t cover everything that we deal with in transit. Many other standards are in development. You don’t have to become an expert in all these standards (although if that’s appealing to you, go for it!). The most important thing you can do is bring an awareness of standards to your decision-making process. As you talk with vendors, you can help nudge them to be thinking ahead about these proto-standards and how they should be incorporating them in future versions of their products.

Leaders: Think in Trade-Offs and Be Ready to Make Hard Decisions

If you trace back the path of many successful technology decisions, you’ll often find that an agency leader had to make a hard decision, say, forcing two agencies to merge or scrapping an entire fare scheme. These decisions can be necessary in order to make a technology solution (and the ultimate goal of improvements for riders) viable. More often than not, these leaders have had to think about trade-offs. Sometimes that analysis involves comparing significant initial effort versus a long-term payoff.

But making decisions at this scale takes leadership. You have to create a vision and then lead your team and external stakeholders through that change. Above all, you can’t just think, “Oh, we just need to buy this technology, and that’s it. Our problems will be solved. The technology will take care of everything.” Whatever technology we pursue for our agencies is part of a much more complex system, and we need strong leadership to help the people who are also part of that system embrace the changes new technology can require.

Phase 3: Procuring

Procurements can be painful. Here are some practices to help make it easier.

• Assemble a review committee that includes the solution-space owner and other affected staff, to continue the commitment to agency capacity building.
• Explore areas for contracting where the vendor’s revenue model aligns with agency outcomes. For example, can you provide bonuses or other incentives if clearly defined outcomes are met, such as cost savings, improved on-time performance, etc.?
• Look into whether your solution can be procured under the cost threshold for a formal procurement. Due to the pricing structure of SaaS subscriptions, you may be able to stay below the formal procurement bar for new software.
• For elements you’ve engineered, lay out all your work: requirements, designs, phasing.
• For problems for which you’re seeking an already engineered solution, don’t over- prescribe. Instead, focus on communicating as simply as possible your conditions, the problems you’re trying to solve, and the outcomes you expect.

Capacity Building Step #3 Put the solution-space owner and other affected staff in decision-making roles

Phase 4: Implementation and Maintenance

As with procurement, successful implementation of a technology project is a topic worthy of further consideration. You’ll need to develop a plan for getting the solution in place and for maintaining it for the long haul. The specifics will vary widely depending on what you’re implementing. Some considerations apply universally, however.

• For the sake of continuity, the solution- space owner should retain a leadership role during implementation and maintenance.
• If you’ve chosen to go with a solution engineered by a vendor, then commit and see that process through.
• Sustain your capacity-building efforts by clarifying roles and responsibilities. Outline roles for implementation and ongoing maintenance across the organization according to whether someone is responsible, accountable, consulted, or informed (RACI). These roles can be summed up in a RACI matrix.⁷
• To the extent the solution involves disruption of established roles, the engagement of top- level leadership is essential.

Capacity Building Step #4 Leave the solution-space owner in a leadership role during implementation

Organizing Tool RACI Matrix

Your work doesn’t end with implementation, however. In the same way that you pay careful attention to ongoing maintenance needs of your fleet vehicles, you also have to develop a technology maintenance mindset. The workings of technology may feel invisible, but they do still need to be tended. You’ve committed a lot of time and money to getting these systems in place, and you’ll want to keep them in good working order. Again, the details will vary depending on what technologies you’re using. As needed, ask for help in developing a maintenance plan from peers at other agencies, your IT department, your vendors, or outside consultants, as appropriate.

⁷ https://en.wikipedia.org/wiki/Responsibility_assignment_matrix