R Rajesh

Hi Kavitha. In those questions, we were trying to find the optimum ways of utilizing or cajoling the team to incorporate management/leadership team's mantra of process improvement activities which can help to achieve in zero defects. There are 2 things to be noted here. 1. Engaging the team was to create the mindset so that it sets into the DNA of the workforce. 2. Zero defects is a management myth to create a buzz. This is akin to.the saying " Aim at the star and shoot at the sky". So aim for the best and finally get closer to it. W.r.t 100 % quality, yes customer would be happy if he/she gets it but can the provider of a service or a product maker can confidently say that his/her process or product is 100% defect free and vouch for it before the service/product is delivered/created? Only tutorial centres will say (lie in most cases) that .. "Join us and we will make you pass. 100% guarantee" . Bottom line is a process or product cannot guarantee you 100% defect free service or product.

Even Nasa which is supposed to operate at higher levels of Sigma as we probably would have heard and seen has failures in its mission.

Good story really which I have also heard. Having said that there are few things which I would like to share. First of all, a country can have a stand/principle of zero defect policy. But the challenge is to have that implemented which is what am trying to insist. The second one is we always equate the dabbawalahs to operating at six sigma level. If we go by that way, it says minimise the variation(and therefore defects) and not eliminate it. So the rarest of failures can happen.

Hi Srinivasa Vasu, first of all, appreciate your presentation of points in your posts. W.r.t SLA., this is precisely the reason , as why people go for SLA range. The organisation that provides the service knows that it cannot provide 100% defect free system to the customer and the customer is also aware. Hence they come to a service level agreemeent (SLA). So the belief itself is that 'Zero defect' is not achievable, and hence they fix a SLA, which is what my argument is. So the SLA tells about your capability (at what level , you can achieve things tothe maximum hilt - but it also says in this case, that you cannot achieve 100% correctness) . This is my view

AGAINST No system can be fool proof. Achieving zero defect is not practically possible. This is why every organisation has a Service Level Agreement (SLA) with its customers in a range. such as >95 % or > 98 %, when it talks about defects free system . No organisation says 100% which is totally out of the equation. The customers also are aware and they are ok to this. Thats the reality everyone knows . This is also precisely the reason, why a process improvement methodology such as Six Sigma says , "minimise the variation" and not "Eliminate the variation" , which is practically not possible. One may think that this zero defect is not achievable/possible only where human element is involved. What if automation/Robot is involved in some activities. Say for instance , take Robots which do complex operations across industries. Imagine a robot is helping a doctor in a complex medical operation . The robot can do the operation and can complete it successfully. The question is cannot it fail ? Can it malfunction atleast once in its lifetime ? Quite possible !! The hospital , therefore will always say that ... ... "Our Success rate is high for that type of operation..." Because of the robot, the success rate will be high and the failure rate will be extremely low, which is what needed for the human being. But nevertheless still you cannot get rid of the rarest failure in this case .

RACI It is an acronym. Purpose of RACI which is put as a matrix, is to clearly articulate the roles and responsibilities R- Responsible – who is in-charge of the activities to do the work A – Accountable – who is for accountable for owning the work and taking decisions for providing actions C – Consulted – who would be consulted for the activity for feedback I – Informed – who would be the informed on the actions or decisions ARMI As a project management it can be used to analyze the support of various stakeholders as we traverse across phases of the project. The acronym stands as A – Approver (Sponsor/business lead) whose approval is needed R – Resource – Skills of a SME, who will be needed for a specified duration M – Member - Who will be full time on the work I – Interested Party – a stakeholder, who would be interested in knowing the project status Let us see the difference between RACI and ARMI S.No RACI ARMI 1 This will be used when we want to know who is responsible/accountable/decision-maker for a work or activity. Here focus is on the activity that needs to be completed and by whom Here the focus is on which stakeholder is playing at what role at a given point of time (as we traverse through various stages in a project) 2 Normally this is a static chart or may not change much in terms of personnel assigned for each role (increase in team size , can increase the personnel count in each role though) In Every role prescribed here, change will happen much more than RACI ,as we traverse through the various stages of the project 3 This is prepared when usually there is a confusion of the activities or work being done by the team as who would be doing what or which activities This may not necessarily happen or created in a confused state 4 There is a Consulted role here which does get involved predominantly in critical activities normally. But the personnel playing that role will not be part of the project team. There is no equivalent role here which is similar to ‘Consulted’ role in RACI. However , ‘Resource’ role is there as an expert role which can be there for a specific period but later can be part of the project team (‘Member’ role) 5 There is no explicit Subject Matter Expert (SME) role that is mentioned here There is explicit mentioning of SME role (‘Resource’ role) Conclusion As we have seen the differences, the focus on RACI is about the work, whereas the focus is on the stakeholders vis-a-vis their roles across various stages of the project. Hence i would prefer RACI matrix, given a choice.

Prerequisites for creating a new product 1. Study the market and observe how it is 2. Then reflect upon the products that your organisation have 3. Measure or identify how much the existing products lag behind the market needs 4. Decide the target recipient for this 5. Decide the technology in which you want this to be designed and created 6. Decide what and how exactly you want to do with your new product 7. Produce a prototype and check if it can match to your expectation, when converted to a full-fledged product development Step 6 is what needs to be focussed. How to design and develop your product? How do you decide your product specifications? Let us discuss in detail. 1. What are the Critical To Quality (CTQ) Characteristics that is used for this new product innovation? For any product that needs to be created, the key is the characteristic that can affect the product. Based on the voice of the internal customer(s)/stakeholder(s) , the CTQ should be obtained. The CTQ should be measurable. As a hypothetical example, let us say an IT company uses some key Mainframe based products (read applications). Now as an innovation, the company wants to integrate seamlessly these products with some java based products. Instead of coordinating with the mainframe based products, it creates a new product which runs on SpringBatch software (based on Java POJO development approach, rather than traditional Mainframe Batch). Now the important characteristic that is looked by the team is the ‘response time’. How quick, we are able to retrieve the data. 2. How to decide on the specification limits for the CTQ characteristic? - This can come with experience /knowledge of the personnel involved - This can be set based on the limitation of technology / development process itself - This can be based on the limitation on external conditions, in some cases - After many trial and errors - Prototype sometimes can provide a pointer as to what level, we can set the specification limits. 3. One of the best ways to put your thoughts (of having new product) into action is usage of Quality Function Deployment (QFD) tool. QFD provides a process for planning new or redesigned products and services. Of course, the input to this is Voice of Customer (VOC). The QFD matrix helps illustrate the linkage between the VOC and the resulting technical requirements. The VOC here would be internal and could be primarily from the observation/study on the market. With the QFD, the functional (product or customer) requirements can be converted into technical requirements. 4. Once the specification limits are known, it can be put in, during the design phase of the product, thereby having a better product once it is developed. Conclusion Setting the Specification limits upfront for critical characteristics of a product is important as it can help in better design of the product. Often this is missed out and at times, the product may not get the due it deserves if this is not addressed.

Rolled Throughput Yield (RTY) Also known as Rolling effect, this talks about the probability that a single unit can pass through all the steps in a process, free of defects. It is the net result of the effect of all of the steps in a process.There are few other things which need to be discussed. Yield is one such stuff. Yield It is the percentage of units coming out of a process, free of defects. Now let us see why yield and RTY are important. The moment we think or talk about a process, two things would come to our mind – most of the processes would not have a single step alone and therefore multiple steps could be there and every process would have some variation. Now when we talk about the variation in a process, we need to consider and take into account the cumulative effect of variation that happen in each step of a process. This is what RTY is all about. Before we find out the RTY, we need to find the First-Time Yield (FTY). This is needed for each of the step in a multi-step process to calculate the RTY. FTY : The number of good units coming out of a process or step divided by the number of total units going into the process or step. Let us see some examples.: Eg:1 Let us see the common steps involved in the manufacturing of a Mobile. The steps involved in this process are Order receipt (Step 1), Material Procurement (Step2), Board Assembly process (Step 3), Final Assembly Process (Step 4), Quality check (Step 5), Rework process (Step 6), Final Quality check (Step 7), Packing and Labelling (Step 8), Shipping (Step 9) Now let us calculate the RTY for this mobile manufacturing process. Remember each of the steps mentioned may itself contain several sub-steps which we ignore for brevity sake. We focus on the respective step’s FTY. RTY = FTY of Step1 * FTY of Step2 * FTY of Step3 * FTY of Step4 * FTY of Step5 * FTY of Step6 * FTY of Step7 * FTY of Step8 * FTY of Step9 Now let us assume that yield of all steps is 99.379% (0.99379) which is at 4 sigma [Note: putting each steps’s sigma at the same level for providing easy DPMO values (for easy understanding)] Then RTY = 0.99379 * 0.99379 * 0.99379 * 0.99379 * 0.99379 * 0.99379 * 0.99379 * 0.99379 * 0.99379 = 0.945478. Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 RTY 0.99379 0.99379 0.99379 0.99379 0.99379 0.99379 0.99379 0.99379 0.99379 0.945478 RTY of 94.54 % means that 94.5 % chance of getting through the mobile manufacturing process without any defect. But the sigma level is down to around 3.1sigma. This is far off, from the probability percentage for each of the step. At 4 sigma, Defects Per Million Opportunities (DPMO) would be 6210 and for around 3.1 sigma range, it would be around 50000. So how many steps are needed for a RTY to be acceptable? The answer is that fewer the steps, better or higher will be the RTY. Eg:2 In a software development project, for delivering the code , a team had a five-step process to deploy to UAT environment (Customer) Step 1 Step 2 Step 3 Step 4 Step 5 Development (Coding) Code Review Unit Testing Unit Testing Review Fix System Testing defects Assuming if the steps are operating at 3 sigma, then the RTY for this would be at around 2 sigma. Step 1 Step 2 Step 3 Step 4 Step 5 RTY 0.9332 0.9332 0.9332 0.9332 0.9332 0.70774 Now the next question is that can a process have RTY as 100% and even if it is so, can it be considered inefficient? Because is a net result of the effect of all steps in a process, RTY being 100% is virtually difficult impossible at a macro level. At a micro level for each step, this could be possible to some extent, but when it comes at the overall steps at macro level, this may be difficult to achieve. Also to arrive to such a maturity in process, it may take quite some time. That maturity might come from reducing steps (Eliminating waste) and also improving processes / process steps. Now if there is a process is available with RTY as 100 %, then it can be considered effective (outcome) but not be efficient (process of doing that). Say for instance, a process has 10 steps and all steps have a yield of 100% and hence the RTY is 100%. Assume, now customer wanted some change in the process flow. Unfortunately for the current month, the team could not achieve 100% in all the steps with this changed process flow. The team found that they can eliminate few steps and minimize the potential variation that could happen and increase the RTY value back to 100% sooner. So the bottom line is even if RTY is 100%, as and when change happens to the process, there could be impact on the RTY. So in such a case, lesser the steps in a process, greater will be the chance of RTY being still in 100%. Then only we can consider a process with an effective RTY (with 100%) deemed as a process with an efficient RTY. Conclusion Better First Time Yield (FTY) will give higher Rolled Throughput Yield (RTY). The most influencing factor would be the process steps involved in a process. Lesser the steps, greater the chance, for increasing the RTY. Greater the RTY, will result in lesser variation.

Hawthorne Effect: This is about how a person/individual (read worker) changes an aspect of his/her behaviour when his/her activities are observed or monitored by someone and the resulting increased attention could lead to temporary increases in productivity in a worker. Eg:1 In an IT development project, the dev team is doing software estimation process. While doing the estimation, team members would be providing their estimation inputs to the functionalities (requirements) that would be developed, to the project lead (especially in a waterfall methodology). In a normal scenario, when the team is rich in experience and expertise, the project lead would collate that estimation inputs and then after vetting the estimation, he/she would finalize the estimation. However when a team is having a mixture of experience (freshers/less experienced, experienced members), there is a chance that lesser experienced team members may provide padding to their estimations, which results in unnecessary additional period (in days, hours, or any predefined unit preferred by the team) of estimation. That additional period is added as a buffer to ensure that a given requirement is finished within that buffer days (let us keep that in days, for easy comparison), in case where the team member is not able to finish that requirement for whatever reasons. So the project lead sits with those team members and educates them how to do effective estimation and would monitor every now and then. As a result, the lesser experienced members would not pad their estimations and this would do proper due diligence and provide right estimations. Having proper estimation would naturally give the right productivity. There could be similar functionalities (requirements). Requirement 1, Requirement 2, Requirement 3 may be of similar nature. For instance, a search page(a Screen or web page) having a search text field and a ‘submit’ button may be categorized to ‘Simple’ which could be equated to 3 days of estimation. But two other similar search pages can be equated to ‘Medium’ category which could be equated to 5 days of estimation. The team might actually be able to complete those 2 requirements (search page) even in less than 3 days leave alone 5 days because already the team would have a chance to complete one search page (estimated at 3 days) and so they may carry that prior experience for doing the remaining search pages which can enhance or increase the speed of doing the development. But instead of putting a lesser estimation, the team could put 5 days of estimation (medium), then while doing the actual development work, can finish it in less than or 2-3 days, thereby earning appreciation or a pat on the back from the supervisor/project lead for expediting the work, showcasing false improvement step. So the estimation process will not be correct and cannot be baselined. Some may wonder as why we need to go for an estimation process for the team. Would an organisation not have estimation templates for development projects for projects of different size, as part of Organisational Process Assets (OPA)? The answer could be yes, in most of the organisations. But that will not be enough and some project specific customisation might be required always. This is where all the issues mentioned earlier would surface. The aforementioned issues could also happen if estimation (as a process) happens first time for the team. Eg:2 While this effect can occur in any type of industry, this effect can be seen even in sports. Taking the game of Cricket, often cricketers when watched by the cricket selectors (who select the national team), would like to impress them by carefully playing with the bat or bowl. This case is about Selection process. There is the negative scenario as well. A fielder (who ensures that he puts the ball back to play) might dive unnecessarily to stop a ball, when all he has to do is to run around the ball to stop it. Here , this is about trying to portraying a simple stop to look like a complex one. This example can be equated to setting Fielding standards when compared with rest of the nations. So this is to tell that even in sports, you have the Hawthorne effect . How to make the process baselining taking this Hawthorne Effect into consideration This can be divided into three facets - Subject knowledge of the Process Owner/Process lead & his/her approach towards the team - Creating awareness on the need for process baselining and subsequent improvement - Commitment of the team members to the process and their trust on the process owner/process lead (who could also be the team’s supervisor in most cases) These 3 facets can be further drilled down. Let us see that in detail Subject knowledge of Process Owner/Lead The Process owner should: 1. Have sufficient technical/functional/domain knowledge to ensure that he/she is in a position to vet and approve the data provided by the team. For instance, this is a critical aspect for a IT development project lead for doing an estimation process (Note: Project Lead normally is the process owner/lead in a typical Waterfall model; whereas in a agile scrum model, everyone provides the estimates but scrum master facilitates it) 2. Be able to challenge the data provided by the team, if he/she feels that data is not correct. 3. Understand the overall strength and weakness of the team 4. Have a personal rapport, but at a professional level and should develop the personal trust within the team members to garner support for streamlining the process. Creating Awareness sessions 1. Process Owner need to educate the team on first baselining of the process. If there is an industry standard existing, he/she has to highlight to the team as how to reach to that level (if the team is lagging behind on that). So it is basically setting up the context and priorities 2. If it is about starting from scratch, then the process owner should clearly define the expectation by setting realistic achievable goals and a roadmap as when to achieve the new process 3. Announcing, Rewards and Recognitions programme, at the beginning (before the baselining process happens), can be a motivating factor to the team as they would be pumped up to know that their efforts would be recognised. Commitment of Team Members 1. The team members need to understand the process owner’s expectation and the team and hence the organisational’s needs. 2. Team members need to show the trust normally unless it turns to be otherwise for various reasons. 3. Team members should have the inclination to learn new things and should work as a team for showing more productivity or improving the process as a team. Conclusion We had seen how Hawthorne effect can positively and negatively impact a process. Whether the impact is positive or negative depends on several factors such as the experience of the team, the experience of the process owner in handling the situation and other factors. But in my opinion, the organisation culture, how the process owner handles the situation can ultimately decide the impact of the effect on the process.

Failure Modes and Effects Analysis FMEA It is a technique using which we can study all plausible problems in a process, the potential/probable impact of each problem and what is the action to be taken to counter with the problem. Because, the technique is used for capturing potential problems (hence could be risks) and provides a probable action to counter those problems/risks, the technique becomes a good risk assessment tool. But this technique has its own limitation as well. Let us take a deep dive on this. Types of FMEA There are 4 types of FMEA viz..,. System FMEA, Design FMEA, Process FMEA, Equipment FMEA System FMEA: Analyses systems and subsystems in the earlier part of concept and in design stages and thereby focusing on probable failure modes happening due to design. Design FMEA: Analyses failure modes in products before they getting released to production. Process FMEA: Analyses failure modes in manufacturing and transactional processes. Equipment FMEA: Analyses failure modes in the equipments used in a process. How does FMEA work Steps associated with FMEA, 1. Assign a FMEA number 2. Provide a title to your process 3. Identify the team responsible for this process 4. Identify the member who will prepare the FMEA 5. Enter the product name of the customer 6. Assign FMEA Key date and Origination date 7. Provide the list of core team members who are involved in this activity 8. List the process function steps which serve as the inputs for the process 9. List potential failure for modes, effects, causes separately 10. Assign detection level to each mode 11. Assign severity to each effect 12. Assign occurrence level to each cause 13. List out the current process controls for prevention/detection of failure modes. 14. Now calculate the Risk Priority Number (RPN) which is nothing but the product of the values in each of the columns - severity, occurrence and detection 15. Now , Prioritize the order of the data entered as per the RPN to have a look as which is to be addressed first , by sorting of data with the highest RPN based entry in the top descending towards with the lowest RPN based entry on the bottom 16. Specify the actions that is recommended 17. Assign owners for the actions specified and assign the actions to those relevant owners 18. Now Recalculate the Risk Priority Number (RPN) and then again sort out the (entire) data based on RPN. Limitations of FMEA 1. This is a tool/technique to be managed by the FMEA owner or his/her backup. Not an ideal tool for everyone in a team to maintain this. So there is dependency created on individuals while maintaining the sheet, even if this is the correct and industry practiced way. 2. Enough exposure/experience required to meddle with this technique/tool as this has considerable amount of fields and you need to ensure that RPN is correctly filled when the problem exists (for the first time) and then for the second time, after an action is taken. This comes out of experience/knowledge gained. So only Subject Matter Expert (SME) can own or handle this. This is not the case, in many other risk assessment proprietary tools found in many organisations (especially in IT service sectors) where risk is assessed using probability and impact which are calculated bit differently than what is done through this technique and where team contribution is directly involved with each one of the members being a SME for his/her own activity. Finally risk owner, collates the risks obtained and then overall risk is provided to all stakeholders 3. This provides a living document and hence this needs constant update as and when the FMEA owner receives from his/her team or foresees a problem. This is quite cumbersome to do if there is so much risks and if the owner needs to do frequently as there are too many columns (fields) to address and it would be taxing , however a person is experienced and lot of scrutiny needs to happen on the data to ensure everything is correct and agreed by key stakeholders as well. Conclusion: Irrespective of its limitations, this tool or technique, if used properly, can be a great one to work or use with. It will make a team to think about its process in a rationalised way. This tool helps in driving a systematic record keeping of the process and can drive change through priorities. A team following this would be constantly improving as well - both knowledge wise and process wise.

Background: For any business to be successful, customer is the key . If a company is aware of what its customer wants or needs, then half the job is done. The next half is to execute them to action. In old days, businessman (individual) or marketing team/person(s) from companies used to approach people with different tactics. They would go to households in a locality and try to obtain a view on how their products are working and what are the concerns faced by the customer and what are the customer views on their products and how things can be improved. Also some business/marketing persons might also record these customer painpoints/observations through a survey. As time progressed, technology changes also happened. With the advent of technologies in computer industry, storing of information and analysing that became much easier and quick. This resulted in several softwares which effectively could encapsulate all essential things for a company to manage relationship with its customers. Managing such relationship with customers is termed as Customer Relationship Management (CRM) So what is CRM ? It is an effective approach to manage a company’s customers –both existing and also potential customers, in the future. What does it do ? 1. It collects information on customers across different channels such as website, telephone, email, live chat , social media... 2. It provides an insight into customer’s information on buying preferences, purchase history, concerns etc.,.. How does it work? 1.With the help of CRM based softwares, customer information is collected, consolidated and documented in a database 2.With the customer information stored in a database, it becomes easier for the business users to access and manage those information 3.Customer interactions are recorded through multiple channels such as email, phone, webchat, social media etc, which is limited only by the capability of the CRM software/system used 4.Providing automation of various workflow processes What are the benefits? 1.Customer retention - ability to effectively address the needs of existing customers and ensure they are satisfied and continue their relationship with the company. 2.Customization – Providing customised products/services to every single customer as per his/her or their(set of customer stakeholders) needs. 3.Potential customers can be targeted. 4.Customer pulse (concerns, taste/needs,...) is known or can be captured quickly. Conclusion: There are quite a few CRM softwares which can effectively help to understand the customer needs and thereby help a company to increase its satisfaction index. A company should know what it wants to satisfy the customer or to increase its business growth and ensure that that its CRM strategy is aligned accordingly.

Lead Time : It is the time taken from the ordering (ordering received by the producer) of a unit/product to its delivery/shipment to the customer. Eg:In an IT service industry, this could be a requirement coming from a customer and which is picked by the service provider and that functionality is delivered finally to the customer. In an Agile world, this could be a user story (requirements are called as user –stories) which would be delivered to the customer, as part of the Iteration/Sprint [Iteration and Sprint - denote a time-boxed period for delivering functionalities. Sprint is a term used in Agile Scrum methodology and Iteration – in other Agile methodologies like Extremme Programming (XP) ] or a release. Cycle Time It is the time taken to complete a unit. For example if there was a 5 member- Agile Scrum team who worked for 10 days (2 working weeks of Sprint duration) with 6 hrs of working on an average /day, if say 30 user stories are created , then we cay cycle time for this Sprint can be =300(5*6*10)/30 =10 hr/story. Though in practice, this is not a metric that is used. Nevertheless the idea is about to portray the concept through Agile Scrum. Why confusion between lead time and cycle time There are quite a few reasons as why this could happen. 1. Lead time measures the production process from the customer’s perspective whereas cycle time is focussed on delivery readiness perspective. For eg., taking an agile scrum example, a Scrum board which talks about the movement of deliverables across various stages can be represented as User Stories To Do Work in Progress Reviewed Done User Story 1 b b b b User Story 2 b b b b Here ‘Done’ refers to the completed functionalities and the user stories (requirements or functionalities) are ready to be delivered to the customer. Now lead time, takes into calculation the waiting time on confirmation of user stories as those stories need clarification from business. Unfortunately the development team waits for the business analyst to come up with the user story to be confirmed. So lead time = cycle time + wait time + delayed time (to start) in general. But this is not factored in many cases and hence there is confusion in handling these two types. 2. Think of the analogy- Thinking from outside in perspective. The famous story of how GE approached the problem for Boeing when its plane was grounded and given to GE for service/repair, from which a great concept (Outside-in) materialized. Here, the SLA of the service provider was not meeting the customer demands / expectations. Cycle time has to meet the TAKT time (measures customer demand) but Lead time is about the customer waiting time. Often the organisation which provides the service or creates the product, does not clearly define its process boundaries or define the SLAs required for each of the processing steps or it could be a combination of both. Because of these ambiguity and the lack of awareness (by the workforce) on the process as where the demarcation (in terms of the process steps owned by the organisation), confusions can happen on the cycle time and lead time. Conclusion: The lead time and cycle time are key elements especially in manufacturing sectors and in service sectors to some extent. Even though these terms are defined properly by industry experts, as mentioned above with few cases, the terms can be confused with.

Let us see each one of the options A. If it is desirable to set an objective of Zero Defect Quality, we should set the goal, but this should primarily be a top-down system driven initiative and not a bottom-up approach. In my opinion, this is a feasible option and the right approach. Management needs to provide its workforce, a clear view and approach on zero defects and emphasis on increased productivity. A SMART goal should be set up by management. A well laid out plan and systematic and focussed awareness trainings on the importance of quality can reach out to an organisation’s workforce. A bottom up approach can also be plausible. That however needs to be followed up by a proper business justification, with the right articulation of problem statement and mentioning clearly the Return of Investment (ROI). Often management expects the benefits to be tangible. Even after portraying the plan with potential benefits, in many organisations such proposals (coming from a lower-rung in the organisation) to up the quality and productivity requires multiple stakeholders’ approval before they are implemented. B. Although there should be an effort to reach zero defects using both top-down and bottom-up approaches, this should not be converted into a slogan for workforce. This approach i feel is good as long as the workforce thinks that management is working in tandem with them on quality by setting the strategies or setting up the conducive environment/platform. But having this quality mandate slogan for the workforce, will create a divisive mindset in the minds of the workforce, which will not be good for the organisation in the longer run. C. Audacious goals create demotivation for management as well as workforce. They must be avoided. In my view, this is a dangerous ploy. If the workforce is small and a dedicated team and is handpicked by management team, where the workforce is enlightened about the need for the goals and are bound/promised to get good recognition, in terms of salary hike or promotion or any other good professional opportunity, then this daring goals can have a positive impact for the workforce team or management team members (whoever is involved in this). Else this will be a very demotivating factor and there would be so much mental agony, pressure, frustration, attrition, anger, across the team. D. Workforce has limited ability to increase productivity or improve quality. Workforce is expected to follow instructions and cannot lead improvement projects. So, it is better to keep them isolated from productivity goals and zero defect initiatives. In my view, this is not an ideal situation for the workforce. If the limitation is due to genuine reasons or due to the nature of work (which may be a rare case), then this approach is fine but only for a short duration. If the workforce is expected to blindly follow the instructions, set up by the management/leadership team, it will not augur well for an Organisation. Soon there would be dissent and attrition. The team members could feel alienated from the organisation as they would feel that they are not being made responsible and given any responsibilities. E. Workforce if engaged in improvement initiatives can do wonders. While slogans and rigid targets should be avoided, improvements in quality and productivity should still be expected from workforce. In my view, this is a positive approach. Management/Key stakeholders should upfront brief about the improvement initiatives to the workforce and highlight the necessity of the initiatives. That can trigger/evince interests amongst the workforce members. F. The ownership for such goals on productivity and quality lies with management and can never be forced as a justifiable target for workforce. This is the most important and key aspect. Any goals related to productivity and quality improvement cannot be done easily or diligently without the involvement or the blessings of management or key stakeholders in almost all the organisations across the globe. This is understandable because the Management /leadership team is the one that has got access to all other departments (such as Sales, Marketing, Accounting, Delivery,...) and knows what is needed (by the market) and what is in store internally and how to bridge the gap in terms of quality and productivity and accordingly set the goals. A shrewd management would put a short term visionary and a long term visionary plan/Road Map. With a SMART goal, it would address its issues on Quality and Productivity. Now how do the management take this further to its workforce? Can it thrust upon this to the team? No. It cannot do that. Management team needs to create the awareness on it goals on Quality and Productivity. It should conduct various sessions on these. It should create the culture and create a “First Time Right” mindset to the workforce. As part of the appraisal process, there can be goals related to productivity and quality, which addressed by the workforce, can be rewarded. This way, quality, productivity improvement initiatives can get imbibed as part of the workforce’s DNA. Conclusion All options can happen depending upon an organisation’s strength, strategy, interests and other factors, though ideally in my purview, the options, F, E, A (in that order) are safe options which can give maximum advantage to improve quality and productivity due to the points aforementioned. Options B,D and C (in that order) are the least options that should be preferred.

Fishbone Diagram It is also called cause and effect diagram or Ishikawa diagram. It is a visualization tool for categorizing the potential causes of a problem so as to identify its root causes. This technique was created by Kaoru Ishikawa. Each cause /reason for imperfection is a source of variation. How the tool is misused? 1. Often people (junior members or less experienced team members) misunderstand that this technique would set actions to solve the problems. But this is not the case. Only root causes alone are specified 2. This tool is not about single cause, but about set of causes that can be affect the outcome. But unfortunately people working on this does not focus on the whole lot 3. For most of the type of problems across industries, this tool /technique can be useful. But with this tool alone, people try to provide the response which may be not correct. For instance, differentiating common causes and special causes, this tool can give some pointers. But to find how much impact the special causes create on the process or in your problem cannot be determined by this tool. You need a tool like Paretto chart. This sometimes team do not understand Eg: For Late Delivery of a pizza - there could be any number of causes Late Delivery of Pizza

Cost of Poor Quality (CoPQ) It represents the known and unknown costs of all the defects that exist in a process. We can divide this costs into 5 categories - Internal Failure, External Failure, Appraisal , Prevention and non-value added activity Internal Failure These are Costs that occur due to defects that are found before the product or service is provided to the customer. Examples: Scrap, rework, retesting, downtime,... External Failure These are Costs that occur due to defects that are found after the product or service reaches to the customer. Examples : Warranty changes , compensation, Returned goods, complaint corrections/adjustments,.. Appraisal This is the cost of determining the degree of non conformance to quality requirements. Eg: Inspection of Deliverables, performing Quality audits, testing Prevention This talks about the cost of minimizing failure and appraisal costs Eg: creating better process for eliminating defects by having proper design reviews and quality planning, having knowledge sessions /trainings, have a preventive mechanism such as checklists or readiness list for smooth delivery. Non-value added This happens when any of the steps in a process cannot add value from the customer’s perspective. Which costs need to be considered? COPQ is a key business metric in a Process Improvement project. As we improve the capability of a process, we not only decrease the variation and defects, but also reduce the cost of running the process. You can find that in below table Sigma Level DPMO CoPQ (% in Sales) 2 308,537 30-40% 3 68,807 20-30% 4 6,210 15-20% 5 233 10- 15% 6 3.4 < 10% The most important costs that we need to focus is on Prevention cost. For this we need to focus on - Identifying the areas for improvement and also identify the people to whom knowledge has to be given - Train the identified resources for providing the training - Identify right steps in each process and ensure only needed steps are placed Prevention cost will help in - Avoiding failure costs – both internal and external - Can help to avoid customer dissatisfaction

Null hypothesis It states that the assumption that there is no difference in parameters for two or more populations and that any observed difference in samples is due to chance or a sampling error. Alternate Hypothesis: An alternate hypothesis is any hypothesis that differs from the given null hypothesis Type 1 Error: This occurs when null hypothesis is actually true, but it is rejected. This is also known as Alpha Error. Type 2 Error: This occurs when null hypothesis is actually false, but it is failed to be rejected. This is also known as Beta Error. As we perform the hypothesis testing, there are 4 possible outcomes which can be put in a truth table format. Let us put the truth table for this Decision True False Fail to Reject Null Hypothesis Correct Decision Type II Error Reject the null hypothesis Type I Error Correct Decision Let us see a hypothetical situation A person (Person1) was seen with a gun on a place where a murder had happened. He was arrested on suspicion of murdering that person (Person2) who was lying down. He is taken to a high court. Now, Null Hypothesis (h0) states that “Person1 is not guilty” Alternate Hypothesis (ha) states that “Person1 is guilty” Then the possible outcomes for the above scenario would be Decision Innocent Guilty Set the person free True Type II Error Jail the person Type 1 Error True Now, with circumstances and other evidences, the innocent person(Person1) is charged with murder and a Type 1 Error has occurred now. The innocent is jailed. Now, Person1’s lawyer takes the case to the highest court of the land (Supreme Court). With his oratory skill and with valid arguments and showing evidences that his client did not do the murder, the lawyer convinces the judge that his client (Person1) did not do the murder and hence is innocent. The judge accepts this and makes the decision of letting person1 free. Now the outcome is Decision Innocent Guilty Set the person free True Type II Error Jail the person Type 1 Error True While accepting the judge’s decision, the prosecutor interrupted that there has to be another case on Person1. The root cause for this suspicion on murder was due to Person1 carrying a gun. The prosecutor said that it is illegal to carry a gun without license and Person1 was carrying it without a license and hence he should be jailed. The Judge agreed to this valid argument but decided not to punish Person1 , because he (Person1) had spend some time in jail for a sin that he did commit and had mental agony. However the judge warned Person1 to be careful going forward. So in nutshell, even though Person1 was guilty, he was freed. Decision Innocent Guilty Set the person free True Type II Error Jail the person Type 1 Error True Conclusion: There are cases where type 1 error can be considered as type 2 error. In the above mentioned example, the null hypothesis states that the person is not guilty. But the Person is jailed when he is actually not guilty, when he is tried for the murdering case. So a type 1 Error happens. But on appeal on the next higher court, the person is set free. But he is found guilty on illegal possession of a gun. But considering that the person has already served sentence ,the judge decides to set free with a caution remark. So this becomes a type 2 error (person set free inspite of being guilty).

DMAIC: It is a problem-solving Six Sigma methodology that does improve your process with lesser variation by having right optimised solution . 8D Problem Solving: It is a problem solving technique which has 8 steps excluding the planning step. It is objective is to identify, correct, and eliminate recurring problems, and it is useful in product and process improvement. The 8 steps numbered as D0, D1, D2, D3, D4, D5, D6, D7 and D8. D0: Plan—Plan for solving the problem and determine the prerequisites. D1: Use a team—Establish a team of people with product/process knowledge. D2: Define and describe the problem—Specify the problem by identifying in quantifiable terms the who, what, where, when, why, how, and how many (5W2H) for the problem. D3: Develop interim containment plan; implement and verify interim actions—Define and implement containment actions to isolate the problem from any customer. D4: Determine, identify, and verify root causes and escape points—Identify all applicable causes that could explain why the problem occurred. Also identify why the problem was not noticed at the time it occurred. D5: Choose and verify permanent corrections (PCs) for problem/nonconformity—Through preproduction programs, quantitatively confirm that the selected correction will resolve the problem for the customer. D6: Implement and validate corrective actions—Define and implement the best corrective actions. D7: Take preventive measures—Modify the management systems, operation systems, practices, and procedures to prevent recurrence of this and all similar problems. D8: Congratulate your team—Recognize the collective efforts of the team. Similarities between DMAIC and 8 D Problem Solving S.No DMAIC 8D Problem Solving 1 Problem Solving, with the extensive usage of statistical tools and techniques Problem solving through data analytical tools 2 Makes use of Root Cause Analysis Makes use of Root Cause analytical techniques Differences between DMAIC and 8 D Problem Solving S.No DMAIC 8D Problem Solving 1 Can be used only for problems which do not need immediate attention. Can be used when a problem needs to be immediately addressed 2 Uses statistical approach and data to do problem solving Makes use of Root Cause analytical techniques When do we use 8D Problem Solving and not DMAIC ? 1. When there is a quick fix to be done for the problem at hand that needs RCA and a correction then use 8D problem solvin When do we use DMAIC and not 8D Problem Solving ? Quite a few things to be considered as when we go for DMAIC . Some essential points mentioned here 1. When you do not know root cause , solution for a problem and it requires deeper thinking or analysis 2. When this problem has been existing for quite some time 3. When you have time to address the problem with proper statistical measures comparing 4. Once you have fixed/addressed the problem using techniques like 8D problem solving and want to ensure that you want to put a better process

Background of 1.5 Shift: When a process is improved through a Six Sigma DMAIC methodology, the sigma value and standard deviation are calculated. These values are deemed as short-term values as the data collection done by the project team, for the process happens over a period of months, rather than years and the data contains only common cause variation, by and large [there could be one or two outliers(Special causes) but in general this is all about common cause ]. Now it would be interesting to observe how the process behaves over a longer period of time (over years), and then the calculation on the sigma value and standard deviation is done. These values are deemed as long-term values as the data collection for the process happens over a longer period. The data can contain both common cause variation and some special causes (assignable cause) variation (as you expect discrepancies during longer period) . As short term data (Sigma level and Standard deviation) do not have this special cause variation, it will have higher process capability than long-term data. It is good to have a long-term view of how the process works or to put in other words, observe how the process behaves over a longer period of time, as controlling a process in the longer run is difficult. The process owner/project team can identify special causes (if any) and then address them. But in reality does this happen? The answer is a firm no. Why is it so? Calculating Long term is difficult because i). It takes time, energy, skill, dedicated human resources to work on ii).Analysis of the data measured needs to be done twice a). First for a shorter period of time (in months) b). Second for an extended period of time /day-to-day (over years) iii).Management/Leadership/Stakeholders approval needed for doing # 1 and # 2 Six Sigma pioneers in Motorola realized all these aforementioned difficulties and adjusted this with a “1.5 sigma shift” . How to make use of 1.5 sigma shift concept to derive one type of Six Sigma level from another ? Any process will have a natural degradation over a period of time, i.e. the centring of the process will tend to shift over a period of time. Six Sigma pioneers at Motorola found out through years of process and data collection that processes vary and drift over time and deemed these process variations as long term dynamic mean variations. They made the calculation and found out that under the worst conditions, the performance degradation of a process would go by 1.5 sigma. Hence the pioneers wanted to allow in their calculations for this worst-case scenario and to compensate for process shifts over time, they corrected in advance for a probable shift of 1.5 sigma. Because of this, even though the statistical tables show 3.4 defects per million opportunities(DPMO), when the distribution between the mean and the closest specification limit is 4.5 sigma, the target is raised to 6 sigma and still thereby achieving a maximum of only 3.4 DPMO. This 1.5 shift is good enough to ensure that the process will meet the goal of 3.4 DPMO over a long run. The short term sigma level is calculated first. Then a shift of 1.5 is used. Short term sigma is represented as Zst. Long term sigma is represented as Zlt and can be calculated as Zlt = Zst – 1.5 Conclusion: There is no hard and fast rule on 1.5 sigma shift. You can use different value when setting the sigma target for a process, if you have the data on experiences obtained from other similar processes. But as we saw, 1.5 sigma shift is good enough to meet the objective of 3.4 DPMO.

Outlier: An Outlier is an extreme value (or observation in the dataset) and is normally outside the upper and lower limits and is distant from other observations. The outlier value might be due to multiple factors : - Could be due to variability in measurement (Measurement error) - Could be due to experimental error (Repeatability and Reproducibility) - Could be due to a special cause/condition What is the need to identify an outlier in a dataset? As an outlier is outside the control limits or further away from the rest of the observations, it is important that we identify the outlier to ensure that it is relatively nearer to the rest of observations and hence thereby within the control limits. What are the methods and approaches that are useful for identifying outliers? Some of the best methods that can be useful to identify outliers are : - Box Plot : It displays 5 points that represent the centering, spread and distribution of a set of continuous data. The plot consists of a box, whiskers and outliers and shows the maximum value, the minimum value, the median, the 75th percentile and the 25th percentile. The outliers are plotted with dots and asterisk. - Control Charts: It tracks process statistics over time and detects the presence of special causes which are nothing but outliers. Example of Outliers and how to deal depending on circumstances Eg:1: Every day, a person goes to office and he needs to be there between 9 am – 9.15 am IST. One day he faces a challenge when a procession delays his going to office and he reaches office by 9.50 am IST. Nevertheless for the entire month, he is on time to office. Now, reaching office at 9.50 is an outlier. But as it happened only once, this can be excluded or ignored as a one-off. Conclusion: Outliers need to be addressed properly in every process. Reasons of outliers could be due to aforementioned factors or could happen by chance in any distribution. Depending on the context/situations, the outliers may be addressed or excluded.

A process in a simplistic term, can be said to be in a mature state under following scenarios: - If it is highly consistent and stable, with minimal or less variation, over a period of time [which means it operates within the specification limits and also well within the upper and lower control limits] - When it is compared with other similar processes and if it out-performs them How does a process maturity happen? Every process can get elevated to different levels at various stages. At its infancy, a process may not be a process at all and it depends on the individual efforts to provide the right results. Then consciously efforts might be taken to increase the efficacy of the process. That might result in the process addressing the efforts put by the individuals. This can be followed by standardization of the process, followed by a concerted effort to stabilize the process by constant reviewing of the process and ensure that everything is in control. Finally, the process is optimized such that continuous improvements are made to ensure that the process is capable enough to meet the rapid demands/needs of the market/customer. Does an assessment for the maturity of a process carry any significance? The maturity of a process needs to be known for various reasons. a).Knowing the current level of process maturity helps the stakeholders to know as what needs to be done to get to the current market/customer needs, in case if the process is below the expectation or need. b).Knowing the process maturity , helps the leadership team in deciding whether the existing process can be used for further improvements (to cater to changing customer/market needs) or whether a new process can be created. Conclusion: Maturity of a process is a relative term. As market/customer needs increases or changes, the process which produces the necessary results need to be improved to cater to the changing needs. The maturity level of the process also accordingly need to be raised. There is chance that a process which was matured enough to handle the existing requirements , being not good enough to handle or becoming inconsistent to handle the new needs/changes. Hence always a constant review is needed on such processes to ensure that the process is matured as it was earlier.

Voice of Customer (VoC): This refers to the stated and unstated needs, requirements and expectations of an organisation’s customers – external and internal, to the organisation. Let us see some examples. Eg: - Timely service at a Food Court (can be any other relevant service) - Rendering/Providing high quality service - On-Time Delivery of a Software Application (can be anything relevant) - Minimal or no downtime of a service, that is being rendered - 24/7 support for banking service or any mission critical service Tools/Techniques through which VoC is gathered 1. Surveys 2. Online Questionnaires 3. Focus groups 4. Face-to-Face interview 5. Observations 6. Telephonic interviews Merits of VoC: 1. Serves as an essential input in streamlining project needs 2. Serves as a very good tool/technique for customer feedback 3. As it acts as a pointer to customer mindset and therefore can help the service provider, in increasing the customer satisfaction Voice of Business(VoB): This refers to both the stated and unstated needs, expectations of the team or persons who run the business for an organisation. Let us see some examples. Eg: - Capturing the market (Market leader) - Revenue growth - Return of Investment - Providing reliable service - Business expansion geographically - Minimal Cost of Quality (CoQ) Merits of VoB: 1. Can help in streamlining internal processes to achieve customer needs in a improved fashion 2. Helps in setting up/improving target metrics for the organisation for upcoming/future period Common reasons that create a conflict between VoC and VoB: 1. Often we would have encountered /witnessed this scenario. Most of the organisations do have their canteen(s) contracted to different vendor(s). The contracted vendor for an organisation would often employ/deploy less amount of people to serve the organisation’s staffs(Employees) .This will hamper the timely service to be provided to the employees of the organisation. Here the contractor runs the business and provides the service to the employees. As per the agreement with the organisations’s admin and mgmt team, the contractor is supposed to provide timely service (VoB) and quality service(VoB). At the same time, the contractor wants to have profit (VoB) in his/her business. So the contractor deploys less workforce (personnel) in the canteen, but this affects the timely service(VoC) provided to the employees of the organisation. Here the eagerness to lessen the operating cost, by the contractor affects the timely service which is an essential aspect to the customer. This conflict of interest results in poor service rendered to the employees (internal customer). 2. Often we find that a service provider struggles to meet the quality expectation of the customer. Business understands the customer's expectation on the quality of service needed by the customer. The cost of the quality can be split into 4 type of costs - appraisal, prevention, Internal failure and External failure. Effort on prevention will reduce the failure and appraisal costs. But many a times, business do not spend on prevention costs and as a result, quality of the service cannot be improved without the customer getting affected. This results in customer dissatisfaction. Conclusion VoC is the key for the success of any business. The VoB should ideally align to that. But as we saw , there are cases where there could be alignment conflict between VoC and VoB. That could result in customer dissatisfaction, if not sorted out.

There are 7 wastes in Lean which are referred to as Muda (in Japanese). Let us quickly go through each one. Waiting: It talks about the non-productive time period due to lack of equipment, material , human beings. This can talk about any delayed arrival of materials or persons, or delay due to equipments broken. So resources would be idle till such time. Eg: Waiting for a human resource to be available to fix an issue Over Production: It refers to manufacturing an item before it is actually needed. It relates to excessive accumulation of WIP of finished goods inventory. It is the worst form of waste because it contributes to all the others. Eg: Preparing unnecessary reports which may not be read at all Rework (or Defects): This talks about the correction needed for fixing the mistakes, normally. These activities are waste of time. Eg 1: Fixing the bugs created in software code Eg 2: Correction on made on the word documents – typo errors/spelling mistakes Motion: It tells about the unnecessary movement of people and equipment Eg: Extra data entry, extra steps ... Over Processing: This refers to non-value added tasks which customer would not be interested. This could be because of poor design of the product/process. Eg1: Any gold-plating work , like beautification of software code which is not required or not asked by customer Eg:2 Sending unnecessary mails doing extra communication Eg:3 Sending some data in multiple reports – duplicate effort Inventory: To keep stock of items , often in excess, than what is required . Eg 1: Keeping stock of raw materials, in plenty (abundance) than what is needed for use. Transportation: It refers to the unwarranted movement of materials, information.. Process Steps should be closely located to one another for minimal movement. Eg 1: Mail Forwarding to another persons , after missing to loop in those persons in the original email Eg:2 Movement of files/papers from one place to another place Now as we have seen the 7 wastes of Lean , there is also another type of waste , which is often called as the 8th waste. It talks about the underutilization of talent and skills. If we happen to address this waste, there is a chance that we can do well with the rest of the waste types.Having said that, let us see how we can make good use of these wastes . Let us take some of the wastes discussed above Waiting: Some IT applications might be quite complex and can involve multiple technologies. In a typical enterprise based web application, the technologies involved could be relational database(s), server-side programming languages, application servers (which host the application), front-end/User Interface languages and programming scripts, messaging tools etc.,. Assume this application is in the development stage. Now we see a potential problem in the way how application is designed. This requires a technical architect to do a course correction as he is the technical Subject Matter Expert (SME).The design change is critical in ensuring application scalability does not impact. Now assume that this architect is shared/utilized across multiple projects within a business unit of the organisation (which owns this application). When he is needed for this project(application) to provide optimal design, he is not available as he is held up in another project for production implementation and would not be available for 2 days. Now the project needs to wait for his presence and its worth waiting 2 days, since the architect would change the shape of the project (application) so that many users (Scalability) can be able to visit post the go-live period 2.Rework: There are scenarios, where this may be required. 1.There could be changes on product /process design due to environmental conditions, government statutory 2.There could be rework due to a design flaw on product. Eg: A product might have sharp edges on it. A consumer would have put a consumer case against it , after getting affected (hurt) by that. So consumer court would have instructed the company which produced the product to blunt the product’s edges. This is a legal issue which definitely needs rework of the design. 3.Inventory: Why this is needed? i).In Software, the developers will always have a copy of the code that they had developed. Those codes would be available in a Version control system (Configuration management). But still developers retain that because they would like to see if that can be used in some other projects. Also they want to see how their code looks changed when compared with the code in the version control system ii). A Supermarket can operate in Push (having Inventory) and Pull type (Just-In-Time). Some items can be fast moving and some items can move slow or have less demand. So the super market can stock fast moving items which do not degrade over a period of time or for a considerable amount of time. Conclusion: This goes to show how different type of wastes can be made use of!!

Let us see some basic information about Central Tendency and Variation Central Tendency It is about the tendency of data to cluster around some value. It is used to determine the location and is usually expressed by mean, median or mode. Variation It is the amount of spread (dispersion) in a set of data, which can be either sample or a population. It is usually expressed by Range, Standard Deviation, Variance, Inter Quartile Range Now let us see two cases. Case 1: A cricketer’s (Sportsperson) performance is being evaluated after he has come out of injury. The chairman of the cricket board is evaluating the player’s past performance (runs scored) as how the player has played across various countries in various cricketing venues , in all the bilateral series (it means - few cricket matches played between two cricket playing nations), that the player participated in the last 2 years. Let us see how the player has performed. The performance measured here is for the Limited Overs international match [which is a form of cricket match – with a limitation on the overs, to be delivered (bowled)] Table contains the player’s batting performance against various opponents for the past 2 years Name Opponent Runs Scored Raj Match 1 Match 2 Match 3 Match 4 Match 5 Total Average (Mean) Country 1 40 35 70 100 35 280 =280/5=56 Country 2 20 0 0 10 20 50 =50/5=10 Country 3 10 40 60 10 5 125 =125/5=25 Country 4 30 20 56 70 38 214 =214/5=42.8 Country 5 40 35 36 80 45 236 =236/5=47.2 Country 6 100 95 140 100 50 485 =485/5=97 Grand Total =1390 Avg=1390/30=46.33 Observed fact from the table: The player got out every time in each of those matches, after scoring those runs. Now a simple look at the above table will tell that the player has been inconsistent in each of the bilateral series that was played against different countries. There is lot of variation in each series and even in an overall perspective. But the mean (average) looks decent as per the cricketing standards. In this case, would the cricket chairman consider the variation in the player’s performance or would he take it onto account the average of the player’s performance which seems to be good. Considering the recent past performance of the player and the average of the player, the chairman would select the player for the upcoming cricket series. Therefore, here the mean (average), a measuring technique for central tendency is given high importance and the variation , which is quite big in this case, is not considered. Case 2: A heart patient, who is hospitalized in a hospital, is monitored for a month, for variations in his Blood Pressure. On a normal human being, it should be > 90/60 and <120/80. Here the doctor is keen to find how much is the variation of patient’s blood pressure throughout the day , on a routine basis and is not bothered about the average (mean) value of the patient’s blood pressure in a day , on a routine basis. The doctor is concerned about the variation in the blood pressure which should not cross the stipulated value; else it would be a health or life threatening risk to the patient. Hence we can infer in this case that Variation is given higher importance and mean, which is a representation of measuring the central tendency, is given least importance. Conclusion Central Tendency and Variation are two key aspects when we talk about Six Sigma. How much your data is spread out and how much data is clustered around a particular value is what we infer from this aspects. As we have seen there can be cases, where importance can be given to central tendency in one case and in another case, importance can be given to Variation. It can vary based on the needs or context in which this is applied.

Discrete Data: Discrete data is about information being categorised to a classification and is countable and data has only finite number of values. Eg 1: Pass/Fail, Go/No-go, accept/reject, Male/Female.. Eg 2: Rating: 1–10 Eg 3: no. of late deliveries Let us see with an example where discrete data is preferred while continuous data can still be used for that. 1. The correspondent of a school is interested to know how many students passed and failed in each section/class of 12th Standard. He is interested only in knowing the pass status. There are 4 sections of 12th Standard class. Section 1 is for Maths, Physics, Chemistry and Biology. Section 2 is for Pure Science (Physics, Chemistry and Biology), Section 3 for computer science and Section 4 for commerce.Each section is having 30 students. S.No Section Total Students Passed Fail 1 Section 1 30 30 0 2 Section 2 30 20 10 3 Section 3 30 25 5 4 Section 4 30 26 4 Totally – 101 out of 120 passed. Now this is a discrete data as it talks about pass/fail. Now if the correspondent wants to know how many students passed with distinction and how many passed with first class marks and how many with second class marks and how many just crossed the pass mark (35/100), then we can show the marks in ranges. Then this data can be treated as a continuous data. S.No Section # Students Pass Range 35-40 40-50 50-60 60-70 70-80 80-90 90-100 1 Section 1 30 2 2 5 6 10 3 2 2 Section 2 30 4 2 1 1 6 5 1 3 Section 3 30 1 2 3 2 9 4 4 4 Section 4 30 5 2 2 6 5 3 2 Conclusion Even though, in general we know it is better to have continuous data for having accurate results, as seen above there are cases where discrete data could be needed and useful to achieve the results, even if continuous data can also be used for that.

Tribal Knowledge It is about knowledge on products, customers, processes known only to a selective group or department or some individuals (employees) within a company. It is kind of information that could have been passed or being passed across some people in a department /group/ company, without being passed to other teams/individuals, from time to time. These sort of information will not be documented anywhere and rely more, on word of mouth. The disadvantage is that critical information could be lost just like that, as there is no documented record or placeholder to store that and that can affect the product of quality of the service provided thereby leading even to customer dissatisfaction. Merits and Demerits of Tribal Knowledge S.No Merits Demerits 1 An individual/team can have useful information on process /products/customer which can help at the right time to other teams or to product/service delivery Only a selective few or individuals or team might have critical information and this may impact productivity or quality of the product/service. 2 - If the SME/relevant individual is not available (and hence knowledge is withheld inadvertently or purposefully) say during a critical time /needed time , there could be a serious repercussion in terms of customer escalation or business impact 3 - Crucial information would be lost in the air , because no written documentation would be available , in general 4 - Storage of Information depends on the individual’s memory of things. If he/she forgets a particular item/step, then it can be deemed to be lost, probably for ever Primary Sources for Tribal knowledge 1.There could be a confidential data pertaining only to few departments or individuals. Any additional knowledge related to that may hence be locked with that group and which could be unwritten 2.When a key employee resigns , the knowledge that he/she possessed can go away with the individual 3.Some highly experienced staffs may not share their way of doing things to others Unlocking the Tribal Knowledge How can we get this data? Is it easy to get this view? First of all do you know that this kind of knowledge or information is persisting in your company? The answers to these questions invariably would be no, most of the times and atleast for most of the staffs in an organisation. Let us see few ways of getting this.. 1.Focussed Meetings: This is one way where key stakeholders can address leadership team across departments/functional areas and then highlight upon challenges/issues. This can address issues related to the tribal knowledge as well. 2.Audits: Sometimes audits that take place can find out how a particular problem is resolved or not addressed. It can point to clear dependency on individuals and will mention the various risks involved and the potential impact it can have. Management team will take this sort of pointers and confirm that the root cause for this could be categorized to tribal knowledge and then would try addressing the issue. Capturing Tribal Knowledge What are the ways of capturing? 1.Identify the Subject Matter Experts from each department / functional areas in the organisation and try to get all tricks, short-cuts and best ideas/practices[that are not known to the rest of the organisation], to ensure that those information can improve your product or service quality or expedite the resolution of an issue or provide improved performance. Capture all these information in a document. 2.When an employee, playing a key role, is about to resign an organisation, what we need to do while replacing him with another person is to ensure that there is a proper Handover- Takeover mechanism (HOTO) between the two parties. There has to be a written document that need to mention explicitly what all routine activities that the incumbent person is doing. The objective is to ensure all activities are captured. This HOTO becomes a part of audits in many companies. Representing this view in a tabular format with action to be done and the owner S.No Action to be done By Whom Remarks 1. Collect tips, tricks, short-cuts, best practices, etc...from the SME of each functional areas/departments and then document it Project/Programmer/Functional Manager or Sponsor of the project which produces the service or product The relevant Manager or sponsor should get the written document from the SME 2. When a key staff of the organisation resigns , he/she should provide a proper HOTO to the incoming person The person leaving the organisation should provide the HOTO and arrange for that meeting. There has to be a 1-1 meeting (preferred face-to-face) and then a written HOTO document with completion status Harness the Tribal Knowledge How to harness the knowledge that we gain through this? 1.Ensure the Documentation is done (as part of Capture knowledge) and put them into action 2.Try to see if the knowledge can be included as part of the automation process which is existing (in place already) Examples Let us see some examples across various sectors. 1.In IT sector, let us take an IT support project. Often we would see a single person handling a key application or few applications for quite some time and later he would have just put his/her resignation. He/she would have some crucial information withholding which is critical to handling the application(s) that he/she handle(s). The withholding of information may be done inadvertently by forgetting to share it with others or purposefully (because he/she would have either felt it not necessary to share or would have felt that he/she did not get enough recognition on doing that work and wanted to punish the team by not sharing the knowledge or it could be any reasons). To avoid this, the new person replacing the staff who has put his resignation should ensure that he gets a proper documented Hand Over- Take Over document. The project owner (manager or sponsor) for the said application(s) should ensure that proper knowledge transition has happened. 2.In manufacturing sector, there could be some information which will be very specific to certain departments, just by the nature of the data like sales related data (like forecast for subsequent month), materials related data. Those information will be only within the respective teams. 3.In general, some experienced people in many companies do not share their ideas/best practices to address issues. Conclusion We had seen how the information gathered through from the Tribal knowledge if tapped properly can help the project/organisation to sustain its activities efficiently.