The difference between costly enterprise integration and dynamic interoperability is the ability to capture and maintain design patterns. Just as with patterns defining Cyber attack profiles, design patterns can be founded upon shared semantic foundations - thus we utilize the same solution premise for both the technical architecture and program management framework. The CCS practice methodology is based also upon shared program / project / portfolio management capabilities which allow us to standardize project solutions and performance.
The CCS Practice Methodology scales from smaller point solutions all the way up to Cross Domain endeavors. The methodology builds upon standardized processes but unlike paradigms such as CMMi, our approach is dynamic and tailored to domains and clients, allowing a greater degree of flexibility than most solution integrators. The CCS Methodology is designed to be Agile by being responsive. We understand that all of our work must be tied to tangible outcomes, sooner rather than later.
We refer to the program management portion of our methodology as Program Lifecycle Management (PLM).Program Lifecycle Management is the recognition that specialization is not the only or even the best answer towards managing complexity. Often times, an excessive focus on specializing specific areas of expertise merely adds to the level of complexity and confusion that typical PMOs face every day. The truth is that many if not most of the people who support PMOs need to be generalists to fully grasp the breadth of topics that they are expected to deal with. It is very difficult to get work done if a parade of experts is required to fulfill everyday tasks and worse yet if that parade constantly changes as the nature of the industry expertise rapidly evolves.
The key to PLM is understanding that the PMO runs on information. That information must be easily accessible, transportable, translatable and must be available directly to the decision makers without going through layers of expert interpretation first. This doesn’t mean that other folks don’t add value to the information, there will always be a need for diverse skills in the PMO, however it means that EVM analyst is no longer primary interpreter of financial data and that the requirements analyst is not the only person who can produce requirements reports. The reality is that no how many specializations are created, the core processes are still all related within specific contexts. Those contexts then allow us to provide a holistic view of what’s happening in the PMO and more importantly illustrate why it is happening.
All methodologies benefit from standardized processes, however when process becomes too rigid it may prove counter-productive
