New Ranks & Badges For The Community!
Notice something different? The ranks and associated badges have gone "Star Fleet". See what they all mean HERE
Highlighted
Absent Member.
Absent Member.
260 views

Change with tasks for multiple assignment groups

Hello,

I always do a keyword search to see if my question has already been asked, but didn't find/see this one.

Today in PSC6, we submit one change per assignment group. So, if a project or release requires assistance from multiple assignment groups, we create multiple change tickets.

In SM7, could this be handled using change tasks? Create one change ticket for all of the related changes and then assign change tasks to each assignment group?

Assignment group approver is a required approver, so if the change ticket had tasks for multiple assignment groups, how could we make sure we had all of the required approvals? Allow for multi selection of assignment groups in change logging?

Is anyone out there allowing this - multiple changes combined into one change record? How did you implement and is it working well?

Thanks,
Liz
0 Likes
6 Replies
Highlighted
Fleet Admiral Fleet Admiral
Fleet Admiral

I would think that Change Tasks might be the simpler way to go here, as you'd have one record as the Change record, and several records as work that needs to be done as part of that change.

If the projects have similar work that needs to be done, you could set these tasks to Auto Open in a particular change phase and have them appropriately assigned to the right groups. If these don't have similaries, then you'll have to manually create the tasks.

Approvals get tricky, though, if the assignment groups are used to determine the approvers. If they are automatically generated, then it's easy, since you'll know beforehand which assignment groups are going to be involved and you can build your ApprovalDef record as needed. But, if they're set manually...

The issue is that you can't close the Change Phase while there are Tasks open; so if the Tasks get generated at the start of the Change workflow, they would have to be closed before that first phase finishes (which wouldn't work in this case). But, if you're using the "Next Phase" Process to move through the change phases, then it doesn't matter. And, then you _could_ generate the Tasks at the start of the change flow, and even query those tasks to get the assignment information and the approval information needed, and roll all of those approvals into the change record...
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

On the Approvals piece--you can add approvals at the Request or task levels. So you could complete the group-related approvals at the task level while managing the higher level approvals at the change level.
----------------------------------------------------
Kudos - what, where, how, and why
Want Good Answers? Ask Good Questions...
0 Likes
Highlighted
Absent Member.
Absent Member.

My understanding is that change tasks are defined in assessment and planning for completion in the coordinate implementation phase. Or, at least that is what we thought we would do so that tasks are well understood at time of approval.

How do you define an approval at the task level? All change tasks would need to be approved prior to change approval? How would we require approval of tasks before approval, but implementation of those tasks to be completed after approval?

OOB, change tasks can be assigned to any assignment group, correct?
0 Likes
Highlighted
Fleet Admiral Fleet Admiral
Fleet Admiral

Actually, Tasks can be defined at any point, but the workflow of SC (and SM until SM7.1) required that the Tasks be closed before the parent change could close and move to the next phase. To get around this limitation, in implementations I've worked on prior to SM7.l, we configure the Next Phase button to work (since that bypasses the check for open Tasks).

In SM7.1, HP finally provided a means for the application to keep tasks open when a Change Phase was closed by making it configurable at the Change Phase level to allow open tasks.

So, if it were me, this is the overall strategy I'd use to approach your requirement:

First, customize the Next Phase button (instead of the Close button) to move Changes through their appropriate phases. That takes a little work because you still want your validations to run, and you still want to be able to limit who can move a change to the Next Phase; the Close Controls in the Change Phase definition record are already set up to determine who can see the Close button, and when it's available.

Then, have your Tasks open in whichever phase you want, configure approval at the Task level, and define your Change approval to ensure that the Tasks are all approved before the Change can be approved.

Then either have multiple phases for your tasks so that the approval of the task happens in a particular task phase, but the task can't be worked on until the parent change is in your Implementation phase, or configure the Update and Close controls on the Task phase to limit when the Task can be worked on based on the parent change's Phase.

It's a little messy and strays from OOB in design, but Change is one of those areas that has seen some significant changes as the application has been upgraded anyway.
0 Likes
Highlighted
Absent Member.
Absent Member.

Hi Jecob,

I have configured a Auto open task for one of the Change phase,task is opening in only this phase and i want that this task should be assign to particular fixed assignmnet group or a user(if possible).
I know from above that it can be done at task level but i don't know how and where i have to do the modifications for this.
I am using SM 7.03.

Thanks,
tushar
____________________________________
Assign Kudo, if found post useful and mark it accepted if solves the issue.
0 Likes
Highlighted
Absent Member.
Absent Member.

Same challenge on my side: Auto assignment of tasks or preconfigured assignemnt of tasks.

I believe this is not possible so far. If some one can help us in this or can share a workaround for this.

Thanks.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.