3 ms·

I feel like I'm lacking imagination - the "act" sounds a lot like the "plan' to me. Surely you apply the things you've learned by making the next plan?

taeric 4y ago
My take is that many get stuck in rapid cycles between "Plan and Do". Without taking the time to actually study the results to build plans based on what you find, you are likely not understanding why you are succeeding or failing. That is, even if you are currently succeeding, if you are stuck in too rapid of a "plan and do" cycle, you are likely to get blind sided by what you aren't learning.
Jtsummers 4y ago
Loops like PDCA/PDSA aren't necessarily tight loops, where you immediately jump into the next. Since the objective is process/quality/whatever improvement the Plan phase is defining a plan to improve the process (sticking with that one). The Do phase is enacting the plan. The Study phase is studying the effect and learning. The Act phase is the continuation of the plan (if successful) or perhaps a rollback if not. Then, at some point, you start another loop (ideally this becomes continuous, but most orgs and teams aren't ready for that I've found). But again, continuous doesn't mean tight. As a hypothetical, you get hired into a team that doesn't use version control (me 12 years ago, fortunately they already knew it was dumb and were fixing it). So you decide to introduce git. There are a dozen codebases and 30+ people on this system. So you start with one codebase and a coupe motivated individuals, you create a Plan. You plan to use gitlab or whatever and see if you can work out kinks (like merge conflicts that they never know about until testing because "merge" is "copy files into the same directory, keep the newest"). Then you Do the plan, you and the motivated individuals try it out for a cycle (whatever that means in this team). Then you study it, see if you had fewer issues, delivered faster, higher quality, fewer erroneous "merges" (probably none now). Then you Act, you roll out this process to the rest of the team and codebases. And if your team is ready for it, you repeat this method over and over to reach continuous process improvement, tackling different aspects of the process and system that are causing problems.

taeric 4y ago

My take is that many get stuck in rapid cycles between "Plan and Do". Without taking the time to actually study the results to build plans based on what you find, you are likely not understanding why you are succeeding or failing. That is, even if you are currently succeeding, if you are stuck in too rapid of a "plan and do" cycle, you are likely to get blind sided by what you aren't learning.

Jtsummers 4y ago

Loops like PDCA/PDSA aren't necessarily tight loops, where you immediately jump into the next. Since the objective is process/quality/whatever improvement the Plan phase is defining a plan to improve the process (sticking with that one). The Do phase is enacting the plan. The Study phase is studying the effect and learning. The Act phase is the continuation of the plan (if successful) or perhaps a rollback if not. Then, at some point, you start another loop (ideally this becomes continuous, but most orgs and teams aren't ready for that I've found). But again, continuous doesn't mean tight. As a hypothetical, you get hired into a team that doesn't use version control (me 12 years ago, fortunately they already knew it was dumb and were fixing it). So you decide to introduce git. There are a dozen codebases and 30+ people on this system. So you start with one codebase and a coupe motivated individuals, you create a Plan. You plan to use gitlab or whatever and see if you can work out kinks (like merge conflicts that they never know about until testing because "merge" is "copy files into the same directory, keep the newest"). Then you Do the plan, you and the motivated individuals try it out for a cycle (whatever that means in this team). Then you study it, see if you had fewer issues, delivered faster, higher quality, fewer erroneous "merges" (probably none now). Then you Act, you roll out this process to the rest of the team and codebases. And if your team is ready for it, you repeat this method over and over to reach continuous process improvement, tackling different aspects of the process and system that are causing problems.