Showing posts with label technique. Show all posts
Showing posts with label technique. Show all posts
Friday, July 20, 2012
CMMI vs ITIL
CMMI and ITIL are two distinctly different maturity models. The fundamental difference between CMMI vs ITIL is that while CMMI focuses on software process maturity, ITIL is broader in scope and focus on all areas of infrastructure, including software and hardware.
Origins
Carnegie Mellon University (CMU)’s Software Engineering Institute developed the first Capability Maturity Model (CMM) in 1990, and followed it up with the Capability Maturity Model Integration (CMMI) that integrated multiple CMMs.
The United Kingdom’s Office of Government Commerce (OGC) developed the IT Infrastructure Library (ITIL) in 1986 to provide guidance for service management. These set of guidelines has since then emerged as the international de facto standard framework of best practices for IT service management and infrastructure. ITIL originated as a collection of books, each covering a specific practice within the IT service management.
Scope
CMMI is a proprietary maturity model that consists of the best practices applied in the development of software, derived from the industry. CMMI segregates the best practice knowledge into five levels: initial, managed, defined, predictable, and optimizing, based on the expertise of the organization in applying such best practices. Each level progresses to higher standards and addresses the development and maintenance of products and services through the product life cycle from conception through delivery and maintenance.
ITIL is a set of comprehensive and coherent codes of best practices, and ITIL scope extend to controlling and managing all aspects of IT related operations.
Comparing CMMI vs ITIL, ITIL does not rank or grade the organization based on the extent or level of its compliance. ITIL instead offers three popular certification levels for practitioners: foundation, practitioner and service manager, based on the extent of competency of the individual in ITIL. ITIL is a non-proprietary tool that encourages the private sector to develop services and products such as training, consultancy, and tools to support ITIL.
Application
The basic difference between CMMI vs ITIL lies in application. While CMMI is focused toward software development, maintenance, and product integration, ITIL is broader in scope and provides a framework for IT service management and operations including a hardware life cycle.
CMMI is geared specifically to software development organizations and focuses on continuous improvement, whereas ITIL addresses IT operations issues such as security, change and configuration management, capacity planning, troubleshooting, and service desk functions.
While the application of CMMI helps the organization gain competency and expertise in software or product development, ITIL applications help align the entire IT process and resources of the organization to business processes.
Structure
CMMI is a prescriptive approach that orders process areas along a maturity model with maturity levels. A CMMI model is not a process but a description of effective process characteristics.
Unlike CMMI, ITIL is not prescriptive and orders the processes in sets. CMMI for instance, recommends requirement analysis but does not specify how to do a requirement analysis. ITIL on the other hand, provides solutions on how to undertake the requirement analysis.
Similarities
Both CMMI and ITIL are process maturity frameworks that follow a similar and structured approach. Both emphasize development of processes to improve product development and customer satisfaction and support the coordination of multi-disciplinary activities related to a project.
Although both CMMI and ITIL are similar in structure, the amount of duplication is, however, small and there is no contradiction between the two models, making it possible to apply both CMMI / ITIL models simultaneously in an organization. CMMI is the de facto quality standard for software development, integration, deployment, and maintenance processes in organizations and ITIL is the first choice of organizations for standards related to operations and the infrastructure side of IT.
Implementation of CMMI / ITIL also aids organizations in reducing the cost of quality, improve turnaround times, and arrive at a precise estimate of efforts required that helps in costing products.
References
* Digite.com. CMMI to ITIL: An obvious graduation?
* FoxIT. Introduction to The IT Infrastructure Library (ITIL).
* Serge Thorn. ITIL and CMMI synergies
~~ Show me the data.
Friday, September 17, 2010
More on Scrum
It is one thing to learn something like Scrum, and to go back to the organization to apply it. I was in such situation and it is really a fabulous learning experience for me and the organization I work with.
To summarize the learning, here is my side of the story. We are attempting very much to apply scrum within the team and within a management environment that base on the waterfall model. It is a difficult part trying to convince the management of what to expect. The 2nd part that differs greatly that the management had a harder time embracing is that: The work that developer commits is based on their estimation. This does not help at all really if you focus very much into the benefits of it.
The solution to the above 2 is that, while internal to the team we practice Scrum, externally, we generate reasonable data and information records for reporting purpose. As for the second issue, the developer commitment will be detailed out as well as time management system continue to be used and required to be filled by all staff.
In addition we had some tools us in the form of VSTS 2008 which has a Scrum template build for those who work on Scrum. We started without, but eventually start to populate the required records such as sprint, start date, target hours of work, planned hours to work and working hours available. The result was using this, we were able to churn out reports much faster and we are able to trace our progress like never before. Though the drawback is that there is a lot of stuff to key in for every sprint.
In the quarterly forum I was also able to meet up with an exert who helped in imparting to me some great ideas if implementation. Mike Sutton from wizewerx.com was the man who gave us the insights.
In a nutshell to move from a waterfall to scrum model, follow the following steps:
1. find a pm, developer, sponsor who is interested
2. find a pilot project
3. do it
~~ Show me the data.
To summarize the learning, here is my side of the story. We are attempting very much to apply scrum within the team and within a management environment that base on the waterfall model. It is a difficult part trying to convince the management of what to expect. The 2nd part that differs greatly that the management had a harder time embracing is that: The work that developer commits is based on their estimation. This does not help at all really if you focus very much into the benefits of it.
The solution to the above 2 is that, while internal to the team we practice Scrum, externally, we generate reasonable data and information records for reporting purpose. As for the second issue, the developer commitment will be detailed out as well as time management system continue to be used and required to be filled by all staff.
In addition we had some tools us in the form of VSTS 2008 which has a Scrum template build for those who work on Scrum. We started without, but eventually start to populate the required records such as sprint, start date, target hours of work, planned hours to work and working hours available. The result was using this, we were able to churn out reports much faster and we are able to trace our progress like never before. Though the drawback is that there is a lot of stuff to key in for every sprint.
In the quarterly forum I was also able to meet up with an exert who helped in imparting to me some great ideas if implementation. Mike Sutton from wizewerx.com was the man who gave us the insights.
In a nutshell to move from a waterfall to scrum model, follow the following steps:
1. find a pm, developer, sponsor who is interested
2. find a pilot project
3. do it
~~ Show me the data.
Sunday, September 12, 2010
Process Improvement Tool - 8D
Recently I came across this tool, which one of my client is using. It does not have that much of a publicity but a size-able number of organization actually follows it. Check it out.
8D is a problem-solving methodology for product and process improvement. It is structured into eight disciplines, emphasizing team synergy. The team as whole is better and smarter than the quality sum of the individuals. Each discipline is supported by a checklist of assessment questions, such as "what is wrong with what", "what, when, where, how much".
The Eight Disciplines
1. Use Team Approach
Establish a small group of people with the knowledge, time, authority and skill to solve the problem and implement corrective actions. The group must select a team leader.
2. Describe the Problem
Describe the problem in measurable terms. Specify the internal or external customer problem by describing it in specific terms.
3. Implement and Verify Short-Term Corrective Actions
Define and implement those intermediate actions that will protect the customer from the problem until permanent corrective action is implemented. Verify with data the effectiveness of these actions.
4. Define and Verify Root Causes
Identify all potential causes which could explain why the problem occurred. Test each potential cause against the problem description and data. Identify alternative corrective actions to eliminate root cause.
5. Verify Corrective Actions
Confirm that the selected corrective actions will resolve the problem for the customer and will not cause undesirable side effects. Define other actions, if necessary, based on potential severity of problem.
6. Implement Permanent Corrective Actions
Define and implement the permanent corrective actions needed. Choose on-going controls to insure the root cause is eliminated. Once in production, monitor the long-term effects and implement additional controls as necessary.
7. Prevent Recurrence
Modify specifications, update training, review work flow, improve practices and procedures to prevent recurrence of this and all similar problems.
8. Congratulate Your Team
Recognize the collective efforts of your team. Publicize your achievement. Share your knowledge and learning.
~~ Show me the data.
8D is a problem-solving methodology for product and process improvement. It is structured into eight disciplines, emphasizing team synergy. The team as whole is better and smarter than the quality sum of the individuals. Each discipline is supported by a checklist of assessment questions, such as "what is wrong with what", "what, when, where, how much".
The Eight Disciplines
1. Use Team Approach
Establish a small group of people with the knowledge, time, authority and skill to solve the problem and implement corrective actions. The group must select a team leader.
2. Describe the Problem
Describe the problem in measurable terms. Specify the internal or external customer problem by describing it in specific terms.
3. Implement and Verify Short-Term Corrective Actions
Define and implement those intermediate actions that will protect the customer from the problem until permanent corrective action is implemented. Verify with data the effectiveness of these actions.
4. Define and Verify Root Causes
Identify all potential causes which could explain why the problem occurred. Test each potential cause against the problem description and data. Identify alternative corrective actions to eliminate root cause.
5. Verify Corrective Actions
Confirm that the selected corrective actions will resolve the problem for the customer and will not cause undesirable side effects. Define other actions, if necessary, based on potential severity of problem.
6. Implement Permanent Corrective Actions
Define and implement the permanent corrective actions needed. Choose on-going controls to insure the root cause is eliminated. Once in production, monitor the long-term effects and implement additional controls as necessary.
7. Prevent Recurrence
Modify specifications, update training, review work flow, improve practices and procedures to prevent recurrence of this and all similar problems.
8. Congratulate Your Team
Recognize the collective efforts of your team. Publicize your achievement. Share your knowledge and learning.
~~ Show me the data.
Saturday, March 13, 2010
Systematic Innovation - Darrell Mann
I am honored to have the opportunity to meet with Darrell Mann, one of the many technical or engineering background man who is looking into technical and organizational issues and even improvement capability using a method known as Triz or better known as a systematic way of studying and applying innovation. Darrell has a lot of researcher helping him to continuously study how to innovate things with a method originated from a Russian guy.
Some of the key points during his presentation includes
- successful theory and method of successful innovation
- asking the right question is important in order to solve or even find a way to innovate.
- some tools that is going to help us do the job of innovation
- many application examples to help us see the light
Also we explored areas such as
-Why do so many software companies do the innovation job so badly?
-And essential to that, the area of business, technology and software, and in fact in many organization, opportunities missed because everyone has a silo view. For example, technical problem is perceived as a problem for the technical team only. Business unit is seldom put in to see if they can make any good of the situation..
Some ideas here may be in contrast with improvement, as Darrell mentioned that, moving forward, improvement projects may be saturated. It is time to move in with innovation, systematically.
~~ Show me the data.
Some of the key points during his presentation includes
- successful theory and method of successful innovation
- asking the right question is important in order to solve or even find a way to innovate.
- some tools that is going to help us do the job of innovation
- many application examples to help us see the light
Also we explored areas such as
-Why do so many software companies do the innovation job so badly?
-And essential to that, the area of business, technology and software, and in fact in many organization, opportunities missed because everyone has a silo view. For example, technical problem is perceived as a problem for the technical team only. Business unit is seldom put in to see if they can make any good of the situation..
Some ideas here may be in contrast with improvement, as Darrell mentioned that, moving forward, improvement projects may be saturated. It is time to move in with innovation, systematically.
~~ Show me the data.
Agile Methodology - Scrum
Recently, I attended a workshop discussing about an interesting framework of software development. It injects a rather new taste into traditional waterfall software development that I know of. It is called Scrum. Scrum is one of the many Agile methodology founded upon or built up from the Agile Manifesto. The manifesto concentrates on areas that my generation of IT professionals tried to move away from.
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
The catch is items listed on the right is important, Agile adopters 'value' more, the items on the left.
Interestingly enough, a very loosely defined Agile Manifesto now has several framework that is designed based on this manifesto. Some of the more famous ones are: Scrum, Extreme Programming (XP), Lean, Crystal, Feature Driven Development (FDD) and Dynamic Systems Development Method (DSDM).
Scrum in a nutshell is quick shot of software development, that attempts to produce working software within a period of about every 2 - 4 weeks. One period of 2 - 4 weeks is known as a sprint and every sprint produces a working product. Team works things out among themselves and they produce what Product Owner wants with the facilitation of a Scrum Master. The team is independent and the core of how this works is that, the team has to be protected and trusted to get the work done.
The traditional Gantt Chart that serves us so well with a lot of other tracking tools are thrown out if you decide to use Agile. In place of that, we have burndown chart and product/sprint backlog. Though a lot of tracking tools are thrown out, we have to follow a few Scrum rules closely, meaning, it should not be skipped to ensure success.
Of course there is a lot of debate on whether it works, it is not difficult to understand, but it may be difficult to implement and blended into our traditional environment. It may seem that a lot more issues will crop out as it is implemented, but then again, nothing good comes easy. Anyone who has implemented Scrum, do share your experience with me. I am all ready in reading your experience :)
~~ Show me the data.
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
The catch is items listed on the right is important, Agile adopters 'value' more, the items on the left.
Interestingly enough, a very loosely defined Agile Manifesto now has several framework that is designed based on this manifesto. Some of the more famous ones are: Scrum, Extreme Programming (XP), Lean, Crystal, Feature Driven Development (FDD) and Dynamic Systems Development Method (DSDM).
Scrum in a nutshell is quick shot of software development, that attempts to produce working software within a period of about every 2 - 4 weeks. One period of 2 - 4 weeks is known as a sprint and every sprint produces a working product. Team works things out among themselves and they produce what Product Owner wants with the facilitation of a Scrum Master. The team is independent and the core of how this works is that, the team has to be protected and trusted to get the work done.
The traditional Gantt Chart that serves us so well with a lot of other tracking tools are thrown out if you decide to use Agile. In place of that, we have burndown chart and product/sprint backlog. Though a lot of tracking tools are thrown out, we have to follow a few Scrum rules closely, meaning, it should not be skipped to ensure success.
Of course there is a lot of debate on whether it works, it is not difficult to understand, but it may be difficult to implement and blended into our traditional environment. It may seem that a lot more issues will crop out as it is implemented, but then again, nothing good comes easy. Anyone who has implemented Scrum, do share your experience with me. I am all ready in reading your experience :)
~~ Show me the data.
Subscribe to:
Posts (Atom)
Posts
