six sigma and low mature software organization

Six Sigma – iSixSigma Forums Old Forums Software/IT six sigma and low mature software organization

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #26523


    I am looking at the issues in adopting six sigma in low mature software organization as a part of my masters degree program.
    I would be grateful to receive any piece of information regarding adoption of six sigma in such organization. If anyone has idea regarding relevant literature in this area, please do suggest me.
    Thank You



    A large part of the questions is how low is low.
    When a Black Belt undertakes a project in a low maturity organization, getting measurements tends to be the big problem.  Software organizations in particular tend to resist measurement, so the culture of the organization can be a large barrier.
    SS is also very process oriented. In many low maturity software shops the process is ill-defined or poorly understood.  In these shops getting a handle on the process can be a challenge.
    If the belt can get the necessary measurement systems in place, then SS can be a potent tool in improving the organization’s maturity.


    Erik Iglesias Abella

    1. First: what is the mission of your company? SW development, IT maintenance and outsourcing or Value-added consulting?
    2. When you answer this question, a practical experience in the 4 IT companies where I was, is that: Don’t sell only 6S, sell CMM/CMMi, ITIL and or CobiT to your management, it is more directly “language” of the industry. Particurarly I have very good experiences with CMMi, the management must see that this is their challenge and idea. CMMi very good helps SW companies with low or with high maturity.
    3. Divide the actions (the improvement areas) in the company in 2 main streams: Organization and projects. Then will be really more easily to introduce the tools, frameworks and techniques that you need: Measurement and analysis, process management, SQA. Dividing means: prepare presentations, GAP analysis for each part, start measuring, never complex measures, only primitive (basis) measures, find people inside the organization that will help you from 2 “castes” middle-higher management that will support you (sponsors) and specialists – the future SEPG teams. Prepare balanced presentations (agressive and sometime intimidating introductions pragmatical messages and optimistical objectives.
    4. Take a little time to prepare the .mpp and be sure, that NEVER you will achieve the plan final milestone that you first planned, after the third iteraction and 3-4 months you will have a much better estimating data,
    5. Remember: The more SW development projects the company do, the best to use CMMi, the same with IT maintenance and ITIL or consulting and CobiT.
    6. prepare really a widely set of smaller trainings, never try to train the configuration management at one – better prepare a workshop presentation about baselines, Config item or CMSystem. You will see how often you will use them again and again …
    7. YOU ARE NOT THERE FOR CREATING ALL THE SYSTEM, you coordinate and manage the creation, enhancement and improvement of the system, but the company creates and improve it. The responsibilties must be given through all the company. 2 months after you start, have prepare and present an SEPG chart or something similar, a chart for each SEPG team – if you will have more of them and a certificate for each SEPG specialist (if you don’t want to go via SEPG teams but via SEPG specialists – “gurus”, advantages and disadvantages are more in each alternative),
    8. It will be without discussion an initiative or program (depending to the PMO, PgO or Project management framework that is or should be implemented in the org) but with more projects – be carefull to always manage this like projects!
    9. Find the typical improvement types from the beginning – then the improvements will be better undestood by the management and employees and they alone will get this like something “in their responsibility” don’t find at the beginning all the improvements. Manz ideas will confuse.(Improvement type: variance reduction, shorter learning curve, less defects, improvement: reduction of (estimating-actual)/estimating, quicker project management – risk management learning …)
    10. AUtomatize the maximum of simple tasks: issues management, tasks management, documents and assets review…
    There are more issues and ideas, those are only from the practical point of view, theoreticaly I don’t know… 

Viewing 3 posts - 1 through 3 (of 3 total)

The forum ‘Software/IT’ is closed to new topics and replies.