NPD PMRs

True/False The PSC department uses Hits and the TAC uses individual PMRs per customer.

False

Modification PMRs (Priority 5 and 8)

Pending Modification PMRs over 5 years old

Problem PMRs (Priority 3 and 4)

Pending PMRs attached to a PMG and over 12 months old OR not attached to a PMG and over 24 months old

Priority Modifications

Scheduled in the PPD-NPD-DEV modification meetings. NPD then uses the CPM "Project Planning" priority modules to track the status.

Send to Reviewer

Use this action to send to another associate for review. This can be done to notify PPD of the idea and get their opinion or comments. This could be done in scenarios where another area is affected, so that the PM can provide any advice about how you should implement it.

A Product Manager should process a Work Order PMR by: Verifying the PMR clearly lists the record needing to be fixed Confirming the dealership cannot fix the record themselves Duplicating the issue A and B All of the above

A and B

Writing PMRs

All NPD Associates (from VP to Trainee) write PMRs. This course will cover some best practices for writing PMRs.

Which PMR types does NPD keep organized? Priority Modifications Punch Lists High Priority PMRs Escalated PMRs B and C All of the above

All of the above

Which of the following is an element of good Problem PMR description? Issue occurring Expected behavior Steps to replicate Necessary conditions All of the above

All of the above

All PMRs default to "Unviewed" status and one of these actions must be taken:

Keep Cancel Cancel Immediately Other Actions (Product Managers only)

Who is responsible for redacting PII information in PMR Documentation?

PMR Submitter

Work Order PMRs

Refers to a situation where a specific record in the system needs to be fixed. This is different than a typical PMR where there's an issue with the underlying code that needs to be fixed.

Cancelled PMRs

Retained for 180 days, then purged by a nightly process.

WO PMRs are typically easy to process. The PM is simply validating:

There's enough information for DEV to find the record that needs to be fixed There's no way the dealership can fix the record themselves

Check PMR queue 4 times a day

When you arrive to work Before you go to lunch After you return from lunch An hour before you leave work

NPD responsibilities

Writing PMRs Reviewing PMRs

Individual PMRs

Writing a PMR for each customer that experiences the issue is typically the best way to diagnose a problem. The additional information provided by each customer can help NPD and DEV research the issue. However, the drawback is that it is time consuming, for both the submitter and for NPD/DEV to track the groupings. PSC writes individual PMRs.

TAC uses

Hit function

When you route a modification PMR out of your queue, you have some options about where to send it:

Hold Send to Reviewer Send to DEV

Handling Sensitive Personally Identifiable Information (PII)

If you receive an email with sensitive PII information, you should permanently delete the email from your Outlook (ie: delete it from your deleted folder). If you need the email, send a redacted version to yourself. If you are gathering screenshots for your own PMR, copy the screen images into a program like Paint and use Shapes/solid fill outline to cover the data. It's important to not redact with shapes directly in the Word document, as the boxes can easily be removed by anyone viewing the document.

DEV Schedules

In this method, NPD reviews the problem PMR, sends it to DEV, and DEV schedules the PMR. Smaller modifications are typically collected on a "High Value/Low Effort" CPM. The DEV Manager can choose modifications from that CPM as time and resources permit.

PSC uses

Individual PMRs

Completed PMRs

Retained for 730 days, then purged by a nightly process.

Which of these priorities is NOT a Modification?

4

Returning the PMR is important because:

It establishes correct ownership of the issue. If the PMR is sitting in your inbox, you are responsible for it. You are forced to enter a note when you return it. This makes it clear to anyone reading the PMR what additional information is needed. If you just send an email to the submitter, no one else knows or can assist if the submitter is out of the office. The submitter's supervisor is notified. The supervisor can make sure the information is supplied in a timely fashion. Also, the supervisor is made aware that the PMR documentation was deficient in some way, which is important if there is an ongoing pattern to be addressed.

Problems/Smaller Modifications

NPD Rankings DEV Schedules High Priority PMRs Punch Lists Formally Escalated PMRs

Information that should be included when writing a Problem PMR

- What the issue is and how the software should be behaving. The issue should be clearly stated in a few sentences at the beginning of the PMR. The Expected behavior should be listed after the issue. For web-based products: -The URL where you encountered the issue -The browser being used -The version number(s) of the product where the issue is occurring -The logged-in UserID or Username you are using -The environment(s) in which the issue is occurring -The system/store/branch where the issue is occurring -A copy of the error message received, if any -A step-by-step process for replicating the error, including all relevant details and the expected vs. actual results -If an RIH transaction is referenced, the URL to the RIH Transaction should be included. -If the issue only occurs under certain conditions or on certain records, list those out -Examples of where the issue is NOT occurring, if applicable -Documentation

Handling Problem PMRs

-Verify the PMR should indeed have been sent to you. This answer will often be obvious either way, but categorization mistakes do happen. -Apply your product knowledge. Is this issue actually a problem in the code, or does the PMR submitter not know the designed reflexes? -Return PMRs not properly documented. -If the issue is legitimate, try to duplicate it on a test system. The PMR should have all the required information for you to do this. -Add a note on the "Notes" tab. Your note should include: --The branch where you tested. (The nomenclature changes based on the application. Use whatever DEV needs to be able to find the record) --The record you used to test --The outcome you saw --The outcome you expected --What DEV should do to resolve (unless it is obvious) -Once you've vetted the issue and added your input, route the PMR to DEV by clicking the "Send to DEV" option in the PMR actions.

Work Order PMRs can sometimes be caused by an issue with the code. Let's say that DEV made a change that caused records to be added with an incorrect key. In this case, there would actually be two PMRs.

A WO PMR with a list of existing records that need to be fixed A standard PMR that explains the problem, cross-referenced to the first PMR number This PMR would typically be escalated. An issue that is causing corrupted records needs to be fixed immediately.

Modification PMR

A modification PMR (priority 5 and 8) is added when a dealership user or a Reynolds associate has an idea on how to improve the software. A modification PMR should include details on how this enhancement will benefit the customer, improve efficiency, improve profitability, provide competitive advantage, etc.

Problem PMR

A problem PMR (priority 1-4) is added when the software is not behaving as designed. A problem PMR includes detailed information on the issue, steps to duplicate, and the expected reflex.

Punch lists

A spreadsheet of PMRs in priority order. NPD creates punch lists when trying to get a product ready for pilot, when piloting, when a significant customer installs a product, etc.

True/False NPD should never change the original priority of a PMR. If you want to let Development know an adjusted priority, add a note instead.

False

True/False PII information cannot ever be included in documentation of a PMR, even if it is needed to research the issue.

False

True/False The PMR Review Process occurs twice a year.

False

True/False Work Order PMRs are handled the same as other PMRs.

False

Regardless if DEV schedules or NPD ranks the PMRs, NPD typically keeps track of these types of PMRs as well

High Priority PMRs Punch Lists Formally Escalated PMRs

Returning PMRs

If a PMR lacks information that you need in order to process it, the only correct way of dealing with it is to Return to Submitter. We must be diligent about returning PMRs.

NPD Rankings

In this method, NPD maintains a manual spreadsheet of PMRs with a simple top 20 list in priority order. The spreadsheet consists of both Problem and smaller Modifications. This should be available to your supervisor at any point to review, so it is usually stored on the LAN. Update the list as new PMRs come in and others are completed, then provide the spreadsheet to your DEV supervisor periodically. This provides DEV a prioritized list to use for quick filler projects.

When reviewing a modification, consider the following:

Is this actually a problem PMR, disguised as a mod? Just like submitters sometimes misunderstand the designed reflexes and submit problem PMRs, sometimes they encounter a problem but don't recognize it as such, especially if there isn't an obvious error message being thrown. Is this PMR supposed to be yours? Is there a legitimate pain being felt by the customer that this mod would alleviate? Have there been many requests for this kind of modification? Should the modification be implemented exactly as it is written? If not, add notes to clarify how you want the modification to be coded. Does this affect any other Product Managers' areas?

Handling Modification PMRs

Modification PMRs need to be processed a bit differently, and there isn't a one-size-fits-all approach.

Annual PMR Review process

NPD uses the PMR Review page in the PMR menu of CSS to review the identified PMRs and take the necessary action. Product Managers should use this time to assess the older PMRs to determine if they are still valid or what action should be taken with each.

Formally escalated PMRs

PMRs that are actively causing a major disruption for a customer. The "Escalate" action is used to flag these PMRs as highest priority and easily monitor them. There is another LMS course exclusively on the PMR Escalation function and process that will go into further detail.

PMRs are categorized under

Platform, Product, and SubProduct. Categorizing a PMR correctly makes sure that it is routed to the correct Product Manager first, who will be most knowledgeable, and then will be handled by the appropriate Development team.

PMR types

Problem Modification Both types of PMRs are added and reviewed in the CSS > PMR application. We have an Inbox section that allows quick and easy access to view, change, and route PMRs.

Miscategorizing PMR

Results in confusion and wasted time, as the PMR will be sent to a Product Manager who does not own the product area where the issue is actually occurring. They end up needing to evaluate the issue, seek clarification, recategorize, and route to the correct PM.

Hits

Support Rep links the PMR to the CMS Call Ticket for that customer, so the organization knows which customers are experiencing the problem. That function logs a Hit on the PMR record and automatically adds a Note to the PMR to cross-reference to the CMS Ticket. Even if the Support team typically logs a Hit, the System and Print PMRs should always have an individual PMR written. System and Print issues can be unique based on the customer's specific environment. Typically NPD and DEV need to research diagnostic logs for that customer to determine the issue and resolution. TAC uses the Hit function.

Other actions (product managers only)

The "Add new CPM Project" and "Add to Existing CPM Project" actions are available to some users (based on your assigned roles). When used, these buttons remove the PMR from the list and automatically link the PMR to the CPM project.

PMR Descriptions

The PMR description is the body of the PMR where you must clearly explain the problem that is occurring or the modification you would like to see implemented.

Cancel

This action cancels the PMR at the end of the PMR Review Cycle. All PMRs cancelled at the end of the PMR Review Cycle will have a generic cancellation note.

Cancel immediately

This action cancels the PMR immediately (don't wait for the batch cancel at the end of the PMR Review cycle). This action requires a "Cancel Note" to be entered. If you plan to cancel the PMR, this is the preferred method because you are providing a specific reason the PMR is being cancelled.

Keep

This action prevents the PMR from cancelling at the end of the PMR Review cycle. PMRs marked as kept will appear on the next PMR Review cycle (assuming it isn't cancelled, completed or linked to project).

High priority PMRs

This is a PMR that is not formally escalated, but needs to be resolved quickly. Send the Development Manager an email. You can manually track this or add yourself as a Notify on the PMR and use a PMR Module to track the progress.

Hold

This keeps you as the PMR owner, but moves it out of your queue and signals that you have reviewed it. Good practice is to attach your held PMRs to a "PMR File" type CPM, so that you can revisit them easily later. This is a common way to process mod PMRs, particularly those that have not been requested before, or which provide a small benefit and would be better combined with other modifications.

True/False Clear, specific notes on your attempts to duplicate a problem are vital for helping Development diagnose an issue.

True

True/False Correctly categorizing a PMR is important because it ensures the PMR gets into the right person's queue as quickly as possible.

True

True/False Medium to low priority problems and modifications are organized with a different system than high-priority items.

True

True/False One of NPD's main jobs is to organize, prioritize and route PMRs efficiently in order to make sure all our products are functioning at peak proficiency.

True

True/False The "Hit Count" on a PMR is one way to determine the impact of a PMR.

True

True/False The PMR Review Process assists with identifying and reviewing PMRs to be canceled.

True

True/False The less time NPD or Development has to spend deciphering how to replicate an issue, the more time they have to diagnose and solve it.

True

Send to DEV

Use this once the PMR is ready to be worked on. Make sure the PMR clearly states exactly how you want the modification to be implemented, either in the description, in the notes, or in an attached document (mini-design). If you write clarifying notes, you can call attention to that fact in the PMR body, such as adding at the top "PM note to Dev - See Notes tab for exact instructions." Include a "Need By" date, if applicable.

Reviewing PMRs

When NPD reviews PMRs, our job is to evaluate, prioritize, and route PMRs in a timely manner in order to make sure all our products are functioning at peak proficiency, and we are enhancing them to meet our customers' demands. As we have thousands of customers, and they sometimes have different opinions on how our products should work, this is no easy task.