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.

Solving the Projects Problem with Sanjeev Gupta #TOCICO18

Sanjeev Gupta of Realization gave the opening keynote on the second day of TOCICO. The talk was billed as "The Rising Importance of TOC" but ended up becoming "Solving the Projects Problem: It's not about buffers or behaviors" based on his experience with years and years of CCPM software and implementations.

The biggest surprise coming out of the talk is Sanjeev's suggestion to change the focus in projects to "focus and finish" workstreams. The focus in execution changes to ensuring the team has everything they need to get the work done with as high quality as possible.

No buffers? No emphasis on reducing bad multitasking? Yikes!

So, what is the problem with the way CCPM is typically implemented?  

It’s not surprising that projects are late. It’s surprising they finish at all.
— Sanjeev Gupta

In general projects are barely managed chaos. Sure, CCPM adds some control to the chaos, but there is still a lot of swirl. I've heard some of these comments previously, but there are a number of aspects in the way CCPM is introduced that can be seen as very negative - particularly for the people who have been doing their best at running projects. Done the wrong way, the conversations about task estimate safety, student syndrome, Parkinsons Law can make it sound like people are lazy or worse. Sanjeev joked that this is music to management's ears as they already believe their people are lazy. (But then maybe the problem in organizations like this isn't the project execution environment.)  On top of all that, from Sanjeev's perspective the successes seen in the community have been nice, but they haven't been big enough or extensive enough. (We come back to this with Alan Barnard's conversation at lunchtime.) 

The direction of the solution that Sanjeev proposes is to move to describing projects in a two-tier model. The top tier describes key elements of the flow of work and is the responsibility of a team of people, rather than an individual contributor. The activities of individuals are added in the 2nd tier as "subtasks" that are managed by the team. All project reporting is managed at the 1st tier. It greatly simplifies the project network and, when done right, can much more clearly describe the flow of work in a project. I think there can be a lot of merit in describing projects this way, but I haven't done it myself and I have some concerns with how it works in practice. (Realization have a number of customers doing this.) It seems to me there is still some expertise in building project plans this way, given the examples I have heard of simplifying complicated networks to significantly fewer tasks.

Sanjeev brought up Baltazar Martinez to talk about how he applied the concepts of "focus and finish" to his landscaping business.  He moved from having 20-30 open jobs to just a few, where the team knows exactly what the flow is expected to be and the jobs get done in 1/2 the time (and faster) than what had been happening. This means better cash flow, less chaos and more time to plan the next stages for his company.

Finally, what does this concept of Focus and Finish imply for the organization.  It changes a lot of aspects. (It wasn't clear if these are requirements for it to work or natural results of using this way of working.) Organizations need to think about how they organize their resources, changing from functional or business line to being organized around the teams the generate the workflow. This might be like Agile Software Development arranging in dedicated teams. Meeting structure changes from coordination of resources to focusing on the flow of work (as should happen in any TOC / CCPM implementation). Measurements change to focus on the on time delivery of the focus and finish workstreams, rather than on individual tasks. Interestingly, this implies that if each F&F task completes on time, there is still hidden capacity. Otherwise, delays pass down the chain (and gains rarely materialize). And transactional systems become useful again, as they can feed the details of the subtasks.

From Sanjeev Gupta's perspective, we make TOC too complicated. A breakthrough solution is the one that when you start using, it creates change in the organziation. 

Enterprise Architecture and TOC #TOCICO18

Engineering Reality at WiseTech Global #TOCICO18