Jump to content

R Rajesh

Excellence Ambassador
  • Posts

    124
  • Joined

  • Last visited

  • Days Won

    14

R Rajesh last won the day on June 8

R Rajesh had the most liked content!

4 Followers

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.

R Rajesh's Achievements

Enthusiast

Enthusiast (6/14)

  • Week One Done
  • One Month Later
  • One Year In
  • First Post
  • Collaborator Rare

Recent Badges

42

Reputation

29

Community Answers

  1. A PEST analysis brings together four environmental scanning perspectives which serve as useful input into an organization’s strategic planning process: Political: This looks at the political stability, war threats, tax related issues, regulatory issues,labour problems etc.,. Economic: This perspective looks at exchange rates, market conditions, inflation factors… Social: This focuses on health indices(factors), demographics, cultural aspects etc.,. Technological: This provides a view at newer technology developments, rate of technological change, technology cost impact etc.,. Eg1 : An Insurance company in USA makes a PEST analysis for implementing its changes in its product. Eg2: Let us see a hypothetical example. In lieu of the upcoming Olympics, a country’s Olympic committee wants to build an Olympic village which will have accommodations for athletes and several new stadiums for playing various sports / games. Let us see with a PEST analysis as how the committee would strategically plan. Conclusion: PEST analysis can be useful for an organisation, in any industry. It helps in providing a holistic approach to the strategy being devised by the organisation. Source: The CERTIFIED Six Sigma Black Belt Handbook (second edition) by T.M.Kubiak and Donald W.Benbow
  2. What is Change Acceleration Process (CAP)? A change management framework with a set of tools to assess the political/strategic/cultural environment in an organisation and plan for action which can eventually decide how much success a change initiative can bring in within the existing operating boundaries. Backdrop (CAP Origin): Jack Welch understood the fact that his company GE was entering an era of constant change and realized the fact that those who adapt to the changes only will be able to survive. Therefore he wanted his team to acquire best practices on change management and come back with a tool kit that can be easy to implement in the organisation. The end result of the exercise was Change Acceleration Process (CAP) Change Effectiveness Equation Jack's team had studied innumerable projects and business initiatives and got quite a handful findings. One such finding was that having a high-quality technical strategy alone is not suffice for getting success. Lack of attention to things like cultural factors can deeply affect a project outcome. The team found this in a hard way. Many a project faced this. This was the time, when the team decided to bring in a formula(read equation) deemed as Change Effectiveness Equation. The equation is determined as follows Quality of the technical strategy * Acceptance of that strategy = Effectiveness of an initiative i.e. Q * A = E, where 'Q' represents Quality, 'A' represents Acceptance and 'E' represents Effectiveness This tells the fact that however superior be the quality of a technical strategy (solution), still it has to be accepted by the people who use or work on it. Else it(strategy/solution) is deemed as a failure which means that the benefit planned for that initiative through that technical strategy cannot be achieved. Let us now see how we can make the mindset change to ensure the 'Acceptance' factor (in the above equation) is obtained, with the help of the CAP model The CAP model This is a 7-step process 1. Leading Change 2. Creating a Shared Need 3. Shaping a vision 4. Mobilizing Commitment 5. Making change last 6. Monitoring process 7. Changing Systems and Structures Let us deeply dwelve on these steps involved in this model. 1. Leading Change - As the name says the leadership team in an organisation should be committed to any initiative being taken. Only with the explicit support and commitment from the leadership team(or management team if you want to call as per your organisation culture :-)) then an initiative can move flow through the hierarchy in the organisation. Otherwise it would be a failure 2. Creating a Shared Need People whom we (as a leader of the initiative) want them to be involved as part of the initiative and whom we think would be using the initiative should be agreeing to the need for this initiative. There has to be a justification as why we are going for a change. The reason for change has to be propagated across these stakeholders at a convenient pace. 3. Shaping a Vision There has to be a clear-cut agenda (vision) and that needs to be shared across and be properly understood by everyone.The resultant state should be observable and measurable in terms of individual behaviour. 4. Mobilizing Commitment After doing the aforementioned steps which includes the commitment from leadership team, your reason for putting this initiative with a proper vision, we try to leverage with an influential strategy to build momentum by roping in with some supporters(those who want to adopt our initiatives/thoughts) to pilot our initiative and then learn from the lessons that the pilot implementation teaches. Because we are dealing the initiatives with the 'supporters' or early adopters, the shortcomings from that pilot work is noted down with a tinge of acceptance (which can be later useful for improving the initiative or the implementation of that-wherever it is failing) 5. Making change last While steps 2,3 and 4 are for making us to adopt to new changes and accelerate towards that, starting from this step till the end step , its all about making the change persistent. Here we tend to take advantage of the gains that we got from our piloted implementations and take the learning and best practices into our wider rollout of our initiative. We get to know what is helping and impeding the initiative and how that can be overcome and also look out for how to integrate our initiative with other existing ones, wherever required 6. Monitoring Process How do we know the initiative that is being brought in newly is working or effective ? Well, there has to be a measurable mechanism for that. Set it up (Own it). Measure and celebrate when it becomes a success. In case it is not measuring upto the expectations, then we need to have the accountability for the lack of progress. 7.Changing Systems and Structures An initiative will make some kind of impact in a business process. When there is a change being made in the business because of this initiative it impacts also the supporting systems and structures, in which the business operates. Therefore, in order to make the initiative a successful one, we need to understand how the systems and the structures get influenced by the initiative. Otherwise, our initiative can become a failure. Let us see some examples of how implementing initiatives through CAP model resulted in unprecedented success 1. Streamlining of 'Continuous Integration' process in Software Development In one of the projects that i was aware of, there was a constant challenge. The developers were not regularly updating the changes that they made on the local workstation(machine). As a result of that, the developed codes grew in size and whenever the developers tried to push their code into the Source Code (version control system for maintaining the various versions of the developed code), there were so many code conflicts and this created software build failures.Moreover, the Continuous integration Server used on the project, Jenkins, provided several reports and it threw lot of coding standards errors Primarily and few critical performance(Memory) errors and all the errors varying from 'low' to 'high' category. The leadership team of the project was worried pretty much and did not have too much control on how to arrest this deteriorating situation at the earliest. Every day the issue was galloping as team kept on developing the code amidst the problems and the woes kept on increasing. Because this was running in managed services mode, the extent of the damage was not fully realized by the customers yet and as such there were no impact to the expected behaviour of the features, but it was a probable question of time that such a thing would happen . I Suggested this CAP approach to the person in charge of the project and it was done as follows and the rest was history :-) ... a. Leading Change: The Group Leader (GL) of the team unanimously agreed to this approach and was wholly committed to this. With the help of a Plasma Screen TV(big size-visible to the whole floor), he made sure that the Jenkins tool's code analysis report is displayed on it, thereby showing the coding standard errors & performance errors for all the files that are developed on a daily basis. This was a big shot in the arm for the initiative owner b. Creating a Shared Need: As the initiative owner (who is a process-savvy person) explained the nitty-gritty of this initiative to the GL, by explaining the proposed steps and how to achieve each one, the GL included the other stakeholders who will help the developers in shaping up this technical journey and all stakeholders such as Technical Architects, senior/key developers,Product Owners and Scrum Masters. The Senior/key developers took this to their respective teams. For implementing the initiative a team was formed with one Technical Architect, 2 developers and a Scrum Master... All of them volunteered themselves to do this activity, apart from their regular work. c. Shaping a vision: It had a straight-forward agenda 1. Improve the Continuous Integration process and ensure developers check in their codes into the version control system (GIT) on a daily basis 2. Minimize the coding standards(Primary) and few critical performance(memory) errors through proper usage of Static Code Analysis tool (which existed in the project but was not utilized effectively). For these 2 things to happen, it depended completely on the mindset of the developers. #1 required changing of the habits of the developers' day-to-day habits (as they have to do check-out or Pulling out of the latest code from GIT and then applying their changes on top of that pulled code and at the end of the day or at a logical point, they need to push or check-in their code into the GIT). #2 required that each developer integrate the static code analysis tool (which will help in proactively identifying coding standard errors and hence will prevent those errors from occurring while the code is compiled) on his/her own. So both these things required a mindset change in developers. These two things were measurable in terms of the number of code conflicts that each developer gets while trying to push or pull the code , in case of #1 and the number of coding standard errors/performance errors that is being thrown when the Jenkins report for code analysis runs for a developer's code (published through the giant plasma screen) in the case of #2. Note, in the case of #1, the more conflicts that a developer gets, the more likely is his/her delay in doing check-out / check-in and adhering to the continuous integration process. d. Mobilizing Commitment: The implementation team had tried to implement these things first in its own sphere of work and implemented it with a fair degree of success. It also identified that displaying the count of coding standards error/performance error for each of the files, along with the name of the developer who had worked on it , was not a great thing to do. Reason was that the report was producing the name based on whoever had worked last in a file. But that developer need not have produced the defect (because the file was there before this process got started and it was throwing all open errors.) So in some instances, the name displayed was not the actual developer who created the defect. This was a lesson learnt for the team. Nevertheless the team became optimistic of taking this initiative to the next level e. Making change last: The implementation team started to showcase the achievements made in the last one month since the initiative was started. It showcased to the senior/key developers first (with a separate session) on how the coding standards errors / performance errors got reduced because of the initiative. Then this was taken to the whole team and then explained in detail as how this can be done effectively. The performance expectation of this initiative was also explained succinctly. By having a proper Continuous Integration process, the team had reduced its build failures and because the software build was integrated with other automation tools like Selenium, all of those tools got regularly triggered. The test case results were also displayed on the big plasma screen f. Monitoring process: As every team in the project started to implement this and each developer started to inculcate this change in his/her DNA, the result was there to be seen in the dashboard created by the team and was very much visible in the giant plasma screen.The coding standards error was very much less and no performance errors and code conflicts were happening very rarely only. g. Changing Systems and Structures: The new codes being developed were not having any errors. But the old codes developed earlier (prior to this initiative start) had lots of errors and had there were too many file dependencies with other systems. So those files had a considerable chunk of code which had to be compliant with standards. Those files in this system and other systems had to be changed as well. The outcome was spectacular. All were changed in 3 months time and the quality of the system was really good in every aspect. The developers were happy to be part of this initiative. The icing on the cake was the CI process that the team had put in place (the team did create a pictorial view of what they had done) became the talk of the town in the entire vertical within the organisation. 2. Let me show another example of how CAP process was done in another project. Agile Transformation for a customer relationship: The projects were running in waterfall model and that had to be transformed to Agile model (Scrum framework). An agile Coach's service was sought to do this transformation. The GL, leading the change, was committed to this cause. The agile coached formed a program transformation vision and developed Key progress indicators (KPIS) which were measurable and also laid out short term and long term agendas as part of this transformation. This was communicated to all relevant stakeholders. The idea was to have transform one line of business (LOB) into the Agile way of working , taking one at a time and then replicate for the rest of the LOBs. Few teams were formed after enlightening them, on the Agile transformation journey. All skepticism and fears were promptly addressed and the teams started to feel the positive impact as development life cycles became short and the interaction within the team and the stakeholders were quick and spontaneous, which was a new thing for many as their earlier model did not have this luxury. This increased the confidence of the teams to reach out to customers and business stakeholders for any business query. As the development cycles were shorter in period, the number of releases to production increased and slowly that line of business started to run using the agile way. This success was achieved relatively quickly and now the management was confident of replicating this in other LOBs. This was replicated in other LOBs as well and in 6 months time, the transformation had been done completely. Because the team had moved to Agile way of working, the team had to change some of the supporting tools that it was using earlier. The requirements were earlier being tracked through word documents and stored in version control systems. But with the introduction of Agile. the team relinquished that and started to use JIRA tool. Suddenly all the huge documentation work that was lying in the existing model was gone and the team now had to do documentation only at a minimal level and the team started to use slack channels for communicating amongst its team members working across the globe rather than doing email communication. Overall this initiative changed the way how the teams thought about software development approach and this transformation was a massive success Benefits of CAP: 1. It shows a systematic approach to make a cultural change in an organisation 2. Because an initiative done through this approach mandates the explicit approval/ commitment of leadership/management team , it gives confidence to the employees that their effort on such an initiative will get the due recognition from the leadership/management and that can help in their career growth 3. A personal feel good factor can occur across the employees when the expected benefit is achieved and when their work gets recognised Conclusion: In real life, every problem that we need to address , we need to take the human factor into account. Every change (read initiative) that we do or plan to do should pass through that 'human' aspect successfully . Else it would be deemed as a failure. CAP model provides a systematic way of doing that. How strong is the leadership/management commitment to the initiative and how clear is our vision and shared need shapes the success of the initiative, to a greater extent. Better they are, better will be the outcome(success). For the sake of understanding more about change management frameworks, similar to CAP, there are other change management frameworks such as John Kotter's 8-step change model which is also akin to this in terms of the implementation steps and that is also pretty useful. References : https://www.isixsigma.com/dictionary/change-acceleration-process-cap/, https://bvonderlinn.wordpress.com/2009/01/25/overview-of-ges-change-acceleration-process-cap/
  3. A 9 Windows tool or technique is defined as a method for exploring issues and their potential impacts by examining the past, present, and future of a System and its Sub and Super systems. It is portrayed in the form of a 3*3 matrix and act as an idea creation tool. How does it work: As we saw in the definition, this explores the issues in the system and its associated Super or sub systems. So what each one means: a. System - The problem or the system in consideration b. Super System - The entity to which the system might be logically or physically connected to or can be correlated to c. Sub System - The constituents(components) of the system or things that could be part of (or associated with) the problem Purpose of the tool: This is akin to what we do in real life. Often we would be doing a self-retrospection after someone gave , say, a very good seminar on a particular topic. We might think "how i wish had done that well last week.This week it was ok and am confident of doing good in the future"... Same way what if something could have been done differently for an issue to get it addressed in the past and in the present and how to address that in the future.. This is what this tool will help you in achieving that Examples: Let us some examples attached here Example1: Nine Windows Matrix: Problem: Over the years, increased Cricket Bat dimensions (size) has given an undue advantage to batsmen Space/Time Past Present Future Super System Group(s) that decided the Cricket rules -Marylebone Cricket Club (MCC) Group(s) that influences the Cricket rules- Marylebone Cricket Club (MCC) and the group that implements it - International Cricket Council(ICC) Group(s) that influences the Cricket rules - Marylebone Cricket Club (MCC) and International Cricket Council (ICC) – ICC Chief Executives committee , ICC Cricket Committee and Associates (Nations) representative committee System Cricket Bat’s impact in pre-80’s era . Batsmen by and large played with wood bats except for few Cricket Bat’s impact in Current Era since 1980s. Lot of batsmen used heavy bats than the stipulated guidelines Batsmen have to follow stringent guidelines as laid out by the Cricket rules Sub System Equipment –Wood usually (Willow wood, Kashmiri wood,…) but there was no specific restrictions (on the type of equipment to be used) till 1979 Bat Length - <=38 inches Bat Width <=4.25 inches Equipment – Willow wood usually and it should be made only in wood Bat Length - Can be bit higher than the usually designated length Bat Width - Can be bit higher than the usually designated length Bat Thickness - Can be bit higher than the usual thickness Equipment – Should be made only in wood Bat Length - <=38 inches Bat Width <=4.25 inches Bat Thickness <= 2.68 inches Bat Edge <= 1.6 inch Example2: Nine Windows Matrix: Problem: For office goers in big cities, precious time is lost due to Traffic snarls, on a daily basis Nine Windows Matrix: Space/Time Past Present Future Super System Limited Transportation Congested Transportation Robust Transportation System Less Vehicle population resulted in less traffic snarls Every day going to office takes time through own or company provided transport, due to heavy Traffic Seamless drive to office with minimal or no hassles. Sub System Less Vehicles Public Transport No special economic zones More Private Vehicles Rapid Urbanisation without adequate supporting infrastructure Clustered Special economic zones Encourage more public transport with good connectivity across places Provide good and sound infrastructure. Have Special Economic Zones in different parts of the city to de-congest traffic’ Encourage hi-fi innovative designs like Flying Car (make the infrastructure available for that) Benefits: 1. Transparency of the problem As we dissect the problem/issue across the systems and at various times using this exercise, we get a distinct representation of how a problem looks/looked like at any given point and what makes/made it to happen. 2. Inspection of the problem (RCA) As we get to know the issue on hand at the past, present and future, we try to see as why it happened, happens and think of how that (issue) can be prevented in the future. By getting to know the RCA or why the issue happened in the past or still happening in the present, we try to explore as what should be done to prevent it in the future. This exercise provides a systematic approach to resolve an issue which can be quite complex in nature and which is adaptive in nature(that which can vary over time) 3.Addressing (Attacking) the problem At each phase of time, we are putting the facts as what we had done, what we are doing and what will / should be we doing.. Based on the kind of solution that we are having at each phase of time(past, present,future), the solution for the subsequent phase gets shaped. The details of each phase might serve as a good input to the subsequent phase and can help (often it can act as a launching pad though not always necessarily) the solution providers to attack the problem with more vigour in the subsequent time phase 4. Continuous Improvement The result of #3 often means that you are improving your systems (with the implementation of those solutions) which is continuous. Thus, doing this exercise will more often than not, be, resulting in a continuous improvement of sorts. Conclusion: This is a wonderful tool/technique for idea generation and is often used in TRIZ, which itself is a powerful technique for problem solving. The technique uses a 3*3 matrix with the kind of systems involved in one axis and the time factor (past, present and future) in another axis and the objective is to see how an issue was/is/will be addressed. How these systems behave over a period of time is portrayed in this exercise, giving a good representation of that evolution References: https://asq.org/quality-resources/nine-windows . Nine Windows Matrix.doc
  4. 4-Eyes Principle : A generic definition says that it can be a rule/requirement/activity by which decisions/business transactions need approval from two individuals. Advantage of 4-Eyes Principle: 1. It gives the confidence that more than one person (atleast two persons) have gone through the activity(can be artifacts/processes or anything) 2. It gives all the stakeholders the comfort on the fact that it was addressed properly since different persons have vetted something 3. It improves the quality of the activity, which is being scrutinized/examined Let us see examples across various sectors Software: In Agile world, there is a technique called 'Pair Programming' which is , i would say a version of 4 eyes. Here, while one developer writes the code, the other does an inline review of the code (and provide valuable inputs) and both will take turns to do these two activities (Coding and reviewing). It has been proven that it improves quality by 150%. Sports: While doing the talent scouting (when looking for the right players to play for their team), often a sports team will take its coach/few key personnel might look for the right players and once they finalize, then the team mgmt (selection board) will take a second look and confirm (even if this happens to be a customary one) Appraisal System: In Many IT companies, this is a prevalent process. The performance of a person(appraisee) is appraised by two persons, the appraiser(immediate supervisor of the appraisee) and the reviewer(appraiser's supervisor). This is to ensure that the performance of the appraisee is rightly evaluated and ensure that no human bias/inadvertent mistake is introduced in the process. Other Examples: 1. How many times, we would have seen in banking or financial sectors with two persons holding key positions, who would verify the transactional details or artifacts and then provide their signatures!! 2. Take DevOps / Business Process Management(BPM) tools - You can see human intervention with machines just to ensure that if machine is treated as one pair of eyes, then human intervention as another. This happens especially in BPM tools thereby stressing on this 4-eye principle. Is this principle, a Value Add or Non Value Add : It depends on the context in which this is being used. As stated in above examples, there are many instances where this principle is a real value add. But there can be some cases where it can be a non-value add or value enablers. Let us see such scenarios. Imagine in an IT company, a product is being developed.The customer is unhappy with the quality of the code being written and that is impacting the performance of the product . The IT service providing company is trying to improve its code review process (which it sees as the root cause for the poor code quality). Earlier it had only a self-review by the developer. Now it is introducing 2 pair of reviews(or 4-eye) which means a self-review and followed by a peer-to-peer or a SME(Subject Matter Expert) review, which will be done by someone within the team. This way the IT company feels, can strengthen the code review process and thereby the product's code quality!! But with respect to the customer, this process improvement does not mean anything as it is internal to the IT company. All the customer needs is a qualitative product. Therefore from that point of view, this is a non value added activity for the customer, whereas this activity(4-eye principle for code review) becomes a value-enabling one for the IT company. So it is the context that decides which activity can be value add, non-value add and value enabler and from whose perspective (Whether the service provider or from customer point of view) also matters. Let us see the same case , with a twist.These are the early days for the project team. The team does not know how to fix this quality issue. The management ropes in a developer(from another team) for 2 weeks, who knows few static code analyser tools which can automatically check the coding standards and suggest best practices and the developer also has knowledge on some design patterns. He parts this knowledge to the team before he leaves. Now every developer does a self-review before he/she builds the code. As soon as the code is built, the static analysis tools get triggered and the developed code undergoes a code review (4-eye principle now enabled). The results are now produced. If there are errors, then the build process is stopped, else it proceeds and build is successfully done. Now the customer is willing to pay for this process because it automates the code review process and quality is built into the system. Where 4-eyes principle may not be more useful? Its practically difficult to use this principle in every situation/scenario. This is what i feel!! To point out a few, 1.It may not be as useful as it may be, where time is a constraint (Eg: When you want to do a hot fix for a production environment issue) 2.When the cost of doing this exercise is more than the expected benefit 3.If the outcome is not sensitive to anyone, why bother verifying with 2 persons Conclusion: 4-eyes principle is an excellent principle which will act as a deterrence for making mistakes, especially human errors.It can be used anywhere where the right outcome (precision, accuracy) is required to the maximum hilt. There can be cases where the use of 4-eyes principle can be a costly affair.But the benefits outweigh the costs in most of the cases. Though it may seem that with the advent of technology, the 4-eyes principle might have lost its sheen, a bit, its not the case. Still human presence is required to oversee the process improvements as we have not completely moved to AI technologies.Earlier , it used be 2 human beings as 2 pair of eyes(4-eyes), now it is a machine and human being (though technically it may not be called as 4-eye) and in the future it could be machine and machine !!
  5. CEDAC denotes Cause and Effect with the Addition of CARDS Dr. Ryuji Fukuda. It is a problem solving tool . It helps in brainstorming the problem by encouraging participants to put forth their ideas and come up with solutions The ideas are written generally through cards or some sort of sticky notes. How does it work: 1. Ideas/Facts given by participants are placed on the left hand side of each of the categories and probable solutions are kept on the right side of each of the categories. 2. A colour code is provided to differentiate solutions and ideas. Let us take a practical example as how this can be made useful. Example1: Imagine a hypothetical scenario. An international cricket match is being played. The batting team management is trying to reason out the situation.The opponent team is asking the Umpire to declare the batsman out. In the above example, amber box highlights the facts and green coloured boxes provide the potential solutions Benefits of CEDAC tool: 1. With a systematic analysis of the problem we will be able to get valuable ideas from which potential solutions can be obtained quickly 2. As this tool supports an inclusive approach (of all participants), more ideas will be generated and there is no bias/favoritism shown, while providing/giving ideas 3. Provides Varying solutions often with Quality (as this is done by people who are actually working on the problem) 4. Can be cost effective and provide rapid potential solutions as problems are displayed on the board and against which solutions are being discussed Conclusion: By using CEDAC, there will be a structured approach in solving a problem. By using this tool, its easy to compare the problems at hand and come up with good and viable solutions at a rapid pace as ideas galore with no restrictions. Reference Site: For definition - https://www.leansixsigmadefinition.com/glossary/cedac/
  6. Morphological Matrix is a good tool for generating a list of ideas and using them as a means to tackle your problem. Often there can be many ideas that can provide various solutions to a problem but we might be lacking the knowledge as how to provide. This is where this tool helps in. What is to be done ? The first step is to define an attribute/characteristic which is vital to influence the problem at hand Second step is to define the values/components for each of the attribute/characteristic The third step is to randomize the values picked in each of the attribute/characteristic and combine them. This will help in generating a combination of values (ideas) from which we can pick the ideal one(s) that suits as better/best solution to our problems. How to do? All attributes/characteristics are to be kept as the column headers in the matrix Place the corresponding values of each attribute under(beneath) the respective attribute’s column. Values displayed in one column does not need to have necessarily any correlation with values displayed in other columns You can randomize the values in the columns, by any means. You can use a software or by say, rolling a dice, or using same combination of custom defined means… The values that you give in each column can be generic or specific depending upon how you want to classify your ideas or provide your inputs. Benefits of using the tool: As you start jotting values/component under each attribute /characteristic , you tend to generate more ideas and by randomization of the values in each column, you get lot of combinations to tackle your problems. It helps in channelizing (organizing) your thoughts to tackle your problem It helps in expediting(picking) the right solution(s) to address your problem, from a bunch of ideas Let us see some examples to understand this tool. Example1 – This is purposefully given for easier understanding of the Matrix To explain this concept, let us consider a hypothetical (J) problem: How to get better response/feedback to your article or make your article getting selected as the best answer (to the weekly question posed) that are posted in this site Article Presentation Content Supporting Artefacts/Relevant Examples 1 Business Excellence Forum Question Neat Slightly out of context Quotations from various eminent SMEs/scholars 2 Blog Moderate Highly Relevant No examples or any explanation given 3 Discussion on Topics Inadequate Relevant Provide multiple generic examples that may not portray a direct depiction of the problem 4 Interviews Improper Totally Irrelevant Provide 1 or 2 examples specific to the context Out of these various combinations, one could be, that a question can be answered with a neat presentation with relevance to the context with 1 or 2 examples to that context. Example2: A big IT team in one of the organisations was doing its agile work. It was going good until recently when it had its problems galore. It had a huge backlog of defects, incidents, end user queries/request and some proof of concept (Research kind of) works that need to be addressed quickly by the team. This backlog was an accumulation of all these issues over a period of time (the team could not able to finish the backlog items on time for whatever reasons). Now the team had to fix these issues. It sought the help of other teams as these work was in a managed services mode and the team wanted to leverage the help of other teams internally on this work. The team lead came up with Morphological matrix. She listed out 3 columns (as who can be the persons who are needed) and then listed down the potential helpers under each column. Once that was done, the random options were generated and when the entire random list was obtained, she got a very good idea as who can help on what category of work. Category of Work Developers Technical SMEs Business SMEs 1 Defects Junior Java Developer Solution Architect Experienced developer with very good domain knowledge 2 Proof of Concept (POC) work Senior Java Developer JEE Architect Business Analyst Probationer 3 Incidents Passionate (learning minded) - Junior Developer Enterprise Architect Experienced Business Analyst 4 End User Support Senior Full Stack developer Database Architect Product Manager For example, from the above table, the combination of Passionate Junior developer , JEE Architect and Experienced Business analyst was really helpful for many of the ‘Proof of Concept’ work which essentially was a research-oriented one and with the able guidance of the architect and experienced business analyst, the junior developer was able to go to the full distance to achieve the objective. Passionate people are required for such explorative activities. Same way, the lead was able to take better decisions in arriving at the right ideas and implementing them to tackle her problems. Conclusion: Often we may have a problem, for which there may be some ideas to address them. Sometimes a team may try to find best possible combination using this tool. There could be a scenario where more ideas could be generated and best possible combination(s) might be picked using this tool as per the laid out procedural steps. So what kind of situations, this tool can be used ? This tool can also be more useful when you want to have more ideas generated in a short span of time (which gives you a cushion with many ideas and addresses your problem permanently in the longer run), or say, in a new product or service as you want to have indigenous way of ideas, because of which you can get a foothold in a new market or establish you as a market leader in your industry. Thus here, we have seen how useful this tool has been when there was a problem and we had different ways to address it but how to address that was is a challenge. Then we derived combination of values using which we arrived at solution(s).
  7. Minimum Viable Product(MVP) - This talks about the essential features/functionalities that can be built into a product or an application. What to be built into aproduct/application depends on customer needs/demands in an existing market. In a new market, customer needs/innovations can decide the minimum viable product. Why MVP is important? You do not create a product/application in a monolithic way but rather produce the product on an incremental way. This ensures that you are building the right productat early stages of the product/application life cycle. The objective is that in case your assumptions about the needs of the customer varies or if the product is not meeting/satisfying customer expectations then this MVP approach gives a chance to quickly resurrect the product development into the right path. It gives early feedback to the business stakeholders, product developers. Products/applications built using agile and/or lean methods naturally tend to use MVP approach because of this. What are the benefits(things that can be accomplished) using MVP approach? 1. Reduced time to market(as minimal features/functionalities only are built into a product) 2. Rapid response to customer needs/demands. 3. Getting early feedback from the market which helps in shaping a better and accepted product/application(system) How to achieve minimum viable product(MVP)? As MVP is all about bringing onto the features/functionality of your product/application, how to decide the minimum viable aspect of a product/application will be the first one. There are several ways. An ideal way is to understand the customer needs by having a survey, focused interview, Questionnaire. Post such a discussion, prioritisation of features/functionalities can be done through techniques like Kano Model , MoSCoW(a popular Agile prioritization technique akin to Kano model,in principle). Conclusion: MVP saves a lot of time because you try to build the right product/application(system) at the first (or every instance when it is an incremental build) and get a rapid feedback thereby ensuring right product/application is produced in quick time.By doing an incremental build, you minimise the inherent defects in your product/application. In order to have rapid deployment of a product/application, building it through a MVP approach results in an incremental build at a shorter cycle - say Sprint or Iteration (in agile terminology). This gives focused attention on the product/application, qualitative product/application and the right product/application to the customer
  8. Poker Planning is a consensus based popular agile estimating technique.It is used for estimating agile development work. This is highly used while sizing(estimating) the Product Backlog items(PBI-say requirements often conceived as user stories) How does it work: A set of planning poker cards are used for estimation. Each card has a value printed on the card. The values(numbers) displayed on the cards usually is made up of Fibonnaci series...0,1,2,3,5,8,13,20,40,100 (up until the value of '13') and beyond that it will be specifically have a value of '20', '40' and '100'. The values indicate the size of the story. Size of the story will be determined by Effort, complexity,Uncertainity. So beyond the value of '13', most organisations do not try to size a story. Beyond '13', it is too big to complete a PBI within an iteration/sprint. Therefore, rather than using a fibonnaci series as a value, the values -'20','40','100' are used. Poker Planning can be used for PBIs sizing (Where it may involve the entire scrum team) and also for sizing PBIs in sizing PBIs in a given sprint/iteration (where PBIs are refined and where Dev Team would be predominantly involved in estimation unless there are some outstanding queries which require Product Owner' help) Let us take an example of how this poker planning works in a Sprint/Iteration planning. During Sprint/Iteration planning, after first part of the planning is done(when the scrum/agile team picks the right amount of work), in the second part of planning, the team does the estimation on each PBI. Everyone in the development team does the estimation using Poker Planning. The Dev team discusses the PBI and once done, estimation process starts and 1 minute is normally used (or when all concur to show their cards). Every developer will choose one of the cards based on his/her understanding of the complexity of the PBI. The developer retains his/her privacy of the card(as what he chose). Once the time is up, all flip their cards and show their chosen values. If all of the developers choose same value, then that value becomes estimate for the chosen PBI. If there are discrepancy in values, it is being discussed and if required, another round of poker planning is done. In a team of 5, if 3 developers agree for a common value (say '8') and 2 developers have a low (say '3')and high value (say '13') respectively then there will be a discussion on the basis for such extremmes so that proper consensus reached. For all PBIs , this exercise is repeated until there is no item left Advantage of Poker Planning: 1. It takes a consensus from the entire team (Dev/Scrum team) 2. It is a better scientific approach and involves data on complexity, effort and uncertainty 3. Estimation techniques like analogous estimation , expert judgement require past projects experience or expertise. This is about the using of collective wisdom 4. Because it is input obtained from various cross-skiled persons, it eliminates bias and there is more accuracy Conclusion: Poker Planning serves as a great estimation technique. Because of the advantage that it has, it is used widely in the software industry
  9. Wiki Definition: A Pick chart is a Lean Six Sigma tool, developed by Lockheed Martin, for organizing process improvement ideas and categorizing them Pick chart is a 2*2 matrix in which the vertical axis talks about the complexity/difficulty and horizontal axis talks about cost benefits. Easy Payoff Low Payoff Hard Possible Implement Hard Kill Challenge What does each of the Quadrant means? Possible – Low payoff, easy to do Implement – High pay off, easy to do Kill – Low payoff, hard to do Challenge – High payoff, hard to do How is it useful: Pick chart is pretty useful when there are many process improvement or problem solving ideas and we want to categorize them as per the 4 aforementioned quadrants. This will give an insight to the mgmt of an organisation where each idea is vis-à-vis its ROI and how much impact it can have on the organisation’s customer(s). Let us see what each of these quadrants means to an idea Possible: An Idea placed in this quadrant means that it (idea) will take less time to complete, either due to less complexity or less difficulty level, and implementation of the idea would result in a lesser ROI. Implement: An Idea placed in this quadrant, means that it (idea) will take less time to complete, either due to less complexity or less difficulty level, and implementation of the idea would result in a greater ROI. Kill: An Idea placed in this quadrant means that it (idea) will take more time to complete, either due to more complexity or more difficulty level, and implementation of the idea would result in a lesser ROI Challenge: An Idea placed in this quadrant means that it (idea) will take more time to complete, either due to more complexity or more difficulty level, and implementation of the idea would result in a greater ROI. Let us see examples for each of these quadrants. Examples: Let me provide examples from software industry. Possible: Imagine an excel sheet is used for PMO activities. Now a person with a VBA(a microsoft application language that can be used for MS products such as excel and actually good for writing macros) knowledge, writes a few lines of code and automates programatically some of the complex things in that excel in a short span of time. This speeds up the work for the PMO team and gives the customer a fool proof mechanism to look at the cost sheet and saves some time for all the stakeholders. Nothing more than that Implement: Imagine development team tinkers with an existing licensed automation testing or a custom automation framework to an open sourced automation framework which is relatively easier to do (than creating automation environment from scratch) and provides the customer a cost effective, end customer satisfying solution. Kill: Imagine development team does refactoring of an existing code which can help the support (maintenance) team to easily maintain the code in the future but does not provide any great tangible benefits/hard savings for the customer Challenge: Imagine a typical agile development team improves its unit testing, functional testing from being manual to automated testing. This will expedite the testing time of the application and can issues can be quickly found and addressed. This will result in more tangible benefits for the customer Conclusion: The examples given are just hypothetical to drive home the point as what each quadrant could have as ideas. (Same) Examples given above can go into different quadrants depending upon several parameters. Thus you can see how PICK charts help in categorizing the process improvement ideas.
  10. Let us see some definitions for Scrum and Kanban from the official site of Scrum guide and few other good sites for Kanban Scrum: It is a framework for developing, delivering, and sustaining complex products. Kanban: Kanban (whose meaning is signboard or billboard in Japanese) originally was used as a scheduling system for lean manufacturing and just-in-time manufacturing (JIT) used to improve manufacturing efficiency by limiting supplies and resources to what was needed for the immediate task. As Kanban usage is spread across industries, it has become ubiquitous. From an agile perspective, Kanban is a continuous workflow management method designed to help in visualizing the process and the actual work passing through that process ScrumBan : Wiki definition: Scrumban is an Agile management methodology describing hybrids of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban. Before we go into details of the why we need ScrumBan, let us see some fundamental characteristics of Scrum and Kanban and where they are stand with each other and how combining their characteristics (ScrumBan) could be beneficial Salient features of Scrum: 1. Scrum is based on Empiricism which relies on Transparency, Inspection and adaptation 2. Scrum uses inspect and adapt techniques to find if any deviation is there from the required levels of expectation. If there is a deviation, then the relevant team needs to adapt to doing the course correction 3. Scrum is a prescriptive framework. It tells what to do and does not tell the 'how' part and leaves the implementation to its users 4. Scrum is a process framework that has some well defined rules and time-boxed events and few roles. The Container event called 'Sprint' is also time-boxed. 5. Scrum is transparent and as a result it ensures work completion by having a definition for that (using 'Definition of Done'- a key aspect) Salient features of Kanban: 1. Visualization of the workflow 2. WIP Limit - which will limit the team to work only items which are in progress and thereby avoid overburdening 3. Workflow management - By having a smooth workflow and ensuring minimal average cycle 4. Continuous Process improvement - Review the effectiveness of the defined Processes and update them wherever required 5. Continuous Feedback and collaboration mechanism - Have a proper feedback system (like daily scrum call or scrum of scrum call) to provide the knowledge gained in the system and with respect to collaboration, share the views with everyone. Scrum Kanban Every Sprint will have a specific goal Here primary goal is to achieve continuous flow There are pre-defined clear cut roles (Development Team, Scrum Master and Product Owner) There are no such clear cut roles It runs on Empiricism It dwells on Visual workflow and WIP limit Velocity is a key metric Cycle Time is a key metric WIP Limit is not a mandatory It operates on WIP Limit Why do we need ScrumBan or what are the benefits of ScrumBan: Let us now see as how ScrumBan could benefit large Agile teams . Scrum being a prescriptive framework does not provide/tell any answers to some of the problems that a team which practices Scrum might face. Eg: In the case of an IT team, the team might have issue with a junior developer who lacks technical knowledge and he is not productive and this is hampering the team's overall delivery. Imagine the team is wondering how to resolve that . In such a case if the project is being run in Extremme programming(another Agile way of doing a project) then it would have team members of the project to do pair programming and do automation as part of its manifesto. But Scrum is lenient and does not emphasize anything like that. Remember the fact that as scrum does not tell about the 'how' part, we have the liberty to use anything without breaking the rules that govern the scrum framework. This is where a technique like Kanban can be used inside the Scrum framework to leverage its process improvement benefits. So let us see as how using the hybrid version, ScrumBan - the combination of Scrum and Kanban, we can get the benefits Benefits: 1. Using Scrum aspect will ensure that system is capable of addressing robust changes , where changes(requirements) are captured in with a proper priority plan 2. Using Scrum events which helps in inspecting and adapting the work, the progress of the work items can be measured and the status of each item can be identified as per that . That will identify the potential bottlenecks . This could point to the workflow movement in the Kanban board and can inform the probable risks / impediments to the customer management 3. Using Scrum Retrospective event in conjunction with Kanban effectively ensures that not only process for workflow improvement but also for process for tools, people, technology can be improved 4. Using Kanban's WIP limit can result in taking limited amount of work items (usually in the form of user stories for a typical IT Scrum project :-) ) and ensuring that you are on achieving to complete your items without overburdening yourselves and complete it on the time-boxed duration. WIP limit gives an opportunity to stay focussed as a team to complete the items that we pick (as a team) and then proceed to the subsequent items and then complete the iteration. It ensures that the planned goal/objective for that iteration(Sprint) is achieved. 5. For day-to day operations/maintenance activities, WIP limit in conjunction with Daily Scrum call can be quite effective[as daily scrum will be useful to see work progress and reassess the situation every 24 hours and WIP limit will set the work item limitation for working on that day] Conclusion: Agile as a way of project management has evolved a lot since its origin. The fact is that it has incorporated lot of lean principles into its scheme of things which is good news for all of its practitioners. ScrumBan is one such technique. This is not the only one though . SAFe is one framework which is being used at Enterprise level by large organisations. SAFe provides a clean structure having at Team level, Program level and Portfolio level and is highly lean oriented in its approach. So i personally feel that based on an organisation's size and its feasibility to operate in a given technique (in every sense) and its passion, knowledge and willingness to change itself to the technique, these techniques are being practised upon by those organisations. References: https://kanbanize.com/blog/kanban-vs-scrum-infographic/ https://en.wikipedia.org/wiki/Scrumban https://www.guru99.com/scrum-vs-kanban.html https://www.scrumguides.org/scrum-guide.html(For Scrum Definition)
  11. 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.
  12. 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.
  13. 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
  14. 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.
  15. 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
×
×
  • Create New...