Informal, Subconscious PDSA Experimentation

"Informal" PDSA is basically how babies and kids learn.  They don't formalize the theory they are testing but their brain is doing it for them.  If they touch the hot stove they learn hey touching that hurts.  Most brains figure out hot feeling gets super hot if I touch what appears to be the source (even without a helicopter parent telling them).  I don't want to be hurt again.  Don't touch that hot thing.  A bit old they connect the stove place as likely to be hot...  Sometimes they are a bit lame and they fail to make the connections until they get burned a couple times.

Same thing with say putting food into their mouth.  They try various ways of doing so with various levels of success.  Eventually they find good ones.  As kids get a bit older they have to modify the most effective ways of getting food to their mouth to make sure the big huge person sitting next to them doesn't stop them (factoring in "manners" as part of what is needed not just efficiency).

Kids really are amazing at doing "informal PDSA."  But their are ways to get even better by realizing what you are testing consciously.  Especially as systems get complex relying on your brain decoding everything behind the scenes (doing its own subconscious pdsa) gets less reliable.

Response to: PDCA – So Simple, It’s Child’s Play

Related: Encouraging Curiosity in Kids - Experience Teaches Nothing Without Theory - Keys to the Effective Use of the PDSA Improvement Cycle

Look First to Improve Your Performance and That of Your Sphere of Control

Improving the State of your Testing Team: Part One – Values

Typically, the first thing out of my test teams mouths when asked “how can we improve the state of testing here”, usually relates to something that other people should do. Very few people or teams take an introspective based approach to improvement, or state their management values, but the ones that do, typically have great success.
...
Being accountable for taking ownership of getting things done – upwards and downwards – is what people expect out of their leaders, and will move the test team higher up the value chain.

Several of the points resonate with me. The idea that so many find it easy to see how others should improve performance but seem surprised they should consider changes themselves is common. I also find the understanding that we run into many problems based on what we think we know (but isn't so) as important and something many people miss. This idea holds true for teams also: look to what we are a group can do to improve not just all sorts of changes other people should make to stop causing the problems we experience today.

In Dr. Deming's management view the second point is explored as part of the theory of knowledge.

People do have to be responsible. I worry about "accountability" because so often it is managers designing and enforcing bad management practices which make good performance difficult and then use "accountability" to blame those in the system for the results of the system.

"the aim of leadership is not merely to find and record failures of men, but to remove the causes of failure: to help people to do a better job with less effort." Dr. Deming

Related: Sphere of control

Long History of Lean Thinking in Government

This is my comment from a closed access Linked In group.

It is good news that a government organization is adopting lean thinking ideas, but this kind of thing has been going on for decades. My father wrote a short section in Dr. Deming's Out of the Crisis on applying these ideas in the City of Madison (early 1980's). I was involved in the Public Sector Network (federal, state and local gov in 1990's) that group joined ASQ and is now the ASQ government division. I was involved with the Federal Quality Network 1990s (federal government effort). I worked in the Office of Secretary of Defense Quality Management Office 1996-2001. I created and maintain the Public Sector Continuous Improvement Site.

There have been many great efforts over the years. Sadly most fade away leaving behind the use of a few good tools and a bit better process thinking but that is about it. Executive comprehension of the better management methods seem to disappear quickly (the executives, in government [not all of them of course, some do great stuff], are also much more reluctant to embrace better management practices than others in the organization).

  Doing More with Less in the Public Sector, A Progress Report from Madison, Wisconsin, 1987.
  Transformation and Redesign at the White House Communications Agency by March Laree Jacques, 1999.

We have to expect more of our governments. Better management practices will provide more value at less costs - both of which are badly needed in the economy today.

Related: Managing Our Way to Economic Success Two Untapped Resources - Focus on the Work: Pick Improvement Projects that Really Help Your Agency's Operations - Using Quality to Develop an Internet Resource

Are Deming’s 14 Points Still Valid?

Are Deming’s 14 Points Still Valid?

Researchers and practitioners in quality management continue to honor Deming’s valuable contributions today, and in fact, my recent bibliometric analysis of the Quality Management Journal (to be published in the January 2013 edition) indicates that Out of the Crisis has been the most central and authoritative resource influencing quality management research over the past two decades. ... But are Deming’s 14 Points still valid in the post-2008 economic era, where vibrant growth and globalization can no longer be expected to dominate the global economy?

Yes they are still valid. On points:

  #1 - I think this is definitely still needed and much underdeveloped today.
  #2 - Dr. Deming's "new philosophy" framework presented a new view of his management system; he found 14 points failed to convey the systemic nature. The points are fine, but the new view he presented captured what is still the best management system I know of.
  #4 - I don't think size matters. Personal relationships are easier but also super fragile, that person leaves and your system is broken. Establishing a culture that supports suppliers is harder but much more robust.
  #11 - I do. Good book Free, Perfect and Now by Rodin. This is a big deal to lots of committed Deming folks. I agree those that just use some of Deming's ideas without the system or really thinking of him much don't pay much attention. Lots of software development folks realize this strongly (they lose respect for "suits" that think try to dangle goals and quotas in front of people). Related: the problems with targets or goals, The Trouble with Incentives: They Work by Gipsie Ranney.

People Leave Jobs When Frustrated with the Results of the Management System and Their Manager

So people join organisations, and leave Top Leaders!

I participated in a Twitter exchange following the CIPD’s report – along the lines of who is the biggest problem – rubbish leaders, managers, HRDs or organisations?  But thinking it through, I would go for the leaders – as they have so much influence over the approach their line managers take.
...
there are clearly a range of factors involved in exit decisions and an individual's line manager is certainly one of these. But I do agree with the researchers, and therefore disagree with Gallup, in that I believe it is the senior leadership which is increasingly the most important of these.

I think your focus on the nuance is where I would put my, granted non-expert, opinion.  I believe what you say about the big impact executives/leaders have in setting and maintaining the management system.  The direct boss I do think has a big impact.  But it is true that much of the direct boss' impact steams from the system - if they are not a good manager that is usually a system results.

It is rare that the organization does a great job of selecting and developing managers and your manager is lousy and you want to leave.  In broken systems (unfortunately many - which is why Dilbert connects with so many) often the direct supervisor becomes the focus of complaints but really they are largely at the mercy of the larger system.

Related: posts from my management blog on managing people - Practical Ways to Demonstrate Respect to Employees - Create a Climate for Joy in Work

The Right Culture Creates a Robust Management System That Delivers Over the Long Term

First, I don't agree with your claim on the only reason for companies to exist, I believe Deming had a better view (considering all the stakeholders).

But I do agree with the general premise: a "culture" isn't an aim.  The reason a culture matters is that it embodies a robust system that delivers the best results over the long term.  The problem of not having a good culture (but doing well today - reducing waste, gaining customers...) is that over and over we see these companies collapse.  The reason a "quality culture" matters is as a strategy to achieve an aim: long term success.

Comments on:  Quality Culture and Feelings
Related: Creating a Quality Culture - Posts on Creating a Management Culture

Rewards Don't Create the Employees You Want

Trying to motivate with carrots and sticks is a bad idea and should not be done.


"Motivation" is not something for a manager to give.  Often the organization saps employee's motivation so a manager can help by removing those bad practices.

Comments on:  The Rewards Edition
\ See more thoughts on managing motivation.

What is a Project Manager?

Response to What is a project manager?

Often PM role is to cope with weaknesses in the current management system.  While you might say just fixing the system is better I think that is often unrealistic.

I see the PM as someone shepherding the project which often means

  1) making sure the pieces proceed properly to meet deadlines (making sure they, or whoever should, make decisions on what to do if things need to be done).  I see the PM often making sure it happens but if the system has a good method that is working fine the PM just watches that.  So if there is good agile software development, the process is working and things are done in order no big surprises sitting around… then fine the PM doesn't have to worry.

   2) dealing with institutional issues so others can focus on doing their jobs.  If the software developers are frustrated with whatever phb action, the PM takes care of it somehow…  That kind of stuff.

   3) improving the system - again this is best done by setting up the system so others can.  This is a bit outside of the scope of the existing project.  The PM (to me) is also responsible for making the system for delivering projects good.  If something new is needed, look at putting it in place.  Develop people as part of this.  Again if management is doing their job this is happening.  Often management isn't though, then I think the PM should.  This is stepping a bit far from what most everyone else thinks though.

  4) coaching people and arranging coaching.  This is probably more for #3 than for meeting the current project needs, but it is also to meet the current project needs.

  5) protect people from blame and give people credit.  Again this is often just dealing with poor current management systems.  Blaming people is ineffective.  If there are failures figure out what is wrong with the system and improve.  When people are trying to blame others (which happens a lot) don't let that be done and instead focus the thoughts on how to improve.  In organizations where business managers run roughshod over others (developers, testers…) don't let them.  In that case communication goes through PM.  If the communication is good then it is better for the developers to communicate directly…

I see communication as part of #1.  It is important.  It becomes even more important as the organization fails at it.  That is often my view the PM is to see where there is weakness and deal with it.  Maybe it means getting more resources.  Maybe it is assuring better test coverage is included.  Maybe it means arguing this project needs to be scoped way down as it isn't a priority given the business needs…  This requires knowledge of the organization, business thinking, software development (for software projects) practices, coaching...

My whole way of think is very Deming based.  So I see improving the system as a big part of everyones role.  It isn't surprising I see it that way for a PM too.

To me the main PM roles are

 #1 manage the existing system to achieve the result for the project
 #2 improve the existing system