Quality Sphere

Here's wishing for a great 2012

2011-12-31T10:38:00.000-08:00

Greetings!

Here's wishing for a great 2012. Not doubt next year will be an interesting one. Several domestic indicators late in the year (shopping trends, job creation and housing starts) have provided reason for cautious optimism, while international economical/political news still require that I keep an adequate supply of antacid tablets on hand.

Several topics have caught my eye recently. And, like I did at the holiday buffets that I was fortunate enough to be invited to this season, I have decided to visit each one and sample its contents:

First, I attended an ASQ meeting recently and was introduced to the Hoshin planning model. Yes, I am a member of ASQ. And yes, I am a CQM, however, I have to admit I have next to no knowledge regarding this model. A vice president of quality for a local medical equipment company has made it his mission to spread the word and spoke at a recent ASQ meeting about the model - and has even developed a software package to aid folks bold enough to test the waters with it. However, the fact is, it's simple. Basically, the model requires company executives determine and agree upon the company's most important goals/objectives for the year. Then, they develop strategies for each goal - then tactics. Each tactic at one level of the organization may then drive a strategy at the next level - which in turn drives another tactic set. Sounds easy enough - right? The problem, but not with Hoshin is (actually, there are four major ones):

1. Executives have to decide and agree upon objectives. Some good organizations do this very well. However, for too many companies, somehow this remains an elusive goal. I can't help but believe the numbers would improve if more executives had formal quality and/or project management backgrounds. I may be partial, but that's my story and I'm sticking to it.

2. The management team (and employees) all the way across the organization have to ensure that they have interpreted the objectives correctly so that their strategy/tactics align with objectives. In other words, there needs to be an ongoing communications stream across the spectrum.

3. Be able to audit status against goals for each level of the organization. Please see#1 above for the reason this is often not successful.

4. This planning model doesn't work overnight. It can take 2-3 years before the organization speaks and acts with true unity regarding its goals and objectives. The organization has to be disciplined enough to stay with it until positive outcomes prevail. Yes, I am saying executive teams lack the perseverance to stay the course. Doing RCA on this topic for many teams may yield some profound outcomes.

In summary, for Hoshin to work, companies need to be able to agree on the decision making process - and stay with the decisions once made. Embark on a constant communication program, develop measurable feedback with full engagement with employees on what measurements should look like, and have the discipline to stay with it. So simple - yet so difficult. No wonder the Hoshin model lacks more widespread adoption. The road to Hoshin may not be a short drive, but still worth the effort when you arrive.

Second, a terrific article was written recently by NiloferMerchant in the HBR entitled; 'People Are Not Cogs'. She feels that the new economy is about producing ideas, experiences and meaning. The output of these singular and collaborative entities may produce revenue on its own, or could be the input to other ideas, experiences and meaning. The full engagement of all employees as collaborative partners is imperative for success. As she states:

'Look at Apple. Their earnings per employee figure is $419,528 per head, beating out even Google's of $335,297/head and well on its way to be double that of Microsoft, currently at $244,831. They outperform their industry because they've figured out how to enable the key asset of the new economy: scalable leverage many people's contributions, including the app developers eager to piggyback on the industry's most attractive devices. Yet most organizations still operate much as they did in the industrial age. We manage the measurable, rather than the things that create meaning that fuels creativity, that enables innovative thinking and that helps any company to outpace the market.'

Also, she goes on to provide objective evidence when shes states:

' (The) Gallup, the research firm, recently did a meta-analysis across 199 studies covering 152 organizations, 44 industries, and 26 countries. It showed that high employee engagement brings an uplift of every business performance number. Profitability up 16%, Productivity up 18%, customer loyalty up 12% and quality up an incredible 60%.'

Then why do many businesses measure the employee as a resource, which keeps the employee at a virtual 'arms length' with the employer. How can true engagement occur when many organizations run on earlier industrial age thinking. Company performance and people are not mutually exclusive - but are rather mutually inclusive now for company success. Again, it seems simple. And, given the data, why are more companies not sprinting in this direction?

Third, a gentleman recently passed away who was a past CEO of a large company in my area - as well as a founder of a couple of other smaller companies. He was a true believer in the quality philosophies of Dr. Deming, and even received the prestigious Edward Medal from ASQ some years ago for outstanding application of quality principles. He and his wife were frequent donators to many local organizations. They have an ice arena, Boys and Girls Club cafeteria and college building named after them. He was a 'people above all else' person, he was constant in purpose and felt you should continually attempt to improve anything you did - or it wasn't worth doing at all. Looks like his legacy would be a great role model for leadership in the new economy. People and performance - together. Thank you Mr. Conway.

People and performance - together. Sounds like the makings of a good company mantra for 2012 and beyond. I'm ready .... bring it on 2012!

Next topic: Method To The Madness: Rise of the idea system

Can Agile and UAT Play Nice?

2011-08-12T12:39:00.000-07:00

Greetings!

This question was posed to me by a QA colleague recently; 'Shouldn't you be able to run UAT testing within the confines of the Agile/SCRUM methodology?'

Fascinating - huh! ..... Or do I just need to get out more often.

If you stop to think about it for a moment, it kind of makes sense. At the the conclusion of every sprint cycle, there should be a completed effort - inclusive of QA testing and documentation. Right?

So why not incorporate UAT into the process? Couldn't use cases be modified to just test the functionality inherent in just that sprint cycle - as well as cases that may tie into functionality from past sprint cycles?

I know, enough with the rhetorical questions. Truth of the matter is that UAT, by it's very nature, can only be accomplished after the last sprint cycle. When the system or solution is nearly ready to be deployed.

But, isn't true you can exercise a use case or three as long as the requirement functionality is present. Absolutely! Won't the chance to discover defects earlier in the development cycle reduce cost (i.e. cost of quality)? Probably.

But here's the thing. Figuring out exactly what to test could become quite time consuming - largely due to the fact the UAT analyst is focused on business requirements - not functional requirements. The analyst also may not have the expertise to separate the functional 'wheat' from the business 'shaft', and will need development and QA help to do so - taking time from their own efforts. Yes, you may be able to execute a few use cases - but with changes post sprint, time lost by associated parties, along with the need to possibly regression test (which is largely outside the scope of UAT), negates any value of testing during each sprint cycle.

If the UAT analyst were able to apply a testing 'centrifuge' to the process that magically determined what to test, then maybe you would have something there (just make sure you patent the thing first!).

Next topic: Quality is Everywhere: The secret purpose of meetings

'Double Header Day' at Quality Sphere

2011-02-01T10:52:00.000-08:00

Greetings!

It's 'Double Header Day' at Quality Sphere as I approach two topic areas at once:

Quality is everywhere:Toastmasters, International, and

Methods to the Madness: Things my mother never told me about UAT

I mentioned in my last article how I wanted to touch upon a quality organization - Toastmasters International (TMI). No doubt on my tombstone will be the motto 'Fran saw quality everywhere'; however, seeing why TMI is such a great organization is easy. But before I extol the virtues of this organization, I would like to address a specific area Quality topic: User Acceptance Testing (UAT).

I recently ran into a possible gray area around how best to defined the following:

End state summary

User scenarios

Use cases

User test cases

To many, and I have to admit that I had my doubts recently as well, struggle as to what are the differences between these terms? Are they just different ways to express the same thing, or are they all just different points in the testing horizon? After some soul searching, reading and on the job experiences (OJE), I believe I have found reasonable answers (notice I didn't say 100% correct answers - I'll leave that to ASQ-BOK gurus to put their stamp of approval on it). I would classify them under two areas:

High level

End state summary: is simply what it says. A summary of where we want to be at the conclusion of Test Effort 'X'. There could be 1 or more 'X's', but nonetheless, it's simply a summary statement. You could also use 'Future state summary' as well.

User scenarios: The high level paths that the user is expected to take that will allow them to arrive at the scenario end state.

Specific

Use Cases: Specific action taken in the user path to arrive at the end state. As with any test case, there should be a stated expected outcome and it should be traceable back to the requirement(s).

User test cases: Can be the same as Use Cases, however, the value of these test cases is to tread into areas either expected or not expected to be encountered by the user. And yes, the terms 'black box' and white box' testing could apply here as well. Again, as with any test case, there needs to be an expected outcome and it should be traceable back to a requirement(s).

Simple enough, but then ponder the 'chicken or the egg' scenario. Does one use the high level to drive requirements, or do you develop requirements to drive the high level? This question was presented to me recently, and I am still mulling it over - but would like to hear your thoughts!

Back toTMI ....
I have been a member of TMI since May of 2009. I belong to a great club called the Synergists. What makes TMI a quality driven organization? They exist simply to promote continuous improvement in communication and leadership ability in EACH individual in a very positive, supportive, efficient, and cost effective manner. And, it works very well! .... 'nuff said!

Holiday Greetings!

2010-12-29T11:29:00.000-08:00

Holiday Greetings!

I hope your holiday season has been a quality one so far. It's a great time of year - other than the snow storm that just created mayhem for thousands of folks a few days ago in the Northeast to Mid-Atlantic areas of the USA. Whether you were traveling by plane, train or automobile, you were at the mercy of Nature and man's limited ability at times to traverse through it.

I come bearing the gift of a slide preso for this article - rather than by just written word alone ... thought it would fun for a change. I recently gave a short speech on Quality at a local chapter of Toastmasters International that I am a member of. The name of the presentation was called 'What is Quality - anyway??' I used this slide deck to support my speech. And speaking of quality organizations, TMI is a great one. In fact, my next article will be to herald the merits of this fine quality driven organization .... remember what my mantra is: 'Quality is everywhere'.

So, enjoy the slide deck, and remember, if you have comments or questions, please let me know. Happy New Year everyone!!

Fran

Company Road Trip: It's ALL About The Beer!

2010-11-07T11:27:00.001-08:00

Greetings!

I just attended a meeting set up by the local chapter of American Society for Quality (ASQ). The meeting was a tour of the Anheuser-Busch brewery facility in Merrimack, NH(now part of AB InBev). Suffice to say, there was very little that was going to keep me from this gathering. After all, quality IS everywhere - and what better place to do research on the topic. Yes, they do serve fresh and very tasty grain beverages at the conclusion of the tour, which was a draw for me ..... a really big draw; however, I did want to see their assembly line in action as well. Although AB claims that this is the smallest of their US breweries, I have heard it can pump out a prodigious amount of beer per day. I felt compelled to get to the bottom of this rumor ....

I arrived early that evening - just to make sure I didn't miss a moment of the tour. We started late - surprisingly because some folks didn't show up on time. The delay made me even more thirsty for ... err ... information about that famous assembly line.

I was very surprised to learn that AB focuses very heavily on water conservation. Not only is water the main ingredient in beer, it is also used heavily in early phases of the brewing process in the making of wort (an ingredient for brewing beer) and is then drained off, filtered, and used again in the the massive containers for fermenting the beer that have to be washed between each usage. There were 15 vats used just for the fermentation process alone and are cleaned every 21 days. To give you an idea of just how large these vats are, it would take one person drinking 1 case of beer every day for 45 years to empty the vat. Talk about a metric with meaning!

AB is known for their beechwood aging process, and they actually take pieces of the wood, sterilize them 6 times, then lay them in the vat to be part of the fermentation process. And, they re-use the wood 6 times before grinding them up and sending it off to local landscapers to be used as mulch. Is that why I see so many folks on their hands and knees spreading mulch with a smile on their faces?? See what I mean about the eco-friendly brewing process - and not one mention on the tour of how this is part of their ISO 14000 compliance efforts.

The beer is quality checked 32 times in the 30 days it takes to make a beer. And, it isn't done by a couple of guys sticking ladles into the top of the keg for a taste either - but rather through a lab based approach to determine alcohol content, consistently, temperature and a host of other elements being measured that we unfortunately were not able to view - I suspect it's too close to their 'special sauce' information.

When we arrived at the assembly line, I was fascinated by a number of things. First, the sheer speed of the line. Bottles are being washed, sterilized, labeled, filled with beer, capped and pasteurized before being boxed and trucked off the property. The current output rate the evening we were there was 62,000 cases of beer/ day!! Fellow quality members and I almost came to tears when we saw full bottles of beer falling off the line and breaking on the floor. It just seemed wrong on so many levels. They said not to worry, they do measure waste, but to achieve their optimal output rates, they will break a few bottles now and again. It's true, you can't make an omelet without breaking a few eggs .... but seeing bottles of beer encountering an early demise on the floor was hard to watch. To minimize breakage, they send a constant steam of soap and water on the conveyor belts that allows for easier bottle movement with less breakage - again, with recycled and filtered water from upstream processes. The floor is washed (more water usage) very 2 hours to insure safety of employees and to keep the place from smelling like Sunday morning at your local college dorm.

Not only was it mesmerizing to watch the bottles whirl and swirl along the line, it also made us all incredibly thirsty. I was fully prepared to chew through steel to have a sip of the beverage if , for some reason, they concluded the tour without a whiff of the grain beverage. Thankfully, the great folks at AB concluded the tour in their 'lounge' where folks could partake in 2 beers of their choice.

The folks at AB are geniuses. The tour showed the brewery to be very clean and organized, the smell of hops in the air intoxicating, and the sight of thousands upon thousands of gallons of beer being loaded into bottles and cans a feast for the eyes. You leave the brewery thinking that AB is just about the best place in the world.

At the conclusion of one of the happiest ASQ meetings I have been to in a while, friends were made, quality issues that were thrown out on the table next to the pretzels for discussion were (seemly) resolved, and a new appreciation for what it takes to build a world class brewery and distribution center was gained. Thank you AB - and cheers!

Next article: Methods to The Madness

Methods to The Madness: A Quality tool for Risky business

2010-10-22T12:48:00.000-07:00

Greetings!

Grab a Red Bull, or a double latte, because today, as promised, we're going to talk turkey about FMEA (Failure Mode Effects Analysis) - which should never be confused with FEMA (Federal Emergency Management Agency). Although, as you know, this agency has no shortage of quality issues of their own that need to be addressed (it might help too if that agency was funded appropriately - IMHO).

I attended a seminar recently and listened to a speaker from the Quality Support Group, Inc who spoke about FMEA. His lead-in regarding how the tool is used to prevent loss of life caught my attention pronto - as he was not talking about a missed delivery date, but rather in terms of human casualties.

The focus of this tool is determining Risk. And, to level set the definition bar here, let's revisit what Risk is. Risk is 'a potential future event that could result in adverse and unplanned consequences'. Risk is NOT 'a problem, issue or crisis'. Risk IS 'a measurement of the potential inability to achieve objectives*'.

In many quality and project management circles, the idea of Risk Management is bandied about with a whole lot of fervor (yes Virginia, there are geeks in every profession), but much of that hoopla might be over such areas as the Risk to insurance premiums when some insurance company book worm makes an error on an actuary table. However, FMEA is used when real Risk is involved, you know the kind where if the product doesn't work right, you're pushing up daisies and your hard earned assets are being redistributed to next of kin who, hopefully, have better luck with that product in the future.

The FMEA tool is really quite remarkable. It has no less than 14 prime categories and multiple sub-categories for determining and tracking Risk entities. But in keeping with my 2010 credo of 'just-get-to-the-point' brevity for Quality Sphere articles, I will touch upon a few key areas of the tool, then I promise to attempt to make sense of it all by the end of the dirge.

Ok .... time to get into the weeds for just for a moment. Key areas:

#1: Potential Failure Mode (types of failures):
When manufacturing anything from medical devices to baby car seats, a great deal of resource energy and time is expended on determining every type of failure for every component or material used and every step in its construction for that product. This evaluation is critical, cannot be done in a vacuum, and it depends on experts who know what the heck they are talking about for every part of the end-to-end development of the product.

#2: Potential Effects of Failure (how bad can it be?):
Again, a critical step that must be done with experts involved. Along with this analysis is listing reasons for why it could fail (proactive root cause review (RCA)). Only through this step can you determine the probability of detection controls that may successfully deter the failure from occurring.

Next, the quantitative portion of the tool takes over to determine severity, probability and occurrence for each potential failure. Based on the collection of data gathered, a Risk Priority Number (RPN) can be assigned and then plotted in a probability/severity matrix chart called an ALARP (As Low As Reasonably Possible). Catchy name ... Huh.

Why did I take you for a quick walk on the wild side of esoteric quality measurements - it's not like most of us deal in the development of products that, if improperly built, can punch your ticket to The Farm? The point is that wouldn't it be interesting if on any project or initiative, we spent some time in the planning stage with SMEs that represent the end-to-end process brainstorming for potential risks - then, build a mitigation plan around the input provided?

Classic project management says that a Risk Management Plan should always be just one of several plans for any project. In real life, project needs are moving too fast, tend to be not very large in scope or size, and frankly, no one wants to talk Risk - as they are seen as 'speed bumps' on the way to an end result. Risk is usually given an obligatory nod - then we move on thinking everything will be .... 'fine'. Risk only seems to count when there are large amounts of cash or causalities on the line (Toyota pushed the envelop big time and are now trying to find their way back to the promised land).

Please let me know your experiences with attempting to develop Risk Management Plans.

Next article: Quality is Everywhere
* Reference: Risk Mgt Guide - DoD Acquisition,4th Edition

Methods to The Madness: What every manager should know

2010-09-03T12:22:00.000-07:00

Greetings!

I've made no secret that my articles are not so much about the tools and mechanics of quality, which are very important (although I do plan on writing an article on FMEA next month - and I hope that we all don't become deer in the headlights in the process), but I really do like to explore the underlying, and in many cases root cause of problems that stem from an organization's culture, teams, or just the plain ol' everyday rut that creates such a funk from the executive team right on down to the really important people.

I read a fascinating article recently in the September edition of the Harvard Business Review written by Robert Schaffer. And, before you snicker at my reading material, try it - you may like it. Great writers, current topics and they are usually frank in their assessments. Good stuff.

His article is entitled ' Mistakes Leaders Keep Making'. He discusses what he calls the '7 Deadly Sins of Setting Demands'. I love that he creates that analogy in the title - alluding to the fact that these mistakes can be as harmful to the corporate body as the original 7 deadly sins can be to the human body - and mind.

These 'sins' are:
1. Establishing to0 many goals
2. Not establishing a plan on how/when these goals will be achieved
3. Failing to push (I prefer coach) for improvement for fear folks are overwhelmed
4. Not assigning 1-person accountability for goal achievement
5. Ask ' if you possibly can' at the end of a statement of expectation
6. Accepting reverse assignments (trading one task for another)
7. Stating goals that may not be definable or achievable

The bulk of Mr. Schaffer's article is around behavioral 'traps' that managers consistently get caught in - and just can't seem to break the cycle of repeating over and over and over again.

Where do I begin ........ so much to say and so little time .....

I had made a promise to shorten my articles but write more often, so I'll select a couple of points he made in the article to make my point.

Mr. Schaffer's point #1: Establishing too many goals (paraphrased below):
Managers are afraid to set specifics goals - so they think quantity is better. It requires considerable thought and planning and is much more difficult that issuing a general order. And, if they set specific goals and they are not achieved, THEY look like failures.

My take: Can you say S.M.A.R.T goal setting. Nice tool. And management, as a team, and with input from employees (amazing what employees can offer) can actually develop goals that have been thought through and in all likelihood can be accomplished. Remember, these goals reside in a living document and must be cared for and watched over like a beloved pet if it is to survive.

When managers walk the talk on teamwork, surprising things can happen!

Mr. Schaffer's point #2: Failing to push for improvement for fear folks are overwhelmed already (paraphrased below):

Managers, when striving for improvements in processes, products, services or any area deemed to have value to the organization seem to be under the opinion that the way to improve performance is by finding new programs to produce these gains. They almost never think about improving a current program. Why? To say that they would like to improve a current process or program means that they weren't doing a good job already on current programs.

My take: P-L-E-A-S-E ..... set the egos aside. I have found managers, on whole, to be an intelligent lot that want the best for the company - and are working hard to achieve it After all, they work there too. They need to obtain a mindset of continuous improvement. And, I can't let the Quality profession off the hook on this one. If a manager is thinking of a new project to 'improve' something, this is ideal - a willing sponsor that needs help. The challenge in quality (me included) is helping the manager determine an ROI on the new program (to support the manager's vision), and/or to determine efficiencies yet to be achieved in the current program via use of quality tools in practice today (DMAIC, fishbone diagrams, team brainstorming, various evaluation metric tools, etc.). The point here is to think (and sell) continuous improvement as an option rather than a default reaction to reinvent the wheel. Exploring CI initiatives may prove to be less costly and with better gains than getting the organization sidetracked on another program with a dubious payoff.

Thank you Mr. Schaffer for bringing these issues to light. They can provide an 'opportunity launch pad' for a company's quality organization.

Next article: Method to The Madness

Quality is Everywhere: Electricians

2010-08-16T12:23:00.000-07:00

Greetings!

I recently spotted quality happening when no one was looking .....

One of the reasons I enjoy writing this article is to help attempt to define the concept of quality and identify its occurrences. Well, recently a random act of quality occurred in my very own home.

I had a potentially dangerous situation where a wire in my circuit breaker box at my house decided to barbecue itself. The result - a strange situation where some lights and appliances work, and some didn't. Not strange you say?? .... probably all on the same circuit?? .... just reset the breaker?? That's what I thought. Funny thing was, none of the circuits were thrown, and outages had occurred on more than one circuit.

It was rather late by the time I spotted the wire and realized this must be the issue, and I knew sleep was out of the question until I had an electrician give it the once-over. The electrician soon showed up, scoped out the situation and declared; 'Yup, it's the wire .... needs to be replaced'. Thankfully, it was a quick and easy fix ..... or so we thought.

He tested the wired first to determine that this was, in fact, the root cause of the problem. Having passed the test, he permanently replaced the wire - and wha-lah! .... The problem remained. The electrician then said; 'I just tested the fix, it should have worked'.

You probably now see where I'm heading with this story ...

It was late, the electrician had already worked a full day and was tired, and he was messing around with a boat load of live wires .....what could go wrong. To pleasant surprise, the electrician did the following :

1. He kept his cool. Very understated quality value when determining root cause. Doing so helps you think more clearly, and in my electrician's case, kept him from getting injured.

2. He logically started asking 'why' questions to help him track the flow of this issue to ultimately find its source. For each question, he attempted to prove or dis-prove it before moving on to the next - thereby building an objective analysis of the outage. In reality, be was building a decision tree to the root cause based on outcomes of his why questions.

3. He tracked his decision tree to ensure he didn't repeat the same steps again. Great idea given both he and I wanted to call it a day.

End result, he was unhurt (real nice to see), and solved a problem that looked like it could have taken hours to resolve (without ranting and and cursing) in 45 minutes. It turns out it was a circuit breaker that sometimes worked, and sometimes didn't.

I went to sleep that night comfortable in the knowledge that I wouldn't have dreams of my house not going up in flames, and having just witnessed a simple yet effective method of RCA and correction is action.

Kudos to my electrician for the quality refresher course!

Next article: Methods to The Madness

Methods to The Madness: The Project Portfolio - part deux

2010-07-07T08:18:00.000-07:00

Greetings!

I know.... I know .... I've lapsed in keeping a commitment to this article blog - in part because I have been very busy - as I'm sure most other folks have been as well. However, the proverbial light bulb did go off over my head on how best to keep up with this forum .... just write less .... but do it more often. I need to incorporate it into my lifestyle - rather than do it in 'fits' of activity. Kind of like with dieting, the activity does not usually drive long term quality results - as it seldom addresses the fundamental (root cause) issue - it's the life style - not the food!

Now, back to the fun stuff ....

In part 1 of my article entitled 'Methods to the Madness - The Project Portfolio', I was mentioning how many companies seem to conduct project portfolio planning by ... well ... not planning. They do often employ the 'spinning-the-plates-on-a-stick' methodology - or put another way, all projects have an equal right to 'spin'. This is a great circus trick to catch sometime, but is probably not an optimum business process. Why, oh why don't more companies use an objective decision model to determine priority??

I had been waiting on a contact of mine to report back on his company's efforts (no cop out as to why I am so late with this article though) to conduct a meaningful portfolio management exercise. His report back, although not surprising, was nonetheless disappointing. I was expecting to hear that the company decided on a tool (ie: Priorities Matrix or just a good ol' fashion checklist to see how the project matches up against company objectives) to determine the relative level of impact to support the overall company strategy. Turns out that the company (a rather large company that's been around for a while )could not determine which projects were deemed to be 'core' to the company. So, when in doubt (remember, uncertainty can and does breed fear - a whole separate dissertation) .... cover your basis. I have heard this story repeated in a number of different forums. The tools work when utilized, but it looks like human nature is doing what it does in times of economic distress too. I'll keep searching on a successful project portfolio story, and will report once I find one.

Just a quick thought regarding Toyota (and it's - until recently - hailed production system (TPS)). Reams of columns have been written about what happened, what may have happened, what should have happened and what they should do now. All I know is that I own a Toyota, and it's a pretty darn good vehicle. Their recent actions appear to be panic/fear driven (see above) - such as reducing the reliance on 'outsourced' vendors staff. These folks, many engineers, worked in Toyota facilities right along side Toyota engineers. This is not where the problem lies - especially if they are true to the TPS and believe in this quality system. Toyota said it correctly when they commented; ' As we look at this past generation of vehicles, it did seem to be all about the growth of the company, and there were lapses' (WSJ: 7/6/10). A healthy dose of RCA is in order. Oh, and to the execs at Toyota, it does start at the top. So, let's get it right and get back to producing those wonderful vehicles I have enjoyed driving!

Just one more quick comment, Sweetwater Music has THE BEST CUSTOMER SERVICE that I have seen . I get nothing for this statement, but do love to announce a true service winner when I see one. All you music affectionados, check them out sometime!

Next article: Quality is Everywhere: Electricians

Methods to the Madness: The Project Portfolio

2009-12-05T14:04:00.000-08:00

Greetings!

It is great to be back - and happy holidays to you! I can't believe it has been almost 7 weeks since my last article. So much has been happening that time has literally flown by.

First, I have successfully completed the certification process for the American Society for Quality's 'Certified Quality Manager/Organizational Excellence'. Humbling experience though .... the BOK to master for the exam was almost more than my little ol' brain could hold.

I also took on a new position that has really taken my complete focus just to get my head around.

All in all - my head hurts ....But it's all good!

Anyway, a topic immediately came to mind upon starting my new role. The idea of the Project Portfolio. I am also a member of a SCRUM Club (no, I'm not Australian sportsman) and this was a large part of a recent topic at one of the club's meetings. it was very interesting to note how few managers responded in the affirmative that they indeed managed, or even subscribed to the idea of a project portfolio.

For folks that may not be familiar with this gem of a tool, it is simply the art and science of prioritizing your projects. Sounds simply - huh? If this is the case, then why don't more folks enlist its benefits? This answer is not so simple, but it does many times revolve around what I call the 'spinning-plates-on-sticks' syndrome. We live in a multi-tasking society. We feel we can, if we are efficient enough, take on as much burden as we choose - with success - and without consequence.

Reality check time. As much as we would like to think we can keep all the plates spinning, projects, unlike the plates, are less predictable. Stuff happens that will steal more attention and resources that originally anticipated. Suddenly, and for some inexplicably, 2 or more projects are off track .... a chain reaction caused by attempting to keep multiple projects concurrently in the air.

Developing and managing a project portfolio provides the discipline to stay focused on the most pressing project. Notice I said project ... as in one, 1, numero uno, the big fish, the top dog .... anyway, you get the idea. A secondary project running concurrently will only deflect you from what the highest priority project is at the time. Unless there have been resources definitively assigned, issues with one project will cascade to the next. If you are running 3 or more projects at a time, you obviously find great joy in suffering or are working in a company that subscribes to the above syndrome.

I'm sure this scenario is nothing new to you Agile consultants contracted to manage quality improvements in the development, testing and release process.

If so,what is a PM to do??? As this topic hits somewhat close to home for me at the moment, and is a work in process, I would like to make this article a two-parter (bingo, a trailer ... just like they do at the movies :-)).

Next article: Methods to The Madness: How to reduce project scheduling overload - a case study.

Be back in a moment ....

2009-09-27T07:46:00.000-07:00

Greetings!

Folks, I will be back to post additional quality articles very shortly .... I am currently in the midst of studying for the American Society of Quality's 'Certified Quality Manager/Organizational Excellence' exam and am tapped out for time at the moment. Once I take the exam (10/17/09), I'll be back with a few very interesting articles that I can't wait to complete an publish.

Have a great day!
Fran

Quality is Everywhere: Could this be the holy grail?

2009-08-24T09:57:00.000-07:00

Greetings!

I like this weeks theme (Quality is Everywhere) for a couple of reasons - the topics are fun and it allows me to do something I like to do - which is to write this article even on weeks that tend to be just a wee bit active. Life is good!!

My son has been constructing a small music studio in his home and ordered some audio equipment as part of the project through a company called Sweetwater.com. Knowing my son, who also has some background in quality as a mechanical engineer, I have no doubt that this studio will be 'top shelf' once completed. The only request from Dad on this endeavor is that I get some free studio time for a project or two I am thinking about ... all part of the fun of having grown kids - you get to use their stuff for a change.

He contacted me after receiving the equipment to relay the story of what transpired during the ordering process. Apparently, when he placed the order through their on-line ordering system, the system stated that there was sufficient quantity in stock to complete his order - but in fact, the inventory counts were incorrect. As a result, the estimated delivery date had to be pushed out.

What caught my son's attention was the fact that they contacted him (not the other way around) to report that there had been a error on their behalf and would he please accepted a package containing two 'high quality' audio cables (free - and not cheap) with their most sincere apologies for the mistake. When he receive the cables, they had also packaged up some chocolate for his eating pleasure.

Wow! In one fell swoop they were able to proactively turn around a customer even before he realized the issue. For this effort, and the cost of the cables (and chocolate), they now have a very loyal customer who will be going back to order more equipment on a regular basis.

Quality is an experience and Sweetwater absolutely gets that point. The ROI for just this one interaction is big. My son is ordering more equipment, he has told his fellow music colleagues, and I'm even writing about it! Did I say Wow already? ....

I did do a little actual research for this article and I called Sweetwater and spoke to the Customer Service Manager Bob regarding the interaction. I asked him if they had standardized a procedure to reimburse customers when they make an error on the order. He said there is no specific rule. It is incident based and they only require that their staff 'do the right thing'. When he made that statement, certain phrases immediately came to mind: employee trust, employee empowerment, customer partnership, progressive, long term thinking, etc. They do have a continuous improvement mechanism in place to consistently review customer based issues. And, they are working to continually improve the systems and processes that are in place now to aid in the customer experience. However, the immediate quality experience the customer is treated to cannot be underestimated as the key business building tool.

Claes Fornell, in his piece The Satisfied Customer: Winners and Losers in the Battle for Buyer Preference states; "We might even have stumbled upon the holy grail for managers, as well as investors: Satisfied customers are economic assets with high returns and low risks. That is, you don’t have to take high risks to get high returns. This is contrary to what most financial analysts believe. It is also contrary to what many in business believe: ‘Be bold. Take risks. No risk, no reward. Nothing ventured, nothing gained".

There's 'quality gold in them there hills', and sometimes all one has to do to mine it is to turn the customer facing staff into true business partners.

Do you have other quality story you would like to let folks know about? Post a comment ....

Next article: Company road Trip

Company Road Trip: Training keeps you on track

2009-08-10T09:40:00.000-07:00

Greetings!

One of the many reasons I like living in the Boston area is the veritable cornucopia of industry types that are doing business here - and hiding in plain sight doing it too. Oh sure, they may not all have the sexy names you would see when driving along Rt. 237 in San Jose, but who cares. Certainly their customers don't - but they do like their products.

I had the pleasure of sitting down recently with Rob Gagnon, an engineering manager at one such technology company north of Boston that manages the delivery of business applications across a company's IT infrastructure. If Rob is a typical example of the type of leadership talent that has set up tent at this company, they are a very fortunate company indeed.

In our hour long meeting, we discussed a number of areas, and Rob made it a point during our discussion to stress that a key goal of the quality group was to 'reduce uncertainty'. I really like that phrase because it addresses one core tenant of Quality - that it is 'an experience'. And what better way to do that than to build product confidence with the customer. So, how do they go about such a task? Rob's philosophy is to develop product excellence through - in a word - training.

Now, I know what you may be saying, that every company says they encourage training. True, it is a commonly pronounced anthem. However, they mean it here, and they achieve it through their consistent, and persistent efforts.

Rob insures that employees are bulking up their domain knowledge as part of the annual review process. However, it doesn't begin and end with issuing a check mark on someone's performance review. The company's new product engineers develop web based product training that quality engineers can become certified on. There is also classroom training (for customers) that the quality team is encouraged to take as well. They even offer brown bag sessions and seminars as the need arises. Again, they are consistent on their training methods, and persistent in its application.

Ok, so the quality group is well trained and current on product line technology developments. So what does that buy you?

Like all progressive engineering managers, Rob wants his development AND quality teams as far upstream in the development life cycle as possible. Think what a well informed quality engineer can bring to the table during the marketing requirements document phase. If this process is fully flushed out, the resulting quality of this effort just rolls down stream from there to the development plan (and yes, for your SDLC junkies, they do a combo Waterfall/Agile method which is very interesting, but could be a whole topic on its own).

Also, you don't want your staff speaking to your customer base if they are only superficially informed about your product. Again remember, they wish to reduce uncertainty with their customers and what better way than to have SMEs speaking with them. Ever see your customers speak with someone they feel is knowledgeable on their issues - they often want to adopt them.

Now, it's not to say that life is perfect. After all, what fun would that be! The company, like my golf game, has challenges it must overcome. Time to market and resource availability pressures can crimp even the best laid plans. And like most companies, they are not immune to these pressures. However, they do take on a very noble challenge from release to release - to work very hard at making sure, as Rob said; 'to put all the best practices into the box before it goes to the customer'. In other words, they take their test escape analysis process very seriously - attempting to turn lessons found promptly into improved quality release over release.

I would be remiss if I didn't point out an area of quality too often overlooked. The company's corporate office is elsewhere, and without a quality culture that encourages trust, good goal alignment and good communications (can't have the first two without the third), you've got ... well ... no trust, mission confusion and a rumor mill. Not exactly a recipe for success. This company gets it - the best ones always do. You had to look no further than Rob to see that this company values an inclusive culture, transparent communications and understands the importance of its role in helping employees be successful. Now that's a quality relationship.

Fran

Next article theme: Quality is Everywhere

Methods to The Madness: Qualitative vs Quantitative Approaches to QA

2009-07-21T08:00:00.000-07:00

Greetings!

Isn't it interesting that in the professional discipline of 'Quality Assurance', we most often use quantitative analysis for tracking status of projects. Shouldn't it then be called 'Quantitative Assurance'???

Last week in my article I mentioned Capability Maturity Model Integration (CMMI). I since had an excellent conversation with a colleague from a DoD company regarding their need for expertise in Change Management - do to a fairly large software integration project. They felt that employing the CMMI model during this project would be a critical success factor. That statement is music to my ears. However, they also felt that a training or HR resource would be needed to manage the effort. They are soooo very, very close on their actual modeling needs.

Some real quick background on this area. In the early 80's, the Software Engineering Institute (SEI) of Carnegie Mellon was approached, then tasked by the DoD to develop a model for engineering organizational development. The model design was to be a set of practices that could be consistently followed - with the ultimate goal of being able to produce high quality software in a reliable fashion. Software development at that time tended to be an adventure, and with the industry growing, any effort to bring a sense of order would taste like a cool glass of lemonade on a hot summer day. The original model was called the Software Capability Maturity Model (SW-CMM) - the predecessor of what is known today as CMMI. The model provides objective process standards levels - called 'maturity levels' - that would systematically guide organizations to higher levels of functionality - and thus higher levels of productivity (to learn more, please visit: http://www.sei.cmu.edu).

Many companies today, with the best of intentions, employ the model to develop their organizations - only to stall out at lover levels of the model. Why? Many companies do not realize that although the model takes into account many objective factors that can be quantified, it does not address the maturity level of their organizational culture (this means refinement of company people processes at the company - not that the company is being run by teenagers) . In effect, they are attempting to improve the quality of the organization with one tool - when two are needed. It's like building a house with a hammer - but no nails. (Note: Six Sigma initiatives succeed only when companies achieve a high level of model maturity)

Largely because of this reason, SEI has since developed a derivative of the CMM model called People Capability Management Model (P-CMM). Like its predecessor, the goal of the model is to provide a quantitative assessment of the maturity level of people processes within the organization, then provide a step level approach for bringing about a higher level of process maturity. Only when the P-CMM model is used concurrently with the CMMI tool, will the odds favor success. Companies have only a 59% chance for long term success with Change Management initiatives when using only CMMI - as opposed to a 79% rate of success when both P-CMM and CMMI models are used in tandem.

However, even though both models provide guidance on the implementation of quantitative analysis tools to measure progress and compliance results, a key success factor will also be a qualitative perspective that must be employed to determine the flexibility of the organization to correctly size rate and depth of implementation.

In this global, cross-functional world, no one department can tackle a Change Management project. The company I spoke with had it largely correct (sans integration of P-CMM). Although the initiative may be owned by Quality, a wide net of sponsors, stakeholders and teams members must be cast so the models can be effectively integrated for optimal result.

Change Management is an all hands-on-deck kind of thing that requires integrated, systematic approaches, multiple perspectives, quantitative analysis and definitely qualitative reflection regarding your most important asset - people.

Fran

Next weeks theme: 'Company Road Trip'

Company Road Trip: To LEAN or not to LEAN .... that was the question

2009-07-10T06:20:00.000-07:00

Greetings!

I really love these road trips! You get a chance to get out from behind the laptop and off the cyber highway, and instead roll the tires, press the flesh and talk quality face-to-face. Todays virtual world has proven to be more efficient, but maintaining ones network and increasing their knowledgebase should include regular roads trips as part of the recipe.

I recently visited a major telecom company to discuss activities in the area of process improvements. Over several years, they had gone through a number of acquisitions. This is tricky business, and if not extensively planned for, can come back to bite the organization in later years in the form of disjointed tool roll outs, broken processes and organizational mis-structures. There are very valid reasons for this, and it usually has to do with limited budget dollars being spent on what is considered critical path projects that will contribute directly (ROI stuff here) to future revenue growth.

I met with a person responsible for hiring a senior level process improvement director. Two major questions I had for her were: 'What changed that you want to hire this person now?' and 'What key skills are you looking for in this role?'.

The answer to the first question was not the result of some 'ah-ha moment' they had, but rather pure economics. Consumers are spending less on their services, and the need for a more efficient business process strategy that could be supported by a lean organizational structure was in order. The answer to the second question was most enlightening.

They felt having someone with a Six Sigma background was a must. As they paraded a number of Six Sigma Black Belt candidates through their doors, they were uniform regarding one particular query to the hiring manager: 'Is there executive level sponsorship for the initiative?' The answer was:' No, that's what we would hire you to do - champion this initiative and be responsible for its outcome - as the executive leadership would not have the time to be involved'.

Anyway, they felt hiring a Six Sigma Black Belt maybe was not the way to go, and that smaller incremental process improvement steps - say via the LEAN methodology - would be the way to proceed. At last update, this was still in discussion.

Now, I know what you're thinking, but I'm hear today to say kudos to the company for making process improvement a priority. They recognize the need - a big first step for them - even if they are not quite sure at this time what is the best strategy.

This is where quality folks can really add value. As much as a quality professional's role is to improve products, services, processes, etc, understanding your audience and providing appropriate information to help them traverse knowledge gaps is a real winning strategy.

Imagine if those candidates for the role mentioned above researched the company and came equipped with say - a CMMI model as a learning tool - and provided some background on the model, where they feel the company fit into the model and a vision for future development. Powerful stuff - knowledge that companies could benefit from and it shows impressive thought leadership from the candidate.

Fran

Next weeks theme is 'Methods to The Madness: Qualitative vs Quantitative Approaches to QA'

Methods to The Madness: Finding your way along the test case audit trail

2009-07-02T07:19:00.000-07:00

Greetings!

First things first. Finding a clear trail from a functional test case back to the original business requirement from whence it came can be, at times, more difficult that finding a seat at the movies after the lights go dim. There ... I said it. It's an ugly truth, but one that is prevalent - even if test managers do not always wish to expose this gap.

Also, I am not saying that all industries have ambiguous compliancy models in this area. Certainly FDA compliancy standards wield a sharper edge than say ISO standards. Please don't misunderstand, the ISO is a fine organization and the standards they promote are ones that I have always attempted to follow as a QA Manager. However, the risk of non-compliance with ISO is not the same risk type as non-compliance with say - the FBI or FCC - which I have had the pleasure to partner with regarding compliance standards.

Why is it then that the test case audit trail can often be ambiguous or even disjointed? There can be any number of reasons or combination of reasons. Lack of tools and time-to-market pressures are two mentioned often. However, I have seen tools that many times are available but are not used effectively. And, there are always pressures to work quickly. So, what's a QA group to do?

The complexity of SDLC (choose your methodology) precludes a desire to come up with a one-size-fits all solution or have one root cause. I have found that listening to the folks developing the test plans/cases for clues is a great place to start. Some good questions during these conversations that come to mind would be: do they understand and are comfortable with the organizational mechanics of feature development, do they have a good handle on the feature they will be testing and do they know about point-of-origin and justification for the feature? Many times the test group for the release may not have been effectively integrated into the process .... regardless of what the Gant Chart states.

Managers would be wise to be actively involved in the release planning process to ensure that resources are scheduled in the requirements gathering phase - then make sure it happens. The QA folks hold much historical information on feature testing and can contribute greatly during the feature requirement and functional specification development phases.

Also, be sure to explore with the QA group available options to link your test cases directly back through the functional specification to the business requirement. If there is a in-house tool, champion its use. If not, and budgets are tight, champion an effort for using another method. I've seen Excel do a decent job - as long as cross functional groups have ID'd their respective requirements. Consider it a critical path activity.

The key point is that when QA understands the direct relationship between the tests they are executing and the origin of the business requirements, they will have more confidence to champion and chart product quality not only in terms of test pass/fail rates, but also to speak more broadly throughout the organization regarding overall product quality.

Early resource involvement and becoming a champion for a quality process that casts a wider communication net adds value to any organization. And, you'll make the compliance folks very happy!

Fran

Next weeks theme is 'Company Road Trip: To LEAN or not to LEAN .... that was the question'

2009-06-19T07:32:00.001-07:00

Quality Sphere
- version 1.0 -

Greetings!

This is the very first article of what will be a weekly series of articles delving into the subject of Quality. I would like to use this first edition to explain why I am writing the articles (the typical stuff: my background, reasons for the article, hopeful benefits and what you can expect). I promise to keep it short and the boredom level hopefully low.

My background:
I am a quality and technical program management professional with over 14 years of functional and project management experience in the area of quality ranging from start up organizations to fortune 100 companies.

Reasons for the article:

Most notably, I am in transition from my current role(translation: the fortune 100 company I worked for had to contract their workforce), but am looking forward to sharing information I gain along this transition road - and it's a great way to stay connected and informed.

I volunteer for a networking group and on several occasions folks made a reference to the term 'quality' as one entity. So, on several occasions I have said (nicely) , " The quality profession is not homogeneous. True, the world of quality may have a generically common thread of purpose; however, depending on the industry the applications, tools, methodologies and expected outcomes could differ greatly.

Hopeful benefits:

My genuine hope for this article series is not only to keep abreast of the profession, but to also inform and entertain. And on a good day, and through on-line discussion, come up with an insight that may change the way we view our practice of quality. That would be exciting! .... so article comments are most welcome.

What can you expect:
The weekly article will have one of three themes (at author's discretion as to when the theme appears):

Quality is Everywhere: I find this area fascinating. The more you become attuned to seeing quality, or the lack thereof, the more you then see it - whether on the supermarket shelf, in a software test plan, production line adjacencies, your local town hall or in a customer service process. It's like one of those pictures you stare at - at first you see nothing but lines, then a figure suddenly pops out from the page!

Company Road Trip: This will be recaps of conversations I have had/will be having with management and other folks of import in various quality roles - whilst I am out looking for new opportunities . I have an exciting line up already of some really interesting companies in a wide range of products and services. Should be fun.

Methods to The Madness: Discussion around a specific methodology or repeatable process to guide or measure that thing we call Quality.

Done.

Hopefully, I finished before you went into ADM (automated dose mode) ... just had to throw in one for all you acronym junkies.

Next week:
Methods to The Madness: 'Finding your way along the test case audit trail'

Fran