Six Sigma is a data driven method for evaluating and identifying improvements to a repeated process.
Six Sigma was originally a very simple notion: if you make widgets and less than 3.4 per million are defective you're doing well. It was a good target to aim at. Though if you were going to ride a rocket into space which had a million parts and six sigma quality would you be happy knowing 3 or 4 parts were probably going to fail...? ("Sigma" is actually a statistical term meaning the standard deviation from the mean of a normal distribution. Very few things lie outside 6 standard deviations from the mean.)
The idea was simple: measure the error rate of each step in a process, identify processes with high and/or unpredictable error rates and improve those processes. And keep doing that until you reach six sigma quality levels. And then don't stop, keep on getting better - for ever. Hence the term "continuous improvement".
These days the term Six Sigma is used more loosely to describe just about any programme which has the aim of
Can Six Sigma be applied to software development projects? What does 3.4 parts per million mean in terms of software? Only 3.4 out of every million software applications have any bugs in them? WOW! Don't think so. 3.4 out of every million lines of code has a bug? Maybe. 3.4 out of every millions characters in the code is wrong? That's certainly more plausible. Could be an interesting debate, but actually it's irrelevant so forget about it.
Let's go back to what six sigma is: a data driven method for evaluating and identifying improvements to a repeated process.
I will give you an example: your programmers find 50% of the errors in their code when doing unit testing. Is that
good? It's appalling! But worse, sometimes they find 100% of the bugs but other times they find none of them. At
least if they always find 50% you know where you stand. If they were my
programmers I'd want to find out why they sometimes find 100% and sometimes none, and put in place something that will mean they consistently find around, say,
50%. I can then do two things: plan system test accordingly and secondly see if I can get the programmers to improve that
50% to 60% on the next project. And do you know what? I have myself a six sigma programme alive and kicking.
Let's say your team found 80% of the errors in their functional design document, the other 20% being found later in development or in live production running; and they found 10 errors in every 100 pages of the functional design document. So you set a couple of benchmarks: 10 errors per 100 pages and 80%.
Next project they find 8 errors per 100 pages (and have used the same error detection procedures). They are getting better, you might think, they're making fewer errors. But, unknown to you, on the first project the functional design was very detailed - all the logic, screen shots, report layouts, etc but in the second project the functional design was an airy-fairy, vague, high level summary. Comparing errors per page is meaningless - you're comparing apples and oranges.
So, one of the major tenets of a six sigma programme is to have a consistent process. In software development this implies a rigorous, consistent (and therefore repeatable and improvable) software development lifecycle (SDLC) in which everyone (at least everyone within a given organisation) goes to the same level of detail in the functional design document and indeed in every other step of the software manufacturing process.
Ah, but technology keeps changing, you say. Well, yes, but not so fast or so radically that you can't get a major
degree of consistency in what you put in functional design documents. Technology changing is an excuse for not bothering,
not a reason for not trying to improve things. And not putting as much detail in the
functional design document as previously because you ran out of time is ludicrous
and you definitely have an out of control process on your hands. Unless you fix fundamental problems like that any
six sigma programme will be just so much window-dressing.
So six sigma isn't about having a few pretty graphs. It's about having a disciplined software manufacturing process in which all the workers on the production line understand what should happen at each stage - requirements analysis, functional design, technical design, etc - and understand their roles and responsibilities.
In a software project the SDLC, the manufacturing process, is enunciated in the project plan - the schedule of who will do what tasks and when; how errors will be found and removed; etc.
In a software project control implies several things: knowing where you are versus where the plan says you should be; having metrics that measure error rates; etc.
In software projects all of these things fall under the umbrella of project management. Planning, controlling,
ensuring quality checks are planned and performed, measuring defect rates and ensuring defect causes are dealt with
are the responsibility of the project manager. And the ability to do these things is not instinctive - project managers
need to be trained.
Our training course for project managers is not branded a Six Sigma project management training course, but the ethos of the course is very much six sigma. We cover the software development lifecycle stressing the importance of consistency and discipline; we cover building the schedule and building in quality checking activities; we cover controlling vs the plan; we cover quality metrics to illustrate the principles of numerical quality control in software projects; we cover quality circles and defect causal analysis; and many other things!
You may also want to attend a specifically six sigma statistical quality control course, but actually if you did all the things our course recommends you would be a long way down the track to having a six sigma programme in place even if you'd never heard of six sigma. A rose by any other name would smell as sweet...
Please click here for details of the
Project Management Course
Articles on Project Management:
So You Want To Be A Project Manager?
Risk Management in Software Development Projects
Quality Management in Software Development Projects
The Tale of Three Project Managers
Towards a Project-Centric World
Project Management Proverbs
Project Management Book
Project Management in the Public Sector
Copyright M Harding Roberts 2005 2006 2007 2008
six sigma six sigma software development six sigma IT projects six sigma software development projects six sigma project management
Home Sitemap Contact Us Project Management Articles Project Management Book IT Project Management Course