After a system goes into production, many operational situations arise. Good capacity planning tries to allow for these types of situations. The most common are discussed briefly here.
New Software Releases
As noted in the section "Monitoring for Growth" earlier in this chapter, network, machine, and application administrators should log any changes made to a production Project Server environment or system. This should be done in the context of an ongoing system monitoring or change policy.
Information Life CycleArchive and Retention Policies
Over time, the database sizes will expand; however, the information within the databases has a life cycle. Projects end; resources leavethese factors mean that pruning of information within the databases is appropriate. Data archival (pruning) policies must be promoted by IT but defined by the business. In addition, the impact of removal of a project or a resource from the repository must be well understood. Removing a project will change the resource loading for the period that that project spanned. Removing a resource should be done only after any projects that resource worked on have been removed from the system. These are important considerations that generally lead to a project retention policy on the order of one or two years. The retention of this information in the system must be accounted for in the physical storage space estimations for the time frames.
Business Need Changes
The EPM system is initially configured to meet the originally defined business needs. It is recommended to have the "whys" of the initial configuration design decisions (and any changes over time) documented. If business needs change or the sponsors and maintainers of the system move on, re-examination or modification of the system can still occur efficiently.
Defined business needs change more frequently than most allow for. Simple requests or formula changes from Finance, for example, can cause project schedule restructuring to better support reporting (which can cause performance impacts depending on how and where formulas are used; for example, formulas not carefully defined in Enterprise Task level custom fields can sometimes cause performance penalties). Large project creation may inspire creation of new roles (for example, resource managers may appear where before there was no such role). It is frequently not the original sponsors and system implementers who have to define the system changes to support the new business need. Having the history of the changes made to the system and why they were made helps prevent configuration changes that appear to address the current need but that may have been previously analyzed and ruled out due to subtle process impacts.
System CustomizationSpecial Needs
Throughout the life of an EPM implementation there are business need changes, system augmentations, and new integration points with other systems. Any of these can lead to customization activity. As soon as customization is broached, a need for a test system arises so that the production system is not impacted until modifications are validated and quality assured. Capacity planning must address the possibility of a test system for completeness, even if no test system is initially deemed necessary.