While reading the SCAMPI A Method Definition Document (MDD), I discovered that providing project specific findings is an option that can be requested by the project sponsor. I always believed that the Findings Presentation could only include findings at organizational unit level. So if the sponsor requests project specific findigs as part of the appraisal output, how are they communicated? Included in the final findings? If this is the case, what about the non-attribution of findings? Or via a separate document?
The SCAMPI Method does indeed allow for project specific findings if the Appraisal Sponsor requests them. If requested, then project specific findings could be communicated in the Final Findings Presentation along with the other information, or they could be communicated separately. Reporting will be negotiated and documented in the Appraisal Plan. Keep in mind that even if the Appraisal Sponsor doesn’t request project specific findings, the PIIDs will contain project specific observations, so if someone were interested in finding out about project specific information, all they would have to do would be to read the PIIDs. The organization is required to retain the PIIDs used for the appraisal for three years, the same length of time that the appraisal results are valid.
The non-attribution issue concerns identifying any individual, project, or group as the SOURCE of the information. So by reporting project specific findings, the Lead Appraiser and Appraisal Team are not violating the non-attribution rules unless they reveal the source of the finding(s). When I conduct an appraisal, the final Appraisal Team activity is to scrub the PIIDs of all attribution information (names, interview sessions, etc.) and deleting all previous versions so the organization only retains the scrubbed PIIDs.
Friday, August 7, 2009
Wednesday, August 5, 2009
Selecting Projects for a SCAMPI Appraisal
One of my client organisations works on hardware and software design projects related to locomotive design for a manufacturer. They want to adopt the CMMI-DEV and scope their SCAMPI appraisals only for their software projects. Both, hardware and software design projects are undertaken by the same organisation, under the same management, same company name and at the same location. Is it be proper for the organization to exclude the hardware projects from their CMMI journey and appraisals? I feel it is not proper and it violates the principle of institutionalization of processes across the organization. Moreover, if the Lead Appraiser agrees to conduct an appraisal for software projects only, he or she will violate the principle of randomly selecting the projects for the appraisal.
The way I look at this situation depends upon on how the company is organized. If there are separate hardware and software development groups, departments, or divisions that deliver products to a program office (for example), then the software group could be appraised on its own. The same could be true for the hardware group. In fact, this situation occurs quite frequently in my experience here in the United States.
However, if the hardware and software groups are tightly intertwined in building and delivering a product (meaning you cannot separate the two), then I would say that both the hardware and software groups had to be appraised together.
The correct decision requires the Lead Appraiser to have a very good understanding of the organization and its business, as well as being a function of how the organization defines a project and what its process documentation states.
The way I look at this situation depends upon on how the company is organized. If there are separate hardware and software development groups, departments, or divisions that deliver products to a program office (for example), then the software group could be appraised on its own. The same could be true for the hardware group. In fact, this situation occurs quite frequently in my experience here in the United States.
However, if the hardware and software groups are tightly intertwined in building and delivering a product (meaning you cannot separate the two), then I would say that both the hardware and software groups had to be appraised together.
The correct decision requires the Lead Appraiser to have a very good understanding of the organization and its business, as well as being a function of how the organization defines a project and what its process documentation states.
Tuesday, August 4, 2009
CMMI Documentation Request
I have read your blog. Can you provide me some documented CMMI processes (Draft)? I would like to learn and implement the process. I have good experience using ISO 9001 for the past 10 years.
There is no such thing as a set of documented CMMI processes that can be provided for a company, though some unscrupulous consultants will try to sell you a set. Rather, there are industry accepted standards for documenting processes, such as ETVX. These process documentation standards are easily available by searching on the internet. The actual processes for REQM , PP, PMC, SAM, MA, PPQA, CM, etc. are a function of the organization’s business and its practices, though there is some commonality across companies and organizations. However, this commonality exists at the CMMI level. The CMMI is a set of guidelines for process improvement. The implementation of these guidelines will differ from organization to organization. The best advice that I can give you is to document all of your current business practices using an industry accepted process documentation standard, avoiding the temptation to improve the process. By simply documenting your existing processes, you will discover opportunities for improvement, but don’t make them at this point. Just document the process as it is currently practiced. Once you have all of your processes documented, then compare the results to the CMMI, add the missing practices, and address any improvement opportunities. Then you will have a set of processes that your employees will have ownership of and will also comply with the CMMI.
There is no such thing as a set of documented CMMI processes that can be provided for a company, though some unscrupulous consultants will try to sell you a set. Rather, there are industry accepted standards for documenting processes, such as ETVX. These process documentation standards are easily available by searching on the internet. The actual processes for REQM , PP, PMC, SAM, MA, PPQA, CM, etc. are a function of the organization’s business and its practices, though there is some commonality across companies and organizations. However, this commonality exists at the CMMI level. The CMMI is a set of guidelines for process improvement. The implementation of these guidelines will differ from organization to organization. The best advice that I can give you is to document all of your current business practices using an industry accepted process documentation standard, avoiding the temptation to improve the process. By simply documenting your existing processes, you will discover opportunities for improvement, but don’t make them at this point. Just document the process as it is currently practiced. Once you have all of your processes documented, then compare the results to the CMMI, add the missing practices, and address any improvement opportunities. Then you will have a set of processes that your employees will have ownership of and will also comply with the CMMI.
Estimating Cost vs. Establishing the Project's Budget
What is the difference between Estimation of Project Cost (PP SP 1.4) and Establishing Project Budget (PP SP 2.1)?
Project Planning (PP) Specific Practice (SP) 1.4 addresses estimating the effort and cost for the project’s work products and tasks based on specified estimation rationale, models, and/or historical data. SP 2.1 takes this information for the individual work products and tasks, along with the major milestones identified in the project’s defined life cycle, any scheduling assumptions and constraints, and task predecessor/successor relationships to construct the project’s schedule and overall budget. Simply put, SP 1.4 concerns individual items in the project and SP 2.1 concerns the project as a whole.
Project Planning (PP) Specific Practice (SP) 1.4 addresses estimating the effort and cost for the project’s work products and tasks based on specified estimation rationale, models, and/or historical data. SP 2.1 takes this information for the individual work products and tasks, along with the major milestones identified in the project’s defined life cycle, any scheduling assumptions and constraints, and task predecessor/successor relationships to construct the project’s schedule and overall budget. Simply put, SP 1.4 concerns individual items in the project and SP 2.1 concerns the project as a whole.
Requirements Traceability, To What Level?
It certainly makes sense to include relations between requirements and source code in the requirements traceability matrix. If requirements change, we've a direct view on the impact on source level. But can this be managed and maintained, even with a tool? Is it wortwhile to put a huge effort in maintaining relations between requirements and the source code? Isn't it sufficient to define these relations at the level of design elements and user acceptance test cases? In this case, we've a means to verify that each requirement is covered by design and test. I believe this strongly reduces the risk of uncovered requirements in the final delivery, which is one of the main purposes of requirements traceability.
The answer is, you do whatever is necessary to meet your business goals and objectives. It depends upon the criticality of the product or service you are delivering. If your product is highly complex and someone could lose their life if there was a missed requirement, then it is necessary to put a huge amount of effort into requirements traceability. Just consider the Space Shuttle program, the amount of requirements etc. The Space Shuttle software is as close to zero defects as you will ever find. And at the other end of the spectrum, you would be justified limiting the amount of effort for traceability.
The answer is, you do whatever is necessary to meet your business goals and objectives. It depends upon the criticality of the product or service you are delivering. If your product is highly complex and someone could lose their life if there was a missed requirement, then it is necessary to put a huge amount of effort into requirements traceability. Just consider the Space Shuttle program, the amount of requirements etc. The Space Shuttle software is as close to zero defects as you will ever find. And at the other end of the spectrum, you would be justified limiting the amount of effort for traceability.
Monday, August 3, 2009
PPQA or VER?
I have a question. When people performa a review to assure than a coding standard is being used, is it considered a PPQA audit or a verification activity (VER)?
The correct answer is, it depends upon the nature of the review. If your documented software development process states that the coding standard is used to write code. Then a process audit of the software development process would be looking at the coding standard and determining if it was indeed being used by the developers. That would be a Process and Product Quality Assurance (PPQA) audit activity. If your documented verification process stated that a code peer review involves comparing the code to the coding standard, then that would be a Verification (VER) activity. And if your documented processes specified both of these conditions, then the answer to your question is both a PPQA audit activity and a VER activity. How you view the code review against the coding standard is therefore context dependant.
If you are asking this question because you are preparing your Direct and Indirect Evidence for your PIIDs and a SCAMPI A appraisal, then you will need to explain the context so the appraisal team will be able to correctly evaluate the evidence.
The correct answer is, it depends upon the nature of the review. If your documented software development process states that the coding standard is used to write code. Then a process audit of the software development process would be looking at the coding standard and determining if it was indeed being used by the developers. That would be a Process and Product Quality Assurance (PPQA) audit activity. If your documented verification process stated that a code peer review involves comparing the code to the coding standard, then that would be a Verification (VER) activity. And if your documented processes specified both of these conditions, then the answer to your question is both a PPQA audit activity and a VER activity. How you view the code review against the coding standard is therefore context dependant.
If you are asking this question because you are preparing your Direct and Indirect Evidence for your PIIDs and a SCAMPI A appraisal, then you will need to explain the context so the appraisal team will be able to correctly evaluate the evidence.
Software Sizing
We are trying to achieve CMMI Maturity Level (ML) 3 in my company and we have decided to skip ML 2. So, now, one of our problems is related to software size estimation. We defined a proprietary method, based on Use Case Points and Function Points, but the practitioners are struggling with it. From your experience, what other methods have you seen or implemented in the companies with this same problem? Or, if a proprietary method was defined, what were the main aspects to take in account?
I would strongly urge you to forget the ML 3 Process Areas until you have mastered ML 2. There is a fundamental difference between how a ML 2 Project Manager approaches Project Planning (PP) and Project Monitoring and Control (PMC) vs. a ML 3 Project Manager. Estimation being one of the differences. Use Case Points and Functions Points are fairly sophisticated concepts and there are challenges with getting consistency in determining what each of these things are. I would recommend that you take a step back from the model and the projects and look at your historical project data. Use the actual effort, costs, etc. from previous projects to estimate a new project. Forget about Use Case Points and Function Points for now. Once you have mastered being able to use historical information to build an empirical estimation model, then it might make sense to add a layer of sophistication by considering Use Case Points or Function Points.
Another recommendation is let the Project Manager create the project estimates and then review them with the practitioners as a sanity check rather than ask the practitioners to create the estimates. Over time as the organization gains experience estimating projects etc., then it makes sense to involve the practitioners up front in the estimation process. You have to learn to crawl first with estimation before you can sprint with the big boys.
I would strongly urge you to forget the ML 3 Process Areas until you have mastered ML 2. There is a fundamental difference between how a ML 2 Project Manager approaches Project Planning (PP) and Project Monitoring and Control (PMC) vs. a ML 3 Project Manager. Estimation being one of the differences. Use Case Points and Functions Points are fairly sophisticated concepts and there are challenges with getting consistency in determining what each of these things are. I would recommend that you take a step back from the model and the projects and look at your historical project data. Use the actual effort, costs, etc. from previous projects to estimate a new project. Forget about Use Case Points and Function Points for now. Once you have mastered being able to use historical information to build an empirical estimation model, then it might make sense to add a layer of sophistication by considering Use Case Points or Function Points.
Another recommendation is let the Project Manager create the project estimates and then review them with the practitioners as a sanity check rather than ask the practitioners to create the estimates. Over time as the organization gains experience estimating projects etc., then it makes sense to involve the practitioners up front in the estimation process. You have to learn to crawl first with estimation before you can sprint with the big boys.
Subscribe to:
Posts (Atom)