Currently browsing the Quality tools Category

People Cannot Multitask

There is plenty of research showing that people can’t multitask. But this knowledge is missed by many people. Here is another study showing this: Why We Can’t Do 3 Things at Once

That’s because, when faced with two tasks, a part of the brain known as the medial prefrontal cortex (MFC) divides so that half of the region focuses on one task and the other half on the other task. This division of labor allows a person to keep track of two tasks pretty readily, but if you throw in a third, things get a bit muddled.

“What really the results show is that we can readily divide tasking. We can cook, and at the same time talk on the phone, and switch back and forth between these two activities,” said study researcher Etienne Koechlin of the Université Pierre et Marie Curie in Paris, France. “However, we cannot multitask with more than two tasks.”

Now I wouldn’t base my judgement on this one study. But we don’t have to. Multitasking decreases productivity. The siren song of multitasking. Multi-tasking: why projects take so long. What we should strive for is flow, the opposite of multi-tasking.

The real world often requires dealing with many interruptions (forcing you not to multi-task but to break up your tasks into fragments). Single piece flow shows the value (the efficient system performance) of getting one thing done then picking up the next. Many interruptions force you to keep stopping and starting tasks. People think they are multi-tasking but in fact they are just doing 4 tasks serially switching back and forth between them. Which slows them down and increases the odds of forgetting something. In these environments checklists are even more important than if you are not being interrupted frequently.

Related: costs of context switchingThe Multi-Tasking MythInterruptions Can Severely Damage Performance

Mistake Proofing Deployment of Software Code

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 DevelopmentBaking in Quality to Software DevelopmentCombinatorial Testing for Software DevelopmentGreat Visual Instruction Example

Combinatorial Testing – The Quadrant of Massive Efficiency Gains

My brother, Justin Hunter, gives a lightning talk on Combinatorial Testing – The Quadrant of Doom and The Quadrant of Massive Efficiency Gains in the video above. The following text is largely directly quoted from the talk – with a bit of editing by me.

When you have a situation that has many many many possible parameters and each time only a few possible choices (a few items you are trying to vary and test – in his example in the video, 2 choices) you wind up with a ridicules number of possible tests. But you can cover all the possibilities in just 30 tests if your coverage target is all possible pairs. When you have situations like that you will see dramatic efficiency gains. What we have found in real world tests is greatly reduced time to create the tests and consistently 2 to 3 times as many defects found compared to the standard methods used for software testing.

You can read more on these ideas on his blog, where he explores software testing and combinatorial testing. The web base software testing application my brother created and shows in the demo is Hexawise. It is free to try out. I recommend it, though I am biased.

Related: Combinatorial Testing for SoftwareVideo Highlight Reel of Hexawise – a pairwise testing tool and combinatorial testing toolYouTube Uses Multivariate Experiment To Improve Sign-ups 15%What Else Can Software Development and Testing Learn from Manufacturing? Don’t Forget Design of Experiments (DoE)

Justin posted the presentation slides online at for anyone who is interested in seeing more details about the test plan he reviewed that had 1,746,756,896,558,880,852,541,440 possible tests. The slides are well worth reading.
Continue reading

Nice Non-techinical Control Chart Webcast

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 CareHow to Create a Control Chart for Seasonal or Trending DataMeasurement and Data CollectionSix Sigma and Common SenseEuropean Blackout, not Human Error

Toyota’s Journey to Lean Software Development

Toyota’s journey from Waterfall to Lean software development by Henrik Kniberg

Toyota builds cars (duh). In the past that didn’t involve much software, and the little software that was needed was mostly developed by suppliers and embedded in isolated components. Toyota assembled them and didn’t much care about the software inside. But “The importance of automatic electronic control system has been increasing dramatically year by year” said Ishii-san.

A modern car is pretty much a computer on wheels! In a hybrid car about half of the development cost is software, it contains millions of lines of code as all the different subsystems have to integrate with each other. He mentioned that a Lexus contains 14 million lines of code, comparable to banking and airplane software systems. Ishi-san concluded that “Therefore Toyota needs to become an IT company”.

Most of Toyota’s ideas about how to do Lean software development resonated well with me. My feeling was that they are on the right track.

One thing bothered me though – the extreme focus on detailed metrics. I agree with the value of visualization, standardization, and data-driven process improvement – but only if used at a high level. My feeling was that Toyota was going to far. They say engineer motivation is critical, but how motivating is it to work in an organization that plans and measures everything you do – every line of code, every hour, every defect, how many minutes it takes to do an estimate, etc?

via: Justin Hunter

Related: Toyota IT OverviewToyota Canada CIO on Genchi Genbutsu and KaizenLean Software DevelopmentMy First Trip to Japan by Peter ScholtesToyota IT for Kaizen

Improving Software Development with Automated Tests

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 SoftwareMetrics and Software DevelopmentChecklists in Software DevelopmentGoogle testing blogHexawise software testing blog

Understanding Psychology: Slogans – Risky Tools

De-motivation Poster

Slogans mainly are bad. But like most things they can be used in ways that help or hurt. The main problem is when they substitute for a method to achieve the aim (most of the time). If the slogan serves like a mission statement to focus people on something useful to focus on and it is one minor part of a system to achieve a result it can be fine and even useful.

The issue, to me, is not so much that slogans are innately horrible. It is that, in practice, slogan are used in harmful ways most often (especially outside of sports). They tend to substitute for system improvement. The main work of shifting psychology (we do expect to win now, we do expect a focus on reducing bugs in our code…) after years of creating a different culture has to be in changing methods, priorities, values… Slogans, if done right, can be a way of focusing on the change. Or they can be a real reminder of values. But the slogan only provides value as part of a system confirming the aim they emphasis.

Unfortunately, they also to be used as a way to focus criticisms on individuals. Don’t you know/care that our slogan says zero defects? Can’t you read? Jeez, I even put up a huge poster with our slogan saying zero defects and you can’t even do what it says in this beautiful poster? Well, I will give you a bad performance review now, you can’t say you don’t have that coming after you failed to do what our slogan told you to do.

A slogan by itself has negative value. Take any wonderful slogan and move it somewhere else it will do more harm than good. As a minor part of a system though it can tap into how we people think and act (psychology) and provide value. Be careful though, it is much easier to do harm with slogans than to provide value.

If the slogan emphasizes what is being practiced every day, it can be a helpful reinforcer. If it conflicts with what is done every day it breeds cynicism and shows disrespect for people. This which is a huge problem. And managers have to know it is very easy for people to see the lack of cloths on the emperor slogan. Dilbert does a great job showing the risks of using slogans. Those you are targeting the slogan to are more likely to think like Dilbert than the they are to think like the pointy haired boss (and if you are the one pushing the slogan that means you are well on your way to being the phb – so be careful).

Slogans clearly fall under Deming’s understanding psychology area of management. To use them effectively you need to make sure the value provided, exceeds the cost and risk. I see no better way to evaluate slogans than through the lens of Deming’s system of management, interdependent components of: psychology, systems thinking, understanding variation and theory of knowledge. If the slogan is not supported by they system of management in place it will do harm.

In response to: Are Slogans Always Bad or Can They Inspire?

Related: Deming on eliminating slogans and motivational postersEliminate SlogansToyota Targets 50% Reduction in Maintenance Wasteposts on psychologyHow to ImproveStop Demotivating Employees

Prophet Unheard: Dr. W. Edwards Deming – 1992

This is an interesting video on Deming and American management (by the BBC in 1992): Prophet Unheard. It includes some nice old footage of Deming in Japan. The importance of respect for people is clear and the video also touches on the idea the danger of relying on data (when you do not understand variation and that many important matters and unmeasurable). The video features many snippets of Dr. Deming speaking and includes Don Peterson, Ford CEO; Clare Crawford Mason, If Japan Can, Why Can’t We producer; and Myron Tribus.

Related: Dr. Deming Webcast on the 5 Deadly DiseasesRed Bead Experiment WebcastPerformance without Appraisalmanagement webcasts

Part two of the documentary explores the Deming Prize, understanding data and the PDSA cycle:
Continue reading

Video Overview of the PDSA Cycle

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 PDSASaving Lives: US Health Care Improvement5 Million Lives Campaign

Communicating with the Visual Display of Data

graphs showing data sets with different looks even though some statistical characteristics are the same
Anscombe’s quartet: all four sets are identical when examined statistically, but vary considerably when graphed. Image via Wikipedia.

___________________
Anscombe’s quartet comprises four datasets that have identical simple statistical properties, yet are revealed to be very different when inspected graphically. Each dataset consists of eleven (x,y) points. They were constructed in 1973 by the statistician F.J. Anscombe to demonstrate the importance of graphing data before analyzing it, and of the effect of outliers on the statistical properties of a dataset.

Of course we also have to be careful of drawing incorrect conclusions from visual displays.

For all four datasets:

Property Value
Mean of each x variable 9.0
Variance of each x variable 10.0
Mean of each y variable 7.5
Variance of each y variable 3.75
Correlation between each x and y variable 0.816
Linear regression line y = 3 + 0.5x

Edward Tufte uses the quartet to emphasize the importance of looking at one’s data before analyzing it in the first page of the first chapter of his book, The Visual Display of Quantitative Information.

Related: Great ChartsSimpson’s ParadoxSeeing Patterns Where None ExistsVisible DataControl ChartsEdward Tufte’s: Beautiful Evidence

YouTube Uses Multivariate Experiment To Improve Sign-ups 15%

Google does a great job of using statistical and engineering principles to improve. It is amazing how slow we are to adopt new ideas but because we are it provides big advantages to companies like Google that use concepts like design of experiments, experimenting quickly and often… while others don’t. Look Inside a 1,024 Recipe Multivariate Experiment

A few weeks ago, we ran one of the largest multivariate experiments ever: a 1,024 recipe experiment on 100% of our US-English homepage. Utilizing Google Website Optimizer, we made small changes to three sections on our homepage (see below), with the goal of increasing the number of people who signed up for an account. The results were impressive: the new page performed 15.7% better than the original, resulting in thousands more sign-ups and personalized views to the homepage every day.

While we could have hypothesized which elements result in greater conversions (for example, the color red is more eye-catching), multivariate testing reveals and proves the combinatorial impact of different configurations. Running tests like this also help guide our design process: instead of relying on our own ideas and intuition, you have a big part in steering us in the right direction. In fact, we plan on incorporating many of these elements in future evolutions of our homepage.

via: @hexawiseMy brother has created a software application to provide much better test coverage with far fewer tests using the same factorial designed experiments ideas my father worked with decades ago (and yet still far to few people use).

Related: Combinatorial Testing for SoftwareStatistics for ExperimentersGoogle’s Website Optimizer allows for multivariate testing of your website.Using Design of Experiments

Baking in Quality to Software Development

One of the reasons my organizations switched to Ruby on Rails for software development was the great integration with automated testing. We always wanted to have good test coverage on our software applications (which are web applications – some used only inside our organization) but didn’t actually find the time to do so. Since we adopted Ruby we have been doing much better in this regard. It isn’t just the switch to Ruby, of course, but the switch to Ruby coincided with the beginning of many improvements to our software development practices that have continually improved over the last couple of years.

Here is a post on How to build quality software by an agile, Ruby, lean software developer

I’ve mentioned previously about baking-in quality and not having developers throw code over a wall to testers.

Everyone on the team is concerned with not only assuring quality in what we deliver, but making it visible to ourselves and the business.

We work in an agile manner, iterating through development with extreme programming practices and Behaviour Driven Development. Facilitating our relationship with the business is Scrum and we utilise kanban principles and systems thinking to maintain a speedy throughput of high-quality work. This mixture allows us to communicate effectively, develop the correct features properly and continuously deploy our work when it is complete, thus maximising business value. I should also mention that we are fortunate enough to have our business people/customer sat across from us.

Without testers or a QA team there is no wall over which work can be thrown and the responsibility for quality absolved.

The inspection typically carried out end-of-cycle only yields bugs that were low severity and of no real impact to the end user.

An agile testing must-have, we use TeamCity to continuously run our unit tests on each check-in. We also execute our Cucumber acceptance tests on scheduled runs. The status of the builds are visible on dedicated monitors around the office as well as a nice 6′ projected screen.

via: @benjaminm

Related: Combinatorial Testing for SoftwareChecklists in Software DevelopmentSoftware Supporting Processes Not the Other Way AroundSoftware Development and Business Process SupportTop Blogs for Software DevelopmentHexawise: more coverage, fewer tests (my brother’s company)

Don’t Hide Problems in Computers

Making things visible is a key to effective management. And data in computers can be easy to ignore. Don’t forget to make data visible. Paul Levy, CEO of Beth Israel Deaconess Medical Center in Boston recently hosted Hideshi Yokoi, president of the Toyota Production System Support Center and wrote this blog post:

Together, we visited gemba and observed several hospital processes in action, looking for ways to reduce waste and reorganize work. It was fascinating to have such experts here and see things through their eyes. Mr. Yokoi’s thoughts and observations are very, very clear, notwithstanding a command of English that is still a work in progress.

The highlight? At one point, we pointed out a new information system that we were thinking of putting into place to monitor and control the flow of certain inventory. Mr. Yokoi’s wise response, suggesting otherwise, was:

“When you put problem in computer, box hide answer. Problem must be visible!”

The mission of the Toyota Production System Support Center to share Toyota Production System know-how with North American organizations that have a true desire to learn and adopt TPS.

Related: The Importance of Making Problems VisibleGreat Visual Instruction ExampleHealth Care the Toyota Way

Checklists in Software Development

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 LivesFind Joy and Success in BusinessLean, Toyota and Deming for Software DevelopmentThe Power of a ChecklistMost Meetings are Muda

Combinatorial Testing for Software

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 ManagementThe Defect Black MarketMetrics and Software DevelopmentFull and Fractional Factorial Test DesignGoogle Website Optimizer

How to Create a Control Chart for Seasonal or Trending Data

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 CareCommon Cause VariationManaging with Control ChartsMeasurement and Data CollectionFourth Generation Management

ER Checklist

The popular ER TV show highlighted the importance of using checklists in surgery yesterday.

Such powerful quality tools, like the checklist, are just waiting to be used. But far too many fail to use these simple improvement tools. And in health care those failures are potentially critical.

Related: Checklists Save LivesThe Power of a Checklistmanagement improvement dictionaryArticles on Improving the Health Care System

Jeff Bezos and Root Cause Analysis

Jeff Bezos and Root Cause Analysis by Pete Abilla

There are several things amazing about this experience:

  1. Jeff Bezos cared enough about an hourly associate and his family to spend time discussing his situation.
  2. Jeff properly facilitated the 5-why exercise to arrive at a root cause.
  3. He involved a large group of stakeholders, demonstrated by example, and arrived at a root cause and he didn’t focus on symptoms of the problem.
  4. He is the founder and CEO of Amazon.com, yet he got involved in the dirt and sweat of his employees’ situation.
  5. In that simple moment, he taught all of us to focus on root causes — quickly — not heavily relying on data or overanalysis of the situation, and yet he was spot-on in identifying the root causes of the safety incident.

Using quality tools really works. Lots of people don’t use them. Improving is often not any more difficult than just applying tools that have been used for decades. Improving does not require rocket science. Just do the simple things and you are well on your way to great success. Of the 10 stocks in my original 10 stocks for 10 years post Amazon is one of 4 that are up.

Related: Bezos on Lean ThinkingAmazon InnovationBezos Webcast on the Internet BoomImprovement Tools and Improving ManagementRoot Cause AnalysisEuropean Blackout is Not “Human Error”

Checklists Save Lives

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 ImprovementThe Power of a ChecklistNew, Different, BetterManagement Improvement History and Health CareOpen Source Management TermsFast Company Interview with Jeff Immelt

Information Technology and Business Process Support

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 AroundInformation Technology and ManagementUsing Quality Management Principles to Develop an Internet Resource by John Hunter, Jun 1999 (pdf)

  • Recent Trackbacks

  • Comments