Posts about Process improvement
agile management blogs Books Career Carnival commentary continual improvement Creativity curiouscat Customer focus customer service Data Deming Economics engineering executive pay Google Health care Innovation internet Investing IT Japan John Hunter leadership lean manufacturing Lean thinking management managing people Manufacturing motivation Performance Appraisal Process improvement Psychology Quality tools quote respect for people Six sigma Software Development Statistics Systems thinking tips Toyota Toyota Production System (TPS) webcast
Full tag cloud

Delighting Customers

Posted on July 26, 2010  Comments (1)

If you have customers that see you as adequate you will keep customers based on inertia.

But you have several big problems awaiting you. Those trying to win your customers business only have to overcome inertia – which can be very low hurdle (saving a small bit of money, some minor additional feature). If your customers are delighted they won’t leave (by and large) without significant reasons to.

Also your attempts to increase price are very likely to lead to increased customer losses (than if customers are delighted). Delighted customers are willing to pay a premium which helps profits enormously (Apple has done this quite well).

Delighted customers will refer others to you – great free marketing.

Satisfied customers leave you very little leeway for error. If you cause satisfied customers some problem (which granted, hopefully you won’t but if you do) they are not likely to be forgiving. If they are delighted they may well stay even if you have a delay, provide less than stellar customer service for some request…

There are many ways to attempt to delight customers. One of the simplest powerful tools is to ask a very simple question: What Could we do Better?

Related: What Job Does Your Product Do? – It Just Works – Kano Model of customer satisfaction – customer focus resources

The Problem is Likely Not the Person Pointing Out The Problem

Posted on July 19, 2010  Comments (2)

I believe the problem is likely not the person pointing out the problem. Now granted I have often been that person. Part of what I have been tasked with doing in various jobs is finding ways to improve the performance of the organization. I was told the managers wanted to hear about problems from someone working there, so I was asked to do so. What it often meant was they wanted someone to fix the problems they thought existed not point out the problem was the systems, not the people forced to deal with the systems.

I have learned managers are a lot happier if I just shut up about all the problems that should be addressed. There are happy if I can fix what I can (though really they seem to care much more about not being negative than any actually improving) and just be quiet about anything else – otherwise you are seen as “negative.”

How to Manage Whining with no Problem Solving

As individuals begin to focus on the negative and don’t engage in problem solving, this behavior is unacceptable
…
The first time, it is a venting and commonly a subject matter problem. The next time we have a trend occurring, and this is where we need to coach our team player to be constructive process improvement artists. If the whining continues, we may be dealing with a negative attitude which has begun to permeate our colleague.
…
explore the previous solution’s outcomes; help the individual to be empowered to resolve the issue. If it is absolutely above the teammate authority, offer to help and commit to actions.

I think it is right to focus the effort on problem solving to improve the situation. I fear that far too often though “As individuals begin to focus on the negative and don’t engage in problem solving, this behavior is unacceptable.” turns into ignore problems. Yes, I know that isn’t what the post is suggesting. I am just saying that the easy “solution” that is taken far too often is to focus on the words “negative” and “unacceptable.”

I believe the focus should be on “broken systems are unacceptable.” I would prefer problem solving to address the issues but a culture of ignoring issues and seeing those that don’t as being negative is often the real problem (not the person that points out the problems).

I have discussed this topic in some posts previously: Ignoring Unpleasant Truths is Often Encouraged and Bring Me Problems, and Solutions if You Have Them. Once I am given those problems I agree with you completely. Use them as an opportunity to coach effective problem solving and process improvement strategies to improve the situation. And to develop people.

Often the problem is not the person at all. The organization never adopts fixes. People have learned that they can bang their head against the wall and then never get approval for the fix or they can just whine. Blaming them for choosing whining is not useful. I don’t see how Asking 5 whys you get to blaming the employee, except in very rare cases for not problem solving. It seems to me the issue is almost always going to lay with management: for why people are frustrated with system results and are not problem solving.
Continue reading →

Involve IT Staff in Business Process Improvement

Posted on July 6, 2010  Comments (5)

I started out basically working on management improvement from the start of my career. My makeup (I am never satisfied and figure things should always be better) along with a few traits, experiences and probably even genes made this a natural fit for me. I tend to take the long view and find fire fighting a waste of time. Why fix some symptom, I want to fix the system so that problem doesn’t happen again. My father worked in statistics, engineering and business improvement and as I was growing up I had plenty of experience with process improvement, understanding variation, experimenting, measuring results…

I came into the IT world as I had needs and found the best solution was to write some software to help me accomplish what I wanted to. One thing that better software tools allowed is this type of thing when organizations failed to use technology well, individuals could just do so themselves. Without these tools people had to rely on the organization, but today atrophied IT organizations can often be circumvented. Though the IT organizations often try to avoid this largely by bans (instead of by providing the tools people need), which is not a good sign, in my opinion.

I then spent more and more of my time working with technology but I always retained my focus on improving the management of the organization, with technology playing a supporting role in that effort. That is true even as where I sat changed. And I have become more convinced organizations would be served well by using the information technology staff as business process experts.

At one point I sat in the Office of Secretary of Defense, Quality Management Office where I was able to focus on management improvement and using technology to aid that effort. Then I went to the White House Military Office, Customer Support and Organizational Development office and focused largely on how to using technology to meet the mission. Then I was moved into the White House Military Office, Office of Information Technology Management.

And now I work for the American Society for Engineering Education in the Information Technology department. My role started as partially program management and partially software development and as we have grown and hired more software developers I am now nearly completely a program manager.

I believe technology is a central component of understanding business processes today. But the truth is, many business people don’t have as complete an understanding as I feel they should. Now I believe, most anyone interested in planning their management career needs to develop a facility with technology and specifically how to use software applications to improve performance. You don’t need to be an expert programmer but you need to understand the strengths, weakness, limits of technical solutions. You need to understand how technology can be used (and the risks of options).

At the same time I just don’t think it is likely management everywhere will get a decent understanding of application software development. I also believe that in many cases organizations should do software development in house. This is a issue that certainly can be argued (but I won’t do it here). Basically I don’t think organizations should cram their processes into designs required by off the shelf software. Instead I believe they should design processes optimal for their organization and using off the shelf software often does the opposite (forces the process decisions around what software someone decided to buy). There is plenty of use for off the shelf software that doesn’t force you to make your processes fit into them (and sometimes even if it does that is the business decision that has to be made – I just think far too often organizations look at short term costs and not the overall best solutions for the system).
Continue reading →

Trust Your Staff to Make Decisions

Posted on June 22, 2010  Comments (5)

The failure to give your organization the flexibility to serve customers is a big mistake. Many companies make this mistake. Often the basic problem is managers don’t trust that their systems to hire and develop people that will make good decisions. The solution to this problem is not to give your staff no authority. The solution is to manage your systems so that you can trust your people. This is not as easy to do as it is to say, I will grant that.

Southwest Airlines and Zappos are companies that do respect employees. And those employees then provide great service. But it isn’t a simple thing. To truly manage a system with respect for people isn’t as easy as just putting up some slogans. But if you want to provide good customer service this is one requirement. There are plenty of others: continual improvement, evidence based management, customer focus, systems thinking…

These thoughts were prompted by a nice post, jetBlue Just Blew It

You see, when I booked my flight last night I used their online system (good) and made a mistake in booking the date for my return (bad). I’m going to Boston for the weekend and accidently booked by return flight a month later in August instead of the 4 days I was looking for.

Of course their site has a lot of bookings and almost no one makes an error like this. But any UI designer who looks at their site could see that it’s absolutly possible since the length of the trip is never revealed except for the flight dates. (I”m arguing that they could put in a little fading header that tells you how long your trip is for.) If’ I’d see anywhere that my trip was scheduled for 35 days I’d have immediately know there was an issue. (I could make a simple change to the jetBlue UI that would solve this problem for everyone within a day.)

Today when I looked at my emailed itinerary I immediately spotted the problem and went online to change my ticket. They have a $100 change fee which I paid thinking I’d give them a call and that surely they’d waive that. After all, it wasn’t a change I was asking for, it was the ticket I wanted in the first place. It was less than 24 hours and the flight wasn’t for a month.

But no.

In speaking to the customer service rep who ‘called’ a manager. I was informed that I had only a 4 hour window to make any changes and that after that, there was nothing anyone could do. You see, no one at jetBlue customer service has the ‘authority’ to refuse this fee. It was company policy that they couldn’t actually do anything.

Continue reading →

Mistake Proofing Deployment of Software Code

Posted on May 19, 2010  Comments (1)

This is a continuation of my previous post: Improving Software Development with Automated Tests. Lets look at a typical poka-yoke example. A USB connector must be put in the right way up – for the connection to work properly and the communication to occur as intended. So to mistake proof the process the connector won’t allow the USB device to be put in upside down – the hardware connection designed to not allow that type of connection.

Using a deployment process that prevents code from being submitted that has an error follows a nearly identical process. The process blocks an error from being made. It seems to me a process that blocks code with a bug from being deployed with an error is the basically the same as a USB connection that will not accept the device being put in upside down.

Mistake proofing in no way should limit focusing on improving the process. Mistake-proofing a process both improves it (many poka-yoke solutions make the process easier to use) and prevents an error in case you still try something wrong. So I see the automated tests as a way to serve as a backstop, in case the process improvement you made to the software development process failed in some form. Then the automated testing required to deploy would prevent the introduction of that error to the production environment.

Related: Checklists in Software Development – Baking in Quality to Software Development – Combinatorial Testing for Software Development – Great Visual Instruction Example

Ignoring Unpleasant Truths is Often Encouraged

Posted on May 4, 2010  Comments (4)

We can’t Handle the Truth

Unfortunately, the proverbial “kill the messenger” is alive and well in American business. People who speak the truth are often labeled as a non-team player, a disrupter, a trouble maker or the current tag of being “not a good fit”.
…
It doesn’t take much to see that the truth can get watered down, altered or hidden entirely inside a company, especially as it moves vertically up the ladder. We may believe, at least in the short term, that this is the best way considering the risk, political correctness and social politeness but at what cost?

What I have seen is truth is not valued much. I’m interested in creating improvement. I thought people would be driven by data and possible strategies to improve. But I have found that just isn’t often true.

So, from my experience, the strategy to improve means not distracting people with many of the truths. Try to fix the system and convince others to fix the system as you can. If some efforts are resisted try to adjust. Sometimes try a different strategy to get improvement. Sometimes I just drop trying to improve that particular thing. There are usually so many options for improvement it isn’t tough to find plenty of others that may be more successfully tackled.

I am someone who find it frustrating that many don’t seem interested in really understanding what the system is producing and where weaknesses exist. But, at least for me, trying to have things work the way I want (where an open exploration of the truth was the focus) isn’t the priority. I have figured it is better to give up on that desire and work within the reality that exists.

I can’t stop myself though from pointing out things far more often than people want. I have no doubt it has annoyed people and gotten me in trouble. But nothing that wasn’t manageable, I just make things a bit more difficult for myself.

One, very visible, sign of people avoiding the truth is if people say very different things in meetings and out of them. It is amazing to me how much less likely anything that could be sen as a complaint or criticism to be voiced in a meeting versus in the hallway. It isn’t so surprising if you understand human psychology (the tendency to blame those who voice a problem). People figure this out and keep their mouth shut. But to their friends they understand they can point out the problems and not be blamed (so in the hallways, you get a much more honest understanding of what people think). This is a bad sign. If your organization trains people to ignore unpleasant truths it makes managing more difficult and results in poorer performance.

Related: The difference between respect and disrespect is not avoiding avoiding criticism – Information Technology and Business Process Support – How to Improve – Find the Root Cause Instead of the Person to Blame – Information Technology and Management – Respect for People, Understanding Psychology – Bring Me Problems, and Solutions if You Have Them – Better Meetings – People are Our Most Important Asset

Nice Non-techinical Control Chart Webcast

Posted on April 28, 2010  Comments (0)

This very brief introduction to control charts by PQ Systems provides a very watchable non-technical overview. Getting people to understand variation is important, and not easy. This video is one more quick reminder for those still trying to incorporate an understanding of variation into their view of the world.

The idea is simple. But actually thinking with an understanding of variation people find difficult, it seems to me. It is very easy to continue to revert to special cause thinking (who did it? is often a sign of special cause thinking) – thinking that results are due to a special (unique) cause, instead of as the result of a system (which includes lots of common causes).

The value I see in this video is as a reminder for all those trying to operate with an understanding of variation. It is also a decent introduction, but much, much more would be needed to get people to understand why this matters and what is needed.

Related: Control Charts in Health Care – How to Create a Control Chart for Seasonal or Trending Data – Measurement and Data Collection – Six Sigma and Common Sense – European Blackout, not Human Error

Improving Software Development with Automated Tests

Posted on March 8, 2010  Comments (7)

Automated software testing is a mistake proofing (poka-yoke) solution for software development.

The way automated testing works is that software code is written that tests the software code of the application. This automated testing code test that business rules are correctly being followed by the code in the application.

So for example, a user should not be able to create a new account without entering password. Then you create code that does not allow an account to be created without a password. And you write a test that passes if this is true and fails if it is false.

The best implementation will then not allow deploying code to your production environment until the code has passed all the automated tests. So if a software developer changes the code, the automated tests are all run and if there is an error noted by the automated testing the code cannot be deployed to the production environment. So, in the example above, if somehow the changes made to the application code somehow now let an account be created without a password the test would fail, and the developer would know to fix the problem before putting the code into production.

Thus automated testing mistake proofs the process. Now the mistake proofing is only as good as the test that are added. Software development is complex and if the code has an error (based on the business rules) that is not tested then the code can be deployed to production and affect customers. But it is a huge help in preventing many errors from affecting customers.

It seems pretty obvious but until the widespread adoption of agile software development techniques and frameworks that make it easy to adopt automated testing (like Ruby on Rails) this sensible process improvement tool was used far less often than you would think.

Related: Combinatorial Testing for Software – Metrics and Software Development – Checklists in Software Development – Google testing blog – Hexawise software testing blog

Video Overview of the PDSA Cycle

Posted on December 20, 2009  Comments (2)

Robert Lloyd, PhD From the IHI Open School‘s, presents a nice overview of the PDSA Cycle (plan-do-study-act). The webcast includes an example of using PDSA to improve the discharge process for a hospital.

As I have said many times the keys to success are to turn the PDSA cycle rapidly, predict the results in advance, and analyze the results to continually improve. the Improvement Handbook is an excellent resource.

The IHI Open School is a great resource and exactly the type of thing organizations with a mission to improve performance should be doing. Provide resources online that are easy for people to access and then apply in their organization. See more management webcasts.

Related: Tom Nolan on PDSA – Saving Lives: US Health Care Improvement – 5 Million Lives Campaign

Making Better Decisions

Posted on November 24, 2009  Comments (3)

I think the most important thing you can do to make better decisions is to learn from the decisions you make. It sounds easy, but very few people do so effectively.

The best strategy to learn from decisions is to:

Lean Inventories Do Not Excuse Failing to Deliver

Posted on November 20, 2009  Comments (2)

Low inventory levels do not mean failing to have products available for customers. Now, if you manufacturing in huge batches and can’t respond to customer feedback then it might mean failure to predict customer demand does mean failure to deliver. But lean thinking has shown how to avoid this problem. People need to adopt lean manufacturing practices and gain the benefits of low inventory levels without the costs of failing to deliver what customers want.

Sorry Santa, We’re Out of Stock

The “it” gifts this year could swiftly vanish from store shelves, as retailers, with nightmares of Christmas 2008 markdowns dancing in their heads, have slashed inventories to some of the leanest levels in recent memory.
…
Retailers themselves are battle-scarred by last year’s fourth-quarter fiasco. Following the financial meltdown of September 2008 and amid the most severe economic crisis since The Great Depression, consumers retrenched.

That’s when stores hit the markdown panic button, slashing prices upwards of 75 percent. The result was the worst holiday selling season since 1970, according to The International Council of Shopping Centers.

But although leaner inventory levels should drive profit margin gains this holiday, “retailers might not have enough inventory to fully satisfy demand,” said Citigroup retail analyst Deborah Weinswig, in a research note. It is a risk they are willing to take.

“They would rather lose a sale than take the markdowns they had last year,” said Goldman Sachs analyst Adrianne Shapira.

The retailers need to design their systems with lean thinking in mind (not lean – as in cut expenses without thought). And they need to work with suppliers using lean manufacturing principles.

Related: Be Thankful for Lean Thinking – Guess What? Manufacturing in the USA is a Good Idea – Tesco: Lean Provision – Zara Thrives by Ignoring Conventional Wisdom – Operational Excellence – lean manufacturing articles

If Your Staff Doesn’t Bring You Problems That is a Bad Sign

Posted on June 15, 2009  Comments (5)

The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help them or concluded that you do not care. Either case is a failure of leadership.

        – Colin Powell

I discussed my feelings on this in a previous post, Bring Me Problems:

If an employee never learns how to find possible solutions themselves that is not a good sign. But it is much, much better to bring problems to managements attention than to fail to do so because they know the manager thinks that doing so is weak. It is the attitude that problems are not to be shared that is weak, in my opinion.

Related: Where to Start Improvement – Stop Demotivating Me! – How to Improve – Leadership quotes

“Having no problems is the biggest problem of all.” – Taiichi Ohno

Why Setting Goals can Backfire

Posted on April 27, 2009  Comments (2)

Dr. Deming long ago stated in his 14 obligations of management: “Eliminate numerical goals, numerical quotas and management by objectives.” I think he was right then, and is right now. A goal can help set the scope of the effort. If you are aiming for 2% improvement different strategies may make sense than if you are aiming at 50% improvement. But that type of use is rare. The problem with goals is what actually happens in organizations. They create serious systemic problems and should be avoided (other than in setting the scope). They are deeply ingrained in the way many people think, but we would be better if we could eliminate the use of goals, as they are used now (mainly as arbitrary numerical goals).

Ready, Aim … Fail, Why setting goals can backfire

In clawing toward its number, GM offered deep discounts and no-interest car loans. The energy and time that might have been applied to the longer-term problem of designing better cars went instead toward selling more of its generally unloved vehicles. As a result, GM was less prepared for the future, and made less money on the cars it did sell. In other words, the world’s largest car company – a title it lost to Toyota last year – fell victim to a goal.
…
Rather than reflexively relying on goals, argues Max Bazerman, a Harvard Business School professor and the fourth coauthor of “Goals Gone Wild,” we might also be better off creating workplaces and schools that foster our own inherent interest in the work. “There are lots of organizations where people want to do well, and they don’t need those goals,” he says. Bazerman and others hold up Google as an example of a company that manages to do this, in part by explicitly setting aside time for employees to pursue their own projects and interests.

Today, as the economic situation upends millions of lives, it is also forcing the reexamination of millions of goals – not only the revenue targets of battered firms, but the career aims of workers and students, and even the ambitions of the newly installed administration. And while it never feels good to give up on a goal, it may be a good time to ask which of the goals we had set for ourselves were things we really needed to achieve, and which were things we only thought we should – and what the difference has been costing us.

Related: Measuring and Managing Performance in Organizations – Arbitrary Rules Don’t Work – The Defect Black Market – Goals can Distract from Improvement – Be Careful What You Measure

More Management Blog Posts From January 2006

Posted on April 25, 2009  Comments (1)

energy chart

  • Great Charts – The lack of such effective visual display of information is another example of how much improvement could be made just by applying ideas that are already published.
  • Change is not Improvement – if you have to document how you will know the change is successful it makes it more difficult to change for just the appearance of improvement.
  • Management Excellence – Most management practices cannot be plugged into any organization and work well. That practice must be applied in a sensible way given the organizational system.
  • China now the 5th Largest Economy – China’s economy grew 9.9 percent in 2005, overtaking France as the world’s fifth largest, powered by exports and investment in factories, roads and power plants.
  • Zero Defects – eliminating defects that get to customers (and even those that don’t) is wise. But doing should be as the result of continually improving your processes. I do not believe you succeed by declaring your goal to be zero defects. You succeed by creating a culture of never ending improvement, of customer focus, of fact based decision making, of learning…

Checklists in Software Development

Posted on April 7, 2009  Comments (2)

Verify your work with checklists

WHO has recently shown that surgical deaths can be reduced by a third when hospitals follow their Surgical Safety Checklist. The checklist is very low tech. It includes questions like whether the patient has been properly identified, whether the proper tools are available, and whether everyone knows what kind of procedure is about to be done.

If a checklist so simple can save so many lives, I thought the technique could surely help us do better as well. So after reading about this study and their checklist, I’ve been pushing us to create checklists for all the common procedures at 37signals.

We now have checklists in Backpack for confirming that a feature is complete, we have a checklist for preparing the feature for deployment and for executing the deployment, and finally for verifying that the feature is working as expected in the wild.
…
It’s the kind of stuff that we all know, but that we’ll often forget if we’re not being reminded about it in the moment. Thinking back to the mistakes we’ve made in the past, there are plenty of those that could have been avoided or caught much earlier if we had been using checklists.

This is a great reminder of two things: using checklists and adopting good ideas. Checklists are a simple and effective quality management tool. We use them for our software development (I have been a bit slow at getting them in place but we have been making progress recently). Also this shows how management improvement should work. You get good ideas from others and adapt them for use in your systems. Copying what others do, doesn’t work well. But understanding the concepts they use to improve performance and then adapting those concepts to your organization is the path to improved performance.

Related: Checklists Save Lives – Find Joy and Success in Business – Lean, Toyota and Deming for Software Development – The Power of a Checklist – Most Meetings are Muda

Jeff Bezos Spends a Week Working in Amazon’s Kentucky Distribution Center

Posted on March 28, 2009  Comments (4)

Photo of Jeff Bezos, Amazon CEOPhoto of Jeff Bezos during the 2005 O’Reilly Emerging Technology Conference by James Duncan.

Jeff Bezos, Amazon CEO, is working for a week in Amazon’s Kentucky distribution center. I hope, and based on his past, I believe, that he is going to the gemba (Genchi Genbutsu) to learn more about how Amazon operates. That would be great.

He worked on wall street and understands the fake constraints they attempt to put companies (you must focus on short term profits, you must focus on pleasing wall street analysts not customers…). He understood the importance of managing cash flow and the unimportance of short term profits. And he understands the importance of customer focus. He understands lean thinking. We need more CEO’s like him.

Amazon CEO comes to Lexington

“Thanks so much for your interest in speaking with our CEO Jeff Bezos,” said spokeswoman Patty Smith. “Unfortunately, I’m not going to be able to arrange any interviews or photos this week while he is in Lexington.

“He is there to work,” Smith said, “and, unfortunately, we are just not scheduling any interviews while he is in town.”

Local Amazon employees say Bezos is working in the warehouse with the company’s hourly employees to see what they do and hear their comments about their work. Most CEOs would benefit from spending a few days on the shop floor.

Once again his actions indicate he is the type of CEO I want to invest in.

via: Jeff Bezos Works In Kentucky Distribution Center For A Week

Related: Jeff Bezos and Root Cause Analysis – Management by Walking Around – Amazon Innovation – Amazon’s Amazing Achievement – Louisville Slugger, Deming Practices – Management Excellence

Combinatorial Testing for Software

Posted on March 26, 2009  Comments (8)

Combinatorial testing of software is very similar to the design of experiments work my father was involved in, and which I have a special interest in. Combinatorial testing looks at binary interaction effects (success or failure), since it is seeking to find bugs in software, while design of experiments captures the magnitude of interaction effects on performance. In the last several years my brother, Justin Hunter, has been working on using combinatorial testing to improve software development practices. He visited me this week and we discussed the potential value of increasing the adoption of combinatorial testing, which is similar to the value of increasing the adoption of the use of design of experiments: both offer great opportunities for large improvements in current practices.

Automated Combinatorial Testing for Software

Software developers frequently encounter failures that occur only as the result of an interaction between two components. Testers often use pairwise testing – all pairs of parameter values – to detect such interactions. Combinatorial testing beyond pairwise is rarely used because good algorithms for higher strength combinations (e.g., 4-way or more) have not been available, but empirical evidence shows that some errors are triggered only by the interaction of three, four, or more parameters

Practical Combinatorial Testing: Beyond Pairwise by Rick Kuhn, US National Institute of Standards and Technology; Yu Lei, University of Texas, Arlington; and Raghu Kacker, US National Institute of Standards and Technology.

the detection rate increased rapidly with interaction strength. Within the NASA database application, for example, 67 percent of the failures were triggered by only a single parameter value, 93 percent by two-way combinations, and 98 percent by three-way combinations.2 The detection-rate curves for the other applications studied are similar, reaching 100 percent detection with four- to six-way interactions.
These results are not conclusive, but they suggest that the degree of interaction involved in faults is relatively low, even though pairwise testing is insufficient. Testing all four- to six-way combinations might therefore provide reasonably high assurance.

Related: Future Directions for Agile Management – The Defect Black Market – Metrics and Software Development – Full and Fractional Factorial Test Design – Google Website Optimizer

How to Create a Control Chart for Seasonal or Trending Data

Posted on March 25, 2009  Comments (1)

Lynda Finn, President of Statistical Insight, has written an article on how to create a control chart for seasonal or trending data (where there is an underlying structural variation in the data). Essentially you need to account for the structural variation to create the control limits for the control chart. She also provides a Minitab project file. Both are available for download from the Curious Cat Management Improvement Library.

Related: Control Charts in Health Care – Common Cause Variation – Managing with Control Charts – Measurement and Data Collection – Fourth Generation Management

Checklists Save Lives

Posted on January 17, 2009  Comments (3)

photo of surgery room

Checklists are a simple quality tool that have been used widely for decades. Pilots use them, without fail, to save lives. Some surgeons have been using them and the evidence is mounting that checklists can save many more lives if more in health care use them. Studies Show Surgeons Could Save Lives, $20B by Using Checklists

Eight hospitals reduced the number of deaths from surgery by more than 40% by using a checklist that helps doctors and nurses avoid errors, according to a report released online today in the New England Journal of Medicine.

If all hospitals used the same checklist, they could save tens of thousands of lives and $20 billion in medical costs each year, says author Atul Gawande, a surgeon and associate professor at the Harvard School of Public Health.
…
In his study, which was funded by the World Health Organization, hospitals reduced their rate of death after surgery from 1.5% to 0.8%. They also trimmed the number of complications from 11% to 7%.

The study shows that an operation’s success depends far more on teamwork and clear communication than the brilliance of individual doctors, says co-author Alex Haynes, also of Harvard. And that’s good news, he says, because it means hospitals everywhere can improve.

Researchers modeled the checklist, which takes only two minutes to go through, after ones used by the aviation industry, which has dramatically reduced the number of crashes in recent years.

This is more great evidence of the value of applying simple management tools that are already well known. The idea that improvement takes brand new breakthrough ideas is just plain wrong.

Related: Using Books to Ignite Improvement – The Power of a Checklist – New, Different, Better – Management Improvement History and Health Care – Open Source Management Terms – Fast Company Interview with Jeff Immelt

Information Technology and Business Process Support

Posted on December 3, 2008  Comments (4)

I moved from management improvement work into information technology work (where I continue to practice management improvement). Many IT practices follow quality management guidelines well (agile software development for one).

I have found it far easier to design and provide software solutions than convince people to change their processes directly. I found it funny that as I delivered new IT solutions, in which was embedded a redesign of the process, those changes were often accepted without any significant debate. But the same changes that I tried to implement without a new IT solution had been impossible to make progress on (all sorts of reasons why it couldn’t be done were raised).

I strove, and believe I succeeded, to implement software solutions in a manner consistent with management improvement concepts. I started doing so in areas where I had been working and I was designing software tools based on my intimate knowledge of the system. And in doing so I tried to use an iterative approach (and the concepts of PDSA, though not really formally doing PDSA) involving those who were actually working in the business system. So I am not talking about just plastering in some IT solution from headquarters on the other side of the continent.

Too often organizations fail to invest enough in IT. The IT department is staffed merely to do what others request (and often not even provided the resources to do that). So then the executives can get what they need from IT. Others can get IT to respond if the manager can elevate the issue and explain how important it is that they get some support. But in general, all sorts of obvious improvement opportunities are wasted because the resources to carry them out are just not available.

In my opinion many organizations would benefit from increasing the resources to IT and shifting the focus from passive supplier to active participant in using information technology to meet business needs. This requires staffing IT with some people that are able to work with others to determine business needs and then determine the best IT solutions and then deliver those solutions. I have found many IT people are well suited to this role (though not all – which is fine those that prefer to focus on technical implementation can do so).

Another reason this often makes sense is how integral IT is to the functioning of the company. Expertise is technology is often very important today (and it is often missing). And getting your proactive quality experts working closing with IT will help them provide more value.

This post presents some thoughts in response to: Does anyone see value in merging Quality and Information Technology departments into a Business Process Management department?

Related: Software Supporting Processes Not the Other Way Around – Information Technology and Management – Using Quality Management Principles to Develop an Internet Resource by John Hunter, Jun 1999 (pdf)

  • Recent Trackbacks

  • Comments