This website covers knowledge management, personal effectiveness, theory of constraints, amongst other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

How could CCPM be improved? #TOCICO

The second half of the day today (Sunday) was devoted to breakout sessions on each of the TOC application areas. The stated goal was on having people familiar with these applications discuss opportunities for improvement.  I decided to sit in on the projects (CCPM) discussion, as that is where I have the most current experience.  (I was tempted to sit in on the Thinking Processes, because that is an area where I would like to learn the most.)

The session started with an overview of the areas where CCPM has been applied, which is in many, many areas from projects WITHIN a business, projects AS the business, maintenance & repair, new product development, and infrastructure development.  These might be single project, multiple-single project or full multi-project implementations.  While each of these environments have differences, there do not appear to be material differences in how CCPM applies and helps improve the environments.  They all value improved speed of completing projects in some way. 

The challenge for the participants was to come up with situations and environments where CCPM does not work as well.  Or maybe where "plan vanilla" CCPM needs to be tweaked and modified to enable success.  The group came up with a list of about 20 ideas and whittled those down to five for further assessment. (see lists below)  We were then asked to look for the key difference or key issue in the selected areas that calls out for improvements to the baseline solution.

I picked the group that discussed new product development where there is the potential for never-ending iterations in the search for the perfect answer.  There are a lot of pieces to this discussion, such as the role of research from the perspective of management or the perspective of the researcher, or how to manage a backlog of potential research while other research continues. One direction for the researcher-manager conflict is to look for injections that will support the researcher and provide a happy result for the manager.  For example, we suggested that more up-front planning work is needed to create the killer experiments.  As part of that, the organization may need to change its measures around scientific prestige to include not only scientific publications of "successes" but also the design of excellent killer experiments. We also suggested there needs to be a better discussion of "kill criteria" in the Full Kit setup for projects, so that the designers of those killer experiments know where to aim.  

On the managing work side of things, we talked about looking for mechanisms to help the researchers to NOT multitask across multiple projects.  This has to be more than simply telling them to not do it or setting WIP limits.  We thought we wanted to create a reason for the scientists to want to do things differently.  One idea was to have a primary project, and then when there was downtime that the person could become an advisor on other projects with their colleagues.  This would keep them engaged and have the happy coincidence of helping other projects that might be struggling with a tricky experiment or looking for good experimental design.  

I enjoyed the discussion.  I would like to spend another day diving into these issues in conversation with people.  Facilitation definitely helps.  The next stage to this discussion is to take these half-baked ideas and conduct a deeper analysis and see if there is something truly new here.  

Appendix - Additional notes from the breakout:

General areas and concerns that I have in CCPM implementations. I came up with a list of items or areas of concern for CCPM implementations.  Some of these were discussed, and many are for another day:

  • non-project work
  • too-large batches as projects (an ongoing question I have: Are the fact of projects a symptom of a larger problem?)
  • iterative delivery of projects or project elements (instead of everything at the end)
  • visualization of the work
  • nature of knowledge work (it is hidden until the output is finalized)
  • collaboration within projects
  • do projects work in isolation of the rest of the business?
  • environments where projects aren't the constraint of the larger system
  • CCPM is "too big a change"
  • level of detail within plans (too much detail; not enough detail)

Here are the items that came up in the breakout session as possible areas where CCPM doesn't directly apply.  From these we broke down into five groups and discussed further.  Unfortunately, the results of each group were not discussed collectively.  There is a possibility that this will come back at the end of the conference.

  • New product development
  • R&D project selection
  • Shut downs: triangle
  • Project + Non-Project Work
  • Customer-depenent engineering
  • Choking the release intuition
  • R&D and iterations
  • Start-ups
  • Long-duration procurement
  • Environment is changing underneath you
  • Engineering procurement contracting
  • Multi-project w/o dependencies
  • Sales & Marketing projects
  • Lack control over actual duration
  • High share of Fixed Lead Time
  • external supplier eats / consumes buffer
  • short duration tasks
  • man-hour contracts
  • how to connect shortened cycle-time contract incentive to suppliers
  • The Cost element

Management Attention - is it a constraint? #TOCICO

Day 1 of #TOCICO conference