Evaluating Customisations

A key planning activity during PeopleSoft application or tools upgrade projects is to evaluate existing customisations in order to,

• Decide whether a customisation has to be retained (re-applied), typically referred as keep/drop analysis
• Estimate the effort to re-apply customisations

While there exists many documented and un-documented ways, I have discussed below a streamlined process of objective and subjective analysis to perform this activity.

Objective Analysis

This step is performed to scope the existing customisations by getting the number and size of customised definitions in the application.

While the customisation guidelines and practices may vary among various sites, few standards could be considered standard and are followed widely for PeopleSoft applications like,

• Customised objects grouped into Project definitions
• Custom created objects follow a naming denoted with site specific prefix or suffix
• Delivered User IDs like PS, PPLTOOLS not used to perform customisations

On these assumptions, a quick report on the number and size of customisations can be generated using a sample SQL below,

SELECT P.PROJECTNAME, P.PROJECTDESCR, P.LASTUPDDTTM, P.LASTUPDOPRID,(SELECT COUNT(*) FROM PSPROJECTITEM I WHERE I.PROJECTNAME = P.PROJECTNAME AND I.OBJECTVALUE1 NOT LIKE '%XXX%') AS PS_OBJECTS_CUSTOMISED FROM PSPROJECTDEFN P WHERE P.LASTUPDOPRID NOT IN ('PS','PPLTOOLS') ORDER BY P.LASTUPDDTTM DESC;

Value ‘XXX’ in the SQL above needs to be replaced with site specific naming convention.

Objective of this query is to produce a report shown below and the query can be updated based on site specific customisation practices to produce a more accurate report.

While the individual projects indicate the number of customisations, count in ‘PS Objects Customised’ column indicate the size of each customisation. As can be noted in the SQL query, only the definitions delivered by Oracle and customised by customer is reported under ‘PS Objects Customised’ column.

Note: Custom objects created by customers can be upgraded without any re-apply effort, so it is not exclusively reported above.

Subjective Analysis

Subjective analysis is performed to qualify the customisations and determine the complexity of re-applying activity.

This step require reviewing the customisations individually and could be performed either by accessing the impacted definitions (using application designer, external programs) or accessing related documentation (using functional/technical specifications). Tribal knowledge of in-house team could also be a valuable input to perform this activity.

Report created in previous step is used and further columns added to qualify individual customisations.

Purpose and approach of the qualifying columns listed below,

1. Duplicate – If a project definition contains only the objects which duplicate with a master project definition. E.g. A bug fix project to an existing customisation. Duplicate projects need not be qualified further as they need not be re-applied separately.
2. Keep/Drop – If a customisation need not be re-applied in the target version. Evaluate if customisation can be replaced using a delivered feature in target version or business requirement becomes obsolete due to product or process changes. Projects to be dropped need not be qualified further.
3. Complexity – For those customisations that are deemed as non-duplicate and have to be re-applied, complexity has to be determined. A simple scale of high/medium/low could be used. While number of PS Objects customised provides an indication, nature of the customised objects and the changes in the target version could determine its complexity. E.g. adding a custom field to multiple records could be lower in complexity than re-applying changes to a page as it may have changed significantly in the target version.

On completion of the qualifying columns, customisation projects with the complexity estimated can be used to calculate the effort for re-applying activity, with complexity tags mapped to a range of effort days. E.g. Low = 1 – 2 days/Medium = 2-4 days and so on. Consistency while assigning a complexity is key to accurate effort estimate.

Advertisement