Layered Configurability
Every client that needs a certain kind of software will operate about the same way, conceptually. But, when it comes to the details, every client is different. Enterprise software vendors need a way to address the differences of each client. The two approaches available today are customization and configuration . You can do either or some of both.
Here is a quick primer.
· Customization – modify the software itself, by modifying the software code or building an add-on component, to behave as desired. This happens when a client wants a behavior that is not in demand by other clients. Because the behavior is not in demand, the client would expect to pay directly for the customization. The software vendor, or a third party, will modify the software or build the add-on to meet the demands of the client. Customization is usually not supported by the software vendor once complete. The advantage is the client gets exactly what they want. Disadvantages are the high cost and risk of maintenance throughout subsequent software releases.
· Configuration – manage the way software operates by changing configuration settings in the software. An administrator, or other trained personnel, can select the configuration settings. The software has been fully tested to operate properly with all the available configuration settings. Configuration settings are added and maintained by the software vendor, typically at no charge to the client. Configuration settings are built into the software and, therefore, supported. The disadvantage is you may not get exactly what you want. An advantage is you may get better than what you want because the software vendor is building configuration based on feedback from many clients. Another advantage is you get a product that is fully tested and supported.
When enterprise software first appeared, customization was the only way clients got what they wanted. After hardships and learning lessons, configuration became available.
Configuration is great for enterprise software. You configure the software for the enterprise and all processes and behaviors work the same across the enterprise. This promotes consistency, communications, and roll-up reporting. But what happens if multiple parts of an enterprise want different behavior or different processes? They will need a different configuration than the rest of the enterprise. That means they need their own instance of the software, which means the consistency, communications, and roll-up reporting goes away.
So, an enterprise needs to balance two competing needs and their two competing solutions.
·Purchase a single instance to have enterprise-wide consistency, communications, and roll-up reporting. Some parts of the enterprise will be stuck with a configuration that does not work for them. They either must work around it or modify their processes to conform to the enterprise.
·Purchase an instance of the software for the enterprise and for each part of the enterprise that wants to be different in order to meet the needs of individual parts of the enterprise. Multiple instances can get expensive and likely cannot communicate with each other. This prevents important capabilities, such as rolling up reports to the enterprise.
Any enterprise that has robust program and project management will have the need to configure differently for different parts of the enterprise. An enterprise may have multiple PMOs and each PMO may run multiple programs. That same enterprise will also have the need for consistency, enterprise-wide communications, and enterprise-wide roll-up reporting. Program reporting must roll-up to the PMO and PMO reporting must roll up to the enterprise. It is important for PMOs to be able to share information with other PMOs. For example, a project in one PMO may have a dependency on a project in another PMO.
P3M Engine introduces the answer to this dilemma with Layered Configurability.
P3M Engine serves an enterprise to any scale. An enterprise can have as many PMOs as needed, each PMO can run as many programs as needed, and each program can have as many projects as needed. They all reside in a single instance of P3M Engine, enabling robust cross-PMO communications and reporting rolling up to the enterprise.
Each PMO and program can configure independently. In P3M Engine, configuration defines your processes. You start by defining and configuring the processes for your enterprise. The enterprise can then permit PMOs to configure some, or all, of their processes. This enables the enterprise to enforce process where needed and allow differentiation where needed. Likewise, a PMO can permit programs to define their processes. The enterprise and PMOs define their processes through an Administrative function. Programs define their processes in their Program Management Plan. What the program is permitted to change, by the PMO, will be enabled in their Program Management Plan. What they are not permitted to change will appear, as information, but is disabled.
Through Layered Configurability, each layer of your program
and project management organization (enterprise, PMO, programs) can configure
their processes as needed and manage the capability of the layer below to
configure their processes. This will
provide the tailored processes wanted by each PMO and program while giving each
PMO and the enterprise the consistency needed to facilitate good communication
and upward reporting and analytics.
See more at http://www.p3mengine.com.










