Quality means doing it right when no one is looking.
- Henry Ford
jueves, 30 de agosto de 2012
4 every problem...
"For every problem there is a solution: simple, neat, and wrong."
- Mobil Oil Company (advertising).
via @ASQ
- Mobil Oil Company (advertising).
via @ASQ
martes, 25 de octubre de 2011
lunes, 17 de octubre de 2011
From the morning ledger lessons
Steve Jobs left us with valuable lessons for business and for life. His creativity, his obsession with detail, his imagination, his drive, his emphasis on teams and his autocratic style, his feel for the consumer and his refusal to cater to consumer demands — contradictory elements that combined to make a visionary.
No matter your industry or role, there’s much to learn from Steve Jobs. Here are some of his lessons.
Passion. Asked what advice he had for entrepreneurs in a 1995 Smithsonian interview, Jobs said that to succeed you really need passion – “because it’s a lot of work. I’m convinced that about half of what separates the successful entrepreneurs from the non-successful ones is pure perseverance.”
Focus. Jobs channeled his own passion when he rejoined Apple, moving with “speedy intensity” to turn the company around, this Fortune article from 1998 says. He focused on core products, slashed inventories and revamped distribution so only authorized resellers could sell Apple products.
Teams. In this 60 Minutes interview from 2003, he said the Beatles were his business role models because they balanced each other and the total was greater than the sum of the parts. “You know, great things in business are never done by one person.”
Follow your heart. And if you need inspiration to act boldly, read Jobs’s commencement address at Stanford from 2005: “Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition.”
Jobs’s best quotes. On technology, design, business, the future, and life. Impossible to pick just one – worth a read.
http://blogs.wsj.com/cfo/2011/10/06/the-morning-ledger-lessons-from-jobs/
sábado, 9 de abril de 2011
Enfoque de la mejora
Y bajo que fuerza impulsas un proyecto de mejora en una organización si no se tiene patrocinio?
No es cosa simple cambiar los vicios, confianzas y costumbres... y menos si todo inicia desde la cabeza...
"Si sigues repitiendo los mismos esquemas, repetiras los mismos resultados..."
No es cosa simple cambiar los vicios, confianzas y costumbres... y menos si todo inicia desde la cabeza...
"Si sigues repitiendo los mismos esquemas, repetiras los mismos resultados..."
Puedes hablar como merolico, presentar más de una medición o métrica especializada, trabajar como desesperada, hacer tiempos extras, cuidar a los proyectos como niñera oficial, predicar con el ejemplo y sin embargo nada se mueve si desde arriba no se quiere cambiar...
Si no se considera a la mejora de procesos como un proyecto estratégico organizacional, sencillamente no pasa nada... seguiremos caminando en el intento, como entrenar para un maraton con zapatos de tacón, podrás avanzar haciendo malabares, pero no tendrás las condiciones para correr...
No es que me canse de los intentos, sencillamente hay realidades irremediables... cultura señores, es cuestión de cultura... ¿Qué se puede hacer cuando la calidad no es relevante para los que toman las decisiones?
Eso sin mencionar que tampoco se ve lo que el mercado solicita a gritos por estandarización a las PYMES
Sin INVOLUCRAMIENTO y sin patrocinio nomás que no se mueve al elefante... ¿Mejora de procesos? ¿Dónde pues?
Eso sin mencionar que tampoco se ve lo que el mercado solicita a gritos por estandarización a las PYMES
Sin INVOLUCRAMIENTO y sin patrocinio nomás que no se mueve al elefante... ¿Mejora de procesos? ¿Dónde pues?
sábado, 5 de marzo de 2011
Mejora de procesos, cuestión de cultura
Sin comentarios, entre más empresas mexicanas considero para la mejora de procesos, confirmo que no es cosa sencilla cambiar la cultura de trabajo... :(
sábado, 6 de noviembre de 2010
For those who follow CMMI (Top 8 New Concepts in CMMI Version 1.3.)
8. Organization-Level Contracts
As Welsh singer and septuagenarian heartthrob Tom Jones might say, "It's Not Unusual" for organizations to have lists of preferred suppliers, or for work to be issued under task orders. This isn't explicitly acknowledged in CMMI Version 1.2. In Version 1.3, some informative material -- not a lot -- has been added under the following specific practices:
OPD SP 1.1 Establish Standard Processes (all 3 models)
SAM SP 1.1 Determiner Acquisition Type (DEV and SVC only)
SSAD SP 1.1 Identify Potential Suppliers (ACQ only)
Example: "Examples of types of acquisition include... obtaining products from a preferred supplier." [SAM SP 1.1, informative material]
Sure, this may sound like small potatoes compared to some other items on this list. Still, it's a nice acknowledgement of a reasonable best practice.
7. Prioritized Customer Requirements
I have a way-too-long list of things to do around the house this coming weekend. So I've prioritized my tasks to make sure I at least accomplish the most important ones... like downloading new music!
Prioritization is not exactly rocket science. However, if you peruse your dog-eared CMMI v1.2 book, you'll have a tough time finding much on priorities (specifically, customer priorities).
This changes in CMMI v1.3, by bringing prioritization to the forefront in RD SP 1.2 and by adding informative material to the following process areas:
CMMI-DEV: OPD, PP, RD
CMMI-SVC: PP
CMMI-ACQ: PP
Example: "SP 1.2 Transform Stakeholder Needs into Customer Requirements. Transform stakeholder needs, expectations, constraints, and interfaces into prioritized customer requirements." [RD]
6. Lifecycle Needs and Standards
Perhaps to you, a "lifecycle" is a machine you hop onto at the gym to log your 20 minutes of daily cardio. Well, for Version 1.2 of CMMI-DEV, the lifecycle is focused on development. It doesn't say much about other lifecycles that could be applicable to your organization, such as manufacturing, deployment, operations, maintenance, support, and disposal.
In Version 1.3, Part 1 of CMMI-DEV now explicitly references CMMI-SVC for lifecycles such as manufacturing and maintenance. References to relevant standards have also been added, in the Appendix and in an example box in OPD SP 1.1:
"Examples of standards include the following: ISO/IEC 12207 Systems and Software Engineering - Software Life Cycle Processes [ISO 2008a], ISO/IEC 27000 Information Security Management Systems [ISO/IEC 2009], ..."
5. Customer Satisfaction
The concept of "satisfaction" may figure prominently in a certain Rolling Stones song, but it's rarely mentioned in CMMI v1.2 -- especially in CMMI-DEV. You still won't see customer satisfaction measures required by CMMI v1.3; however, you'll find informative material added to these process areas:
CMMI-DEV: MA, OPF, PMC, RD
CMMI-SVC: MA
CMMI-ACQ: ARD, OPF
Customer satisfaction, and the related concept of customer loyalty, plays a significant role in driving my business -- and hopefully yours as well. The added material is welcomed.
Example: "...Candidate improvements to the organization's processes and process assets are obtained from various sources, including... results of customer satisfaction evaluations" [OPF, Introductory Notes]
4. Causal Analysis at Low Levels of Maturity
At the 2008 NDIA CMMI Technology Conference and User Group, I delivered an impassioned presentation on Using CAR to Rescue a Sinking Process Improvement Program. In my talk, I discussed how I used causal analysis to assist a client organization in solving an important problem -- despite their "low maturity." (I won an award for that presentation, although my friend Angie claims that my skillful inclusion of a shirtless Brad Pitt photo unfairly swayed a few key voters.)
In CMMI Version 1.3, there's now more explicit encouragement to do just that: use causal analysis at lower levels of maturity, without the use of statistics and process performance baselines. To help with this, the Introductory Notes of some high maturity process areas have been revised. Also, a new specific practice has been added to QPM (SP 2.3 Perform Root Cause Analysis), and a few low maturity process areas have been tweaked.
Example: "Address causes of selected issues that can affect project objectives" [IPM, SP 1.5, subpractice 5 (new)]
3. Teaming Concepts
In CMMI Version 1.2, Integrated Process and Product Development (IPPD) is formally known as an addition to the model. Think of it as an option you might add to that yellow Lamborghini of yours, but one that can have a significant impact on your driving. IPPD's use is targeted for complex projects building complicated products. From an appraisal perspective, you could be appraised against CMMI-DEV, or CMMI-DEV + IPPD, although the latter has happened only in about 5% of recent CMMI-DEV appraisals.
What's changed in Version 1.3? The IPPD addition, as well as the concept of integrated teaming, is now gone. A more general concept of teaming has taken its place, making this new approach to teaming consistent across the three constellations. (CMMI-ACQ v1.2 and CMMI-SVC v1.2 already had incorporated generalized concepts from CMMI-DEV's IPPD addition.) You'll find a few new specific practices in CMMI-DEV.
Example: "Establish and maintain teams." [CMMI-DEV, IPM SP 1.6 (new)]
2. Modernized Development Practices
Like the model itself, much of the engineering content of CMMI-DEV is as old as Buddy and Koko combined (ten). Because the other two constellations (SVC and ACQ) essentially used DEV as their starting point, they're similarly lacking.
Version 1.3 has added, or in some cases simply beefed up, concepts such as quality attributes (non-functional requirements or "ilities"), product lines, systems of systems, allocation of product capabilities to release increments, architecture-centric development practices, and technology maturation. Key changes include:
Glossary updates, including new terms and revised definitions
Informative material updates in all three constellations (especially in RD, REQM, VAL, and VER) to bring more balance to functional vs. non-functional requirements (e.g., quality attributes)
Additional informative material updates to address other modern engineering approaches (e.g., product lines)
Minor required and expected content updates (RD SG 3, RD SP 3.2, and SSD)
Example: "quality attribute: A property of a product or service by which its quality will be judged by relevant stakeholders. Quality attributes are characterized by some appropriate measure. Quality attributes are non-functional, such as timeliness, throughput, responsiveness, security, modifiability, reliability, and usability. They have a significant influence on the architecture."(Glossary)
1. Agile Interpretive Guidance
Say the word "Agile." Great! Now say "CMMI." Super! Quick question: which sounds sleeker... smoother... sexier? Even the authors of the CMMI would have to admit they lose that battle every single time!
Now, I certainly can't claim to be an agile expert, based on the fact that once-upon-a-time I read a book and then I kinda-sorta applied it. (Along with a dose of the CMMI for Services, though, it did help to turn my little company around.) But I'd be a fool -- and so would you -- to ignore the fact that agile methods such as Scrum have taken the development world by storm in the past decade. Yet, agile developers often don't see how CMMI can help them. Reasonable people have said it can, and publications like CMMI or Agile: Why Not Embrace Both! have explored the ability of CMMI to compliment or improve agile methods.
That being said, don't look for any specially-added goals or practices in Version 1.3 to accommodate agile. Why? They're simply not needed; agility fit just fine into Version 1.2... if you only knew how to interpret the model! (I know... that's a big "if." I make my living largely by telling people for three days at a time how to interpret the CMMI!) So for Version 1.3, you'll find that interpretive guidance has wisely been added. Look for a new section in the CMMI for Development (CMMI-DEV) Chapter 5, entitled "Interpreting CMMI When Using Agile Approaches," as well as new informative material in the following process areas:
CMMI-DEV: CM, REQM, PP, RD, TS, PI, VER, PPQA, and RSKM
Example: "In agile environments... Teams plan, monitor, and adjust plans in each iteration as often as it takes (e.g., daily). Commitments to plans are demonstrated when tasks are assigned and accepted during iteration planning, user stories are elaborated or estimated, and iterations are populated with tasks from a maintained backlog of work."
So, finally, you now have my Top 8 New Concepts in CMMI v1.3:
As Welsh singer and septuagenarian heartthrob Tom Jones might say, "It's Not Unusual" for organizations to have lists of preferred suppliers, or for work to be issued under task orders. This isn't explicitly acknowledged in CMMI Version 1.2. In Version 1.3, some informative material -- not a lot -- has been added under the following specific practices:
OPD SP 1.1 Establish Standard Processes (all 3 models)
SAM SP 1.1 Determiner Acquisition Type (DEV and SVC only)
SSAD SP 1.1 Identify Potential Suppliers (ACQ only)
Example: "Examples of types of acquisition include... obtaining products from a preferred supplier." [SAM SP 1.1, informative material]
Sure, this may sound like small potatoes compared to some other items on this list. Still, it's a nice acknowledgement of a reasonable best practice.
7. Prioritized Customer Requirements
I have a way-too-long list of things to do around the house this coming weekend. So I've prioritized my tasks to make sure I at least accomplish the most important ones... like downloading new music!
Prioritization is not exactly rocket science. However, if you peruse your dog-eared CMMI v1.2 book, you'll have a tough time finding much on priorities (specifically, customer priorities).
This changes in CMMI v1.3, by bringing prioritization to the forefront in RD SP 1.2 and by adding informative material to the following process areas:
CMMI-DEV: OPD, PP, RD
CMMI-SVC: PP
CMMI-ACQ: PP
Example: "SP 1.2 Transform Stakeholder Needs into Customer Requirements. Transform stakeholder needs, expectations, constraints, and interfaces into prioritized customer requirements." [RD]
6. Lifecycle Needs and Standards
Perhaps to you, a "lifecycle" is a machine you hop onto at the gym to log your 20 minutes of daily cardio. Well, for Version 1.2 of CMMI-DEV, the lifecycle is focused on development. It doesn't say much about other lifecycles that could be applicable to your organization, such as manufacturing, deployment, operations, maintenance, support, and disposal.
In Version 1.3, Part 1 of CMMI-DEV now explicitly references CMMI-SVC for lifecycles such as manufacturing and maintenance. References to relevant standards have also been added, in the Appendix and in an example box in OPD SP 1.1:
"Examples of standards include the following: ISO/IEC 12207 Systems and Software Engineering - Software Life Cycle Processes [ISO 2008a], ISO/IEC 27000 Information Security Management Systems [ISO/IEC 2009], ..."
5. Customer Satisfaction
The concept of "satisfaction" may figure prominently in a certain Rolling Stones song, but it's rarely mentioned in CMMI v1.2 -- especially in CMMI-DEV. You still won't see customer satisfaction measures required by CMMI v1.3; however, you'll find informative material added to these process areas:
CMMI-DEV: MA, OPF, PMC, RD
CMMI-SVC: MA
CMMI-ACQ: ARD, OPF
Customer satisfaction, and the related concept of customer loyalty, plays a significant role in driving my business -- and hopefully yours as well. The added material is welcomed.
Example: "...Candidate improvements to the organization's processes and process assets are obtained from various sources, including... results of customer satisfaction evaluations" [OPF, Introductory Notes]
4. Causal Analysis at Low Levels of Maturity
At the 2008 NDIA CMMI Technology Conference and User Group, I delivered an impassioned presentation on Using CAR to Rescue a Sinking Process Improvement Program. In my talk, I discussed how I used causal analysis to assist a client organization in solving an important problem -- despite their "low maturity." (I won an award for that presentation, although my friend Angie claims that my skillful inclusion of a shirtless Brad Pitt photo unfairly swayed a few key voters.)
In CMMI Version 1.3, there's now more explicit encouragement to do just that: use causal analysis at lower levels of maturity, without the use of statistics and process performance baselines. To help with this, the Introductory Notes of some high maturity process areas have been revised. Also, a new specific practice has been added to QPM (SP 2.3 Perform Root Cause Analysis), and a few low maturity process areas have been tweaked.
Example: "Address causes of selected issues that can affect project objectives" [IPM, SP 1.5, subpractice 5 (new)]
3. Teaming Concepts
In CMMI Version 1.2, Integrated Process and Product Development (IPPD) is formally known as an addition to the model. Think of it as an option you might add to that yellow Lamborghini of yours, but one that can have a significant impact on your driving. IPPD's use is targeted for complex projects building complicated products. From an appraisal perspective, you could be appraised against CMMI-DEV, or CMMI-DEV + IPPD, although the latter has happened only in about 5% of recent CMMI-DEV appraisals.
What's changed in Version 1.3? The IPPD addition, as well as the concept of integrated teaming, is now gone. A more general concept of teaming has taken its place, making this new approach to teaming consistent across the three constellations. (CMMI-ACQ v1.2 and CMMI-SVC v1.2 already had incorporated generalized concepts from CMMI-DEV's IPPD addition.) You'll find a few new specific practices in CMMI-DEV.
Example: "Establish and maintain teams." [CMMI-DEV, IPM SP 1.6 (new)]
2. Modernized Development Practices
Like the model itself, much of the engineering content of CMMI-DEV is as old as Buddy and Koko combined (ten). Because the other two constellations (SVC and ACQ) essentially used DEV as their starting point, they're similarly lacking.
Version 1.3 has added, or in some cases simply beefed up, concepts such as quality attributes (non-functional requirements or "ilities"), product lines, systems of systems, allocation of product capabilities to release increments, architecture-centric development practices, and technology maturation. Key changes include:
Glossary updates, including new terms and revised definitions
Informative material updates in all three constellations (especially in RD, REQM, VAL, and VER) to bring more balance to functional vs. non-functional requirements (e.g., quality attributes)
Additional informative material updates to address other modern engineering approaches (e.g., product lines)
Minor required and expected content updates (RD SG 3, RD SP 3.2, and SSD)
Example: "quality attribute: A property of a product or service by which its quality will be judged by relevant stakeholders. Quality attributes are characterized by some appropriate measure. Quality attributes are non-functional, such as timeliness, throughput, responsiveness, security, modifiability, reliability, and usability. They have a significant influence on the architecture."(Glossary)
1. Agile Interpretive Guidance
Say the word "Agile." Great! Now say "CMMI." Super! Quick question: which sounds sleeker... smoother... sexier? Even the authors of the CMMI would have to admit they lose that battle every single time!
Now, I certainly can't claim to be an agile expert, based on the fact that once-upon-a-time I read a book and then I kinda-sorta applied it. (Along with a dose of the CMMI for Services, though, it did help to turn my little company around.) But I'd be a fool -- and so would you -- to ignore the fact that agile methods such as Scrum have taken the development world by storm in the past decade. Yet, agile developers often don't see how CMMI can help them. Reasonable people have said it can, and publications like CMMI or Agile: Why Not Embrace Both! have explored the ability of CMMI to compliment or improve agile methods.
CMMI-SVC: SSD
CMMI-ACQ: AM, ATM, PMC, and PP
- Agile interpretive guidance
- Modernized development practices
- Teaming concepts
- Causal analysis at low levels of maturity
- Customer satisfaction
- Lifecycle needs and standards
- Prioritized customer requirements
- Organizational-level contracts
For more detail:
Suscribirse a:
Entradas (Atom)