Continuous Process Improvement and the Homework Dilemma…

Dawn Keller 22 April, 2015

Generally speaking, I have a problem with authority. I don’t like being told what to do or how to do it. I’m not proud of that.

I recall debating with my High School Trigonometry teacher regarding the value of the homework “process.” Specifically, in those situations where the student in question did not require practice to get an A. And, if said student was getting a 98% on the exams, why spend effort trying for those last 2 points? In the world of cost/benefit analysis, what’s the point? That homework effort may have cut into said student’s social time and said student had to make choices.

To this day, I believe that I had a valid point. Although I’d recommend, based on an unfortunate turn of events that resulted in an 89% and a difficult explanation to my parents, there’s probably a time and place to disagree with process. Touché, Mr. Petrunyak. Touché.

Fast forward many decades, and now my job is to deliver products in the most effective and efficient way possible and to continuously improve upon our methods and approaches to doing just that. And that often involves “process,” including analysis, diagrams, checklists, etc. Getting better and better at what we do. While I have no personal vendetta against process diagrams, checklists and general process of getting better, I believe, as with homework, they are tools that have their time and place.

Case in point.

Minitab, like many companies, has a variety of products at different stages of the product lifecycle. We have products that have been around for a while, products newly introduced or on the cusp of introduction and products that are a mere twinkle in a statistician’s eye. So, while we actively pursue process improvement, its application varies dramatically based on this and other factors.

“Established” Stage

Products that have been in the field for years tend to have a developed architecture and team. We also have plenty of data available on usage, issues, etc. In these cases, we are often interested in improved cadence or efficiency, so we’ll employ many traditional CPI methods. We regularly assess the data and make improvements in the development methodologies to improve our ability to get features to our customers in a more efficient manner. We can glean from the data how best to “spend” our testing dollars based on configurations in the field, risk areas of the applications, etc. We can use the data to identify high-risk areas requiring mitigation strategies. It’s the perfect place for some good, old fashioned data analysis.

The example below is from a one-year post-release assessment performed by our product development team. At Minitab, the product development team owns the release, pre- and post-release. They own the results and adjust based on their findings. The Pareto Chart depicts the types of issues found. From that, they identify and implement areas of improvement.


“Show Time” Stage

For products that are newly introduced or on the cusp of introduction, it’s a different ballgame. We don’t jump out of the gate thinking “Great—let’s pull out the Pareto Charts!” Instead, we step back, observe and learn. We don’t have an excessive amount of data on usage, yet so we aren’t churning out a variety of charts. We evaluate the information as it comes and we adjust, but it’s not process-heavy. We are evolving the process as we are learning.

“Twinkle in the Eye” Stage

This is someplace we don’t go peddling our CPI wares. Innovation drives this guy, not process. Sure there’s market data and analysis. And, sure, there’s learning. But, we aren’t evaluating the development process like we do with products in the field. For example, we aren’t assessing how “buggy” the code was the first time we prototyped something—it doesn’t matter at this point, and it’s not how to win statistician friends. If anyone would ever want to win a statistician friend, that is.

So, we learn and we get better. But we recognize the limits of standardizing our improvement processes. What fits for one part of the business doesn’t necessarily fit for another. But through careful consideration and effective data analysis, the way we've tailored our approach works for us.