Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

Change Control

CHG0003185

Release Notes

https://yale.service-now.com/syskb_attachmentview.do?syssysparm_idarticle=XXXKB0000066

Documentation

Info

Detail is provided in the description. Full implementation detail is captured in the update set, which can be viewed (with admin rights) by drilling down into the links.

...

Requirement (Original Names)

Functional Tested?

QA Tested?

Dev Status Notes

Description

376

(tick)

(tick) (w/ caveat)

(Vamshi) Works fine (However, the Change Type gets updated only after using 'Execute ‘Execute Risk Calculation'Calculation’)

When submitting the risk calculation clicking on the 'submit' button should calculate (and also re-calcualte when redoing the risk calculation) the risk assessment. Should not have to click on the 'execute risk calculation' to recalculate. Marked as a higher priority requirement by Change Process team.

423

(question)

(tick)

(Retest) w/ Charlie. This works & passed QA.

When the Change passes through the CAB and goes into implementation phase changes cannot be made to the Change in the system. ITIL users should be able to add work notes, comments and attachments to the Change but not make changes to any of the other fields.

536

(question)

(question)

missed documentation, just added to list... but was there originally. Implementation details changed from originally stated prescription.

Change: add new Change Task type of "Review"

  • this requirement as originally stated was looking for ad hoc approvals, which might have caused problems for Configuration/Change process in the future. Now people will be able to create/assign change tasks to have people review changes, but approval ultimately resides with the CI owner.

546

(error) 9/4

(tick)

(Charlie) If the Owner group is changed the change goes back to Acceptance state. If the change is in CAB approval State you can roll back to Acceptance State. After it gets to implementation state the ability is no longer there to go back.

Defect #311: Change: Change Manager needs the ability to roll changes back to any prior phase without breaking workflow. If Change goes back to prior phase it should then have to go through all appropriate approvals again as it moves through the workflow.

556

(tick)

(tick)

(Retest) Failed if 'Submit for Acceptance' UI Action used in a standard change. This button doesn't make sense in a standard change.

Change: Planned/Actual End dates should be after Planned/Actual start dates. Currently you can make a planned end date before the planned start date.

561

(tick)

(tick) 8/21

(Vamshi) Failed (Needs a tweak). (Bill) Modified this so that the UI action doesn't appear until the required fields are entered and saved.

Change: Risk Assessment Process. When filling out a risk assessment you should have to fill in the required fields BEFORE filling out the risk assessment so you don't fill out the assessment and then lose your info because you haven't saved. Currently if you fill out the risk assessment and you have not filed out the other required fields you can't save the change and you lose the work you did on the risk assessment. Need to make sure that when you fill in the data before filling out the risk assessment it does not disappear when the risk assessment is saved.

562

(tick)

(tick)

(Vamshi) Failed (Needs a tweak). (Bill) This was changed to be required in Assessment phase, along w/ planning info

Change: Planning information should not be required at the assessment phase as you do not know any of these until you're closer to Production time. This 'planning' information should be requried before the second approval (CAB or second Manager approval).

563

(tick)

(tick)

(Retest) Jumps to implementation during standard change, does not allow you to select for release (this checkbox will be hidden in standard changes, since per the Change Process they are preapproved).

Change: Second Approval RequirementsManager of Change Owner Unit: Approves Minor Changes Andrea (Release Manager): Must approve the Change if the 'Application Change for Release' box is checked.CAB: Must approve for major, signifiant or when the newly requested 'CAB Approval' box is checked. Dual Approvals: If the change is significant or a major change and the assessment code is application change for release then both the CAB and release manager need to approve.

564

(error) 9/4

(tick)

(Vamshi) Works fine (The checkbox is hidden for a Standard Change). But I think it would be apt to communicate about this change to Chloe and have her update the existing requirement in HPQC. (Charlie) Works O.K. but once the Change moves into CAB approval state the box can no longer be modified for any type change.
Standard Change - If box is checked for this it also works but no approval is required.

Change: Add a box that says 'CAB Approval Required'. If the change is major or significant the box is checked automatically. Changes that are mimor folks should be allowed to check this box. If thie box is checked then the change needs CAB approval. If this box is checked via automatic workflow (e.g if the box is checked because the change is significant or major) the box may not be unchecked. The box should only allowed to be unchecked if it was checked manually.

574

(tick)

(tick)

(Can't Replicate) was working but failed again on 8/21, need to replicate

Change: When Assignment Group Changes Approver should change. If a Change is mistakenly assigned to a group and then re-assigned to the right group the approval stays with the manager of the original group. The approval from the original group should no longer be required and approval from the new group manager should be required.

575

(tick)

(tick)

(Restest) per Charlie: Defect 363: closure code is req'd, but once you close PI task the change closes w/ a blank closure code

Change: Make Actual Implementation Dates and Implementation Code required before the Change can be moved to the post implementation phase. These fields need to be completed before the Implementation task can be completed and the change move to the Post Implementation phase. Added a check for closure code pursuant to this defect.

377

(tick)

(tick)

trivial

Hide Configuration Item on Change Task screen. Add 'Affected Component' to the Change Task screen. The data in the affected component should carry over from the parent change.

434

(tick)

(tick)

OK

Change: At the bottom of the Change ticket where it shows the approvals to be approved and the approval history it should tell me what type of approval is required or what type of approval was done.

518

(tick)

(tick)

OK

1- Add 'Create Standard Change' to the Change Module menu in the navigation screen
1a- When selecting this option it should do the same thing as applying the standard change template in the template field on the Change screen. Applying this special template not only fills fields but also applies the standard change workflow applied when this template is used.
2- Change 'Create New' to 'Create Normal Change' in the Change module menu in the navigation screen
3- Remove the Standard Change Template from the available template list
4- Remove the Template field in the Change ticket

535

(tick)

(tick)

This was changed to be required in Assessment phase, along w/ planning info

Change: Make Change Owner a required field before submitting for CAB approval. Per Lou Tiseo.

541

(tick)

(tick)

OK

The Post Implementation Task is requiring CAB review for every change. This Task should be completed by the Manager of the Change Owner Unit for minor changes. All Significant and Major Changes get PIR by CAB.Please change the default task to have the Change Owner Unit Manager Minor Changes. - Lou Tiseo

553

(tick)

(tick)

OK

Change: Would like to be able to select a highlight button for change type. Per Lou Tiseo.

565

(tick)

(tick)

OK

Change: Remove the Assessment Condition Codes drop down box and the fact that this is a required field.

573

(tick)

(tick)

OK

Change: Add a check box that says 'Application Change for Release' with accompanying workflow. If this box is checked the Change must have a parent change. If there is no parent change the Change should not be allowed to go to the CAB for approval. The Change should not be approved to go to implementation without a parent change (e.g. a release).

...