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]

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