I attended a number of talks on CCPM today at TOCICO, as that is work I am doing these days. And these weren't even all the material that was available on CCPM. There were also some interesting hallway conversations.
David Brown-Brulant talked about extending CCPM with concepts from Lean and Six Sigma. He talked in particular about implementing in a high uncertainty environment like R&D, where the projects themselves aren't guaranteed to deliver the hoped-for result. In these cases one needs to extend the standard CCPM work to include better mechanisms to kill projects that aren't getting to where one would like. The big challenge is always the "one more experiment" mindset. I've also liked other suggestions around developing "killer experiments" that should be done early on in these environments.
Kaoru Watanabe of Hitachi talked about a user-centric design methodology they had developed within their CCPM practice that has helped them develop applications that better meet the needs of their users. In particular, they describe the use case from the perspective of the "flow of desirable effects" - pulling on two threads that are familiar in the TOC community: Flow and Desired Effects.
Chizuru Soejima of NTT Data talked about their enterprise-wide implementation of CCPM. She focused on the mechanisms they created for promoting and supporting CCPM within the organization, but I found most interesting the fact that CCPM project execution is one of the 8 engines of growth for NTT Data that they have acknowledged in their annual reports.
Duncan Patrick and Jack Warchalowski of CMS Montera presented a last-minute replacement on the schedule on a challenging topic: the hidden costs of CCPM - "too big to change". They talked about the issue that public companies which make their money selling projects have to report their financials on a regular basis - and those financials must include actual and expected revenues from projects: revenue recognition and revenue forecasting. This includes reporting the "cost" associated with people allocated to projects. Cost allocations and forecasting is normally an anathema to TOC professionals, but it appears to be a reality. Complicating this reporting in a CCPM environment is the idea that CCPM seeks to shift from scheduling people to scheduling tasks and then executing those tasks as quickly as possible. That's great from a project execution perspective, but from the finance perspective the calculations still need to know how much effort was expended by which people over a given time period. They don't have a specific solution, but they hinted at a few. I prefer the one that relates to the other part of the current reality: most "project management" software that does financial reporting isn't used for project execution - let's keep it that way.
The day closed with Sanjeev Gupta of Realization talking about a high level recommendation to combine CCPM and Kanban in order to deal with the situation I have seen in many project environments where there are activities that must be completed, but they have no a priori interdependencies. Simplify the project network to represent the 20 percent of the work that is truly sequentially linked, and put the remainder of the work into a "task list" and have the work owners manage the work in a Kanban mechanism. This has been done by many people in the CCPM community, and Gupta wanted to acknowledge that it is a valid way to operate.