Most people shudder when they hear Six Sigma focus within a technology company…They think creativity will be hindered and replaced with process controls…While on the surface, the textbook DMAIC program might contribute to that urban legend, the reality and practicality of it is that you probably wouldn’t want to introduce DMAIC first…In this example, I would recommend implementing more of the new process/product methodologies like DFSS, DMADV or SDSS or SPSS (coined by SBTI).
But, consider this…if a tree falls in the woods and no one is around to hear it, does it matter, even if that tree was the biggest, loudest, and most important tree in the woods? Equally, if a program is selected and implemented without metrics and controls, one never knows the health or the true state of their roll out, new product release; deployment –whatever; this concept can be applied to most anything in the business sector; it’s what I like to call ‘VOD – Voice of the Deployment’ which basically means "the health of their implementation". This is applicable to most any program or project. Metrics, when selected correctly, better known as KPIs, can be quite powerful (they can also be detractors, but that is discussed in my KPI selection blog entry from last week).
Selecting a tightly scoped set of metrics, relevant to your business leaders and linked to your strategy plan, cascaded through all organizational boundaries, from top to bottom line, will enable a deployment leader to prove success proactively. How…?
Well, we use MS Business Scorecard Manager for our BSC program…So, we should walk the talk and leverage the same concept (not necessarily the same structure) for managing our Six Sigma health metrics…Drinking the cool-aid and a true believer, this concept is new for us, and one that causes some trepidation…For us, selection of these metrics was a team effort, in which the black and green belts brainstormed the universe of potential metrics, in order to affinitize into logical subgroups and finally yield a tightly scoped list of metrics that serve two purposes:
1) they rollup to the corporate strategic objectives for the year and 2) they cascade from top through the BU and finally through the Six Sigma yearly objectives. This will give you true light of sight and will help place the importance on the correct metrics, rather than just any metrics that you deem important.
Some of the KPIs that could be leveraged that go against the typical metrics that I have seen used (# of black and green belts trained) in a product development environment are:
# of black belts placed into a leadership position after in the 3rd year;
# of days spent per phase per belt of the development cycle
Total dollars generated as a result of design projects driven by a belt
# of iterations requested by the business to the design or scope post project charter
# of projects in pipeline for six sigma
# of Pri 1 bugs that shipped immediately after release (will tell you if your program is helping at all improve the quality of your dev team)
(% of total project list that are six sigma projects) – yield an idea of how much your program is impacting your product dev lifecycle and output of projects
It is important after Year 1 to start thinking about metrics and proactive reporting of your program and belt status and what better tool that the sharepoint based BSM that Microsoft offers. It is easy for end users, less easy to implement without consultant help, extremely scalable and extensible (though I wouldn’t necessarily recommend the latter as you should go out from the gate with controls in place about what type and in what look and feel for scorecards should be adopted). MS also offers some cool scorecard tools for building more robust controls and metrics in their new product PerformancePoint 2007. In fact, you get 3 products for the licensing cost of 1, with the acquisition and integration of ProClarity with what was formally called Biz #. They now look at these in two buckets: M & A (Monitoring and Analytics which is where BSM & Proclarity fit in) and Planning (which is where the former Biz# fits in).
These tools wont help you select KPIs which is my personal bug-a-boo…I am a stickler to manually defining your strategy map, then your KPIs, then your vehicle, your frequency of updates needed, and lastly, the SLA of your IT support needed (if you implement outside of the IT department, and have to leverage them to support your productionalized scorecard platform). Once all of this infrastructure is in place, you are ready to start the software selection process, if you have good traction in your manual program; i.e. good traction and user adoption.
Even better, if you are already leveraging Sharepoint for your intranet site, you will have achieved an easier roadmap towards user adoption because your users will already be used to navigating the same look and feel as offered by BSM. In fact, BSM is just a webpart in which you drop onto a web part page in Sharepoint. How simple is that?
Imagine leveraging this to measure your black belts and green belts with Red, Yellow, Green indicators or measuring the progress of your program by thresholding the amount of bugs that are getting shipped with the code you are implementing (hopefully with a decreasing trend if implemented correctly). It creates a background that is driven by process, but not at the expense of creativity.