EH Process to submit Change Requests

Developing the Request

When submitting a Change Request ticket, please keep the following in mind:

1. Clearly identify the pain point or business goal that requires correction.

   1. Consider the potential benefits of incorporating the following items into your workflow:

      1. Adding a Modifier

      2. Creating an activity from on an existing activity.

      3. Receiving notifications regarding changes within the system

      4. Completing a task or checklist prior to transitioning an activity

      5. Turning on PDF Reviewer

   2. How frequently does this step lead to delays or errors?

   3. Are there aspects of this step or process that are unclear or require further explanation?

   4. What impact could this change have on overall efficiency or team workload?

   5. Is there a disconnect between communication with external users and internal users?

   6. Is this issue causing additional problems later in the process?

2. Discuss with the key Program Area staff how the change(s) could affect their work.

   1. Has the request been discussed with the affected Program Area staff?

   2. Does this change affect other areas of the workflow or the existing business process?

   3. Do people understand this change and how it will affect their processes?

   4. What’s the best way to introduce this change without disrupting other parts of the workflow?

   5. How can we make sure everyone is aligned on the updated process?

Submitting the Request

1. Once agreed upon by program staff including engineers, if applicable, Cat or designated program area staff will submit the change request.

2. Make sure the request contains the following information:

   1. Name of the responsible party

   2. Summarize the request (Title that the request will be referred to)

   3. Configuration

      1. Select the area that you are requesting the change:

         1. Dynamic Forms

            1. These are the internal MiEHDWIS Forms that internal and external users complete. Common changes to forms are:

               1. Adding and removing sections

               2. Updating form specific language and instructions

               3. Making specific form fields required or optional

               4. Adding options to Select form fields

         2. Notifications

            1. Notifications about activity movement change be generated by the systems.

         3. Activity Type

            1. Changing the activity name to follow activity naming conventions

            2. Deciding if an external user “can view” or “can create” a specific type of activity

            3. Adding document and KBA links to Activity Description

         4. Wording Change

            1. General spelling and instruction changes

            2. Updating Guidance sections of activities

         5. Dropdown Menu Items

            1. Change the order of transitions in the transition drop down menu.

         6. Workflow

            1. Adding/removing a step

            2. Having tasks automatically generated for internal or external users

         7. Other

            1. If you have a change that doesn’t fall in any of the areas listed above, select Other.

   4. Affected Program Areas

      1. Select all the program areas you believe will be affected by this change.

         1. For example, if it is a change to a Campgrounds workflow - it will only effect Campgrounds.

         2. However, if a decision is being made that effect all EH program areas, select all program areas.

   5. Is there a deadline (statutory or financial) that requires the work to be completed by a certain date?

      1. A statutory example would be an activity that needs to be submitted by a legal deadline.

      2. A financial example would be a grant application with a time-sensitive deadline.

   6. Description

      1. Review the questions covered in Developing the Request to help complete the description section.

         1. What is the proposed change?

         2. Why is this change being requested?

      2. will this change need a new or updated KBA?

   7. Attachments

      1. Include screenshots or videos of where you would like the requested change, if possible. This will help the configuration team when they are reviewing the change request ticket.

Post-Submittal Processes

1. Once the change request has been reviewed by the configuration team, a note will be added asking for sign-off by program area staff/engineers and management, stating they understand the outcome of the change request.

2. If a discussion is needed with the configuration team prior to sign off, Amy will set up the meeting with program staff, including Cat, to tell them their request cannot be configured as requested and why.

3. Once configuration is completed, KBA’s will be created or updated.

4. Responsible party and possibly Rotational Engineer will review KBAs and videos.