In larger CA PPM environments, that support multiple PMO's, often each PMO has their own requests for how CA PPM can be configured for their use and individual needs. Fortunately/unfortunately, I have been in many of those environments. A few have an EPMO that is quite strict with the configuration of CA PPM and others, well, not so strict. I have decided to include a few finding about these environments in this blog. Please feel free to comment and and your experiences as no two environments are the same and there really there is no right answer since the goal is to support the business and projects.
In the more strict environments I have found that CA PPM has been configured to support their methodologies and business processes, with very few requests being implemented that do not have a business or project benefit that either reduces project risk and/or assists in the completion of the project successfully. Requests that are more to track information or to report on information that does not directly have a positive affect, then they are not implemented. Everyone, uses the same fields and this also keeps support costs down as
In the less strict environments, I have seen a plethora of reports and fields that have little or no value in the delivery of a successful project or reduces project risk. Instead they were added as fields (attributes) simply to track additional information for some report. So not only was a new field added, reports would have to be added/updated to support the use of the field. Often these new fields are already available in CA PPM in some for or another.
For example: A manager requested a field that lets them know when the Execution Phase starts and a field that lets them know when the Execution Phase was completed.
Hmmm, A real difficult one! How about having a task called Execution Phase? Or if you are tracking a fuller schedule in CA PPM have all the phases in your methodology in the schedule as summary tasks. You can just pull the start and finish date of the "Execution Phase" summary task. No new field required!
When you have an environment with a lot of additional fields that support individual user requirements, you not only make it difficult to support the system, keep any semblance to an updated Data Dictionary nearly impossible, but when other users start using those other fields for their own purposes, not only does this invite increased support costs, but if the original owner wants a change to the field, it screws up the other unintended users of the field. Welcome to the hectic world of Change Management in a difficult CA PPM environment. This also have an additional impact on training and keeping training materials updated.
Custom fields are almost always required and I for one support them. But I always ask the requester a number of questions before proceeding any further:
- What is the business value of the field?
- Will it help the project complete successfully or benefit the project in some manner?
- Will it reduce project risk?
- Are there any reporting requirements to support this change?
- Do you have a budget for the implementation of the field?
Lets face it, if you have been around CA PPM for a few years, how many fields have you seen that have no value, nobody uses, or nobody remembers why they had that field in the first place. To avoid this, lets just not create them in the first place.
If we are going to add a field or functionality, lets do it for the right purpose.
Have a great weekend.