Now that PeopleSoft 9.2 is in GA – general release – you can review your current list of modifications and compare it to the list of new features/functions in your PeopleSoft applications. The exercise of deciding what to migrate to PS 9.2 is key to keeping your system both easy to use and cost effective.  As you know, there is the initial cost to develop something new, and then there are additional costs to apply patches and fixes around your changes (~30%-60% of the original cost each year).
Let’s start with some definitions:

  • Modification – a change to a delivered PeopleSoft object (keeps the same object name).
  • Bolt-on – a brand new object(s) that connects to PS.  (These objects usually require less maintenance as they usually don’t change the delivered system.)

To keep things simple, I’ll refer to both the above as modifications in this article.

A question I often hear from clients is, “how many modifications is considered normal?” I have one client (A) that runs a PS system with 70,000+ modifications.  I have another client (B) that runs a 100% vanilla PS system. Yes, there are differences in the two companies’ size and complexity; however the difference that drives the extent to which their PS system is modified can be traced to each client’s underlying business model/philosophy.  Client A’s heavily modified PS system can, in large part, be attributed to its decentralized structure. The many stakeholders, in many locations, defined different (and sometimes conflicting) requirements when the system was initially installed. Then, over the years, Client A has kept and also added to those modifications.  In contrast, Client B has a strong, single sponsor that, while not unilaterally opposed to modifications, has not been able to financially justify any modifications, at least so far.
While I know we can’t draw global conclusions from these two examples alone, I have found that strong central sponsorship and objective cost/benefit analyses help limit modifications. I’d like to suggest that instead of thinking in terms of norms, it is better to think in terms of what would be appropriate based on a client’s unique requirements and the cost/benefit calculation for each modification considered.
I use a simple algorithm to look at the cost/benefit:
(FTE reductions + other hard savings {paper, postage, etc.} + efficiency savings) / (modification cost + 50% of the cost * 4 years)
Often, there are no full FTE reductions, only efficiency improvements and other hard savings.  Efficiency savings are those that save a little time whenever a modification is utilized.  Frequent, high volume transactions, like time entry and expense reporting, can add up to thousands of hours per year.  If a modification makes high volume transactions easier, it will improve user acceptance, decrease errors, and save time. The question then is, “how much are these benefits worth?”
Additionally, proposed modifications will likely be evaluated/prioritized differently, depending on which executive in the organization is ultimately responsible for the decision to make a change.

  • CFOs most value the cost/benefit evaluation discussed above.
  • CHRs often try to reduce administrative work while providing actionable data about people. This role will often value efficiencies, integration and timeliness. How will the proposed modification provide the benefits they value, and at what cost?
  • CIOs can see modifications as simply more work for his/her organization and increase risk when something doesn’t function well. They need to see a well thought out and documented design. Include details on why this modification is needed, who benefits, how they benefit, when it is needed, and what is at risk if the change is made or not made.

It’s important to track what you proposed vs. what was actually modified. This information will help you establish or fine tune your modification policy and leads me to another question I’m often asked, “what modifications should I bring forward?” Over the years I’ve seen organizations make many modifications during the initial install. Years later, they compare how much it cost to make the modifications versus how much they actually benefited from it, and often they de-modify the system during an upgrade. Many original modifications just didn’t make fiscal sense. The client may not go completely vanilla, but they do modify much less.
So, which modifications should you retire?  We help our clients evaluate whether or not to retire modifications by examining them in light of three criteria.

  1. In general, if the new PS functionality replaces any modifications, retire them.
  2. If a modification is not worth the cost of maintaining it, retire it.
  3. If you can change your business process to follow a delivered process, you can retire any associated modification(s).

Keep in mind that when you retire a modification, you change how your users interact with the system. You will need to address this with Organization Change Management.  (As promised, I’ll talk more about OCM and its associated ROI in an upcoming blog.)
Having the option to make modifications is one of the really powerful benefits of PeopleSoft; however it can also create unnecessary and expensive work if the proper up-front, client-specific cost/benefit evaluations are not performed.
Next week I’ll discuss options for deciding what to include in your project scope, new functions, BPI, Organizational Change Management (OCM), and training
As always, feel free to contact me at if you have comments or questions.