Six Sigma

[malvolio]

OK, but the "How" of quality improvement is to establish a set of KPIs and then measure them over time and count the improvement. For example, waiting times are too long, so the KPI is that nobody should be on the waiting list longer than 20 minutes before being attended to. So the team set up a pre-waiting list queue where you are parked until your call can be done in 19 minutes, when you get moved to the "real" queue that feeds the KPI. Sound familiar?

The management mistake (and I've seen a few cases) is to view support as a repeatable, consistent process. It isn't: if a given incident is repeatable, it is liable to the same resolution and should be on the known errors log with its cure as an output from Problem Managaement. However, most calls require different things to happen before they are resolved - and that takes them out of realistic scope for Six Sigma.

As for code development: either it's bespoke, in which case it's a one-off and so unmeasureable agasint anything else, or it's agile in which case who cares since it's cheaper to recode than improve.

Turn out 7m tonnes of housebricks though, and you might have a case...

[daviejones]

OK, but the "How" of quality improvement is to establish a set of KPIs and then measure them over time and count the improvement. For example, waiting times are too long, so the KPI is that nobody should be on the waiting list longer than 20 minutes before being attended to. So the team set up a pre-waiting list queue where you are parked until your call can be done in 19 minutes, when you get moved to the "real" queue that feeds the KPI. Sound familiar?

The management mistake (and I've seen a few cases) is to view support as a repeatable, consistent process. It isn't: if a given incident is repeatable, it is liable to the same resolution and should be on the known errors log with its cure as an output from Problem Managaement. However, most calls require different things to happen before they are resolved - and that takes them out of realistic scope for Six Sigma.

As for code development: either it's bespoke, in which case it's a one-off and so unmeasureable agasint anything else, or it's agile in which case who cares since it's cheaper to recode than improve.

Turn out 7m tonnes of housebricks though, and you might have a case...

Six Sigma and ITIL complemet each other, which is the point that some of us were making.

[mailric]

i've dome the Lean and DFSS - but its broadly the same as TQM from back in the day, maybe a bit more applied outside of manufacturing. (even quotes alot of the 70's gurus!)

its the same as Prince II - might come in handy if your building a space shuttle.

Otherwise, as long as you get a decent grip of the principles theres some pretty useful (if not original) stuff in there.

[polus]

I took an instant dislike when a self confessed six sigma expert told me Engineers were incapable of problem solving, this after Id told him that Im and Engineer (third sentence after meeting in a social situation). He then went on to describe a problem that a cup manufacture had tasked them to solve and how they managed to save the day but all that came across to me was that Six Sigma had been used as a badge to charge obscene amounts of money.

I presume it has its uses and that the courses dont transform all attendees into arrogant muppets?

[mailric]

met a few like that myself. once met a master black belt who i'm pretty sure thought it made him somewhat yoda like.

[Sockpuppet]

met a few like that myself. once met a master black belt who i'm pretty sure thought it made him somewhat yoda like.

No but the amount of cash that he can command does.