Friday 28 June 2013

6-Sigma twaddle

Diversion - I've wandered into a management quicksand as part of my asset management explorations.

Lean Six Sigma: Combining Six Sigma Quality with Lean Speed - WHAT - is this stuff? 

Read more: http://www.ehow.com/about_7296799_difference-six-sigma-six-sigma.html#ixzz2Wy5Rw5Zp

This surely is management twaddle gone mad! Brown belts, yellow belts - do we really need all this - not very agile and looks a bit old school. I'm sure its all very well for improving what a business does but do we really need all the associated scientific psycho-babble.


Quote from my font of knowledge;

"Hence the widely accepted definition of a six sigma process is a process that produces 3.4 defective parts per million opportunities (DPMO). This is based on the fact that a process that is normally distributed will have 3.4 parts per million beyond a point that is 4.5 standard deviations above or below the mean (one-sided capability study).[6] So the 3.4 DPMO of a six sigma process in fact corresponds to 4.5 sigma, namely 6 sigma minus the 1.5-sigma shift introduced to account for long-term variation.[6] This allows for the fact that special causes may result in a deterioration in process performance over time, and is designed to prevent underestimation of the defect levels likely to be encountered in real-life operation.[6]
The role of the sigma shift is mainly academic. The purpose of six sigma is to generate organizational performance improvement. It is up to the organisation to determine, based on customer expectations, what the appropriate sigma level of a process is. The purpose of the sigma value is as a comparative figure to determine whether a process is improving, deteriorating, stagnant or non-competitive with others in the same business. Six sigma (3.4 DPMO) is not the goal of all processes."

If you believe all that you will believe anything - can we get some real scientist involved please.


Friday 21 June 2013

Agility fragility

Everyone says they are but are they really?

I'm talking about - agile - that's in the systems development sense of course. Though when I think of agile my analogy is of a footballer who has the ball and is running down field avoiding tackles changing direction etc. That's agile in my mind - making changes and looking for opportunities to gain an advantage on-the-fly.

In software and systems development the term agile seems to be cropping up everywhere I look. Agile development, agile design, agile management, agile this, agile that. However, the question in my mind is, is the systems engineering industry really ready or 'real' agile.

A few worrying issues are appearing. Firstly the industry is developing an 'Agile Standard', certificates the lot! Doesn't seem to fit very well with the concept. Having worked over the past few months with leaders in system development. There is a willingness to embrace the concepts of 'agile' but we are all struggling letting go of our background in structured approaches to systems development. Which now, given the speed at which things are changing definitely looks like an 'industrial era' approach to design.

When I check my font of all knowledge Wikipedia its not much better - a thousand and one versions of what people think agile is - very well presented though! High level concepts fair enough but where the rubber hits the road not much cop.

The journey continues......






Saturday 8 June 2013

When do you stop....

So when do you stop?

That's requirements gathering and defining and modelling and verifying and ...

At some point you need to get on with it and start designing and building. But when is the right time to begin - we just need to check we have the requirements in from planet zog and then we are good to go!

There is also a bit of Parkinson's law going on in this phase of the systems engineering lifecycle. A bit of of well we have a few months (years) left to go lets have another cup of tea and think about some more requirements. Just when do you have enough requirements?

What's the answer - nobody knows! There will be a tipping point in every project and then the muck hits the fan and off we go - then its - what requirements - I'm too busy building stuff!

You would almost be better off starting by creating a 'Compelling Event' milestone in your project plan - by plan I mean a high level plan - not the Primavera I've planned everyone's tea break's for the next 5 years type plan. The 'Compelling Event' might be something like when we reach 100 requirements that's it we are going into build or it could be if you don't have something working by now then you are all sacked.

Either way, this would provide a point of reference for everyone to sign up to and then focus on. There obviously needs to be an incentive scheme associated with the CE or it will be just a 'so long thanks for all the fish' point in people's lives ;)

Sort of on optimised Parkinson law!