Prevent or control status changes in CPRO structure objects

[Former Member]

Hi all:

I think I've seen this done before in a previous example/ implementation, but how does one prevent or control automatic status changes from occurring in cProjects, as in the standard system?

Business need/purpose:

1.  To prevent the mass REL of tasks to project participants for execution  (i.e. WF event notification)

2.  To effectively track and manage which project activities are truly "Ready for Processing", without having to analyze project structure dependencies and relationships

Business scenarios:

1.  Item/Project from CRTD to REL (i.e. by project coordinator), but automatic Phase REL needs to be prevented  (discretion of PM or PMO Ctrl)

2.  Phase from CRTD to REL, but automatic Task REL for entire subtree needs to be prevented

• As with #1 above, direct child objects are released along with parents.  This means the task tree under Phase 1 all gets released.
• In reality, not all L1 tasks for a Phase becomes ready for processing once the phase is released.
• Consider task dependencies and relationships:  Certain successor tasks don't need to be released until parents are completed.
• In reality, only tasks without successors (other tasks) within the phase (or tasks outside the phase that are not completed CMPT) should be released.

3.  Parent Summary Task from CRTD to REL, and automatic Child Task REL of entire subtree needs to be prevented

• As with #2 above, direct child objects are released along with parents.  This means the task tree under the parent summary task all gets released.
• Same argument as with #2's bullet points above, there needs to be some kind of control over which subtasks get released, based on dependencies and relationships.

4.  Finally, once predecessor tasks are CMPT or CNCL, then successor tasks should be automatically REL, but only if no other predecessors exist that are not CMPT or CNCL.

At the very least (or, solution question 1 of 2) I'd like to understand if there's a way to disable the standard automatic release of entire sub-objects/ sub-trees when parents are released.  The next step (or, solution question 2 of 2) would be to enable "controlled" automation using a combination of relationships and status should happen from the phase-down.

Any thoughts?  The only way I can think to do this is via custom development and workflow using BAdI DPR_EVENTS and the various BAPI_BUS function modules.  I'm wondering if anyone's come up with any other options, especially if it's close to standard, or uses standard to a great degree, before resorting to custom code.

Thanks much!

Lawrence

[Former Member · Accepted solution]

Hi Miranda,

The solution to most of the business needs you have mentioned above lies in making the TASK to release manually. This is not possible if you try doing it from the related webdynpro components of task or phase.

Once the Phase gets released (like first phase gets released as soon the project structure gets released), all the tasks inside it gets released. When I debugged this we realized that even before the control comes to the WDDOINIT method of the TASK's WD Component (DPR_DET_DATA_TASK_O), the status gets changed to RELEASED.

The status of these Phases, Tasks and Projects can be controlled within a class CL_DPR_STATUS_CHANGE_OBSERVER. This class has methods like ON_PROJECT_RELEASED, ON_PHASE_RELEASED & ON_PHASE_APPROVAL_GRANTED. These methods are solely responsible for everything that happens when a Project gets Released (ON_PROJECT_RELEASED),

when a Phase gets Released (ON_PHASE_RELEASED) and when a Phase gets Approved (ON_PHASE_APPROVAL_GRANTED). In simple words, you can control the "automatic Release" of Task/Phase etc from here.

If you want to make your Tasks non-automatic (i.e manual) Release, just goto these method and comment out the few lines where the Task (or Phase if required) status is changed.

[Former Member]

Hey Lawrence,

I had a very similar requirement one of my projects sometime ago. My initial thought was also to change the standard behavior and control the task status. However, due to the technical complexity and other potential issues we decided to use workflow instead.

To elaborate further, instead of controlling the task status, we decided to control when the email notification was sent to the folks who will be doing the task. We also used the Process field (you can use any other field or custom field for this) to capture if a task is "Ready for Processing" or "Not Ready for Processing".

When a phase is released, all tasks will be released as in standard, however the email notification will only be sent for tasks which do not have predecessors and process will be set to "Ready for Processing". When a task is completed, the workflow will check if there are any successor tasks and send the email notification and process will be set to "Ready for Processing". We had to build in conditions to figure out what to if new tasks are created, relationships changed, multiple successor predecessor tasks etc, but you get the general idea. The reason we set a value in the process field is so that the task dashboard can be filtered to only show tasks which are "ready for processing".

With this approach we were not messing around with the task status, it still eliminated the need for any manual release and the development was less complex.

Hope that helps and best wishes for 2014.

Lashan

[Former Member]

Guys,

Thanks for the responses!  I think they're both excellent answers, and hit the nail right on the head.  I've always found the structure element "release" behavior to be hoakey, but primarily insofar as workflow and notification are concerned.  But I'm now thinking a combination of both your suggestions might be a great solution for this requirement:

1.  Disallowing automatic release of Phase 1 upon Project REL  (Sunny's suggestion)

2.  Use of a custom or standard field to drive workflow notification and dashboard display  (Lashan's suggestion)

I fear that simply making everything manual (in the case of task release) replaces one good thing for another, and so there has to be some level of compromise.  Perhaps others who will read this thread will find another ingenious way to design such a process.

Thanks again to you both.

Lashan - A wonderful and fruitful New Year to you as well!  Funny you should mention, but I did see your work firsthand at your abovementioned project.  I thought that was quite ingenious, simple and sweet.  I've always thought this would be an excellent feature to make standard, and your design made it quite reasonable to achieve.  When I came onboard to help with some post-prod work, requests to continually refine the workflow procedures were still ongoing (for instance, when predecessors' statuses were set or reversed).  It was a great and necessary piece of design, especially since it impacted production work in a very real way.

Perhaps there'd be another opportunity to enable something like this as standard in the future, especially considering some of SAP's competitors in the PPM space already do have this feature as standard.  It just simplifies the UX and closes real-world gaps in project execution.  Always looking for better ways to do things better and simpler, wherever possible.

Lawrence

[Former Member]

Hi Lawrence,

Thanks for the kind words. For some reason I missed this reply hence the delay in responding. Yes, I think there is absolutely room for SAP to make certain functionality standard. There are a few custom developments that I found myself doing on every implementation. Project numbering was something that  was long overdue until they implemented it in SP10. I remember, whenever I tell folks that we need an enhancement albeit a simple one to generate project/portfolio item numbers, the response every time is "are you sure there is no number range object?".

Lashan

[Former Member]

As a follow-on, I just realized another benefit / business purpose for enabling this:  cleanup, to fix those "just in case" moments when Phases, etc. are accidentally released.

Take for instance if Phases are progressed accidentally  (if no approvals are required by config of course).  There may be circumstances where DPs would need to be rolled back for the purpose of "accuracy" in management reporting.  This, despite the condition that entire phase sub-objects in CPRO are now released.  I would imagine that intentionally not configuring DFM sync for any other status than REL would not be a very clean solution.

I realize there are pros and cons to both, but if controlled release of tasks were available, then there would be less concern about breaking sync and data inconsistencies.  Furthermore, I propose that the authorization to begin Phase work would be the accountability of only a few people by proper role authorization, i.e. the PMO or Project Managers.