Peer Review Defect Categories

During peer reviews and testing we find defects and record them in defect log sheet. These defects can be used further for defect data analysis or other purposes (defect prevention). Keeping all these in mind, what defect categories should the organization use for better and easy analysis?

Rather than ask what others are using as defect categories, you should be analyzing your defect data and determine the categories that your defects naturally fall into. These categories also need to have meaning for your organization. If you were to use someone else’s categories and these categories do not relate to your products, projects, or organization, then they will be meaningless. Just like the exercise you should be going through to define your measures (MA), you should also perform a similar exercise to decide on the defect categories. In point of fact, this decision is one of the Measurement and Analysis (MA) steps you should be doing to define your peer review measures. You are really talking about what the CMMI calls derived measures. One set of defect categories MIGHT be process defects, requirements defects, design defects, and interface defects. However, once again, you have to determine which categories support the information needs you should be documenting by following the MA process. Basically, what problem(s) are you trying to solve by performing peer reviews? Once you can clearly answer that question, then you will be able to determine your necessary defect categories.

Satish Kumar provided some addtional information to my response:

Typically IBMs Orthogonal Defect classification is widely used in software projects with minor additions / modifications to defect types. You can get more details about the same from the following link: http://www.research.ibm.com/softeng/ODC/ODC.HTM

The link takes you to IBM's "center for software engineering"site. Browse through the publications to find good information about defect classification.

Note: In your organization's defect types categories, avoid using a type named "Miscellaneous / others". My observation is when we included this type, people had a higher tendency to classify using this category and this is not useful to do any defect analysis.

Thanks & Regards,
Tumu Satish Kumar
SCAMPI Lead Appraiser
CMMI Instructor
Concept QA Labs Pvt. ltd.
www.conceptqalabs.com

What is the Difference Between PPB & PCB?

Please explain the difference between Process Performance Baseline (PPB) and Process Capability Baseline (PCB) as OPP PA talks only about establishment of process performance baselines.

This is a good, but very easy question to answer. First, you should ALWAYS check the CMMI Glossary first before asking a question. Many times you will find the answer to your question in the Glossary. Here are the Glossary definitions for these two terms. I think that these definitions clearly point out the differences.

Process Capability – The range of expected results that can be achieved by following a process.
Process Performance Baseline – A documented characterization of the actual results achieved by following a process, which is used as a benchmark for comparing actual process performance against expected process performance.

Does "interface" in CMMI include user interface ?

In interpreting RD SP2.3 "Identify interface requirements", someone told me that the interfaces can also include man-machine interface, or so-called user interface. But the model says "Interface between functions (or between objects) are identified", at first, I thought that the definition of "interface" in CMMI does not include user interface. But however, in some software development methodologies (e.g. object-oriented), the users are also considered as objects, so, maybe user-interface is also a kind of interface? The same question is also in TS SP2.3 "Design interfaces using criteria", PI SP 2.1 "Review interface descriptions for completeness", and PI SP2.2 "Manage interface."

The interface requirements referred to in Requirements Development (RD) Specific Practice (SP) 2.3, Technical Solution (TS) SP 2.3, and Product Integration (PI) SP2.1 and 2.2 cover ALL interfaces. Keep in mind that you have to do whatever is right for your organization and your projects. If the user interface is important to your project and product, then it should be included in the interfaces covered by the referenced SPs.

CMMI Maturity 3 Appraisal Process

We are planning to go to CMMI 3 level certification. I recently joined in my company. Please tell me the necesary processes and steps.

1. First off, just to be clear, there is no such thing as “CMMI 3 level certification.” An organization is appraised to the CMMI using the SCAMPI A appraisal method to determine either the organization’s Maturity Level or the Capability Level of the organization’s processes. The result of the SCAMPI A is not a certification, but simply a rating of the current Maturity Level or Capability Level.
2. Has your company already achieved Maturity Level 2? Has your company hired a CMMI consultant? Has your company hired an SEI-authorized SCAMPI Lead Appraiser? Has an SEI-authorized instructor provided the SEI Introduction to CMMI class to your company?
3. If the answer to all of these questions is NO, then hire a CMMI consultant and a Lead Appraiser. The Lead Appraiser cannot provide the CMMI consulting. Most Lead Appraisers are also authorized CMMI instructors, so the next step is to train your process group and any people who might be an appraisal team member on the CMMI.
   
4. Perform a Class C appraisal (gap analysis) to identify where you need to focus your CMMI implementation efforts. Use the findings from the Class C to write a process improvement plan, and use the plan to monitor and control your CMMI implementation efforts.
   
5. Implement CMMI Maturity Level 2 FIRST. Once you have established the firm project management foundation of Maturity Level 2, THEN consider implementing Maturity Level 3. If you try to implement BOTH Maturity Level 2 and Maturity Level 3 at the same time, you will encounter difficulties. There is a huge difference between managing projects at Maturity Level 2 and managing projects at Maturity Level 3.
   
6. Once you feel comfortable that you have addressed all of the findings from the Class C and you have had several project cycles to institutionalize the documented processes, then consult with your Lead Appraiser to determine if your organization is ready to conduct a benchmarking SCAMPI A appraisal.
   
7. There will be more training (appraisal team and PIIDs) and activities leading up to the SCAMPI A, but your Lead Appraiser will tell you exactly what you will need to do to prepare for the appraisal.

TS SP 2.2 Establish a Technical Data Package

During our implementation of the Technical Solution (TS) Process Area (PA) we had some discussions on how to implement the Technical Data Package.

Is this Specific Practice (SP) expecting just the design documents with the generic artifacts captured as part of CM plan or SMP deliverables?
OR
Is this SP requiring explicit capture of all the applicable technical data like architecture, data sheets, other technical articles, etc. as a section of the design document?

The quick answer is yes. First go to the CMMI Glossary and look up “technical data package.” There you will find a “shopping list” of the typical contents of the technical data package. The contents of the package are a function of where you are in the development lifecycle. Early in the lifecycle there won’t be a lot of content, but at the end of the lifecycle there should be a lot of information. The organization should decide on what the standard contents of the technical data package should be and then each project will tailor this list for its particular needs.

The purpose of the technical data package is to provide the developer with a comprehensive description of the product or product component as it is developed throughout the lifecycle. You have to decide what the necessary documents and information are to provide a comprehensive description.

Definition of Complexity

While going through some SEI Presentations, I came across a term Design Complexity which was one of the contributing factors for the Delivered Defect Density. As we have chosen this as one of the PPMs in our organization, I would like know how to define the "Design Complexity". I have been searching in Google for the definition, but unable to find it.

I see a problem right from the start in your approach. You have elected to use a term and build a Process Performance Model that has no definition within your organization. Don’t do a literature search to determine what Process Performance Baselines (PPBs) and Process Performance Models (PPMs) to build for your organization. You need to start from the basics. What are your organization’s Quality and Process Performance Objectives (QPPOs)? You need to determine these first. Then you analyze the data in your measurement repository to build PPBs and PPMs that support the QPPOs.

The next step to use Measurement and Analysis (MA) to take the QPPOs, derive the information needs for the QPPOs, and then the measurement specifications that support the information needs and QPPOs. Once you have performed the MA process for your QPPOs, then you will be able to determine if you in fact need to look at Delivered Defect Density and/or Design Complexity. And keep in mind these two terms are just labels. The data you collect and analyze for Delivered Defect Density in one organization may be different from the data for Delivered Defect Density that are collected and analyzed for a different organization. The concepts are important, but going through the MA process will help you define what you need for your organization. Then you can apply whatever label makes sense for you. The MA process will also focus you on what data to analyze to build the PPBs and PPMs that will support your QPPOs.

Obviously Delivered Defect Density and Design Complexity are interesting things to look at, but do they support your organization’s QPPOs? If not, then there is no point in investigating them any further.

Now having said all that, I am surprised that you haven’t been able to locate any information on Design Complexity on the internet. In fact here is an SEI link on this subject http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html and a Wikipedia definition http://en.wikipedia.org/wiki/Cyclomatic_complexity

Tom McCabe has developed a whole collection of complexity measures, which you find out more about here http://www.mccabe.com/

Bottom line, work through the OPP and MA processes first, THEN look for help with definitions and building PPBs and PPMs. Don’t adopt someone else’s PPBs and PPMs just because these worked for them.

Project Artifact Repository

I have a concern about documentation repository related to CMMI.

We develop projects locally but we store deliveries/documents in a customer online system and use customer clear case to store source code. To improve our process to have CMMI, our consultants said that we must have full control over documents, requirements, etc, because if one day our customer says that we don´t have access to the remote network, we will lose all project information, historical data, etc. Is this a correct interpretation of the CMMI?

But it´s very difficult to us have all artifacts in a local repository because they would be duplicated information and rework, it is not so secure to have confidential information locally, and we would require an infrastructure that we do not need.

What do you think about this solution: to have a contract where the customer affirms that they will permit our access to the documents/sources of our projects for X years even if the business relation ends ? X = ? who should be the signer?

Either your CMMI consultants are giving you some incorrect CMMI compliance advice or you are misunderstanding their message. The CMMI says nothing about the location of the CM repository and the ownership of the repository. What your consultants have told you may be good advice, but not necessary to comply with the CMMI. When considering implementing the CMMI, you have to think about what is best for your organization and how you conduct business.

1. It sounds like you are custom building a system for your customer and they own the repository. It all depends upon the contractual stipulations on ownership of the source code etc. In all likelihood, the customer owns everything and therefore it doesn't matter if the customer denies you access to the repository in the future. You don't own the sourcecode.
2. Now if you are also using the customer's repository for storing project artifacts etc. for different customers, then you do have a problem. In this situation, you have made a bad business decision that has a huge risk to the company's future viability. Now you do need a locally owned and managed repository if your customer elects to deny you access to the repository.

I would NOT try to modify your existing contract per your suggestion below. Instead I would "bite the bullet" and purchase a CM tool and create your own repository if #2 applies to your organization. At a minimum, you may just want to mirror the contents of your customer's repository in the event of network outages just so you can continue to perform work without interruption.

Thank you your reply.

I work in an area that has a lot of projects for one big customer, so all of the artifacts and source code are maintained in the customer repository. There are some "internal" artifacts that we do not deliver, and we maintain in a local repository (metrics, audit reports), but the source code and project plan, requirements spec, etc, are all in the customer repository.

So must we store project plan, requirements spec etc in the local repository too?

Given your explanation, it sounds like you have the proper CM structure established. The customer’s project artifacts are stored in a customer repository. I can only foresee one circumstance where the customer would deny you access to their repository and that would be if they gave the work to a different company. And I am assuming that your contract states that the customer owns all of the project artifacts. Therefore you don’t have the rights to the information if they deny you access to the repository.

Now considering all of the information you are placing in your customer’s repository, there may be some information that you may want to retain for your own records. Depending on how your contract is written, you may have to inform your customer that you are retaining copies for internal purposes. And this subset of information you would place in your local repository. Please keep in mind that the CMMI does not require you to also keep a copy in a local repository and that I am not telling you do to so either. You need to evaluate your business need for maintaining copies in a local repository.

Perhaps it may make sense for you to run through the DAR process to determine which customer artifacts, if any, need to be placed in a local repository.

Process Measures

Can someone please suggest what meaures could be taken for the DAR process area for ML3.

Just like any product, project, or process measure, you should be following the Measurement and Analysis (MA) process of defining the information need and measurement specification so you can collect, analyze, and report on measurements that are relevant and have meaning for your organization. After following the MA process you may find that your resulting measurements are the same as other organizations have used, but NOW you know WHY you need to collect, analyze, and report these data. The justification for these data are now driven by your business and projects, NOT simply because you found some examples in a presentation.

If your organization does not have a history of using data to manage processes and/or projects, then you will need a strong position on why you have chosen the specific measures. Most likely you will receive “push back” from people and if the only justification for the measure is from an external presentation, you may find yourself in a losing situation.

For Decision Analysis and Resolution (DAR) process measures, you may want to look at how much effort is spent conducting a DAR, the number of alternative solutions examined, the number of people involved in the DAR, the effectiveness of the decision (was the right decision made after following the process). BUT you must follow the MA process to determine the RIGHT set of process measures for your organization.

The best place to go to for information about MA and process and product measures is the Practical Software & Systems Measurement web site at http://www.psmsc.com/

Appraising Your Own Organization

In writing yesterday's blog entry I had included a statement that a SCAMPI A Lead Appraiser was not allowed to audit his or her organization, which I removed before posting. The SEI requires that the appraisal be done by an external third party. However, when I looked for this requirement in the ARC and MDD I could not find the reference. Through the help of other Lead Appraisers I have since located this requirement. Go to the SEI's Appraisal Policy Changes site and read the 4th bullet http://www.sei.cmu.edu/cmmi/faq/apc-faq.html.

Can a Lead Appraiser in an organization perform an v1.2 appraisal in that organization?

All Class A SCAMPI v1.2 appraisals that will become public record (e.g., announced in a press release or on an organization's Web site, or posted on a published SCAMPI appraisals results Web page) or used in a proposal in response to U.S. Department of Defense requirements must be led by an SEI-authorized SCAMPI Lead Appraiser from an external, third-party organization.

The external, third-party organization can be another SEI Partner organization or a separate business unit from the one containing the appraised organization (e.g., from corporate or from a different division, group, or other organizational business type, which is under separate management).

Lead Appraiser Authorization Steps

What are the requirements for the SEI to "approve" a lead appraiser?

The SEI is the only body allowed to authorize a SCAMPI Lead Appraiser (LA).
The process for becoming a SCAMPI LA is:

1. You must take the SEI’s Intro to CMMI 3-day class, either the current v1.2 class or the v1.2 Upgrade class if you have taken an earlier version.
   
2. You must have an SEI Partner sponsor you as a candidate Lead Appraiser
   
3. You must take the SEI’s 5-day Intermediate CMMI Class v1.2 $2750
   
4. You must participate on at least two SCAMPI A appraisals within the past 24 months
   
5. You must take the SEI’s 5-day SCAMPI LA class $4200
   
6. You must be observed by an SEI Observer leading a SCAMPI A Appraisal
7. The SCAMPI LA renewal requirements can be found here http://www.sei.cmu.edu/appraisal-program/appraiser-communications/scampi-renewal.pdf . There is a three year period in which the LA has to conduct at least one SCAMPI A and accrue at least 3 points

In addition, the prerequisites for becoming a LA are:

• at least ten years of project management and engineering experience in systems or software engineering
• a minimum of two years of experience managing technical personnel
• an advanced degree in a related technical area or equivalent experience

Since there are limited appraisal opportunities within a company, there may not be enough opportunities for the LA to accumulate the necessary 3 points in order to maintain his or her LA credentials.

Frequency for REQM SP 1.5

A system analyst asked me how often he should be checking for inconsistencises between the project plan, work products, and requirements. I told him that he should be checking at least at each milestone, ideally at each week, to verify that the interim work products satisfy the baselined requirements; if he finds any gaps, document them in the defect log, and send it to PM for resolution. If he thinks that the project plan needs to be revised, document that in the defect log too. My answer is based on the fact that the PM reviews the project activities/schedules weekly. Could anyone provide more practical way to do this practice?

In my opinion checking for inconsistencies between the requirements, work products, and project plan each week is overkill. It would be proper to check for inconsistencies at each project milestone and probably each time the requirements, work products, and/or the project plan are updated. By updating the project plan, I mean re-planning or re-baselining the project plan, NOT the regular updating of the project status (e.g. % complete, etc.). If you checked at a higher frequency, most likely you won’t find any inconsistencies and whoever is performing this check will begin to question its business value.

Once an inconsistency is found, the process you described seems reasonable to me.

Interpreting RD SP 1.2

Please help me understand Requirments Development (RD) Specific Practice (SP) 1.2 Develop the Customer Requirements. The Typical Work Products listed for this practice are

1. Customer requirements
2. Customer constraints on the conduct of verification
3. Customer constraints on the conduct of validation

How are work products 2 and 3 different from the first work product?

The expected component for SP 1.2 is “Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements.” There are many different ways to accomplish this Specific Practice as well as there are many different work products that will be created by accomplishing this SP. Your question is regarding the list of Typical Work Products. Typical Work Products are part of the Informative Component and are NEITHER required NOR expected. They are provided to give you some idea or hint, if you need it, as to what types of work product(s) result from transforming needs etc. into customer requirements.

Customer requirements are the most obvious output or work product from this SP. The other two may only be evident or applicable when providing a custom-built product. In this situation the customer may be placing some restrictions on how you perform verification and/or validation. Possibly on the use of certain test facilities, use of certain test data, etc. The specific constraints would be specified by the customer and/or be the result of requirements analysis.

In my opinion, it is not that important to be concerned about the second and third items in the list of Typical Work Products. What is important is performing the practice and creating the list of customer requirements. The proper performance of this practice will determine what the true work products are for your organization. And, in point of fact, you may end up calling all three examples of Typical Work Products “customer requirements.”

The CMMI, A Short History

Mike Konrad recently posted a short history of the CMM and CMMI on the Yahoo CMMI discussion group as he has been involved in both models at the SEI. It is a great summary and worthy of finding a home on this blog.

I will frame my answer from this perspective: I joined the SEI in February 1988 and contributed to the development of both the Software CMM (mostly to SW-CMM V1.0 - less so to 1.1 and 2[A-C]) and CMMI (team lead or co-lead for all DEV versions; a team memgber for ACQ and now, SVC).

Relative to the PPM (1988-1991 approx.), I led the very small empirical team that analyzed those questionnaires (including Manuel Lombardero and Alyson Gabbard Wilson, both statisticians and graduate students at CMU at the time) from 1988-1990. We conducted various item analyses and sponsored an independent study (under the supervision of Jane Siegel) of an AIR (American Institutes for Research in the Behavioral Sciences). Those studies examined construct validity and internal consistency - but much less so on predictive validity (whether retrospective or concurrent).

Where did the data from the analyses come from? Many of the early (pre-Software CMM) appraisals were conducted by the SEI - which is where we got our data for the above-mentioned analyses (under the leadership of Watts, Dave Kitson, Tim Kasse - in the early years).

Some of us (but not me) visited the part of IBM in Houston responsible for developing the onboard software for the Space Shuttle (now part of United Space Alliance), which was an eye opener to some of us at the time relative to what was possible in terms of coordinating the development/maintenance of large software systems to produce high-quality operational software.

These studies and visits influenced the early content of the Software CMM. (Under the leadership of Bill Curtis, who had a simple but powerful vision of making the model behind the questionnaires explicit, easily accessible to the community, and change-request- based - a practice continued with the CMMI.)

Mike Bandor points to our online archive of early articles on CMMI - an excellent suggestion. Also, if you have a copy of the CMMI book handy ("CMMI [Second Edition]: Guidelines for Process Integration and Product Improvement"), you will find on pages 9-21 a series of brief "histories" of CMMI as presented by the following individuals: Watts Humphrey, Mike Phillips, Bob Rassa, Roger Bate, and Bill Peterson - all of whom had significant impact in guiding CMMI to what it is today (less directly so, Watts, but I include him because he helped start it all). Reading these will provide a good digest from multiple perspectives (though less so from other influential individuals, including Jack Ferguson).

In 1994-1995, some influential studies about the Software CMM were published (still available as technical reports at the SEI Web site): "After the Appraisal" (CMU/SEI-95-TR-009) and "Moving On Up" (CMU/SEI-95-TR-008) by Goldenson, Herbsleb, Zubrow, and Hayes. These did examine predictive validity and enablers/disablers of successful process improvement. Personally, I consider these reports an important milestone in the maturation of understanding about process improvement and the means by which to analyze it.

About CMMI:

In the early years (1998-2002), the approach to developing CMMI focused on properly integrating three related best practice efforts: the Software CMM Version 2 Draft C, the EIA 731, and the IPD CMM (as Mike Bandor points out). In those early years, we were striving hard (under Jack Ferguson's leadership) to bring a variety of communities separated-through-different-CMMs together. Before V1.0, we did not quite have it right, but with V1.0, we finally seemed to have a version that could be common to multiple communities.

But the studies continued during those years - e.g., there was a workshop on Technology Change Management that reflected on the ML5 SW- CMM KPAs Technology Change Management and Process Change Management - that led to our re-organizing those two KPAs in CMMI, leading to the Organizational Innovation and Deployment process area that we have come to love :-) today. There were also at least two High Maturity Workshops (led by Mark Paulk and others), that brought together early practitioners in the high maturity practices to try to better understand high maturity practice.

In those early CMMI years, our empirical work looked at interpretation issues (arising from bringing multiple communities together) to try to ensure CMMI was usable/useful to a broad group - and frankly, that we retain a large subset of early SW-CMM adopters. During this time, a number of us, especially Mike Phillips, took advantage of the fact that many conferences/workshops/SPIN meetings would bring folks together who were practitioners and who could influence or champion process improvement, and hosted forums, birds- of-a-feather events to elicit feedback on proposed directions for the next CMMI version. (A practice continued last year with our "Beyond V1.2" series.)

Two years ago, as part of our new focus on understanding high maturity, we again brought together expert practitioners/leaders/champions of high maturity in a variety of organizations for insight and input to better understand how the high maturity practices can be better implemented. Starting last March, Bob Stoddard and Dennis Goldenson have been leading what is planned to be a series of workshops looking at best practices in process performance modeling (invitation only in the initial stages, sorry).

Thus, while the focus of our studies and workshops have evolved somewhat over the years, they have continued. From our first focus on providing a diagnostically-useful questionnaire (based on the PPM) to the current focus on better understanding high maturity, the work and support has grown. The models today embrace a larger set of business operations - now including acquisition and services and over a larger region of the world. But many of the principles we've learned in the early days of the Software CMM persist to this day: models available on-line for free, community-based change-request system to guide further evolution of the product suite, a diagnostic methodology that is a companion to the model, and engagement with or support of the broad community of practitioners through SPIN meetings, conferences, and workshops and the like (both directly by the SEI and its many partners). And: the empirical studies continue to this date, including the recent one on the effectiveness of systems engineering practices and two new ones on state-of-the-practice with regards to measurement and analysis and high maturity - as well as a new one on program performance.

Mike Konrad

How Should I Charge Paid and Unpaid Labor Hours?

I'm developing a process to charge labour costs to internal projects, hopefully supporting our CMMI level 3 objective and specifically Project Monitoring and Control.

For CMMI, I understand that all hours must be captured even unpaid.

My question is: what hourly rate is charged/estimated for the unpaid hours to the internal project. In two large (CMMI) companies I have asked, they render the unpaid hours to the internal Project Manager, at a rate of zero; in essence capturing it as an important metric. But this requires the employee to separately enter the distribution of his/her unpaid hours by project on their timesheet.

My accounting colleagues insist that all hours must have an internal $ charge and this would eliminate the need for the employee to enter a separate "unpaid" line on his timesheet. But I'm concerned that this approach will cause Project Managers to discourage employees entering any unpaid hours as it will eat into their Project budgets without any personal gain to the employee.

There is nothing in the CMMI that I am aware of that requires anyone to track time. What is required is that the organization uses Measurement and Analysis (MA) to examine its information needs and measurement objectives to determine what base measures to collect and what derived measures to compute to develop measurement indicators that the decision makers can use to make decisions. Now when you crank through the MA process, the organization usually realizes that it has to collect some kind of effort information in order to make a decision.

Part of the process for determining the measurement indicator is specifying the units on the indicator: hours, dollars, number of defects, etc. So my first question back to you is why do you need an hourly rate for tracking your ML 3 efforts? Is just tracking hours spent insufficient? Many times the hourly rate is competition sensitive, so project managers do not have access to that information, but they do have access to effort. Also, how does using an hourly rate help with estimating new process improvement efforts and projects? I submit to you that what you really should be tracking is effort and not dollars. Then you don’t have to be concerned about unpaid vs. paid labor costs, just time spent on a task. When the data are all rolled up, then you could apply an average labor rate to convert hours to $ if you are interested in cost numbers.

If you don’t track unpaid hours, then you really are not getting the true picture of how much effort it took to do a job. For example, if the organization states that an employee will only get paid for working a 40 hour week regardless of how much overtime, no one tracks how much time is spent in excess of 40 hours. Therefore, it appears that it only takes 40 hours /week to produce what is actually may be taking 60+ hours/week to produce. Then management may dump more work on top of the employee because it looks like they can handle the additional burden. So it becomes difficult to justify adding staff because you do not have a true picture of how much it costs. And you really don’t have any accurate estimates for the project.

What is IPPD All About?

Would you please explain the basic concepts of IPPD, why, when, where and how to use it? Please try to explain using simple terms not using the cmmi terminology, although down the road that terminology can be referred.

Basically Integrated Process and Product Development (IPPD) is a beefed up version of Intergroup Coordination from the Software CMM and it is intended for use when you assemble a team or teams of people from different groups to work a specific task. For example, if you were to design and build new car, the design team might consist of a propulsion expert, a transmission expert, an interior design expert, an electrical expert, a manufacturing expert, etc. These experts may come from several different departments and have at least two reporting paths, one to the project team for technical issues, one to their home organization for administrative issues, and possibly others. This integrated team is empowered by management to make technical design decisions and there may only be a team lead and not a manager on the team.

Sometimes an organization may use an integrated team for new design, but then the team remains intact for the sustaining engineering phase, which could last for years. In this situation the integrated aspect of the team becomes blurred. According to Mike Phillips/SEI IPPD can apply to almost any type of team as long as you can demonstrate that you are satisfying OPD SG2 and IPM SG3.

Another example of an integrated team is the SEPG. Typically the SEPG exists outside of the normal organizational management and teaming structure. The SEPG is formed by bringing people from different groups together to address the organization’s process improvement needs and objectives.

So, when do you need to use IPPD? When you need to bring together people from different groups to address a specific task or work an issue. If your organization structure is such that the project manager is responsible for both the technical work and the administrative needs of his or her staff, then IPPD probably does not apply. And if you are not being required to demonstrate the IPPD capability by your customers, I would not be concerned about implementing IPPD, unless you feel it is applicable or absolutely necessary.

Applicability of the CMMI to a Volunteer Association

I'm hoping all y'all can help ... one of the volunteer associations that I am involved with is considering developing an organizational assessment model to evaluate project management maturity or competence. I'm looking for some market info/competitive analysis.

1. If you are familiar with CMM and CMMI, do you feel that these models are adequate to assess non-software organizations?
2. Do you have direct, personal experience with any of the existing models? Was it good or bad?
3. If you don't have direct experience, do you have any secondhand information about any of the models?
4. What models are you aware of? What do you know of their strengths
   and weaknesses?
5. Has your current employer expressed any interest in an assessment? Why or why not?
   

First off, let me set some things straight about the CMM and CMMI. The CMM is no longer valid for use as of December 31, 2005. It was replaced by the CMMI. Since its introduction in December 2000, the CMMI has evolved into what the Software Engineering Institute (SEI) is calling a group of constellations. The first constellation is the CMMI for Development (CMMI-DEV). The second constellation is the CMMI for Acquisition (CMMI-ACQ) that was released last Fall. And the third constellation is the CMMI for Services (CMMI-SVC) that will be released towards the end of 2008. There is a core set of 16 Process Areas that are common to all constellations and the core includes the Project Management Process Areas of Requirements Management (REQM), Project Planning (PP), Project Monitoring and Control (PMC), Integrated Project Management (IPM), Risk Management (RSKM), and Quantitative Project Management (QPM).

REQM, PP, PMC, IPM, RSKM, and QPM apply to any type of organization, not just software organizations. The CMMI-DEV is for software engineering, hardware engineering, and/or systems engineering organizations. The CMMI-ACQ is for organizations who have outsourced their development and/or maintenance work and are just managing their subcontractors. The CMMI-SVC is for organizations who provide services.

REQM, PP, and PMC are the basic project management Process Areas (Maturity Level 2). IPM and RSKM build on REQM, PP, and PMC to enable the Project Manager to proactively manage the project (Maturity Level 3). And QPM builds on REQM, PP, PMC, IPM, and RSKM to allow the Project Manager to quantitatively manage the project and statistically manage selected sub-processes to achieve the organization’s and project’s quality and process performance objectives.

It might take a little bit of thought and discussion to determine how these Process Areas can be used in a volunteer association, but using the CMMI would be a great place to start.

Motivate and Facilitate buy-in

What are some different ways and means of making the process implementation look easy to the implementers (like creating high level architecture of all the process interactions, providing templates with dummy data, etc...) to facilitate buy-in?

There are two basic audiences for the process documentation:

1. the process engineers (those who define and document the processes) and
2. the practitioners (those who have to follow the processes)

The process engineers are very interested in the overall process architecture, inputs/outputs, interfaces, etc. The practitioners just want to know what they need to get their specific jobs done. When you read the purpose of OPD, one of the key words is establishing and maintaining a USABLE set of processes and process assets. Therefore, in order for your processes and process assets to be usable by the practitioners, it doesn’t help them to provide all the process architecture, inputs/outputs, interfaces, etc. that the process engineers need and want. The simplest approach that I have seen for the practitioners is to provide a “swim lane” process flow chart. Then it is very easy for the practitioner to see where they fit into the process. Also providing good, as well as bad, examples of how a template or checklist should be filled out is also a good idea.

But keep in mind, that an approach that works in one organization for achieving “buy-in” may not work in another. You really need to work with the organization and jointly determine the best method for the organization. If most of the practitioners, for example, do not relate to visual process flows, then the “swim lane” approach I mentioned above may not work.

Individual benefits are highly variable. You may gain some insight into dealing with different people by reading my presentation on Managing Cultural Change. I have posted it in several locations on the web. You can access it through my web site www.ppqc.net or at SlideShare http://www.slideshare.net/HenrySchneider/managing-change-324890/

ML 2/ML 3 Measurement Objectives

For a Maturity Level 3 organization , is it acceptable if the organization sets its process performance objectives qualitatively? For example reduce testing cycle time , improve productivity, etc. and in OPF SG1, one of sub-practices states that process performance objectives may be expressed either quantitatively or qualitatively. Also would you please explain this clarification linking to ML2- MA - SP 1.1 - Establish measurement objective?

These are good questions, but the best way to receive a decent understanding of the concepts it to attend the SEI’s Introduction to the CMMI class. Intro to CMMI course description Brief answers, such as mine in this blog, will probably only raise more questions that would be better addressed in a classroom setting.

1. Only for High Maturity organizations (ML 4 and 5) is there an expectation for quantitatively setting process performance objectives. It is acceptable at ML 3 for qualitative objectives. But to fully understand this distinction you really require a good discussion on the expectations for each Maturity Level, which you would receive in the Intro to CMMI class.
   
2. A measurement objective is different from a process performance objective. The measurement objectives are the purposes for which measurement and analysis is performed and also specify what kinds of actions may be taken as a result of data analyses. In order to determine the measurement objectives, you first have to describe the information needs. An information need is an insight necessary to manage objectives, goals, issues, risks, and problems. The measurement objective is derived from the information need and it is a statement about what should be measured in order to satisfy the information need. For example, the project manager or other decision maker concerned with allocating budget and associated resources to a task may believe that productivity is related to the type of task being performed. Increasing productivity is then the measurement objective that addresses the defined information need. Determining productivity then requires that entities such as the product and the process be measured. There are many ways that productivity can be computed, but the measurement objective is unaffected by the different methods.

To fully understand these concepts you should take a class on Measurement and Analysis or Practical Software Measurement. Trying to explain these concepts in a paragraph or two does not do the subject justice.

Stakeholder Involvement Question

Would you please explain the differences between monitoring stakeholder involvement (PMC) and managing stakeholder involvement (IPM)?

The difference is, at the core, the difference between a Maturity Level 2 organization and a Maturity Level 3 organization.

Monitoring stakeholder involvement basically means watching the involvement of the stakeholders. If a stakeholder is supposed to perform some activity or attend a meeting, did the stakeholder in fact do these things? And if the stakeholder does not perform their activity, did this lack result in a significant deviation in project performance? If so, then the Project Manager would take a corrective action to address the deviation.

Managing stakeholder involvement builds on the monitoring aspect by being proactive in ensuring that the stakeholder does perform their agreed to and assigned activities. For example, if a stakeholder is supposed to attend a meeting, managing their involvement might be to ensure that they are invited to the meeting, to ensure that they acknowledged the invitation, to ensure that they sent an appropriate substitute to the meeting if he or she could not attend, and to ensure that the stakeholder actively participated in the meeting to fulfill their role and responsibility as opposed to merely attending the meeting. If the Project Manager determines through these checks and balances that the stakeholder is not involved as agreed to, then the Project Manager does the necessary actions to ensure that the lack of stakeholder involvement is mitigated in the meeting, for example.

Please read my other blog "Query on ML 3 and ML 4" for a brief description of the characteristics of each Maturity Level.