Highlighted
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class
123 views

Applying Workflow Enhancements to Existing Projects and Proposals

We have made some significant project manager-requested enhancements to our proposal and project workflows, and are now ready to get them moved into production.  The group that performs the migration from our HP-PPM development environment to production has informed us that these workflow changes cannot be applied to our existing proposals and projects, but will only effect newly created ones.  This obviously presents a problem for us, as we will be forced to operate with multiple workflows until all existing proposals and projects get closed (which could take months, even years), thereby limiting the near-term benefit of these promised enhancements for the majority of our project managers.

 

Wondering if others have faced this same migration issue, and if there is any viable alternative to get workflow enhancement applied to existing proposals and projects?

 

Any ideas / suggestions would be greatly appreciated.

 

 

0 Likes
9 Replies
Highlighted
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

Changes included new workflow steps, new step sources, and notifications.
0 Likes
Highlighted
Cadet 1st Class
Cadet 1st Class

Hi,

 

They are correct. PPM best practice is to use a versioning system for new Workflows, Request Types, etc.. On the PROD environment, if a User goes in to the Workbench and tries to make the same changes, the Workbench will give a warning "This Workflow is already in use, if changes are made, this may cause data corruption" (or something along these lines). So when migrating, the same would apply.

 

Canceling the old Projects and starting new ones or waiting until the old Projects end are the two options.  Some clients have exported the current Work Plan of the old Project in to Microsoft Project, and then imported it in to the new Project with the new Workflow (though this may not be possible or realistic if there are many Time Sheets that are being used to track the Actuals; depends on the Project Settings).  Clients that have tried to make the change and ignore the warning, if data corruption occurs, they create new Projects in the end.

 

That being said, in the past when testing in a TEST environment, I have made minor changes to Workflows and everything worked fine in the old Requests/Projects. It depends on what changes are being made and at which Workflow Step the Request is currently at. Could try testing changes in a STAGE environment with a copy of the PROD data to see if every Project would act as expected taking every possible action from the Workflow Steps where the Work currently resides (though this again my not be realistic as the data will be updated in PROD by the time the STAGE data is tested). This may work, though in the end it is not recommended or supported if should run in to data corruption by ignoring the warning.

 

If absolutely a requirement to use the new Workflow with old Projects, may want to consider hiring the HP Professional Services Organization to ensure there is no data corruption.

 

-Mike

“HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
0 Likes
Highlighted
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

Could the following approach work, in this case for existing projects?

 

1) Migrate workflows into Production as planned
2) Modify the Project Header to allow editing of the "Workflow" field

3) Produce a list of all existing active Projects, displaying / sorting by current workflow step
4) Using the list above:

     a) Modify the "First Step" of the (enhanced) Project Workflow to match the current workflow step of an existing

          project
     b) Open existing project currently in that workflow step
     c) Copy / save off the "Workflow Status Details" (in Notes or as a Reference attachment)
     d) Copy / save off the "Transaction Details" (in Notes or as a Reference attachment)

     e) Make a copy of existing Work Plan task statuses (as these will need to be restored)
     f) Change the "Workflow" field to the name of the (enhanced) Project Workflow and "Save" the project

     g) Update Work Plan task status ( as they would have been changed to "Cancelled" as a result of the workflow

         change)

5) Continue through all existing projects currently in that workflow step until all converted

0 Likes
Highlighted
Cadet 1st Class
Cadet 1st Class

That may work. Though I suspect PPM may not allow the canceling of the Work Plan/Tasks, if there are already Actuals logged against a the Tasks with Time Sheets in a "Closed" State.

 

If Time Management option in Project Settings is not being used, then after changing the Workflow, it would be like starting a new Project, and would just have to re-enter the data you described to get the Project back to where it was.

 

Try switching the Workflow in the STAGE environment to see if that workaround can be used prior to making any PROD changes (to throw in the usual disclaimer).

 

-Mike

“HP Support
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Hi,

I would not recommend this approach at all.

We are constantly performing workflow updates and request type updates and we are able to properly migrate the new entities to the production environment. It is all in the impact of the changes you are implementing. I can't make a list of all possible situations you might encounter, but if you have specific issues, we will definitely help you.

Cheers
Alex

--remember to kudos people who helped solve your problem
0 Likes
Highlighted
Vice Admiral
Vice Admiral

Changing existing projects in the middle of a workflow is dangerous!  It has been our experience that when this is done you end up with more problems than you started with.  We attempted this with over 200 projects one time and ended up having to apply the new workflow to every project and then progress each project to the point in the workflow where it had been before.  This caused multiple issues with the projects and we ended up restoring our backed up database and implementing the new project workflow as recommended in the documentation. A very, very mistake prone and time consuming process.  Definitely not worth the effort. 

 

Max

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Hi, MaxH,

I am sorry, but it all depends on the level of impact assessment you perform before and during the implementation of the changes. I have performed workflow - and request type - changes for about 5 years now for various customers. We have never had any issues whatsoever since we invested the proper amount of effort in assessing the changes.

Out of curiosity, what kind of issue did you encounter, which forced you to apply a new workflow? If you cannot post here, we can take this conversation offline.

On another note, I really do not agree to the fact that a new workflow should be applied for each change. There are so many drawbacks to this approach, starting from a huge impact in custom reporting, from not being able to apply the changes to existing requests / projects.

Cheers
Alex

--remember to kudos people who helped solve your problem
0 Likes
Highlighted
Vice Admiral
Vice Admiral

Alex,

 

Sorry it took me so long to respond to this.  I actually didn't realize there was a needed response until now.  We are once again at the point of changing our main Project workflow to incorporate a change that reduces the number of steps (thereby saving the Project Manager time), so this conversation is once again relevant.

 

When putting a new workflow in action against current open projects, if workflow validations or sources have changed, then of course the project might actually get hung out in limbo because the transitions may no longer work.  We found this to be the case in several instances, so yes; the level of impact assessment performed can have a profound effect on the database and projects contained within.  Since I was fairly new to the PPM process at that time, I did not do enough of an impact assessment.  That said, we learned from that very lesson and I took note of several responses I found in the forums where users has similar issues.  When we place this specific workflow into Production, we are now allowing the old ones to play out, so that we do not have to go into the database and make changes to existing projects or do the changes from the application itself.

 

Additionally, as you noted, there are other issues that come to the forefront, including those with custom reports and portlets, etc.  So, it does make sense to create a new workflow process and allow the old projects to complete before disabling the old workflow.

 

Max

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Hey, Max,

Yet again I do not agree with you 🙂

We have done such workflow changes for our customers multiple times. In situations similar to yours, we used the move workflow feature to update the running projects, which by the way is documented and supported by HP.

Just to prove my point, we could have a discussion on your specific situation.

On another note: what would happen you need to change workflows for long running projects, such as 6-24 months? Such changes are usually required by PMO / project excellence departments and they are implemented for the simple reason that the methodology needs change whatever reason, from regulatory and compliance to business agility needs. In your case, for example, an audit would fail the projects which are not considering the changes.

In conclusion, in my opinion it makes sense to update the existing workflow.

Cheers
Alex

--remember to kudos people who helped solve your problem
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.