Changing OOB phases on Project

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-26-2022 12:57 PM
Hello
We are wanting to change the OOB project phases to align with customers existing phases
Can someone tell me what are the implications of changing these? should they be relabeled or create new ones?
Do all related forms get updated ie project workspace, analytics, status reports?
what are the impacts when upgrading?
thanks much
- Labels:
-
Project Portfolio Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-26-2022 01:11 PM
You can relabel them just for that specific table.
If you create new ones make sure that the value of the new states is unique to the whole Task table. Otherwise it will create an odd issue where people who filter using the filter condition in the list view will see odd bugs.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-26-2022 11:34 PM
Hi Mary,
This is a relatively simple change and one that quite often has a huge impact on the acceptance of the tool versus the insignificant level of technical debt created.
I don't think there's much difference between relabeling versus creating from a best practice perspective, although I have a slight bias to creating new. I like to see what was OOTB without having to review and compare versions.
What does need consideration is the impact of relabeling versus deactivating for any preexisting projects as well as the need for accuracy in historical data. If you re-label an existing phase from 'A' to 'B' all projects that had A will now have B. If the meaning is the same, there is no need to consider historical accuracy for this field and all phases map this way then re-labeling can often be quicker and less risky as you wont need to create fix scripts to set the new phase value. Obviously if the inverse is true for any of those then you're better off creating new, deactivating existing and updating existing projects as needed via a fix script.
You'll also have to also update the Process Flow formatter on the pm_project table to ensure that the chevrons across the top of your project record mirror the new values in the phase field, otherwise all other areas will just reflect the currently active (or inactive if you've deactivated and want historical accuracy) field choices.
In terms of upgrades, both possibility of it occurring and and impact would be minimal. I've not seen any changes to either of these items since they were originally added and see it as being unlikely to change any time soon.
Thanks,
Chris
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2022 10:56 PM
Hi Mary,
we've made the same experience as Chris mentioned: the renaming of phases had a very positive impact on the acceptance of the tool. Reason was to bring the tool more to the already established PM standard PRINCE2, so the phases were renamed to fit P2 standard phases (ie Start up, Initiation, ...). We mapped the E2E process Demand->Project to PRINCE2, so it was e.g. clear what an approved Demand means in P2 terminology. In addition we added some custom fields to be able to track all P2 management products.
Technically this was done by renaming labels (as Chris mentioned don't forget the chevron), this was easy possible as this was done before initial ServiceNow ITBM rollout (it was on New York, I think, so no SPM yet ;-)), consequently we had no existing data.
Hope this experience you to make the right decision!
Beste regards,
Arne