Proven Solutions. Complete. for DMV Modernization. Modernization Guide. Establish the Vision. Set the Scope

Transcription

1 Complete Proven Solutions for DMV Modernization Modernization Guide This document contains a list of activities that jurisdictions should consider when modernizing their Enterprise Motor Vehicle system. Regardless of the approach (custom, proven, COTS or best of breed) these activities, if initiated prior to the modernization effort, reduce the risk to the project. In addition to reducing risk, additional benefits include improving the quality of the new system and the data, and enhancing the overall experience for users and customers. Establish the Vision It is critical for all DMV decision makers to have a shared understanding of what you want your DMV world to look like post-modernization. You can start by listing the major pain points that the new system should resolve, and then move to a description of the new DMV. The vision needs to be documented and articulated so that it not only influences the vendors, but also the staff. Keep it simple, one to two pages should suffice, and remember that a picture paints a thousand words. You may already have this material if you have had to seek appropriations for the modernization and justify the funding. The business case you developed for the modernization and funding should be the vision; you don t need to recreate it. Set the Scope Defining the scope of your modernization project sets the highest level expectations. Working from the vision you established, determine the components: Is the modernization effort only the DMV software, or does it include peripheral areas, such as data warehouse, reporting, imaging, replacing old third party software such as address validation, etc.? If your scope is all inclusive, is it better to run these efforts as one program or separately because they will be dealt with separately? Will you purchase your own hardware, or request that the vendor includes it in the bid? A decomposition diagram can prove helpful to document the scope of your modernization efforts. The scope can also be defined in terms of stakeholder boundaries or business operations framework: Develop a flow of how the counties and the state will do their work post-modernization. Determine what systems are being replaced in the modernization effort. The key is to set a future state boundary, and then handle exceptions as they arise. A Visio diagram of this flow can help clearly identify the scope.

2 Data is by far the most critical activity a jurisdiction can undertake to prepare for modernization. The old adage, garbage ingarbage out, is never more apparent than during a modernization effort. Identify the Stakeholders Identifying the stakeholders starts as an inventory of all individuals, groups and roles that use, consume, or provide data to the DMV system. The inventory should include the following types of data: company name, group name, role, their interest in the system or the data in the system, and the mechanism i.e. extract, input, report, direct access to, request data from, system to system interface, frequency of interaction, and contact information. This feeds into a RACI chart that will be essential to your Organizational Change Management plan. Identify your Early Adopters, Thought Leaders, and Change Agents Identifying key personnel is fundamental to the success of the modernization project. Once these individuals are identified, you know your core project team, and can delegate proper authority to these individuals. They also become the change agents for the modernization efforts. In addition to naming them to the project, consider reducing their everyday operational tasks to allow them the ability to focus on the project. Some experts recommend removing them from their regular jobs; however, that pulls them from the mainstream and can negatively impact how they are perceived by the rest of the staff. Data Data is by far the most critical activity a jurisdiction can undertake to prepare for modernization. The old adage, garbage in-garbage out, is never more apparent than during a modernization effort. The degree and depth each jurisdiction can take to prepare their data depends primarily on technical and user resource availability. Some activities to consider are: Data purge if a data purge program exists in the legacy system, consider running it periodically before the first conversion test, as well as part of the project go-live activities. Data history define what data must be converted and why. This is primarily for getting all of the stakeholders on the same page. DMV management, users, partners and IT staff should layout the data plan and communicate it regularly. Have the plan in place before the modernization begins; do not make it part of the project and no not assume you have to convert all historical data. De-duplication If a duplicate check program already exists in the legacy system, run it often. If no program exists, then consider manual efforts to prepare for the modernization. With assistance from IT, run queries and reports. These can be simple throwaway reports that identify possible duplicates. Using the report, form a SWAT team to manually clean up duplicate records. This can happen either by manually combining the duplicate records into one and deleting the others, or by linking duplicate records together. For example, if there are six Jane Smith records in the database, and it is determined that three of the six are the same person, enter the same DLN and DOB in all three records and store it in an agreed upon field in each of the three legacy systems. During the modernization conversion process, that field can be used to combine the three records into one record. Continually run the reports and monitor if additional duplicate records are being generated. Correct user actions when they occur. For example, if a seventh Jane Smith is added to the system and displays on the possible duplicate report, address the issue with the clerk. The idea is to correct the behavior, and not add customers when one already exists.

3 Data Cleansing this is most critical for corporate or organization records. How many spellings exist for All State Insurance? How many unique records exist for them? Once the official name and spelling, etc. have been agreed upon, start a cheat sheet. For every piece of data the jurisdiction agrees to cleanse, make an entry in the cheat sheet. Incentivize clerks to apply the officially agreed upon form using the cheat sheet. This activity can be done programmatically if the resources are available. Whether this is a manual or automated activity, the more data that is cleansed prior to modernization the better, to reduce the risk associated with a long running conversion process for go-live. Additionally, establish how to handle data such as street names. Should Street be abbreviated or spelled out? Add these kinds of rules to the cheat sheet and give the users time to clean the data while they are performing transactions. This may impact user performance (time to complete a transaction), but in the end, the quality of the data will be enhanced. Remember, any cleansing you do now positively affects the time it takes to run conversion for go live. To know what you need, you need to first identify what you have. Requirements Development Use a starting point, not a blank piece of paper, leverage boiler plate generic requirements, another state s requirements, or requirements from your last effort. Do not start from a blank piece of paper as it is too daunting. By starting with a generic set of requirements, you give your subject matter experts something to challenge. A cautionary word about requirements work; make sure they address the why and not the how, especially if you plan to pursue a modifiable or proven solution approach to your modernization efforts. There is a growing interest among DMVs to use boiler plate requirements and then plan for an additional 30% to 40% effort and functionality. Using a boiler plate, you evaluate a vendor s solution against boiler plate requirements, and then indicate the percentage of additional work. This puts the onus on the vendors to propose a solution that not only meets the boiler plate requirements, but also proposes enough in the budget to address your unique needs that are not covered in the boiler plate requirements. This eliminates an elaborate requirements development process. This is especially useful if you agree that state to state you do a great deal alike, and that the boiler plate requirement represent that similarity. Reports and Correspondence It has taken many decades to build up the inventory of reports and correspondence that is either automatically or manually generated from the legacy system. It is unrealistic to expect that any modernization effort will include replacing all of those reports and letters. To know what you need, you need to first identify what you have. Create an inventory of all reports, when they are produced, who consumes them or who originally requested them, how they are handled and why they exist. Eliminate the nonessential reports from the inventory list. This is done by determining who uses the report and what they use it for. If you determine that no one has done anything with a report in the last six months to a year, eliminate it from the inventory.

4 Prioritize the remaining reports on the list. Determine which ones have to be available the first day, week, month, quarter and year of go-live. This sets your priority in that any report that must be available the first day, week or month of go-live should be included in the scope of the project. The remaining reports can be post go live, and be outside of the project. Sometimes these are better handled through a report writer product, such as Crystal Reports. Once you have the priority list of reports, determine the commonality. Examine each report to make sure it is unique and not just a variance of a theme. For example, a report of vehicle ownership history that is in customer and then vehicle order is not really different from vehicle ownership history report that is in vehicle and then customer order. The idea is to reduce the scope of the modernization project to the most valuable reports. This lets the project team concentrate on more important items. Repeat the same activity for correspondence/letters. This may be more problematic to build the inventory, as the jurisdiction may find that individuals have customer letters they have developed using MS Word. Once these are all inventoried, follow the same steps as you did for reports. In addition, determine which correspondence should be included in the scope of the project, and which should remain MS Word documents. The uniqueness of the letter or how rarely it applies (is it an exception to the exception?) should help determine if it should be included. Interfaces Interfaces are similar to reports and correspondence. It is important to develop an inventory of interfaces and collect key characteristics on each interface, such as the nature of the interface (batch or real time), the third party involved and the technical constraints of the third party, the timing of the interface and the contact information. It is not necessary to define every data element in the interface at this time. However, if it is available, it will come in handy later in the project. Once you have the interface inventory, the jurisdiction should reach out to third party partners to open the lines of communication. The jurisdiction should share their modernization plans, and determine if there are activities on the third parties agenda that may conflict with or interrupt the modernization efforts. For example, are they undergoing modernization efforts, changing projects, challenged with resource issues? This preparation activity is about opening the lines of communication. It is important to develop an inventory of interfaces and collect key characteristics on each interface. Preparing for Common Customer Many jurisdictions modernization efforts include moving to a common customer model, particularly when Title & Registration (T&R) and Driver License (DL) issuance are within the same agency. In this case, all of the above data activities help prepare them for a common customer model. Consider the following: Manual synchronization now- this requires the clerks to enter a unique identifier from one system into the other. For example, it is very typical for the T&R system and the DL system to be separate and to have their own customer data. For each T&R transaction performed in the legacy system, the user/clerk is required to record the DL number in an agreed upon field in the T&R legacy system. That DL number is then converted at go live, populated in the common customer record, and used again when the DL conversion takes place. It becomes the primary matching criteria at conversion time. Whether you are synchronizing between a Title and Registration system and a Driver License system or synchronizing between county Title and Registration systems and main Title and Registration systems, the activity and the benefit is the same.

5 Define matching criteria this requires subject matter experts from IT, Title & Registration and Driver Licensing. Together, they define the data that is used to match customer data records. Regardless of the go-live approach, big bang or phased, some combining of records occurs during conversion to go-live. Everyone has to agree to the logic or rules around when records match. Typical data to consider is: ST/DLN and Date of Birth, first five characters of the last name, first three characters of the first name, and Date of Birth and SSN and Date of Birth. Organizational Change Management (OCM) Organizational Change Management is the single most important activity for successful modernization projects. This topic relates to the focus, attention and value an agency puts on OCM. In preparing for a modernization project, the best action you can take is to plan for it. Select an OCM expert in house, or require your vendors to include an OCM plan with their bid. OCM includes: Training Prepare the technical team and the users for modern technology. Start with an assessment of where they currently are. Do the users need Windows training? Are they comfortable with the internet, using a mouse, and multi-tasking? Does the IT staff have any modern technology experience? Once you know the starting point, you can devise a training plan and specify the training approach. Do you train everyone or do you train instructors who then train everyone? Determine if you will provide classroom training and/or selfpaced training. Are you set-up to provide classroom training? If not, decide to outsource all training activities to your modernization vendor or a third party vendor. End User Readiness Assessments Document how you will measure when the end user is ready for the new system. Will they have to demonstrate proficiency, or spend a certain number of hours in the new system in a sandbox environment? Define a plan to address any deficiencies. Help functions Define the help aids you expect as part of the modernization effort. Will online help be enough, or will FAQs, videos, manuals, etc. be required based on your staff knowledge and comfort level? Communications Use the RACI chart developed above, when you identified the stakeholders. Develop a plan and approach for internal and external communications. Identify what should be communicated to whom, and on what frequency. Should communication be triggered by a specific event? How should it be disseminated i.e. newsletter, presentation, teleconference, distribution, etc.? This is your path to keeping all of your stakeholders informed and involved as appropriate.

6 Infrastructure Document your specific constraints. The extent of this will largely be influenced by whether you plan to host the solution yourself, or if you are going to rely on a vendor to host, support and operate the modernized solution. Once the constraints are documented, this is shared with the solution provider/vendors and you will seek their ability to conform to your constraints. For example, if you have a state-wide standard of.net platforms at a specific release level, this should be documented, shared and included in your requirements. Set Project Expectations Define the expectations around the project. Create a laundry list of topics and document the expectations. Consider the following: Project Management how many years of experience should they have, what certifications are required, is industry knowledge required? Resources/Staffing what percent should they be on-site, what percent of their time should be committed to the project? Implementation approach will you rely on vendor expertise and experience, or will you dictate the approach? Tools and methods will you rely on vendor standards, or dictate a different standard? Whether you are preparing for an RFP or the actual project, these activities are fundamental to your successful modernization. 3M assumes no responsibility for any injury, loss or damage arising out of the use of a product that is not of our manufacture. Where reference is made in literature to a commercially available product, made by another manufacturer, it shall be the user s responsibility to ascertain the precautionary measures for its use outlined by the manufacturer. Important Notice All statements, technical information and recommendations contained herein are based on tests we believe to be reliable, but the accuracy or completeness thereof is not guaranteed, and the following is made in lieu of all warranties, or conditions express or implied. Seller s and manufacturer s only obligation shall be to replace such quantity of the product proved to be defective. Neither seller nor manufacturer shall be liable for any injury, loss or damage, direct, special or consequential, arising out of the use of or the inability to use the product. Before using, user shall determine the suitability of the product for his/her intended use, and user assumes all risk and liability whatsoever in connection therewith. Statements or recommendations not contained herein shall have no force or effect unless in an agreement signed by officers of seller and manufacturer. 3M is a trademark of 3M. Used under license in Canada. 3 Traffic Safety & Security Division 3M Canada Company 3M México, S.A. de C.V. 3M Center, Building 235-3A-09 P.O. Box 5757 Av. Santa Fe No. 55 P.O. Box London, Ontario N6A 4T1 Col. Santa Fe, Del. Alvaro Obregón Please recycle. St. Paul, MN MHELPS México, D.F M All rights reserved.