Best Practices Guide



Best Practices GuideBasic App Selection and Deployment1270007981950November 20, 2020 1000000November 20, 2020 About This DocumentThis Best Practices Guide is designed to support general mobile application selection and deployment by public safety agencies across the State of Minnesota, providing key topics and activities to consider during the process. Within each category you assess, it’s also vital to engage with your user groups and stakeholders to understand their needs upfront. Knowing what factors to consider and what requirements your users and experts have will help you make the best decision for your agency, regardless of your agency’s unique needs. To enhance clarity, this document also features examples of how real-world public safety applications can be evaluated within the context of the assessment categories. It also includes questions to answer with your agency or prospective vendor to give you a well-rounded understanding of your needs and the available solutions.It is important to note that since agencies may choose to purchase only software, software and services, or even software as a service (SaaS), there can be a variety of considerations for the agency in making a purchasing decision. Functional Requirements/FeaturesThe most important factor when considering an application is whether users can achieve the needed objectives with the app. This includes not only the specific features it offers to users and administrators, but also the app’s user-friendliness, accessibility, and ability to integrate with agency protocols.User FunctionalityConsidering all the user groups who would be using the app (Information Technology [MIS] departments, fire, EMS, law enforcement, telecommunicators, managers, front-line personnel, etc.), what functions does the software need to perform for each user group? For example, front line police officers may use a user interface that is customized to their typical operations, while a dispatcher or manager may have a customized interface for their typical activities. Is the application able to accommodate changes in the roles of individuals for approvals or functionality?Consider any accessibility requirements the app needs to meet to ensure your users have equal access to the features. For example, does the app (or its documentation, training videos, etc.) comply with WCAG 2.1AA concerning the need to be compatible with a screen reader, allow magnification, or offer different color settings, such as high contrast or dark mode? Text to speech, speech to text, and Universal Design in general may also have safety benefits for users who are driving or engaging in other activities that limit their ability to interact with the device screen. Has the vendor documented or tested their app accessibility and published a Section 508 Voluntary Product Accessibility Template (VPAT?)?Think through and aggregate all your requirements in order to assess compliance. For example, if you are assessing a Push to Talk app, does it need to provide unit geo-tracking or are you evaluating it solely based on Push to Talk features? Be sure to factor in other functional requirements, as well, such as data sharing (see the REF _Ref50487873 \h \* MERGEFORMAT Interoperability/Integration section for more information) or triggering higher priority for LTE networks. Ease of UseWhether the app provides the features you need is only the first part of whether you’ll be able to use it effectively. The app should be easy to use and have an intuitive interface. Make sure to get a demo and test the app with representatives from your various user groups to ensure they will be able to use it correctly and to its fullest potential. Better yet, try to get a trial from the vendor for long enough to ensure that the product meets your needs and can fit your operations. While learning to use a new app may require some training and practice, you don’t want your users struggling on an ongoing basis with an app that’s inefficiently or illogically designed. It is important for public safety applications to be intuitive, easy to use, not inundate users with notifications, and not be cluttered with unnecessary content or controls. Make sure that the new application functions alongside the other applications installed on your devices. For example, if the application must be active on the device and doesn’t allow the user to interface with other, higher priority, applications, the application may get in the way of day-to-day device operations. Many of the above issues can be addressed if the app has options/settings available to the end user. Ask if local administrators can control which options/settings end users can change.Consider which devices the app will be installed on and any requirements that may be applicable to those form factors. For example, is the app touch enhanced for tablet use? Is a PTT button or an emergency button used? If necessary, test the app on the different devices to ensure all your users will have comparable experiences.If different agencies or users have different needs, it’s also important to determine the extent to which the app is configurable and customizable. Keep in mind that this customization could also require custom development and could potentially inhibit interoperability or add cost.Mobile Data Use and AccessConsidering that the application will be used in a mobile environment, make sure it can accommodate conditions and challenges that are specific to your environment. Especially in areas with poor coverage, wireless connections can be sporadic or very low speed. In high population areas, there could be large demand on the wireless network. Is the app efficient over the network? An inefficient application can run up your wireless bill and even cause your users to have their data speeds throttled. Especially if the application streams video, but also in other cases, make sure that it uses network resources economically. Ask the vendor if they have documentation of testing their app for data usage and efficiency. The Work Group recommends that you trial or pilot the application whenever possible and track wireless data usage as part of the trial. Can it perform well even when connectivity is sporadic, on congested networks, or data speeds are slow? Additionally, keep in mind that users may not always have access to the network. Therefore, it’s important to evaluate the app’s capacity for offline usage (e.g., offline map access) or cached data use. Or if a dispatch center loses connectivity to their cloud CAD, the application can continue to use cache or downloaded data input until connectivity is reestablished, enabling dispatchers to continue to perform critical services.Software Architecture and OS SupportShould the app be a web application or an executable that is installed directly on devices? Web-based apps are generally operating system independent (e.g., they can generally be used on Android, Apple, or Microsoft operating systems equally well), but they may require constant internet connectivity, so this may not be a feasible solution for users who work in environments where wireless coverage or internet service is not dependable. Additionally, web apps may require more bandwidth, which can affect their performance where coverage is weak, or networks are congested. This can translate into lack of responsiveness that may impact your users’ operations. Web apps may lack critical features that are important to your user base, such as push notifications, and may require additional authentication for security. However, web apps may also be easier to deploy and update. Some solutions may also use a hybrid approach, bringing the best attributes of both options. When deciding, be sure to consider efforts associated with installation, updates and maintenance, and scaling. This will be addressed further in the REF _Ref50039346 \h \* MERGEFORMAT Deployment factors section.If you take the executable approach, there may be advantages from integrating with the device and operating system, but you will need to ensure the app works on the type and version of operating systems your agency uses. Document all the devices (remembering shared or spare devices, as well) to make sure all the operating systems (e.g., Android, iOS, Windows, Linux) can be supported. If you take the web app approach, make sure that the app functions properly on your browsers (mobile and desktop).Regulatory Compliance Depending on the purpose of the app and the data that will be contained within and transported across it, your agency may need it to comply with certain regulations. For example, does the app need to comply with Criminal Justice Information Services (CJIS) Security Policy and Health Insurance Portability and Accountability Act (HIPAA) requirements? Are there State or local laws/policies (e.g., ) it needs to comply with? And are there any certifications (e.g., FirstNet certification or others) that you require? Determining how the vendor will document, verify or audit compliance will be an important part of evaluating the suitability of the app.Administrative RequirementsUsers and administrators at your agency will have a variety of administrative needs associated with the app and its associated operational and user access database. With your staff, determine their database requirements. For example, do they need a specific type of database? Consider format, specific fields required for reporting, requirements for querying the database, and other possible needs. Think about what administrative controls are needed to manage and/or restrict access to data from the app and whether you have sufficient configurability through the app or vendor administrative portal to establish the different levels of access you need. Also think about search/query requirements within the database, including what fields must be searchable and what other data must be contained within the search results. If the data is being stored offsite, what precautions are being taken for security (hashing, encryption) and high availability?In addition to data access, you should consider whether you have requirements pertaining to access and control of features within the app. Will administrators be able to manage the agency’s user groups and access to achieve the desired results? Will administrators be able to limit certain functionality or data to specified user groups (e.g., managers, or special operations personnel)? Do the allowable configurations align with how groups are organized within your organization? Do you need the app to log user actions and changes? And by what means will your organization manage this administration, have access to logs, reports and conduct audits?You may have technical requirements to consider, as well. For example, what capacity requirements (e.g., number of users, calls, etc.) does your agency have? And will you need the ability to scale the software to accommodate additional users and usage in the future? Does your agency have specific performance requirements (e.g., PTT setup time < 0.5 seconds, database throughput for queries < 250 milliseconds)? If applicable, the requirements may also need to address whether the vendor provides data servers and other networking equipment for enterprise deployments. Alternatively, could this capability occur in a cloud environment (e.g., AWS, Azure) or the agency’s data center?The software should be able to perform well on your devices, and you should try it with your specific operating systems and other software applications in a pilot or test environment before rolling it out to your end users. Make sure the software doesn’t conflict with other applications you are running on your devices, that it doesn’t drain battery power too quickly, and that it doesn’t demand so many resources that it degrades performance for other applications or uses so much storage that it prevents other uses of the device. Can the vendor work with your agency to stress test the app to simulate how it would perform during disaster or emergency conditions?Finally, there are security related administrative requirements. Administrators may need to remotely disable a rogue device or a device that has been lost or compromised. Can the vendor demonstrate compliance with your security requirements and conduct a drill or exercise? There may also be needs for auditing and logging related to identify access or data security breaches. If the solution does not offer an additional level of security, such as its own username and password, and relies solely on the device’s PIN, administrators may need to employ other solutions on the device to ensure the integrity of the solution. And, if applicable, the application may need to meet evidentiary standards.Interoperability/IntegrationInter-Agency InteroperabilitySome agencies will need to use their app in collaboration with others. Will your system need to share information with the systems of other agencies? If so, determine what information needs to be shared, how the information needs to be shared (bidirectionally or unidirectionally), with whom (for both your agency and your mutual aid partner), and under what conditions (only when authorized, always, on-demand). Is the agency with which you need to interoperate able to accept an interface with your system? It will be important to understand how this would be done and be prepared to coordinate this effort with the other agency. It’s also important to know which vendors support this capability. Find out whether interoperability with another agency will only be possible if you select the same vendor. Or, is interoperability only possible if you share a system? Determine your inter-agency interoperability needs early and make sure that you understand each vendor’s capability to satisfy your interoperability requirements. Make sure that you have a clear design, approach, and responsibility matrix that has the support of your and your neighbor’s vendors and IT departments. Make sure the vendor obligations are clear, and that the solution is tested as part of your process to operationalize the interoperability capability. We’ll discuss the planning and policy related elements in the deployment section below.An important element to inter-agency interoperability may be where each agency’s application is hosted (an element that will be discussed later). It’s possible that a vendor may offer a cloud service or one that’s installed in your agency’s data center. It’s possible that they may only support inter-agency interoperability with the cloud service that’s operating on the same server(s) and lacks the ability for two independent agency installations to be able to share information.Finally, consider whether there is interoperability across wireless carrier networks, as well. There may be some circumstances where a carrier-provided application might not be interoperable with users on another carrier even if they both use the same open standard. This could be an issue with both users at your own agency (e.g., your agency’s account is with a different carrier from many individuals in your agency who will use the application) and users at other agencies that have different carriers. Inter-System InteroperabilityWithin your own agency, does this new capability need to interoperate or integrate with other systems? Identify all systems with which the system must interoperate and how. For example, does it need to interface with your CAD? How? Does it need an Application Program Interface (API) with another app (e.g., trigger a PTT call from within another application)? Does it need to integrate with your credentialing/access management systems (e.g., your Windows login / Active Directory) or perhaps the FirstNet Identity, Credential, and Access Management (ICAM) solution? Does the app need to support data feeds from other systems (e.g., remote automatic weather stations [RAWS], sensors or wearables)? Does it need to utilize other data files or databases (e.g., your custom ESRI maps)? And does it need to support standards-based interfaces (e.g., mail support via Simple Mail Transfer Protocol [SMTP] or with a centralized network management platform via Simple Network Management Protocol [SNMP])? Make sure that you evaluate each vendor’s capabilities to interface with your other systems and ensure that it becomes part of your contract to confirm and test proper operations.Backwards compatibilityWill this new system be replacing an existing system? If so, does the new system need to support backwards compatibility with existing files, databases, etc.? Will all users be upgraded to the new platform, and if not, will users that cannot be upgraded be able to interoperate with new users?Security IT security is complex, and every new application that you deploy can increase that complexity. If you have an IT department, plan on leaning on them heavily regarding the systems, operations, and policies you will need to introduce to keep your new solution and your existing network safe, secure, and operational. You should consult your IT department ahead of any software deployment or change to develop your security requirements and a security plan for each application. If your agency has a Chief Information Security Officer (CISO), consult him or her early in your process to ensure existing security requirements are adhered to, and that your master plan is always addressing security implications. If you do not have an IT department, seek support from a neighboring agency with such expertise and have a detailed discussion with the vendors to understand how their solution will be safe, secure, not impact other systems and comply with appropriate standards and guidelines mentioned in this document. Depending on the configuration of the software, different security elements may need to be addressed. The following sections detail recommendations to ensure that your deployed solution is safe, secure, and provides mission critical and public safety grade performance. The common security elements including Availability, Authenticity, and Confidentiality are detailed below. CJIS and HIPPA have substantial security related requirements, and if those regulations apply to your agency/data, then your system and its operations must meet those stringent requirements. Vendors might claim compliance but be sure to do your homework and make sure they actually comply. The State of Minnesota IT Services (MNIT) has developed enterprise information security policies and standards that are an excellent resource for IT security. There are also other excellent security guidance documents such as those from the International Organization for Standardization (ISO) and the National Institute of Standards and Technology (NIST) providing guidance and standards for cybersecurity. Ideally, you should conduct a security audit of your system and vendor and depending on the type of data you are protecting, ISO and NIST have practices that can be applied to the process.It is important that you seek expert help on security related matters and that your IT support follows disciplined processes and guidelines like those listed above. But every person responsible for deploying a new system should become educated on the different aspects of security and to go through a deliberate planning process. Hackers are constantly changing their approaches to gain entry for personal gain and to disrupt systems. Public safety’s systems and practices must also evolve to constantly thwart the threats. It is also important to understand that susceptibilities to security attacks are often not limited to a single system. A hacker that gains access to a computer inside your network may have access to a number of systems. As a result, a holistic security approach is needed that addresses good security behaviors as well as systems, detection, and operations. A secure system prevents eavesdropping of your data through encryption. It can also be resilient in the face of “brute force” attacks that try to overwhelm your system. If hackers can intercept data, gain access to your system, or overwhelm it, they can temporarily or permanently disable it, causing major problems for your agency’s operations. It’s important that your security plan enable the system to avoid disruptions.A secure system also protects data stored on systems by making sure only those authorized to access the data or system can do so. Many of today’s current attacks get users to unwittingly share usernames and passwords. Ultimately, individuals need to prevent such disclosures, but there are technologies that can help reduce the risk, like multi-factor authentication that less sophisticated hackers are less likely to defeat. Smartphones with only PIN level access may be more vulnerable to the device falling into the wrong hands. Multi-factors methods like biometrics (e.g., your fingerprint) can combat these. Some systems may be configured for “single sign on” or may leverage some other credentials. For example, a vendor may support using your organization’s logins. This can ease the burden of your users from having to manage multiple usernames/logins. And if your agency is already enforcing strong security measures like robust passwords and updated passwords, the new system can then leverage this best practice. The bottom line here is that your system needs to make sure that only people authorized to access the system can access it. It is likely that your system will contain very sensitive information. And to take it a step further, there may be various levels of sensitive information that different tiers of users in your agency can access. It will be important for you to identify sensitive data elements and who needs to access them. As discussed above, the software should be able to differentiate between those user groups and prevent unnecessary access. It’s important for you to understand how your users could accidentally disclose information and how the system, training, and policies can limit that. Also, don’t forget that if some of your users will be using their own personal devices, they will have their own sensitive information on their devices that must be protected. Your solution might try to avoid any local storage of data as a result and should allow users to cease sending information they consider sensitive. Your system needs to keep confidential information confidential, and the system’s functionality and your policies and procedures need to consider that.Deployment FactorsThe features, functionality, interoperability, integration, and security of the vendor’s proposed solution are just some of the factors in your decision making and planning for a successful deployment of a new application. Agencies will likely need to go through a procurement effort to contract with new vendors for the solution. And, the implementation of a new solution requires a plan that addresses all the elements of successful deployment including new policies, training, how the new software will be distributed, staffing implications, and others. ProcurementIn making your decision regarding the right vendor, you should consider the important attributes for your partner. A good place to start is the experience of other agencies and users that you know. What did they like or dislike about the vendor’s product? Would they purchase it again? What are some ways that the solution needs to be improved and does the vendor plan to make those improvements? Reviews on the App Store or Play Store might uncover certain strengths and weaknesses of a particular application. Ultimately, you need to determine if the vendor is a trusted source to deliver a solution that is integral to your operations.Is the length of time the product has been on the market, demonstrated reliability and meeting public safety’s needs a factor? If so, include this among your considerations. More mature products may have been enhanced over time to include additional features you may not have documented in your requirements. Will the selected vendor operate the platform for you, and do they have a history of offering public safety grade service availability? Consider the vendor’s experience with similar deployments. Does the vendor have deployments of similar size and scope under its belt? Does it integrate the agency types you envision? Has the vendor demonstrated interoperability with the systems you intend to interface with?The app you select may be one you use for a long time; in addition to the features available now, you should also consider the future. Does the vendor have a compelling product roadmap? Are certain critical features available in the near future? Policies and AgreementsThe new solution could affect your agency’s policies. Think about the policies at your agencies that exist today and that may be needed in the future that will affect how the app is used. What departmental policies are required to encourage or require usage? For example, will the department require all personnel to utilize a new computerized system for certain business operations? What existing policies affect the application or may need to be modified to facilitate the application? What new policies (e.g., acceptable use, security-related policies to protect confidentiality of data) are required regarding the new system? If the solution will be interoperable with other agencies, a data sharing agreement is likely needed as well as a host of other policies. Your agreement should specify who can share information and with whom the information can be shared. It should address when the information can be shared or accessed. It should establish expectations of confidentiality of the data and data ownership. To go along with this agreement, your agency will need to develop policies that address your obligations in the agreement. Who will have the rights to share your data with other agencies? Who will have the ability to access partner agency data? What are the scenarios when sharing is allowed to occur? What special policies are required regarding securing a partner agency’s information? How will your agency manage sharing over time and how personnel changes will be accommodated? Software DeploymentYour plan will need to get the software in the hands of your users. If your existing hardware does not properly support the new software, you may need to integrate device upgrades as part of your deployment plan. The new application may require custom handset features like a push-to-talk button, or require substantial processing power, or perhaps will only function properly on 4G networks. These factors could trigger device upgrades that must be factored into your decision making and planning. But minimally, your plan must address how to give your users access to the new capability. If the new software is an executable application, how will you distribute the software to your users? Do you have a mobile device management (MDM) in the case of your smartphone or tablet deployment? Do you have a desktop management system for deployment to computers? If so, create a plan for distribution through those systems for ease of management and distribution. Alternately, will you need to budget for labor for installations? Or will you ask the user community to self-install (which may require you to provide some support)? Do you need support from the vendor to perform this task?Consider these same elements for future updates, as well. What approach is required to facilitate application upgrades and enhancements? Server Deployment If you are purchasing an enterprise software license, you’ll need to plan how you will host the application. Will you put the new servers in the cloud and outsource most of the operations? If so, you’ll need to design the architecture, purchase the services, and configure the solution. If you will use your own data center, there are many more tasks that your IT department will need to execute. You’ll need to ready your infrastructure to support the new application in your data center, including acquisition, installation, and configuration of servers (rack space, battery backup, HVAC upgrades), IP addresses and routing, web certificates, and network traffic impact and upgrade network capacity as needed. You’ll also need to consider your security design in your server deployment. For example, how does your agency’s firewall need to be reconfigured to accommodate the new capability? You’ll need to budget for and allocate IT resources for design, implementation, and cutover of new servers and potentially a new operating environment in the event your existing space or assets cannot support the new capability.StaffingRegardless of how your agency will host and service the new capability, there is likely to be some impact regarding staffing. While it is possible that the software might introduce efficiencies in your operations, some elements of your organization will be impacted by the deployment. It is important that your deployment plan address the resources that are needed to successfully implement the new solution. Deploying a new app can affect staff at your agency beyond just the end users. You may also need support from:Staff to support deployment of software to client devicesStaff for architectural design, data center upgradesStaff for procurementStaff to project manage the implementation process, including:Program Design/Planning/BudgetingProcurement (requirements, RFP, negotiations, contract execution)System DesignSystem implementationCutoverTraining (for implementation and future changes to server software)Transition to operationsStaff to support ongoing operations, help desk, software upgrades/updatesStaffing impacts for end-users (e.g., overtime or additional shifts to address training time)All of these affect the potential ease, time commitment and cost associated with your decision. These impacts need to be part of your deployment plan to ensure that the right resources are available to support a successful launch of the capability.Operational FactorsA successful software solution will include planning for and executing effective operational activities. The new capability needs to be properly supported, augmented, and maintained in order to continue to derive the benefits that were originally intended. Some of these operational factors impact how the solution is installed and architected, while others impact ongoing internal operations. Before you move forward with your new software deployment, make sure you consider how the solution needs to be operated to meet your agency’s mission. Redundancy and Reliability It’s important your users can rely on an app when they need to use it. So, during the assessment process, consider how the vendor guarantees its availability. For example, is their architecture set up to be redundant and automatically failover? If the vendor will be responsible for operation of the service, will they offer service level agreements (like offering 99.99% uptime, quick response time, etc.)? And in the event of a major failure, does the solution address backup and disaster recovery to ensure your data is not lost? Does the vendor have a continuity of operations plan?Architectural ModelWould your agency prefer to completely outsource the software (software as a service, or SaaS) or will it be loaded on agency-controlled servers (cloud or in agency data centers)? In the case of SaaS, you may increase ease of access, use and upgrading, but in exchange, you may sacrifice customizability. Enterprise software is purchased and installed on your own servers. This tends to come with increased customizability, interoperability (i.e., interface to your credentialing systems) and ease of reporting but may be more expensive and labor-intensive to implement. Note as well that interoperability can be affected by the model you choose. For example, a cloud-based app may not be able to be interfaced with an enterprise (locally installed) app. Interoperability with other agencies may then impact your architectural model. For example, if the State managed a hosted site and your agency chose a cloud service, will the solution enable interoperability with the State? Regardless of your preferred model, consider the lifecycle support the vendor will provide. Will they guarantee support for a certain number of years? And during that timeframe, do they offer 24/7/365 support to mission critical agencies? Vendor ServicesDepending on the size of your agency and the expertise and availability of your staff, there are some services you may provide in-house and some may want the vendor to provide for you. If applicable, identify what services you need from the vendor. Will you need the vendor to migrate your existing databases to the new platform? Consider, too, what will happen if you stop using the application in the future. In that case, how and in what form can you take your data with you? Do you need the vendor to install software on servers or provide support? Do you need the vendor to provide support in cutting over from an existing application to the new application? And will any of your user groups (consider law enforcement, fire, IT, administrators, etc.) need training to operate the new platform?In general, cloud hosted systems are updated and patched automatically with the vendor’s overall service platform. For software operating in your own data center, you will also need assurances from the vendor that it will be maintained and patched to continue working when your system gets updates and patches. While your initial contract may cover some of the initial setup, consider securing periodic updates and upgrades to stay on current supported versions and securing new capabilities. Get an understanding of the cost and frequency of updates and how they can be deployed. Does the vendor support skipping versions for agencies that prefer to upgrade/update less frequently?Also determine the extent of customer and technical support your agency needs. For example, do you need 24/7/365 technical support? Do you require 24/7/365 higher-tiered support to handle outages? Alternately, depending on the type of service, perhaps support only during business hours is sufficient.Support FactorsAn important element to your operational model is how you will support the product within your organization. Will end-users be able to self-support with limited assistance and involvement from administrators? Will system administrators need to be the conduit with vendor? Depending on the complexity of the solution, this could create substantial impacts on internal resources needed to support the new software or capability. When possible, you might query other agencies who have deployed the solution to understand their operating model and its impacts on personnel. If the service will be added to your help desk, be sure to include training and processes for your help desk to properly support the new capability with incidents (including security incidents), service requests, and change requests. Training is another important element in your operational model. How will your agency ensure that your personnel are appropriately trained? Will the vendor be responsible for training? Will there be annual training when new releases are implemented? How will your agency address training of new hires? Regardless of how the service is operated, your agency will need to monitor the service, manage the vendor(s), and ensure that the software provides continuity, availability, and is meeting the intended purpose. Your IT department (or the department responsible for the software) will also need to manage changes and configuration of the system. Good change management goes through a rigorous process to make sure that changes to the system are well thought out and will not harm operations. It will reduce the number of unauthorized changes to your system and will help you understand what changes can be made with limited negative impacts. Change management processes generally identify fallback procedures when changes become detrimental to operations. Good change management also provides more transparent and helpful communication with your end users during the transition process. And finally, robust change management will also include detailed documentation of the changes to your systems and will allow future IT professionals to understand the current state. Your operational support model will also need to consider ongoing testing of new features and software updates. Deploying new features and updates is a part of change management. You should ensure that any change to your system be evaluated for its impacts, and, where possible, be tested in your current environment. For example, is there a key change to the system that could impact interoperability with other systems? If you have to upgrade the operating system to be able to support key security patches, has your application been tested on that new operating system? Or, in the case of inter-agency interoperability, can a change impact interoperability with neighbors? If so, these elements of your changes should be tested in advance to identify any issues before operational cutover of the new update or upgrade.How you choose to run operations could have other implications. For example, do you need to track your own trouble tickets and track them until resolution? Perhaps your operations personnel also need to track system uptime and availability to ensure that the system is meeting your performance metrics. Your operations planning should also address upgrade approach (annual, as needed), network and server management, and others if you choose to deploy an enterprise platform. And, before you engage a particular vendor, make sure that you understand their upgrade policies. Will upgrades be mandatory? How often will their upgrades occur? Do you have the resources to test, plan, and train on each new upgrade? How long will they support a particular version? How does that fit into your operational model and plans for upgrades? Financial factorsA variety of financial factors come into play when purchasing new software. Your financial planning for your new application should include both one-time and ongoing costs. One-time costs would most likely be those incurred during the initial deployment, while recurring costs are those you would be on a monthly or annual basis. You could also incur one-time costs after your initial deployment – for example, you may need to upgrade your servers every five years to support the new capability. In addition to software licensing costs, consider the ongoing operational costs associated with software, hardware, support, upgrades, and staffing. There may be fixed fees, or pricing affected by the number of users and/or the amount of use (e.g., amount of data). There may also be deployment costs for training, labor, and hardware. Include internal one-time costs of staffing, lost productivity, and other initial costs to transition to new capability, along with the ongoing operational costs for internal staff, ongoing training, etc. All the services you need to acquire from the vendor, and the additional internal costs associated with supporting the new application should become part of your budget. Consider other ancillary costs, such as system peripherals that may need to be swapped out (e.g., will your agency need new holsters for everyone’s new devices?) or the soft costs that affect other support staff or processes. Throughout this document we have highlighted several potential additional cost-related events that could impact the net one-time and ongoing costs for your project. For example, if you need to replace some or all of your end-user devices, that should be factored into your financial plan. Or, if the operating system software for your client and server devices must be upgraded, those need to be added to the budget.As you assess the financial impact, think about what operational benefits and cost savings can be achieved that might offset the one-time and recurring costs. Can this new app make staff more productive and achieve realizable cost savings? What plans can you put in place to shed one-time or operational costs via the new solution? These cost-savings may help justify the new expenditure. On the flip side, if you received a grant to cover the initial cost for deploying the software, don’t fall into the trap of not projecting the costs associated with maintaining the solution and securing the appropriate budget to keep the system operational and scheduled for typical life cycle replacement.Finally, don’t forget about the associated network usage related costs. Does this new application require more wireless users that will increase your costs? In other words, in order to truly benefit from this application, do you need front-line employees to have access to wireless broadband communications who are currently not provided devices and subscriptions? Or, do you have metered wireless service (pay per gigabyte, for example) and will the new application incur substantially more data use? It’s also possible that downstream networking impacts could occur. For example, if you are adding a real-time streaming video service to your operations, the data use could trigger needing a larger internet connection to your data center. If 20 different users access a high definition video surveillance stream and each of those streams consumes two megabits per second, that alone will generate 40 megabits per second and may leave insufficient bandwidth for your other applications.A Special Thank you to the Section Leads:Peter AngelosJosh JacobsonBrandon LarsonJake ThompsonMelissa Reeder ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download