Jump to content

R Rajesh

Excellence Ambassador
  • Content Count

    114
  • Joined

  • Last visited

  • Days Won

    12

R Rajesh last won the day on December 16 2019

R Rajesh had the most liked content!

Community Reputation

37 Excellent

5 Followers

About R Rajesh

  • Rank
    Advanced Member

Profile Information

  • Name
    Rajesh Rajagopalan
  • Company
    NA
  • Designation
    Associate Consultant

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Often people misconstrue about SixSigma just like how 'Bench' feels. Six Sigma approach is a good candidate when there is a problem or issue which is there for quite some time and the relevant team does not have a solution in place for that and that the stakeholders do have a effort, time and cost luxury to invest on that. Also there has to be a mechanism to measure the effectiveness of the metrics/data to be captured. If this is understood, then 'Bench' can get enlightened. Coming to 'Mark', having the right and capable measuring system and determining whether improving the process(DMAIC) or creating a new process(DMADV,DMADOV...) will get the requisite results, is what he has to do.
  2. 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.
  3. When 'Bench' does not know or show interest on Lean, Six Sigma principles, he should try to make a 'Mark' in his field, by joining Benchmark Six Sigma and gain the extra knowledge in Business excellence that Lean , Six Sigma approaches can provide
  4. Normally when an issue happen in an IT Infrastructure, an assessment is made to see the kind of impact it can have for the business and ultimately to the customer. Accordingly fix for the issue will be put in by the respective teams. So even though there can be multiple issues that might happen and for which there may be root causes which are distinct or isolated, each of the issue needs to be tackled in terms of its severity or priority level(decided on the basis of the business impact and the resultant effect on the key customers that the business has). Some organisations address the tickets (called as Incidents in IT Infrastructure projects) in terms of Priority and some organisations, in Severity. Sample Classification of Priority tickets denoted by P1,P2,P3,P4 where P1 and P2 are critical/High respectively and P3-Medium and P4-Low or Sample Classification of Severity tickets denoted by Sev1, Sev2, Sev3 and Sev4 ; where Sev1-Critical; Sev2-High, Sev 3-Medium ; Sev4- Low Now if the issue is of a critical/high nature then we need to put a quick fix. Often the fix would be a workaround. Permanent fix might be later. But if the issue is of a lower nature(priority or severity) then those incidents (issues) are pushed to 'Problem Records' which is used for providing Permanent fixes. This is because the Service Level Agreement(SLA) for Resolution time for Sev1/Sev2 or P1/P2 is very short(in minutes to few hours) and for Sev3/Sev4 or P3/P4 , it can be mostly(in a single day to few days or so). Therefore, it is the severity/priority of the issue that decides the best way to handle the given issue. Accordingly it is decided to have the issue either to be incident managed and needs to be addressed immediately with some sort of fix, or it can be marked as a problem record and moved to 'Problem Management ' category, for a permanent fix. However there are few things that can be done: 1. Maintain a Known Error Database (KEDB). This is an industry standard. Since we talk about issues with isolated root causes, it becomes difficult to track things as we don't have a standard cause to provide a fix. So what happens when an issue happens again for the 2nd time say after a month (from the 1st time when it occurred). Imagine, the person(say a Subject Matter Expert) who provided the fix is not available on that day (when the issue happens or reoccurs), for whatever reasons(assume he/she is resigned). Whoever is working on the issue may have to go through the issue all over again. It would unnecessarily take time to fix the issue. The knowledge therefore would have been lost. Imagine if we have multiple issues with different root causes and how difficult it would be to address each one. For such scenarios, KEDB can be used - which is primarily serves as a log of issues with solutions captured(it can be workaround or permanent fix). It can be a customized tool, excel sheet or any other file. 2. When there are multiple issues and if an issue is repetitively occurring, whether it is high or low priority(severity) issue, then the issue can be tagged as a 'Problem Record' as part of Problem Management. 3. While many teams goto Problem Management based, on getting repetitive issues , which is reactive Problem Management , some wise teams - look for patterns and trends in their project/applications and based on that do a proactive problem management (by basically finding out potential problems) and have problem records created and proactively do a permanent fix avoiding in the process , potential problems (which can avoid even disasters). There are tools like Kepner Tregoe method which can help Problem Management. Conclusion: IT Infrastructure projects will have different type of issues with different priority/severity level. Each may have different or distinct root causes. But as we saw, based on the severity/priority of the issue, the issue is dealt with. It is always a good practice to have a KEDB to ensure that workaround solutions or solutions for permanent fix is available. For instance, an error in a page can happen and which may be a critical or high issue, but for which the workaround solution might be say restarting a server(just a crude example but using here to drive home the point). So this can be mentioned in KEDB for that issue Also there could be cases where issues can be created as Problem records so as to provide permanent fixes. In such cases, for recurring issues, records are created reactively (issues have happened as incidents - be it critical/high or medium/low) and proactively also records can be created. The more proactive potential issues we find and provide upfront fixes, better would be stability of the applications in production, better customer satisfaction and minimal adverse impact for the business.
  5. Before we even look into the techniques, i feel its worth mentioning who is a stakeholder. A stakeholder is someone who is positively or negatively impacted by a work(which can be an activity, a process, a task, or a project which can produce a service / product). The stakeholder can be either involved(read as person/team, who is doing the development/creation/shaping) in the work or be a recipient of that work. An organisation can have many stakeholders.Some Stakeholders are influential enough to determine the successful outcome of the specified work that they are associated with (for simplicity sake, let us call that as 'project' for further discussion in this article). In this specific context, we are focusing on the influential stakeholders which are more likely to be the recipients of the project's outcome(either a service or a product). With this introduction, let us move to some of the key techniques which can be quite useful while engaging the stakeholders in the early stages of a project. There are some quite a number of factors which are key while engaging the stakeholders especially during the beginning stages of a project. 1. Stakeholder Identification 2. Understanding the stakeholder expectation and needs 3. Prioritization of needs 4. Stakeholder Consent and Acceptance . 5. Early feedback from Stakeholders
  6. In my opinion, there are quite a few reasons as why DMAIC is not favoured by some of the leaders. 1. (Perceived) Time taken by the DMAIC project to showcase the right results to the relevant key stakeholders (whow may be keen to see the outcome of the project), as they expect. Imagine that you are doing a black belt project which can take a minimum of 6 months - 1 year. Now with a DMAIC in place, you have some amount of work to do. You need to compare of measurement of AS-IS and TO-BE process. The comparison might be exhaustive and data collection can be time taking as well. As DMAIC involves improvement of an existing process, completing the six sigma DMAIC project with the desired result can be a real nightmare for the leader who is in charge/accountable for the project. 2. Potential Complexity involved in data collection as more quantitative data and statistical tools are involved 3. In the opinion of the leaders, there may not be a practical significance (outcome) despite a statistical significance by doing the six sigma DMAIC project. 4. As lot of data to be collected to compare the AS-IS and TO-BE systems, and also the fact that the measurement system is also intensive and complex and is time consuming, getting a dedicated(read motivated) team might be difficult (in the opinion of the Six sigma leaders). Hence the leaders might feel DMAIC projects not worth trying under the circumstances. Conclusion: As we had seen above there could be a number of reasons because of which leaders do not go for DMAIC. There could be some rare cases where Six Sigma leaders(say, of a Service Providing organisation) might be directly involved with customer business growth. The customers might want the Six Sigma leader to be focusing more on their products(better product designing) rather than any of their process which in their opinion (and actually) is well placed. In that case, neither the six sigma leader nor the service providing organisation has got any chance. They nend to act as per the customers. So in this case DMAIC will go out of the way.
  7. There are quite a lot of Metrics that are quite useful cutting across sectors. Some of such metrics are cycle time(multiple industries use this), response time, resolution time(IT Support), Web response time(Web application), Velocity(Agile Scrum). For instance, Cycle Time is a critical metric used across industries. In an IT production Support project, 'response time' and 'resolution time' metrics serve as part of the Service Level Agreement (SLA) between a service provider and it's customer. But these metrics are not applicable in a development project as the product is either in progress or ready to be deployed in production. Similarly consider the web response time. It is critical metric for a Web based project but not so for a desktop application where the focus could be on ease of use or the response time is expected to be instant (so the metric is not at all a useful metric in this case) . Take the case of 'Velocity'. In an Agile Scrum world, 'Velocity' is often measured as a key metric, which is used as a measure of work progress in a given iteration(a defined time duration in terms of weeks- in a broader sense), calculated in terms of story points or ideal days/hours . While this serves as a pointer for picking potential work in subsequent iterations, the authority body for Agile Scrum (scrum.org) says that 'Velocity' is an optional metric. That means some organisation can also decide not to use it. Despite it being efficient why it's not used by some organisations. The problem lies in the fact that some organisations start misusing the efficiency of the metric. For instance, with 'Velocity', people start to compare the velocity of one team with the velocity of another one. There is apple to orange comparison. This defeats the objective of the metric. Also, Velocity can be applicable to an Agile project and not to a project that runs in traditional models such as waterfall. So metrics which are considered to be important will not be needed at all times. Conclusion: There is no 'fit for one size' metric. Every metric is unique and the efficiency of a metric depends on the environment, context in which the metric is used. What is an efficient metric in one case may not be applicable or efficient for all scenarios. Therefore, in my opinion, it is improbable to have a metric to be defined as better than another as could be seen from the aforementioned examples
  8. Definition: As the wiki definition says "Net Promoter score(NPS) is a management tool that can be used to gauge the loyalty of a firm's customer relationships." Objective: The tool is used to predict customer loyalty to a product, service,brand or company. What is it all about? As succintly put in the wiki for Net Promoter, the tool measures the loyalty between a provider and a consumer . The Net Promoter Score (NPS) tool is used by a provider who can be a service provider or an employer or who can be any other entity . The Provider will ask question as a survey, which need to be answered by the consumer. The consumer is the one who can be a customer (to the service providing organisation), or an employee(in case this is measured by an organisation for its employees) or a respondent to the survey for this NPS. How it works ? NPS is based on the calculation obtained from a question posed to the respondent. Often the question could be "How likely is it that you would recommend our company/product/service to a friend or colleague?" NPS score can range from -100 to +100 when measured across multiple people, where negatives indicate that the respondents are deemed as detractors and positive scores indicate that the respondents are called as Promoters. In a 11-point scale (0-10), the rating is classified such that respondents who provide values in the range of 0-6 are branded as "Detractors", respondents who provide values between 7 and 8 are branded as "Passives" and respondents who provide values between 9 and 10 are branded as "Promoters". Formula to find NPS score NPS score = % of Promoters - % of Detractors Promoters are loyal and would provide support to the provider of service/product/service providing organisation. Passives are neutral support people who are susceptible to become detractors quite quickly at any point. Detractors are unhappy customers who can damage the service provider's brand and can portray a bad picture about the organisation, through word of mouth. Why Ordinal data is converted into categorical data ? Before we talk about that let us see what categorical data and Ordinal data do. Categorical data will have data classified into multiple categories and has no intrinsic ordering. Whereas in Ordinal data, the ordering happens. Now let us take a look at the conversion part. Imagine the 0-10 point scale. Assume (in a hypothetic way) that each ordinal point is representing a categorical value as mentioned below : 0- worst, 1-very poor, 2-poor, 3-Not bad, 4-Average, 5- Fair, 6-OK,7-good, 8-Better,9-Very Good, 10- Excellent Now let us compare the difference in categories between 0 and 2 and the difference in categories between 4 and 6. The difference in these 2 set of categories would be quite different from being worst to somewhat palatable (but sill not good enough from the customer perspective-which is a different issue altogether). Here the ordering happens but we can see the size of the difference between the categories is inconsistent as the spacing between the categories in each set is varying. Also is the fact that upto the 7th point of the scale(0-6), it is deemed as "Detractors" and 8th and 9th point of the scale(7-8) called as "Passives" and 10th and 11th point (9-10) as "Promoters" . Therefore there is no need to focus on the Ordinality. Hence it is branded as Categorical data. Conclusion Effective use of NPS tool can bring in the right perspective to an organisation about its customer and can potentially make an organisation succeed in understanding the customer's expectations and also ensure a satisfied customer which can bring more additional customers and revenues for the organisation
  9. Mahatma Gandhiji said once , that 'Customer is the King'. If we want to do business successfully, it means that we should satisfy our customers. Else we would loose the race in the respective field(area of business). Having said this, there are some interesting places where we would think as a business provider that we can better stay away from a customer. In my opinion, there are multiple reasons as why we may not like to have some customers(in a corporate world or an individual business) In a corporate world it could be because 1.Of a high demanding customer to which the 3rd party or service provider organisation cannot cope with - It could be due to high expectation on performance , end-user satisfaction 2. The service providing organisation may not see a long-term benefit(profit) in its engagement with a customer as it had originally envisaged and the effort in putting the work therefore may not be the worth. 3. Of a stringent regulatory compliance/mandatory in a given location (in/from which the customer is operating) that the service provider cannot afford to have for various genuine reasons(like infrastructure/logistical challenges, lack of specialized skill,...) Eg: Take Automobile industry for instance. Indian car makers need to comply with European automobile standards 4. Of a tough SLA compliance which the service providing organisation may not be able to meet or may be fraught with much risk in terms of penalty for non compliance which may not be worth for the benefit that it gets. Especially in an IT industry say in a production support(maintenance) where penalty clause might be stringent and the organisation may not want to get involved for that kind of work for the benefit it gets. In an Individual business it could be because 1. There is a perennial problem with payment from the customer side 2. There is loss of trust due to the happenings in the earlier dealings 3. Of ethical and moral values which the customer may not practice for whatever reasons. Conclusion Every organisation/individual running business would a benefit to cost ratio. Especially , in a corporate world, how much profit an organisation (Service provider) would get from the customer/customer segment is what the top mgmt would think of. If the customer is not going to be of any benefit to the growth of the organisation or not helping the image for that organisation, then there is no point in having such a customer. For individual business, there can be any number of reasons.
  10. A wiki defition of Simpson's paradox, also known as yule-effect states that, it is a phenomenon in statistics, in which a trend appears in several different groups of data but disappears or reverses when these groups are combined. How this happens? We always try to see relationship between the dependent (Y) and independent (X) variables. But there could be also a factor- called the confounding variable which can influence both your X and Y which we might not have considered while taking decisions. This plays a hand on the reversal of the trend!! Let us see some examples Example:1 Imagine a hypothetical case. Elections Ruling Party % won Opposition Party % won Candidate for Local Councillor Election 50% 45% Candidate for City Mayor Election 50% 40% Candidate for State Assembly Elections 40% 60% In a state(or province), two elections happens in some of the major cities - first councillor elections happen for the place/area, you live within a city, followed by mayor election for your city (due to unforeseen circumstances). Now sometime later, state assembly election comes. Even as in the first two elections, the members of the ruling party wins, the crucial assembly elections the ruling party loses!! While there is a correlation between a party and the candidate who represents the party , for each of the election, there could be other confounding factors such as people's perception of the party, in matters close to their heart or liking or any other lurking factors whose effects would have been failed to be studied or noticed. I also noticed some sites like https://www.britannica.com/topic/Simpsons-paradox, and also wikipedia for this topic , for further understanding and good examples. Conclusion: It is very important to identify confounding factors which can impact the causal relationships. Failure to do so, can create the Simpson's paradox. This could even confuse the decision makers to take a firm decision. The positive side of this is that it will highlight that there is something more to be explored to!!
  11. There are many reasons as why Green Belt Professionals do not use Hypothesis Testing despite they getting trained on it: 1. Time constraint due to Management needs: One of the foremost reason (in my opinion) is time. Companies (especially Corporates!!) do have their own agenda - in completing a number of Six Sigma Green Belt(GB) projects (or even Black Belt projects) within a stipulated time period(normally half-a year or a year)- For instance, in the case of an IT company, it can happen at every vertical (Say Banking, Finance, Health,Manufacturing...) - this depends on a company's needs!! This goal can probably be set by top leadership and/or a combination of market needs(from Company's strategic thinking or goal alignment perspective) and Key stakeholders/top mgmt. So every Continuous Improvement(CI) activity/project might have a curtailed time period and therefore this hypothesis testing might be overlooked. 2. Time constraint (induced due to size and complexity of the Data Collected): Time is a precious commodity. Normally, any CI project like PDCA, Six Sigma could take atleast 3-4 months of time and only with the help of a dedicated Sponsor or a process leadership team or a motivated set of individuals , a CI project such as a six sigma project(be it GB or BB) can be achieved.Now Assume (For simplicity sake, taken a crude and yet powerful(?!) example)that we are collecting data for efficiency(in terms of timely availability at the destination and prompt start from the bus depot-both measurable things) of bus transportation within a state or province. I need to have atleast 3-4 months of data to see a pattern of how bad (that's why you go for an improvement project. Is it not?) it is. Assuming now you have collected the data (do you ever thought data collection is an easy job always ? :-) ) Now as we move on to hypothesis testing, the complexity and size of the data collected becomes a big challenge. Multiple factors can come into play especially if the scope is for multiple bus transportation units(Different vendors operating different category of buses across multiple locations) in that said state or province. So the GB team may not have sufficient time to properly analyse and utilise the data collected given the time bound nature of Six Sigma phases. Therefore Hypothesis testing might not be preferred. 3. 'Cost' Factor: Any continuous improvement activity requires few things: Motivated Individual, Idea(to improve), Time and Cost. Often you get the first two (in that order), but the next two(Time and Cost) are vital things which determine if the idea can be implemented over a stipulated period of time. 'Time' and 'Cost' should go hand-in-hand to have an improvement activity. Having time alone and not having 'cost' is a problem. Hypothesis testing can turn-out to be a costly affair especially when analysis is made on complex and huge data and if there is not a proper guidance from a Black Belt or Master Black Belt (say, in case of a GB/BB project respectively), or if there is no subject matter expert(functional domain) associated for helping the GB team on providing the finer points on the analysis of the data collected.Therefore the GB team may consider in relinquishing this(hypothesis testing) exercise. I feel the aforementioned factors, are key reasons for Hypothesis testing not being used effectively. A special case scenario is also there. Fear Factor (Due to lack of Hands-On Experience): However well a person is trained on Hypothesis testing(for that matter any activity!!), unless the person gets a personal(hands-on) experience , he or she will not feel how and what it is to do a hypothesis testing. The fear factor(for some people it is difficult to overcome the inhibition) can cause a team to deny the use of hypothesis testing. Though this can be a rarity case(but i have seen people with such inhibitions because hypothesis is a demanding technique and which requires deeper understanding and usage and training knowledge is not suffice and practical knowledge also slightly steep and only by experience you get accustomed to that). Conclusion: Hypothesis testing is a very key activity in a continuous improvement exercise. Reason is that , you can statistically prove your point(read notion) or argument(Statement). It can statistically tell how significant or insignificant the factors that you took for your hypothesis is justifying the outcome.In other words, With hypothesis testing, we can actually see how much the statistical significance is being converted .into practical significance and how much it benefits the business. Therefore it brings so much value to the table. Its therefore, wiser to use hypothesis testing more so especially if the professionals are more trained in it.
  12. Root Cause Analysis(RCA) techniques have been there for many years. It is one of the most powerful techniques. Let us see some examples which uses Fishbone diagram,5-Whys ,some popular RCA techniques to take a deep dive answer to the question put forth. Before going into that , we will look into what a 'cause' is about and what a 'Root Cause' is. Definitions: Cause: It is the reason because of which something(event) is impacted or happened or someone is impacted by some means (positive or negative). Or in other words, it is the reason because of which there is a positive or negative effect on something/someone or something(event) has happened . When used in conjunction with root cause analysis , cause normally will portray an adverse situation/effect or used in negative connotation. People normally don't find the causes for things that go well (because assumption is that you know how to make it happen - that is a different subject/topic on its own. Lets not go there for the time being!!) . Root Cause: It is the primary reason(source) because of which an event would have happened that can be backed by some evidence or per the conclusion made by the person (probably under circumstantial evidence or based on gut feeling or using some custom based or analytical techniques such as 5-Whys, Paretto Chart...or using hypothesis testing.) who would have done the investigation (or done the root cause analysis). A cause can be deemed as root cause, if we are not able to drill down further or break into that (finding the reason for that situation to happen). This is where analytical techniques like 5-whys come into picture. Root cause(s) can also be found out using hypothesis testing (in Six Sigma or other statistical based methodologies). Now when can a cause or a 'set of causes' be deemed as a Root Cause or Root causes? When we know that for a problem(effect), if there is cause beyond which we cannot drill down for a source (primary reason due to which the effect or event has happened) or when straight-away know that there is only one cause for a problem, then it can be deemed as the root cause . If there are such multiple causes, then they can be deemed as root causes. We can also make an assumption (hypothesis testing) and with the help of statistical techniques can find the probable root cause(s). Picking a Single Cause (from a set of causes) to be deemed as a 'Root Cause' Eg:1Fishbone Diagram: Delayed Delivery of 'Pasta's for a family There was a 'delivery' agent company (who delivered Eateries to households in the nearby vicinity). One family in that area, ordered 5 'pasta's to this company and the sales representative said that it will serve(deliver) the order in 30 min. However after 45 minutes, still no signs of 'Pasta's was getting to that family. The Person who gave the order enquired on this with the customer care cell of the company. Even as the person in the customer care conveyed that her staff left and was on the way to the destination and should reach out to the person's home(destination) any time, she started thinking as why there was a delay in delivering. The customer was also thinking why it was taking too late. Now Customer care person was doing a digging as what really happened(because already the 'delivery' person left) and now she wanted to know where and how it became late. Putting a fishbone diagram she saw the potential causes for delay and tried to rule out each one if she could. She found out that everything was okay except for the 'Traffic Delay' which was not neither in her or in her company's hands. She realised that there was a planned protest , done by some protesters for a good cause, on that area where the customer was placed at. So she could correlate that with the 'Traffic Delay'. This was vindicated by another 'delivery' person who went to the same area to a different house for delivering an order. He also went bit late to that area and delivered it late and the customer called her and gave vent to his feelings. This 'Traffic Delay' cause, became the single Root cause as other potential causes were compliant and functioning as per they are supposed to or destined to and there was either enough or no evidence to support that they were malfunctioning or not in sync with what they are supposed to. Picking multiple causes (from a set of causes) to be deemed as 'Root Causes': Eg1:Fishbone Diagram: A national cricket team loses the final in a prestigious cricket tournament . The cricket board/management of that country analysed using Fishbone diagram, as why the team failed in the Final. Unfortunately when the board listed out that the potential causes (as depicted below) , it found that all causes had a part to play on different times of the match, right from 2 days before the match(practice) to during the match when batting during evening time the light was poor and sighting the ball was a problem in some of the areas of the stadium. and some team members playing poorly. As a result, the team lost . Now all of these causes were deemed as 'Root Causes' as in this case, the evidence was there for all these. Eg2:Fishbone Diagram: A national Football team loses to a minnows team in a league match in a prestigious Soccer(Football) tournament . The management team did a root cause analysis using Fishbone diagram and found that there were multiple reasons(causes) to loose the match, which are listed below. There was enough data (statistics) and visual display of the game (recorded) to see the set of causes which were deemed as 'Root Causes'. Eg:3 Fishbone Diagram: Production Defects in an IT project A software team delivers an application for an Insurance customer. After 2 days into Production, quite a handful of defects occurred and the customer was irate. The team did a root cause analysis using Fishbone diagram. They listed all the possible causes and found that except for the 'data centre' issue which was a one off case(for defects that happened on that single day when the fire ravaged that data centre) , rest of the causes were providing the source for these production defects. Hence they were deemed as 'root causes'. Why is the importance given for the causes and root causes? Because these causes/root causes are the sources of variation. You want to minimize your variation in your process . Is it not ? If you take a look at a DMAIC Six Sigma project for example, during the analyze phase, you would look at the potential factors that is creating the variation for your problem. Take the equation, y=f(x). You would like to know what are the 'X's , that would address the 'Y' . Not many times you may be able to provide the causes/root causes, with conventional analytical techniques, which could be due to size of data, data gathering is complex,due to cost of data gathering,....(typical scenario in a six sigma project) . So you make an assumption(hypothesis statement) and then find out the influential factors(cause or causes depending upon the assumption) . Accordingly, the factor(s) is/are deemed as root causes for the given problem on hand. So those factors(X) are addressed to improve Y. Conclusion: For every problem or effect that is happening or happened, there would be a reason/cause or reason(causes) because of which the problem would have occurred in the first place. Making use of proven and relevant techniques can help in nailing down the problem, at hand. Root Cause Analysis(RCA) of a problem helps in addressing the problem by specifically focussing/working on the root cause(s) identified and ensure that time is spent only on the actual issue and make sure that part is addressed. Ultimate Objective for anyone/team for doing the RCA is to fix the root cause(s) for a problem and ensure that there is minimal variation in the process(if the problem is part of a process) or ensure that a particular event or thing does not happen (if the problem is a standalone feature or entity) .
  13. Let us start with the need for Six Sigma. Six Sigma primarily focused on variation reduction.There were several methodologies such as DMAIC, DMADV, DMADOV, etc.,. Each had a slightly different flavour from one another in some phases of the six sigma project. Later the lean part also became prominent and together it became Lean Six Sigma and the focus was now modified to waste elimination and variation reduction. This was a super combo and had great telling effect for an organisation which was doing lean six sigma projects. Let me go highlight (to the best of my knowledge) the importance, relevance and business value that a Lean Six Sigma approach can bring to an organisation that makes use of it, in modern-day context. A Lean Six Sigma approach, 1. Can provide a roadmap as when(time-bound) to arrive at the outcome (organisational goal) for business strategy(ies)/objective(s) 2. Helps in providing a Systematic way of driving or realizing business objectives into tangible goals, and will have a dedicated team to achieve those goals 3. Helps in Agile SAFe. As Organisations across the world is moving towards Agile, many large organisations are moving into Enterprise Agile where hundreds and thousands of teams work on multiple products and those organisations employ a popular framework called SAFe (Scaled Agile Framework for enterprise) which uses Lean product development (applying lean principles). This helps in providing often a defect-free product as we focus on eliminating defects(wastes) and therefore productivity increases and we are able to seamlessly deliver our goods(can be any product or software application) on time. Sometimes this helps in ensuring deliverables are released on the fly(on demand) using DevOps and/or Continuous Integration and Continuous Deployment processes , especially in IT sector. So this is an example of the Lean Six Sigma philosophy that is mentioned in the question. 4. Can help in RPA and Analytics. Before working on the automation , value stream mapping can be done and after improving the existing process, automation can be done. 5. Can provide a sort of knowledge on statistics and regression are needed for you to have an effective understanding of the algorithms, for Deep Learning. To the Six Sigma Ignorant people or Detractors: Six sigma does not come for free - it requires bit of time and money and energy (effort spent by few human resources). The question is whether it is good enough to sustain or do that in an organisation. Invariably the answer across organisations is a firm yes -because more often than not,the benefits outweigh these aforementioned factors. Why ? Thumb rule : Six Sigma is time intensive process. So it is carefully designed such that you take it only on certain parameters. Does your problem happening for quite some time and has given your customer a considerable amount of pain - monetarily or reputation-wise; is the problem happening for quite a while now; is there no immediate solution for this and that you don't know the solution as yet and also do not know the root cause for the problem; is the customer willing to wait for you to do a Six sigma - which will provide a systematic and scientific data gathering and analysis and then come up with a solution based on that? If you have the relevant answers for these questions only, then Six Sigma comes into picture. Also it can ask you whether your problem is aligned to your business goal additionally. What all these questions means that unless we have these answers applied, Six Sigma cannot be started or not ideal. That's why Six Sigma when done properly can yield expected results. Conclusion: In today's fast paced Agile world, every organisation wants to expand their business in an exponential way. We are in a digital era where we talk about Robotics, Artificial Intelligence, Cloud Computing, Analytics (especially Big data). Every organisation wants to make use all of these to enhance its business. However be, an organisation is superior in any one of these aspects, if the processes within the organisation is not streamlined, still the organisation cannot achieve maximum capability. This is where lean six sigma in 3 different facets - as methodology , as philosophy, as Management systems come to play, as we saw above with some pointers. Imagine IT companies, saying 'First Time Right' , 'Zero Defect' in 'Integration Testing' Phase, 'System Testing' phase. How many times we would have heard this. This is applicable across other industries as well. Lean Six Sigma is not about executing six sigma projects. It teaches about the best practices for providing right tools and techniques for Problem Solving, Process Diagrams, Data Analysis, Quality Control, SPC,.... With the help of these tools and techniques, we can take the right ones for the right area. For instance, Value Stream Mapping and COPIS diagram can help in doing waste elimination. Some of the most productive tools can help in day-to-day life of an organisation bringing robust design. Imagine you do Root Cause Analysis (RCA) using Fishbone Diagram and did a paretto chart finding top 5 causes for the instability of a release of the most important product(of my customer). You did a brainstorming and with a Pugh Matrix, you choose one best option from several ones. Now you addressed the 5 causes immediately and within next Agile iteration(2 weeks) you fixed those issues and released the product. Everything is resolved. Customer is extremely happy and within a week he gives your organisation a new business similar to this existing one. Has this happened to you or not ? Or Will not this happen ? It will . With the advent of Lean Six Sigma, thinking pattern of people(approach to a problem) also gets changed to the better (personal experience and also i have seen many). Tendency is to view things laterally (outside-in perspective) and that helps in addressing the problems effectively. Therefore i personally, very strongly believe that Lean Six Sigma provides a significant contribution to an organisation, in terms of business value.
  14. Let me start with my assumption of what it takes to qualify as a Project in Project Management realm , a Project and a Process in Business Improvement or Six Sigma world. Project in Project Management Realm: In a one-liner , we can say a project will have an objective with a definite start date and a definite end date. Eg:1 Converting a meter-gauge rail(track) to a broad-gauge rail can be a project, for Railway engineers. Eg:2 Creating a software product can be a project, for an IT team. Eg:3 Constructing a shopping mall could be a project, for a builder Project in Business Improvement of Six Sigma context: A project will have a goal with a definite start and end dates. That will be accompanied by a strong business case explaining an explicit reason as why this project is needed in the first place and it will highlight the end dates for the various phases that a project might have. Process: In generic terms , we can say that it is a set of instructions/sequence of steps to achieve a particular activity/complete an event. Essentially , every process would have certain parameters which act upon as inputs and then there could be a set of actions or a sequence flow which would be necessary so that there is a tangible outcome which serves our need. That outcome becomes the output which will/can be consumed by other actors(could be another process /events/users/activities..) Eg:1 Setting up Continuous Integration(CI) is a key process as part of Continuous Delivery and Deployment(for delivering your IT delivery rapidly). CI includes multiple steps : 1. Check-out the latest code from the Code Repository (say GIT) and put that into local workspace(Developer's workstation). 2. Do your code changes on the local machine and unit test it thoroughly 3. Post a peer review (and after fixing comments, if any - unit test it again) 4. If everything ok, get the latest code from Code Repository, 5. If no difference found in the version of the code, then push the code to the code repository with proper comments 5. Automatically Build should be triggered (When a change is pushed). 6. If build succeeds, then ensure that your change is successfully working in the Integration box. Now as we see multiple steps are there. The sequence is important to get a successful testing of your functionality which is the outcome from this process. Eg:2 Code Review is a process - Steps involved: 1. Review the code. 2. Check if the code adheres to coding standards and guidelines. 3. Whererever the stds/guideline not followed, provide proper feedback comments. 4. Ensure the developer fixes the comments.5.Ensure functional misses are not there. 6.Ensure same mistakes are not repeated. 7. Ensure all comments are fixed. Now let us first compare and contrast a project in Project Management(PM) realm and a project in Business Improvement(BI)/Six Sigma world. We have compared and contrasted project in PM realm and in BI/Six Sigma realm. Let us now contrast a project and a Process in BI/Six Sigma context. Let me explain these difference with an example. Imagine an improvement project. An IT team's delivery quality is poor. They are getting multiple escalations and they are unable to meet their SLA of <5% defects in a critical application. This is happening for the past 6 months. Now team is doing an improvement project. It is trying to zero in the problem. It needs to fix the issue in 4 months time. Goal is to have <5% defects by 17th June 2019. Now it starts to check its flow from where it has to correct itself. It reviews the AS-IS process. It finds (after doing Value Add activity process) that it needs to improve upon Design Patterns(for Coding), Code Review, Automatate Unit and Functional Testing. These are processes which have their own steps which need to be done so that quality of the deliverable meets the defined SLA as per the goal statement. Now without the processes, the project goal cannot be achieved. At the same time, the processes can be independently achieved but if not tagged to a project, the chance of systematically finding the deficiencies in a process or a need for a new process(if old process is too bad to be modified) would be missed out. Conclusion: From the differences that we saw now, it is clear that process and project in a business improvement/six sigma world or different entities. Having said that there is always a bit of these two words conveniently interchanged especially in Business Process Outsourcing(BPO) industries. Many teams use process to represent what could be possibly called as a project. For instance, those teams might call HR Payroll system as a process, whereas an IT team might call that as a project. One reason it could be because of the fact that BPO bretherens could construe each of the steps in the system happening in a sequential flow. But in general, by and large as the definition says and based on the differences that i articulated above, my conclusion is process and project are two different entities.
  15. Imagine you are going in a cab. One of the back wheel trye gets punctured. It is already getting late for you as you are having a business appointment with some one, shortly. The cab driver understands the situation. Rather than taking up the jockey and changing the wheel which may take some time (every minute is precious for you to be time-bound) , the driver goes to the nearby fuel station and fills air , which is good enough to travel to the destination, thereby taking you to the destination on time. Now what he has done is provide a temporary relief to his problem. This is what Stop gap is . Stop Gap provides a temporary measures/relief to handle a situation which is providing a concern to someone or something. It will act as an interim solution to a problem, when we are trying to find a permanent solution. Why/When we need Stop Gap ? Sometimes we may not know/get the apt solution for a problem. But we may have a temporary solution to it , the solution being applicable to certain conditions or upto certain period. Or there could be cases where solution to a problem might be known but it could be costly at a given time, for which the cost approval would not have been given by the mgmt (or by Key stakeholders).So, a temporary measure/solution could be used for some time till mgmt agrees to the original solution. Quick Win: A quick win helps in having a short term gain. It helps in motivating the team when the team is pursuing for a much bigger and a longer goal/objective. Quick wins also provide confidence to the relevant stakeholders. Eg: Imagine you have a six sigma project in one portfolio. Assume that the problem is fixed during analyse phase but your senior mgmt does not want to wait to see how this is behaving for atleast few months. So it decides to make use of the outcome found in this project, in a project of another portfolio (which has a similar issue), just to get the confidence from the customer and say that this issue has been resolved. Conclusion: Stop Gap provides an interim relief to a problem. But there has to be a permanent solution. Quick Win is about having a short term gain which can motivate the team which does the work and can provide the confidence to relevant stakeholders. A quick win can be an intermittent step to the ultimate objective needed. It can act as a pointer to what is going to be achieved in the longer run.
×
×
  • Create New...