Greetings!
Isn't it interesting that in the professional discipline of 'Quality Assurance', we most often use quantitative analysis for tracking status of projects. Shouldn't it then be called 'Quantitative Assurance'???
Last week in my article I mentioned Capability Maturity Model Integration (CMMI). I since had an excellent conversation with a colleague from a DoD company regarding their need for expertise in Change Management - do to a fairly large software integration project. They felt that employing the CMMI model during this project would be a critical success factor. That statement is music to my ears. However, they also felt that a training or HR resource would be needed to manage the effort. They are soooo very, very close on their actual modeling needs.
Some real quick background on this area. In the early 80's, the Software Engineering Institute (SEI) of Carnegie Mellon was approached, then tasked by the DoD to develop a model for engineering organizational development. The model design was to be a set of practices that could be consistently followed - with the ultimate goal of being able to produce high quality software in a reliable fashion. Software development at that time tended to be an adventure, and with the industry growing, any effort to bring a sense of order would taste like a cool glass of lemonade on a hot summer day. The original model was called the Software Capability Maturity Model (SW-CMM) - the predecessor of what is known today as CMMI. The model provides objective process standards levels - called 'maturity levels' - that would systematically guide organizations to higher levels of functionality - and thus higher levels of productivity (to learn more, please visit: http://www.sei.cmu.edu).
Many companies today, with the best of intentions, employ the model to develop their organizations - only to stall out at lover levels of the model. Why? Many companies do not realize that although the model takes into account many objective factors that can be quantified, it does not address the maturity level of their organizational culture (this means refinement of company people processes at the company - not that the company is being run by teenagers) . In effect, they are attempting to improve the quality of the organization with one tool - when two are needed. It's like building a house with a hammer - but no nails. (Note: Six Sigma initiatives succeed only when companies achieve a high level of model maturity)
Largely because of this reason, SEI has since developed a derivative of the CMM model called People Capability Management Model (P-CMM). Like its predecessor, the goal of the model is to provide a quantitative assessment of the maturity level of people processes within the organization, then provide a step level approach for bringing about a higher level of process maturity. Only when the P-CMM model is used concurrently with the CMMI tool, will the odds favor success. Companies have only a 59% chance for long term success with Change Management initiatives when using only CMMI - as opposed to a 79% rate of success when both P-CMM and CMMI models are used in tandem.
However, even though both models provide guidance on the implementation of quantitative analysis tools to measure progress and compliance results, a key success factor will also be a qualitative perspective that must be employed to determine the flexibility of the organization to correctly size rate and depth of implementation.
In this global, cross-functional world, no one department can tackle a Change Management project. The company I spoke with had it largely correct (sans integration of P-CMM). Although the initiative may be owned by Quality, a wide net of sponsors, stakeholders and teams members must be cast so the models can be effectively integrated for optimal result.
Change Management is an all hands-on-deck kind of thing that requires integrated, systematic approaches, multiple perspectives, quantitative analysis and definitely qualitative reflection regarding your most important asset - people.
Fran
Next weeks theme: 'Company Road Trip'
Tuesday, July 21, 2009
Friday, July 10, 2009
Company Road Trip: To LEAN or not to LEAN .... that was the question
Greetings!
I really love these road trips! You get a chance to get out from behind the laptop and off the cyber highway, and instead roll the tires, press the flesh and talk quality face-to-face. Todays virtual world has proven to be more efficient, but maintaining ones network and increasing their knowledgebase should include regular roads trips as part of the recipe.
I recently visited a major telecom company to discuss activities in the area of process improvements. Over several years, they had gone through a number of acquisitions. This is tricky business, and if not extensively planned for, can come back to bite the organization in later years in the form of disjointed tool roll outs, broken processes and organizational mis-structures. There are very valid reasons for this, and it usually has to do with limited budget dollars being spent on what is considered critical path projects that will contribute directly (ROI stuff here) to future revenue growth.
I met with a person responsible for hiring a senior level process improvement director. Two major questions I had for her were: 'What changed that you want to hire this person now?' and 'What key skills are you looking for in this role?'.
The answer to the first question was not the result of some 'ah-ha moment' they had, but rather pure economics. Consumers are spending less on their services, and the need for a more efficient business process strategy that could be supported by a lean organizational structure was in order. The answer to the second question was most enlightening.
They felt having someone with a Six Sigma background was a must. As they paraded a number of Six Sigma Black Belt candidates through their doors, they were uniform regarding one particular query to the hiring manager: 'Is there executive level sponsorship for the initiative?' The answer was:' No, that's what we would hire you to do - champion this initiative and be responsible for its outcome - as the executive leadership would not have the time to be involved'.
Anyway, they felt hiring a Six Sigma Black Belt maybe was not the way to go, and that smaller incremental process improvement steps - say via the LEAN methodology - would be the way to proceed. At last update, this was still in discussion.
Now, I know what you're thinking, but I'm hear today to say kudos to the company for making process improvement a priority. They recognize the need - a big first step for them - even if they are not quite sure at this time what is the best strategy.
This is where quality folks can really add value. As much as a quality professional's role is to improve products, services, processes, etc, understanding your audience and providing appropriate information to help them traverse knowledge gaps is a real winning strategy.
Imagine if those candidates for the role mentioned above researched the company and came equipped with say - a CMMI model as a learning tool - and provided some background on the model, where they feel the company fit into the model and a vision for future development. Powerful stuff - knowledge that companies could benefit from and it shows impressive thought leadership from the candidate.
Fran
Next weeks theme is 'Methods to The Madness: Qualitative vs Quantitative Approaches to QA'
I really love these road trips! You get a chance to get out from behind the laptop and off the cyber highway, and instead roll the tires, press the flesh and talk quality face-to-face. Todays virtual world has proven to be more efficient, but maintaining ones network and increasing their knowledgebase should include regular roads trips as part of the recipe.
I recently visited a major telecom company to discuss activities in the area of process improvements. Over several years, they had gone through a number of acquisitions. This is tricky business, and if not extensively planned for, can come back to bite the organization in later years in the form of disjointed tool roll outs, broken processes and organizational mis-structures. There are very valid reasons for this, and it usually has to do with limited budget dollars being spent on what is considered critical path projects that will contribute directly (ROI stuff here) to future revenue growth.
I met with a person responsible for hiring a senior level process improvement director. Two major questions I had for her were: 'What changed that you want to hire this person now?' and 'What key skills are you looking for in this role?'.
The answer to the first question was not the result of some 'ah-ha moment' they had, but rather pure economics. Consumers are spending less on their services, and the need for a more efficient business process strategy that could be supported by a lean organizational structure was in order. The answer to the second question was most enlightening.
They felt having someone with a Six Sigma background was a must. As they paraded a number of Six Sigma Black Belt candidates through their doors, they were uniform regarding one particular query to the hiring manager: 'Is there executive level sponsorship for the initiative?' The answer was:' No, that's what we would hire you to do - champion this initiative and be responsible for its outcome - as the executive leadership would not have the time to be involved'.
Anyway, they felt hiring a Six Sigma Black Belt maybe was not the way to go, and that smaller incremental process improvement steps - say via the LEAN methodology - would be the way to proceed. At last update, this was still in discussion.
Now, I know what you're thinking, but I'm hear today to say kudos to the company for making process improvement a priority. They recognize the need - a big first step for them - even if they are not quite sure at this time what is the best strategy.
This is where quality folks can really add value. As much as a quality professional's role is to improve products, services, processes, etc, understanding your audience and providing appropriate information to help them traverse knowledge gaps is a real winning strategy.
Imagine if those candidates for the role mentioned above researched the company and came equipped with say - a CMMI model as a learning tool - and provided some background on the model, where they feel the company fit into the model and a vision for future development. Powerful stuff - knowledge that companies could benefit from and it shows impressive thought leadership from the candidate.
Fran
Next weeks theme is 'Methods to The Madness: Qualitative vs Quantitative Approaches to QA'
Thursday, July 2, 2009
Methods to The Madness: Finding your way along the test case audit trail
Greetings!
First things first. Finding a clear trail from a functional test case back to the original business requirement from whence it came can be, at times, more difficult that finding a seat at the movies after the lights go dim. There ... I said it. It's an ugly truth, but one that is prevalent - even if test managers do not always wish to expose this gap.
Also, I am not saying that all industries have ambiguous compliancy models in this area. Certainly FDA compliancy standards wield a sharper edge than say ISO standards. Please don't misunderstand, the ISO is a fine organization and the standards they promote are ones that I have always attempted to follow as a QA Manager. However, the risk of non-compliance with ISO is not the same risk type as non-compliance with say - the FBI or FCC - which I have had the pleasure to partner with regarding compliance standards.
Why is it then that the test case audit trail can often be ambiguous or even disjointed? There can be any number of reasons or combination of reasons. Lack of tools and time-to-market pressures are two mentioned often. However, I have seen tools that many times are available but are not used effectively. And, there are always pressures to work quickly. So, what's a QA group to do?
The complexity of SDLC (choose your methodology) precludes a desire to come up with a one-size-fits all solution or have one root cause. I have found that listening to the folks developing the test plans/cases for clues is a great place to start. Some good questions during these conversations that come to mind would be: do they understand and are comfortable with the organizational mechanics of feature development, do they have a good handle on the feature they will be testing and do they know about point-of-origin and justification for the feature? Many times the test group for the release may not have been effectively integrated into the process .... regardless of what the Gant Chart states.
Managers would be wise to be actively involved in the release planning process to ensure that resources are scheduled in the requirements gathering phase - then make sure it happens. The QA folks hold much historical information on feature testing and can contribute greatly during the feature requirement and functional specification development phases.
Also, be sure to explore with the QA group available options to link your test cases directly back through the functional specification to the business requirement. If there is a in-house tool, champion its use. If not, and budgets are tight, champion an effort for using another method. I've seen Excel do a decent job - as long as cross functional groups have ID'd their respective requirements. Consider it a critical path activity.
The key point is that when QA understands the direct relationship between the tests they are executing and the origin of the business requirements, they will have more confidence to champion and chart product quality not only in terms of test pass/fail rates, but also to speak more broadly throughout the organization regarding overall product quality.
Early resource involvement and becoming a champion for a quality process that casts a wider communication net adds value to any organization. And, you'll make the compliance folks very happy!
Fran
Next weeks theme is 'Company Road Trip: To LEAN or not to LEAN .... that was the question'
First things first. Finding a clear trail from a functional test case back to the original business requirement from whence it came can be, at times, more difficult that finding a seat at the movies after the lights go dim. There ... I said it. It's an ugly truth, but one that is prevalent - even if test managers do not always wish to expose this gap.
Also, I am not saying that all industries have ambiguous compliancy models in this area. Certainly FDA compliancy standards wield a sharper edge than say ISO standards. Please don't misunderstand, the ISO is a fine organization and the standards they promote are ones that I have always attempted to follow as a QA Manager. However, the risk of non-compliance with ISO is not the same risk type as non-compliance with say - the FBI or FCC - which I have had the pleasure to partner with regarding compliance standards.
Why is it then that the test case audit trail can often be ambiguous or even disjointed? There can be any number of reasons or combination of reasons. Lack of tools and time-to-market pressures are two mentioned often. However, I have seen tools that many times are available but are not used effectively. And, there are always pressures to work quickly. So, what's a QA group to do?
The complexity of SDLC (choose your methodology) precludes a desire to come up with a one-size-fits all solution or have one root cause. I have found that listening to the folks developing the test plans/cases for clues is a great place to start. Some good questions during these conversations that come to mind would be: do they understand and are comfortable with the organizational mechanics of feature development, do they have a good handle on the feature they will be testing and do they know about point-of-origin and justification for the feature? Many times the test group for the release may not have been effectively integrated into the process .... regardless of what the Gant Chart states.
Managers would be wise to be actively involved in the release planning process to ensure that resources are scheduled in the requirements gathering phase - then make sure it happens. The QA folks hold much historical information on feature testing and can contribute greatly during the feature requirement and functional specification development phases.
Also, be sure to explore with the QA group available options to link your test cases directly back through the functional specification to the business requirement. If there is a in-house tool, champion its use. If not, and budgets are tight, champion an effort for using another method. I've seen Excel do a decent job - as long as cross functional groups have ID'd their respective requirements. Consider it a critical path activity.
The key point is that when QA understands the direct relationship between the tests they are executing and the origin of the business requirements, they will have more confidence to champion and chart product quality not only in terms of test pass/fail rates, but also to speak more broadly throughout the organization regarding overall product quality.
Early resource involvement and becoming a champion for a quality process that casts a wider communication net adds value to any organization. And, you'll make the compliance folks very happy!
Fran
Next weeks theme is 'Company Road Trip: To LEAN or not to LEAN .... that was the question'
Subscribe to:
Posts (Atom)