I see many customers trying to change the values in the Project 'State' field or how things roll up/down when there is a State change, and I see many HI incidents related to this and Community discussions on this. I am also a customer who has done this and later reversed our changes. I'm starting this thread in hopes that it will provide a central source for content, recommendations, questions, etc. Note that any code changes mentioned here aren't under ServiceNow support - I'm just starting a collection/forum. ITSMgal and others, please let me know what I'm missing or provide clarification on anything I can state more clear, and I'm happy to keep this thread updated.

Some notes first:

• Helsinki version makes it much easier to change the Project 'State' field without having the domino effect throughout the PPM applications.
• The state field has been in PPM since its inception. These states are part of the basic function of the PPM application and the recommendation is to stay as-is in versions prior to Helsinki.

The basics:

• OOTB Project 'State' field values: Pending, Open, Work in Progress, Closed, Closed - Incomplete, Closed - Skipped.

State tentacles / dominoes are listed below (will keep this list updated). The OOTB states in Project (pm_project) table values automatically impact project task states via the 'Process State' BR. If your custom states are NOT one of those OOTB state values, then the BR will not trigger any state changes on the tasks. The default workstate (under planned_task table) is what triggers all this — to prevent this you need to create a dictionary override for pm_project_task. You need to consider if you want your changes to: pm_project, pm_project_task, planned_task. If you add a state, you must modify these state-related attributes on planned_task or other dictionary overrides, per table, for wherever you want these new states to apply.

• When a project is created it is in Pending state. When you click on "Start Project", the state automatically changes to "Work in Progress". This impacts the state of tasks set to Start ASAP.
• Project tasks can be worked on & updated before the project's 'Start project' button is clicked. Once the task 'state' is progressed beyond 'Pending', it automatically puts the project as started, and if the task is completed and has a successor then the successor task state is auto-changed to WIP.
• There are 2 sets of dates in Project and Project Tasks: Planned start date & planned end date, and actual start date & actual end date. Depending on the state of the project & task the planned or actual values are populated. See this post for details.
• Project states impact task states which impact the Planned Duration value. See this post for details.
• When Project state changes to 'Closed Complete', task states will automatically close. Code is being processed in the business rule: Process State Change - around lines 130-135.
• Changing the Project State to any of the Closed states (Closed Complete, Closed Incomplete, Closed Skipped) changes the Project percentage complete to 100% as a result of all of the Project Tasks being changes to 100%. This is from the Business Rule "Process State Change" on pm_project table. See this thread for managing this.
• When the last Project Task closes, the Project state automatically changes to Closed. This happens under both Manual and Automatic calculation types. There are several Community threads on how to stop this behavior (here is one). A recommended business process is to have a Task at the end of every Project that would be assigned to the project manager - like 'Validate Project for Closure" and then make it a successor from the last Task, usually a milestone. When the project_manager validates and closes that Task, then the Project would auto-close and you would record the project manager's validation work in a Task.

When changing states…. The attribute is on a dictionary override for planned_task, so it will only impact planned_task and tables extended from it. ... So it impacts Project Management, Demand Management, SDLC, etc., but not incident, problem, or other things not extended from planned_task.