Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Yesterday
  3. Correct answers by Jaishree, Kiran Kumar, Praful, and Saravanan. Saravanan's answer has been selected as the winner as it explains all the components very well and also mentions the applicability correctly. Well written, Saravanan! Please have a look at Benchmark expert view by Venugopal as well.
  4. The Bathtub Curve Analysis: (not able to copy/attach the bathtub curve from my office laptop) The Bathtub Curve is being used for likely failure rates of any products, be it manufacturing products or technological products. This bathtub concept holds good for almost all the products which are coming new to the market, and has been widely accepted by the reliability community over the years. Predominantly, it has three parts, decreased failure rates (Infant mortality failures), constant failure rates (useful lifetime), and increased failure rates (wear-out failures). During the initial period of any new product, the product life cycle faces a lot of failures because of design failure of the manufactured goods, bugs in the software, wrong positioning of the product, etc. This phase of the product life cycle is being backed up by the strong support team to make the product a success. Hence, we experience decreased failure rates of the product life, which can be otherwise called as Infant Mortality Failure, which was high when the system came into existence and then started ramping down. The second phase of the bathtub curve experiences, less failure rates due to stability achieved in the product. This phase is also called as Useful lifetime of the product, wherein the product experiences only chance failures. The products are designed to operate under certain external conditions with certain stress level and when it crosses these constraints, the failure occurs, which is of rare situation. The end users of the products, would know how to use the products, and hence they do not attempt to cross that limit, and would try to extract more usability from the product. Hence this phase of the product is aptly called as useful lifetime of the product. The third phase of the bathtub curve is called as increased failure phase, wherein the products face a lot of failures due to the deterioration of the machinery, wearing out of its parts, outdated technology, slowness, etc. Either we need to repair the products, increase the support activity or else we need to install a new product/equipment or resort to newer technologies with respect to the technological products. This phase is also called as wear-out failure phase. For any product, the initial and final phases are very short when compared with it middle phase, which is the useful lifetime of the machinery/technological product. In my opinion, the bathtub curve concept is applicable for all the products that are being manufactured, technologically innovated or the written software.
  5. Benchmark Six Sigma Expert View by Venugopal R Bathtub Curve (BTC) is well known for its depiction of the behavior of failure rate of a product during its life cycle. As per the principle of BTC, the failure rate or the probability of failure for a product is high during its initial life time and once it survives a certain initial time period, the failure rate reduces and remains more or less constant until it reaches a ‘wear out’ period, when the failure rate starts increasing. The failures that occur during the initial phase of life are also known as ‘Infant mortality’ and the failures that occurs during the last phase are ‘ageing or wear out’ failures. The causes for the failures at initial stages and the wear out stages would be different. The initial failures could be due to design flaws, manufacturing defects or shipment related. Companies resort to various measures to reduce or manage the infant mortality. It is a common practice to subject electronic products to a ‘burn-in’ test with the intent of weeding out most of the initial failures before shipping the product. Some other methods involve pre-delivery inspections and testing of the product at dock or after shipment to their locations. Manufacturers also provide ‘warranty’ that covers free replacement / repair of products that fail during the early life, subject to certain conditions. The causes for increase in failure rates towards the later part of life are due to wear out of components, other environmental factors such as corrosion, degradation etc. Methods to reduce the rate of ‘wear out’ failures include preventive maintenance, operating procedures, periodic replacement of certain parts such as bearings, belts, tires etc to protect the rest of the product. High Infant mortality would adversely impact the reputation of a product if not controlled within acceptable limits. Further, the resulting expenses due to warranty replacements and product recalls would be a drain due to costs of poor quality (COPQ). Some products like cell phones, computers turn obsolete very fast, due to rapid up-gradations of technology and features. Most users may change over to newer models, even before these products complete their ‘useful life’ period and may not reach the point of ‘wear out’ failures. However, the concept of infant mortality very much applies to them. The concept of BTC applies of all ‘durable’ products that are expected to be in use for a considerable period of time. A related metric that is used for products such as consumer durable is the MOL (Month of Life) failures. As per this, the shipped products are tracked as ‘month wise’ batches based on installation dates, and the service incidents that occur during each month of their life are tracked for a certain period of time. The company will have performance targets on MOL to be achieved. Interestingly, the ‘early failure’ concept applies not only to 'Manufactured products', but to ‘New Processes’ as well. We would have experienced that after rolling out a new process, high incidents of process failures are likely during the early days after implementation, based on which corrections would be carried out. For example, a newly introduced courier service had several incidents of consignments going to wrong locations due to a flaw in their bar-coding system. While ageing failures may be controlled to certain extent for a manufactured product by adequate maintenance procedures, we can reduce or even prevent ageing failures on services by exercising good knowledge management. The concept of 'Bath Tub Curve' may not be very much applicable to goods that are consumed very quickly, such as food items, certain FMCG goods etc. For such products, the life cycle is quite less to distinguish the 3 phases as per the BTC. Instead, the concept of ‘shelf-life’ is more applicable for such products.
  6. Q 218. Both Burn Up and Burn Down charts are used to track and communicate the progress of the project. Compare the two and provide examples of situations where one is preferred over the other? Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday. All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/ Please visit the forum home page at https://www.benchmarksixsigma.com/forum/ to respond to the latest question open till the next Tuesday/ Friday evening 5 PM as per Indian Standard Time. The best answer is always shown at the top among responses and the author finds honorable mention in our Business Excellence dictionary at https://www.benchmarksixsigma.com/forum/business-excellence-dictionary-glossary/ along with the related term.
  7. Bath curve is representations of product life cycle failure rate . It's combines three kind of failure 1. Early failure modes 2. Random failure modes 3. Failure modes due to wear and tear In early product life cycle most of the failure are faced due to process and quality issues . It's more of functional failure in nature as customer irritent. Random failure is of random nature and its combination of design and quality issue. Every product has declared product life, so as it covers time product faces wear and leads to functional failure. This is more of design issues in nature. This concept is applicable for products which cover product life cycle and do not have self healing capability. If the life cycle is terminated before wear and tear of product than this curve can not be obtained.
  8. Explain Bathtub Curve and its utility in reliability engineering. Is this concept applicable for all products? My interpretation : Mostly used in New Product to the Market offerings : Eg : Air Purifiers, Hotel Baking Industry machine new model or a simple NEW to market Coffee Maker. For simple reasons of Product Stabilization 1) The Early stage failures would be high. As they get fixed gradually one after another, the 2) Random/Natural usage based defects popup. Some of these can be solved via quick fixes and some need a product design modification or intervention. Eventually, as the product moves into the 3) Last 1/3rd phase of it's expected life, brands will start receiving breakdown complaints due to the parts that end up wearing off faster than anticipated. The first wave, if addressed, the product's "Usable Life Span" can be validated/improved. The final set to wear off, usually are not aimed for reeingineering as the investment could mean a significtant markup in the production costs. In some ways, this also applies to new service offerings : Eg : Hotels introducing new Cuisine / SPA services etc. The learning curve here helps in maturing the offerings and the last section may not be applicable as in service lines, the improvement in service is a "Continuous Improvement" journey. One way UP !! Note : The image from wikipedia can act as a good pictorial representation.
  9. Bathtub curve is a form of hazard function and has three parts to it. 1. The first part is called decreasing failure or early failure 2. The second part is constant failure or random failure 3. Third one is increasing failure or wear out failures This cannot be applicable to all products, wherever product failures happen more before the wear out period this bath tub curve will not be applicable Jaishree R
  10. Last week
  11. Congrats to Ram, Pavan, and Rajesh for excellent answers. The winer is R Rajesh because of his comprehensive coverage of failures and best practices.
  12. Q 217. Explain Bathtub Curve and its utility in reliability engineering. Is this concept applicable for all products? Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday. All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/ Please visit the forum home page at https://www.benchmarksixsigma.com/forum/ to respond to the latest question open till the next Tuesday/ Friday evening 5 PM as per Indian Standard Time. The best answer is always shown at the top among responses and the author finds honorable mention in our Business Excellence dictionary at https://www.benchmarksixsigma.com/forum/business-excellence-dictionary-glossary/ along with the related term.
  13. Agile methodology, a most prominent way to manage the projects in the Virtual domain (mostly in the Software development) has gained significant popularity in the recent times. It is based on the principle of breaking down the larger projects into smaller and manageable tasks called Iterations thereby creating something of a Value. Once an Iteration is produced, it is then made available to the users/stakeholders and seek feedback. This methodology has proven to be highly successful and many organisations have been able to score high on Innovation, customer satisfaction, quicker resolutions, better products and thereby high revenues. On the other hand, there are many projects which failed to deliver leading to huge financial loses to the technology companies. Hence, we could assume that these powerful methodologies comes with many challenges which play a key role for the overall success of the projects. Let's discuss each of these reasons and the measures that can be taken to reduce the risks of failure. Lack of Management Support: Agile Projects require a great support from the management right from the Planning till implementation. However, in many cases it is found that there is not enough support the management provides to the team due to many factors. This might be due to the pressure from the external customers, competition or the need to deliver the products at a quicker pace. Due to this, the actual focus shifts from the long term benefits to short term gains (or to prevent loses) which adversely impact the overall purpose of applying the Agile methodologies. To prevent these, the management must ensure that they do not deviate from their plan and need to stay focused on their objectives. Further, the management should motivate and actively support the functional managers in implementing the projects. The management should also make sure that all the parties are engaged and actively participating in their respective activities or tasks. Resistance to change: Management of change is another major hurdle in the overall success of the project. The resistance to change can be observed across the functions and has a greater impact on the mobility of various projects. This can be due to organisational culture, lack of collaboration and poor communication. The Management must take effective Change Management steps to prevent this. Effective communication, periodic Stake holder reviews and fostering engagement are some of the ways to ensure that the organization is moving in a right direction. Also, it should take into account the key issues for resistance and take necessary actions throughout the project implementation. Competency and Skill Issues: It is also observed in many cases that lack of necessary skills and expertise is a major cause for the failure of Agile projects. Unavailability of expert resources who fully understand the methodology will lead to confusion among the functional teams and desired results will not be achieved. To mitigate this, the organisation must employ skilled and trained resources to lead and work on the projects. Continuous training should be provided to the people on the Agile practices to develop the required capabilities and competencies thereby contributing to the successful implementation of the projects. Further, the resources who are leading the projects should be capable of mentoring the team members and troubleshoot wherever necessary. Lack of Proper Communication: This is one of the most common concerns not only limited to the Agile projects. As common it may sounds, lack of proper communication is still a major contributor for the failure of a project. Key things not communicated at the right time through the right channels causes delays or errors in the entire process and leads to a major gap across the verticals. The project leaders and the management should take effective measures to ensure a proper communication at regular intervals. This can be done through periodic reviews, regular Stake holder meetings or project meetings. The main objective is to confirm that there are no differences in the present and future actions on the project. Proper communication with the team also fosters the collaboration and boosts the morale of the project team members. Improper Project Management: A vast majority of the projects do see the failure at the implementation phase due to incorrect project management practices. A project leader should be able to manage the ongoing activities in a transparent and acceptable way to negate any wrong doings or deviations from the plan. Many times, incompetent or inexperienced project leads who lack the vision and domain knowledge fail in delivering the desired results. It is of utmost importance to delegate the right work to the right people. The management should deploy a project leader who has both technical expertise, business knowledge and the people management capabilities. The product vision should be clear and the team should ensure that the tasks are completed and should be periodically reviewed. If needed, a project management expert should be consulted. Complex Requirements: Many a times, the projects are too complex and time consuming. This leads to many complex problems arising out from time to time and the team lacks the capabilities to battle these issues leading to failure of the projects. Also, in many cases, the requirements of the end product keeps changing from time to time due to customer or competitor pressure which also derails the progress made by the team and this creates issues too difficult to resolve. The project leader should invest fair amount of time in issue resolving, planning and anticipate the kind of issues that may arise during the course of time and its troubleshooting. This is not always possible owing to the stringent timelines and delivery specifications. However, the project manager should effectively deal with these issues and take the buy-in from management if necessary to ensure the issues are resolved before becoming complex. Also, the management should ensure that the scope of the project doesn’t deviate much and should set realistic deadlines for the deliveries. Above stated are some of the key factors responsible for the failure of the Agile projects and the necessary steps to prevent the failures.
  14. Vishwadeep Khatri

    Oct-Dec 2019

    This album contains Benchmark Six Sigma Training Photographs from October to December 2019.
  15. I wasn’t able to get the survey report to analyze the details behind the survey. The optimistic way of looking at it is that 84% of Agile projects are successful in some forms, which is in many ways around twice the success rates of traditional waterfall approach. Reference (https://vitalitychicago.com/blog/agile-projects-are-more-successful-traditional-projects/) "Agile Software Development is a lightweight software engineering framework that promotes iterative development throughout the life-cycle of the project, close collaboration between the development team and business side, constant communication, and tightly-knit teams. " A key aspect of Agile projects is fail fast. Sometimes there is a blur on what is genuine continuous improvement vs genuine failure I feel it is also got to do with the type of organizations adopting this. We have the new age technology companies (Google, Facebook etc.) vs the traditional Enterprises adopting Agile. For New Age companies, speed is of utmost importance. They constantly are looking at bringing new products to market. The mindset is towards faster rollout, fail fast and improve faster, focus on end to end straight through processes with customer focus as paramount importance. The people who they employ are also tech geeks suited for agile. For Enterprise companies, they are saddled with ageing technologies, often a huge complex myraid set of technologies. They try to leverage existing IT ecosystem to bring in change needed to compete with nimble new competitors. They also train existing business and IT SMEs on Agile and expect them to adopt the new ways of working. The same is the case with many of the legacy IT Services companies, where the large portion of the employee base is used to the traditional Waterfall methodologies. The biggest reason for failure of Agile projects is due to Planning. Most companies don’t have two strong critical roles - Product Owners and Architects. A badly designed and thought through project is only going to iteratively fail. Product Owners need to have a strong handle on the roadmap for the applications and value it delivers. Agile also requires the business SMEs to work in a lot more collaborative manner than before. With myriad of new technologies available, and short durations of Sprints, its critical to have Architects who have a strong vision on the stack to take care of performance and security. The role of the Architect is also to keep it simple, that in turns reduces the chances of failure. Key aspect of Agile is strong collaboration and constant communication. A good collaboration tool is equally important to track the progress and have a strong control on the various aspects of the project. Teams also tend to be geographically distributed. Organizations need to invest in such collaboration tools, including video conference to make face to face interactions. Since Agile involves a small team, its equally important that there is good synergy within the team members. Cannot have a hierarchical approach, discouraging members to speak up. In traditional approach, it became very compartmentalized with specialists for design, documentation, development, testing, deployment etc., but in Agile there is expectation of each member to own end to end, and not looking at passing things to another team. Retrospect and Learning needs to be done in all earnest. More often teams tend to focus too much on process metrics like velocity, backlog, burn down charts etc. and tend to forget the goal - the business value that is to be delivered. This results in teams focusing on getting things done mechanically, being rigid on addressing changes required so as not to break the sprint. Ultimately working software is the key to successful projects. Agile itself is a very simple approach, having some 10-12 key principles. As the saying goes "The devil is in the detail", making Agile successful or not depends on the details behind the planning and execution.
  16. Earlier
  17. Before we take a look at the potential causes for the failures and look at the ways/best practices to avoid these failures, let us take a look at what Agile and Sprint means. Agile: It is a way of doing an iterative and incremental approach to deliver a project (product/service). Agile projects needs a cultural mindset change and has certain set of principles to be followed as prescribed by Agilemanifesto.org While there are many implementation techniques for doing in an agile way, one of the most popular techniques is Scrum, which is a framework and is used for developing, delivering and sustaining complex products. As per the Scrum Org (parental body of Scrum framework) definition, the heart of Scrum framework is the Sprint which is a time period of one-month or less(can be 1 or 2 or 3 weeks as well) during which a "Done" , usable and a potentially releasable product increment is created. Now let me try to answer why and how failures could have happened for these organisations from my perspective. Why Failures happen in Agile Sprint based projects? Before we take a look at this, we need to understand the fact that the world is moving away from the traditional models such as waterfall to the Agile world because traditional methodologies had much higher percentage of failures. As per the Chaos report of 2011 by Standish Group proclaims that Agile Projects are 3 times successful with respect to software development when compared with delivering through traditional methods (as referred in Scrum - A pocket guide book by Gunther Verheyen). Having said that , now even as we make use of Agile for any sort of work (and not only for IT related), the fact that 16% of the projects which run in a popular technique - Agile Sprint(read Scrum) fail is a serious sign that something fundamentally could be wrong somewhere in my view, as an Agile Practitioner. Two cases which i want to highlight: Case 1: For organisations, which move newly(transformation) to Agile, the issues come around how they adapt quickly to Agile mindset and practices. Failure happens when the team lingers on the traditional approach(Command and Control mode and not following servant-leader approach and not doing collaborative work and not having self-organised approach) despite putting the Agile processes in place. Case 2: Organisations which are supposedly mature in Agile Transformation(because they are into Agile for some years and executed many Agile projects) can have different set of problems. They may have some complex projects which might involve multiple vendors and coordination and cooperation required amongst the different teams for a product has to be precise In general Organisations (applicable to case 1 and case 2) are averse to Risk-taking , in terms of failure, then there is more chance that their projects will fail. Agile Scrum works on Empiricism. You get to know more about the product as you progress. Therefore the mantra is Fail Fast if at all you are going to fail. This is why many organisations try to have lesser length for a Sprint (1-2 weeks rather than having the maximum 1 month period, so that you minimize your risk of not making the right product to a shortest possible period. Thats the whole concept of the timebox. Unlike the traditional model in which you finally find that the project is not meeting the customer needs, Agile projects get to know the feedback from the stakeholders at a very early stage and get a continuous feedback. Sometimes even in case 2 organisations, this will not happen properly due to multiple reasons , which is again a recipe for disaster. Classification of Failures: With respect to the Failures (in the attached document), the top two quadrants, 'Agile Maturity' and 'People' can happen in Case1 organisations and 3rd quadrant 'Agile Scrum Maturity and Scrum Process Compliance' can happen both in Case 1 and Case 2 organisations. The 4th quadrant 'Product Vision and Volatile Market' can happen in Case 2 organisations. How to prevent such Failures in Agile Sprint based projects? Most of the Failures would be addressed straight-away if organisations understand and practice Agile and Scrum as they are meant to be. For each of the failure classification, corresponding best practices are also mentioned below. Here are probable reasons (in my purview) for failure and some of the best practices (in my opinion) to overcome such failures. 1. Agile Maturity Agile transformation could not have happened properly (for organisations moving newly to Agile) : Eg: Proper vision would not have been put in place (as how to adopt Agile transformation across the organisation) Agile will expose the existing dysfunctions in the organisation/within teams in the organisation. So that could have been the reasons for failure Eg: Inattention to Results, Avoidance of Accountability, Lack of Commitment, Fear of Conflict, Absence of Trust Organisations wait endlessly to make the actual change to Agile. They would plan for Agile movement but neither they would be in waterfall nor in Agile and end up in between Eg: They would have Dev Teams and QA teams working in Silo but calling the project as "Agile" Agile Maturity Best Practices For organisations moving newly to Agile Have a proper vision . Identify the need for the change , reflect upon your current organisational state (where you are) and what are the Key Progress Indicators (KPI) which can track the progress that you make in this journey. Ensure proper coaching happens to Key Stakeholders/leadership team on Agile nuances and mindset needed for that From leadership team till the last cadre in the position hierarchy this information should pass on Alleviate the concerns/fears and perceptions that people might have due to moving of Agile and its philosophy Once the perception about Agile philosophy changes (for good) then dysfunctions will be minimized to a very negligible/minimal level Teams would be truly cross functional which means they would be self-reliant and do their work without dependent on anyone. 2. People: People(key persons/leadership level) might have been reluctant to change to Agile way of working(applicable to Organisation transforming to Agile). Agile requires shift in mindset from the tradition "Industrial" paradigm (Command and Control mode) to 'Servant-Leader' mode. Reasons are many · People could have felt that their position power and influence was marginalised · They would have thought that adapting to a newer way of working was difficult to imbibe into their working DNA · They would have thought that Agile can expose their shortcomings and hence felt therefore that their personal reputation could get damaged which could hurt their ego. Management/Leadership team probably did not do enough groundwork to convince the organisation members on the need for Agile(applicable to Organisation transforming to Agile). Effectiveness of a solution is determined by the Solution Quality and its acceptance. The acceptance factor(by the organisation employees) therefore might not have been there !! Best Practices for People Management When Management team/Senior Leadership team is convinced and embraces the agile value and stresses the importance of Agile, then Agile Acceptance can happen When Leadership stresses the importance of Agile with statistical data or with proper justification or if there is an incentive (in terms of opportunity for employees while moving to Agile), then employees take upon Agile diligently 3. Agile Scrum Maturity and Scrum Process compliance Project Teams might not have followed Scrum rules, principles properly (ScrumBut) Eg: Scrum Events might not have been properly adhered. They are key to Inspecting the work done and provides a chance for teams to correct things(Adaptation) 'Definition of Done'(DoD) might not have been strong enough to provide a strong product in a short period of time duration(1 week -1 month timeline). DoD defines the completion of "DONE" which indicates that an item picked for that particular Sprint is completed. Teams within the organisations, might not be either able to scale up to the dynamic scope changing nature of the work within the sprints frequently or might have seen some sprints cancelled due to the goal becoming obsolete which can demoralize them (the teams). Agile Scrum Maturity and Scrum Process compliance - Best Practices If Project Teams are educated on Scrum importance by Scrum Master then it helps the whole scrum team 4. Product Vision and Volatile Market Product owner might not have got his/her priorities right while ordering the product backlog items. Reasons could be · Stakeholder Engagement might have been poor · Probably Prioritization was not given importance. · Too many stakeholders might have tried to influence their needs · Product Owner might not have been assertive and was not in a position to influence and shape the destiny of the product. The product was not probably good enough to survive in the market as the Industry(to which the product belongs) is itself volatile and/or highly competitive. Product Vision and Volatile Market -Best Practices Product owner should have constant interaction with stakeholder. Conclusion: Agile is not just a methodology to be practised, but requires a mindset change. Scrum is a framework which has certain rules and boundaries that need to be respected. There are certain principles of Agile (developed by quite a few intellectuals) which needs to diligently followed and a set of Scrum values complementing these principles and set of Scrum guidelines that need to be applied on the project. Doing these will ensure that organisation teams can have the ability to respond to ever changing needs of their customers. Failures when expectations are not met. Gunther Verheyen , a popular Agile Scrum practitioner in his reputed book (aforementioned) says that Agile has 5 characteristics: People driven, Facilitation, Iterative-Incremental, Measuring success, Change. In a typical Agile, People are respected for their creativity , intelligence and self-organising capabilities. Collaboration happens amongst them. Teams are facilitated by servant -leadership. Products are created piece-by-piece and agile processes are defined . Project progress and success is measured in terms of working product by frequently inspecting it and the actual value it can provide to the people who will use it. Even when requirements and implementations are predicted upfront, they would be susceptible to change due to volatile nature of the market and may be due to high competition as well. So when organisations follow these Agile characteristics as part of their working DNA, the failure rates for them is going to be very minimal and their success rate would be high.
  18. Bench is wrong, We can never consider a process to be perfect in a fast changing environment. Six sigma projects not only improve process but also provide an opportunity for innovative / creative solutions.If Kodak had would have done a six sigma project they would have been the leaders in digicam world today.Six sigma projects shall help a organization to create products & services for future.Six sigma helps the process to be active/live and if not done then the process becomes obselete.
  19. Ram Rajagopalan and Pavan Chinta, both are winners for their accurate descriptions of Paynter Chart.
  20. Q 216. According to a survey, around 16% of Agile projects are a complete failure amounting to a loss of around $50 Billion annually to the tech companies. What are the most common reasons for failure of Agile Sprints? What are some of the best practices to avoid such failures? Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday. All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/ Please visit the forum home page at https://www.benchmarksixsigma.com/forum/ to respond to the latest question open till the next Tuesday/ Friday evening 5 PM as per Indian Standard Time. The best answer is always shown at the top among responses and the author finds honorable mention in our Business Excellence dictionary at https://www.benchmarksixsigma.com/forum/business-excellence-dictionary-glossary/ along with the related term.
  21. Benchmark Six Sigma Expert View by Venugopal R While Pareto chart depicts a set of factors in the descending order of their frequencies of occurrences, Paynther chart divides each bar of the Pareto into further sub-groups. The sub-groups thus split-up should be comparable across the bars of the Pareto. Paynther charts are popularly known for combining run charts along with a Pareto for tracking the trend of each sub-group item across a period of time. However, we may find the Paynther chart useful to depict comparisons of sub-groups other than time as well. For instance if we have a Pareto for the number of units of a product sold across various metros, we may construct a Paynther chart by sub-grouping each bar for the product-types. The Paynther chart represents the split-up details of each bar of the Pareto in the same order. From the charts above, it may be seen from the Pareto chart that overall sales for Metro4 is lower than Metro1, but the sale of Product B is more in Metro4 compared to Metro1. Similarly, other inferences may be derived. It helps to prepare the overall Pareto chart first and then create the Paynther chart for the chosen subgroups. The Paynther chart helps to drill down to next level of detail from a Pareto chart and would be very useful for root cause analysis. Other examples where we can apply the combination of Pareto and Paynther charts would be: 1. Defect types across months 2. Productivity of set of services across multiple sites 3. Purchase volumes of a product across by different age groups The Paynther chart may also be adapted to track the impact of actions on specific issues – for example, to track the improvement of specific product failures based on corrective actions implemented. For this, Paynther chart will be constructed with the sub groups following a chronological sequence.
  22. Paynter Chart: Paynter charts are the statistical tools used in the quality improvement projects. Paynter chart is a combination chart which uses the principles of Run charts and Pareto charts to refine the outcomes of the Pareto analysis. In other words, these can also be described as the extension of the Pareto charts. Pareto Principle, which is popularly called as 80-20 rule, provides us with the major causes i.e., the top 20% causes/reasons for a particular problem. Paynter charts further probe these causes over time to give us a specific list or count of these causes that are responsible for the issues. This means that a Paynter chart splits the Pareto graph (the groups) into further smaller sub-groups. This highlights the actual sub-group(s) that is adding up to form the major group. This will also show the manner or the trend in which these subgroups are added and indicate the specific elements responsible for the Pareto bar. Another significant role of a Paynter chart is to measure the variation between these sub-groups within a Pareto Bar which help us understand the overall process variations. To perform a Paynter analysis, first we should have the data sufficient enough for a Pareto Chart i.e., samples to be analyzed, the categories (defects) to be identified in the sample after analysis. Once a Pareto chart is plotted, we will come to know the most frequently occurring categories of the defects. Once this analysis is complete, Paynter analysis could be performed to drill down into these categories (identified in the Pareto) to identify the subgroups of the same which are resulting in the respective category of the defect. For example, if we identify that width of the bolts as a major category of defects from the Pareto analysis, by performing the Paynter analysis, we will be able to further segregate to identify the actual subgroup of errors or defects. In this example, Paynter analysis will give us the proportion of bolts rejected due to the variations in the bolt width (broad, narrow etc.,). This analysis will help us where to act in our process to effectively control the sub group of the defects which is impacting the overall category of the defects thereby causing substantial benefits.
  23. The Paynter Chart may be a tool that goes on the far side a Pareto. A Pareto Chart focuses on issues that supply the best potential for improvement by showing their ratio or size or number of occurrence. A Paynter Chart goes on the far side the Pareto Chart by sub-grouping the Pareto bars. The subgroups may well be days, hours, etc. The Paynter Chart is predicated on the Pareto Chart principle, that focuses on the areas of priority and quickly puts them during a easy graphical type by subgroups. It helps your team focus their efforts wherever they'll have greatest impact.
  24. Paynter Chart: Paynter chart is combination of Pareto Chart and Run chart. Ford developed this chart and other companies started adopting the concept gradually. Benefit of Paynter chart: It gives insight of variation with various other dimensions We can simple create a pareto chart, group the data points into subgroups and then add required additional variable (viz time) to it. Pareto and Paynter Comparison: Similarities: Pareto Chart Paynter Chart Both used as a part of Corrective Action Process We will be able to identify Vital Few in both the charts Based on Pareto principle, 80/20 rule Both are used when there are many problems and when we wanted to focus on few/most significant metrics Differences: Pareto Chart Paynter Chart Results: Vital Few and Trivial Many parameters Results: Vital Few, Trivial Many parameters, variations, subgroup data points Displays individual pareto bars Displays sub grouped pareto bars Will be able to visualize Vital and Trivial defect contributors Will be able to visualize long term corrective actions Variations: Weighted pareto chart, Comparative pareto charts Variations: Sub grouped parameters based on the selected variable
  25. Pareto charts are used to identify the top causes for a particular effect (defects). Its often associated with 80-20 rule, 80% of variances are due to 20% of causes, though often not necessary to meet the guideline. Paynter Chart is a statistical graphical tool that drills down the Pareto chart. It enhances the Pareto Chart with a run chart, that indicate what items add up to the count for each reporting period. The chart displays a subset of key sub groups as a bar chart, with the total across subgroups on the top. Benefits - Helps to drill down the composition of each bar of the Pareto to spot trends and patterns. Paynter Chart was developed by Ford Motor Company Reference Sites https://www.yumpu.com/en/document/view/17279712/paynter-chart-analysis-guidelines-chrysler http://www.statit.com/support/faqs/gpaynter.shtml http://www.statit.com/support/quality_practice_tips/usingpareto_payntercharts.shtml
  26. The winner today is Pavan Chinta. Congratulations, Pavan for a very good answer along with valid examples!
  27. Q 215. Explain Paynter Chart and compare it with Pareto Chart. Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday. All questions so far can be seen here - https://www.benchmarksixsigma.com/forum/lean-six-sigma-business-excellence-questions/ Please visit the forum home page at https://www.benchmarksixsigma.com/forum/ to respond to the latest question open till the next Tuesday/ Friday evening 5 PM as per Indian Standard Time. The best answer is always shown at the top among responses and the author finds honorable mention in our Business Excellence dictionary at https://www.benchmarksixsigma.com/forum/business-excellence-dictionary-glossary/ along with the related term.
  28. It is well known that the demand (or supply) of a product is greatly influenced by the price change. This change in the demand, however is not uniform. Sometimes, a minor change in the price would leads to a great change in the demand quantity and in other cases, even a larger change in the price will have minimal impact on the demand. “Elasticity of demand, also referred to as Price elasticity of demand is the degree responsiveness of quantity in demand (of a product and/or a commodity) due to the alteration of its price. It can be mathematically expressed as below: Price Elasticity of demand = % change in the quantity demanded/% change in the price i.e, the percentage change in the quantity demand divided by the percentage change in the price. This variation in the demand could be broadly categorised into Elastic and Inelastic Demand. The demand is considered as Elastic if a change in the price would significantly impact the demand. For e.g.., Reduction in the prices in cars (by offering the discounts and incentives) have greatly increased the sales. Similar way, the demand is considered to be inelastic if the price alteration has no proportionate increase in the demand. For e.g., confectioneries where the price does not have a proportionate relationship with the demand of these goods. Since this broader classification doesn’t give an understanding of the degree of responsiveness (or unresponsiveness), the elasticity of demand is further divided into 5 categories as explained below: (1) Perfectly Elastic Demand: It is also called as Infinite elasticity. The demand is said to be perfectly elastic when a small change in the process leads to a much significant effect on the demand of the good(s). In other words, a short fall in the prices would cause an infinite increase in the demand and vice versa. This relationship is not very common and has very little importance in the practical world. For example, in the commodity trading, even a slight change in the price would increase or decrease the demand significantly. Another such example is in food or restaurant industry, a slight increase in the price of the usual menu would make the customers chose from the other options or seek for alternatives. (2) Perfectly Inelastic Demand: This is also known as Zero Elasticity. This is the condition where the demand remains uninfluenced by price changes. In general terms this is when the demand remains constant. For example, Automotive fuels (Petrol, diesel), Gold, Pharmaceuticals are few examples where this principle is observed. (3) Relatively Elastic Demand: As the name indicates, Relatively elastic demand is observed when the percentage change in the demand is higher than the percentage change in the price of the commodity, which means, the proportionate increase in the demand is much higher than the fall in the price of the respective product. For instance, even a small percentage decline in the real estate prices can create a higher percentage demand. Other examples include the luxury goods like Phones, electronics automobiles etc., (4) Relatively Inelastic Demand: Relatively inelastic demand can be observed when the percentage demand is lesser than the percentage change in the price. Here, the price has a very less influence on the demand quantity. Even with a higher fall in the price, we may not see a significant increase in the demand. The products or goods for daily use usually fall into this category (like Rice, wheat, Gas etc.,) (5) Unitary Elastic Demand: This is also called as Unitary elasticity and is often considered imaginary. This is observed when the percentage change in the demand is almost the same as the percentage change in the price. In other words, change in the demand percentage is equal to the change in the price percentage.
  1. Load more activity
×
×
  • Create New...