Uncontrolable IT

Six Sigma – iSixSigma Forums Old Forums Software/IT Uncontrolable IT

This topic contains 3 replies, has 4 voices, and was last updated by  Yadav 11 years, 9 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #26701


    I feel frustrated by the fact that when we do six sigma projects, often system and IT bottlenecks are identified as causes of defects/delays etc. But IT is centrally controled and it is wishful thinking to expect them to solve their issues within the typical six sigma project timeframes. What results is that we have no choice but to treat such issues as uncontrolable and focus on those causes that are in our department’s control. I am talking from the perspective of a large services organization. Have others faced this situation and how do you tackle this?



    Do exactly what you are doing and report the System/IT issues as
    Issues/Concerns when reporting progress on your project. In your final report you should report the System/IT stuff as an
    opportunity for further improvement.Get you champion to get a dialog going between the Deployment
    Champion and IT



    Ramesh you are facing a classic problem – it happens between departments/divisions frequently.
    Stan gives good advice. And, your solution will come only from getting high enough into your company to find someone who cares about breakthrough performance and who has control over all participating groups. That person exists – you just have to find them and convinve them changes are necessary.
    It’s the old story of the weakest link. You cannot get Dept A to 6S with Depts B, C & D at 2S.



    The issues highlighted by you can be resolved or taken care of by scoping the project at the appropriate level and take buy-in from all the stakeholders.
    Typically before you kick-off the project, it is expected that you do the SIPOC, which will help you to scope the process based on the inputs and agencies, which will be focussed on, in your six-sigma project. When you face a situation, where-in another dept. is involved, you can get a representative from that dept. in your project or keep that process step out of scope.
    Once your scope is finalised you will have to finalise the team members by getting representatives from these processes so that you can influence these processes. This way, you get their buy-in before you start working on your project.
    A pareto chart will be helpful to understand, what % of contribution is made by different processes/ causes. If the contribution from the other dept. is not so significant (less than 10%), it is better to focus on remaining 90%, which is within your control.
    Hope this helps.

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

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