What is Meant by a Line of Business?

In a CMMI 1.2 Appraisal there is a requirement that practices in projects and functions within the Organisational Unit must be understood and identified ( e.g. Lines of Business, Disciplines, Effort Types, Project Types etc). What do lines of Business and Effort Types mean?

It might be easier to understand the concept of a LIne of Business through an illustrative example.

A small organization would normally produce one type of product, say a voice recognition software package. This package may be installed on a variety of platforms, but it is the same package. In this situation the company or organization has one Line of Business.

In a large company or corporation, there usually is a number of different types of products produced for different purposes, customer types, etc. For example, an automotive company may have several divisions: car, truck, van, commercial vehicle, etc. Each division represents a different Line of Business. Or a financial company may have several divisions: banking, insurance, investments, etc. Again, each division is a different Line of Business. Typically each Line of Business has different goals and objectives, customers, processes, etc. Another example of a Line of Business is the application domain. It is important to note the different Lines of Business because it is extremely challenging, if not impossible, to conduct a single SCAMPI A appraisal across multiple Lines of Business, especially for Maturity Level 3 and up.

If you read the Method Description Document section 1.1.3 Implementation Guidance, it defines the terms you are asking about:

• application domains (or lines of business)
• geographical breadth
• disciplines (e.g., systems engineering, software engineering, or hardware engineering)
• effort types (e.g., development, maintenance, or services)
• project types (e.g., legacy or new development)
• customer types (e.g., commercial or government agency)
• lifecycle models in use within the organization (e.g., spiral, evolutionary, waterfall, or incremental)

So effort type refers to the type of work: new development, sustaining engineering or maintenance, or services.

Criteria for selection of Focus and Non Focus projects for CMMI 1.2 Assessment

What are the criteria used to determine project selection for CMMI 1.2 Appraisals? I understand they are normally termed as Focus and Non Focus projects.

1. Based on size of organization ( count of projects + resources ) how many projects need to be selected? Can someone specify this as a number of projects or percentage of projects required?
2. We have categorised projects as Development + Maintenance + Testing - so ideally how many projects count or percentage wise under each Project Type would need to be selected?
3. What is the criteria for selecting a project as a focus project? I have read and heard that one of the factors could be presence of all Software Development Lifecycle (SDLC) phases in that project, contribution of data points, it should be an on-going project at time of assessment etc.

Here is the criteria for project selection extracted from section 1.1.3 of the Method Description Document (MDD) v1.2:

Sample projects and support groups selected to form the organizational scope (i.e., the combination of focus and non-focus projects and support functions) must represent all critical factors identified for the organizational unit to which the results will be attributed. The coverage of the organizational critical factors provided by these sample projects and support groups in the organizational scope in relation to the organizational unit must be documented, in quantitative terms, in the appraisal input and ADS.

Each sample project or support group in the planned organizational scope of the appraisal must be one of the three types listed below:

• Focus projects must provide objective evidence for every PA within the model scope of the appraisal which addresses model practices applicable to those projects.
• Non-focus projects must provide objective evidence for one or more PAs within the model scope of the appraisal which address practices performed on projects.
• Support functions must provide objective evidence for practices within the model scope of the appraisal that address organizational infrastructure or functions.

In appraisals where the reference model scope includes any project-related PA, the organizational scope must include at least one focus project. If the organizational unit includes more than 3 projects, then the organizational scope must include sufficient focus projects and non-focus projects to generate at least 3 instances of each practice in each project-related PA in the model scope of the appraisal.

Projects, categories, or groups/functions that are specifically excluded from the appraisal must be identified in the appraisal input and in the ADS as well as the justification for their exclusion. This identification includes legacy projects not using current organizational processes and projects waived from using current organizational processes. As needed, the appraisal team may seek clarification or data from other projects or support functions within the organizational unit. These projects or support functions must also be identified in the ADS.

What this means is that you must have at least one focus project. A focus project is a project that has evidence for every practice and Process Area (PA) in the appraisal scope. In order for that to be the case, that means the project is either already completed or very close to completion. A non-focus project is a project that does NOT have evidence for every practice and PA in the appraisal scope. Meaning a non-focus project is either a project that has recently started or a project that began before the processes were deployed and only has evidence for a subset of the practices.

Keep in mind that some PAs are organization level PAs while others are project-related. For the Organization PAs (e.g., OPF, OPD, OT, etc.) you only have to provide one instance of evidence. So the issue of number of projects only applies to the project-related PAs (e.g., PP, PMC, IPM, REQM, RD, etc.). Therefore, according to the MDD, if the organization has more than three projects, you have provide three instances of evidence for each practice. You could choose to supply three focus projects, two focus projects and multiple non-focus projects, or one focus project and multiple non-focus projects.

Another aspect of evidence that you must comply with is that you have to provide Direct Evidence for every practice and PA in the scope of the appraisal. But you don’t not have to supply Indirect Evidence for every practice and PA. Your Lead Appraiser can explain to you the one row, one column and 50% rules. As a risk mitigation, most of my clients choose to provide 100% coverage for both Direct and Indirect Evidence.

PMI PMBOK - CMMI Process Map

I often meet managers trained in the PMBOK and are certified PMPs (Project Management Professionals) who do not know enough about the CMMI but continue to press for using PMBOK as a guide in improving IT project management processes. I have studied the PMBOK and believe that the CMMI is a better option for managing IT projects. I can help PMPs understand my views better if I can show a map of processes in both the PMBOK and CMMI processes and then showing additional features of the CMMI helpful in managing IT projects. I would appreciate it if you could lead me to any such study where the two are mapped, something similar to the CMMI - ISO 9001:2000 map.

Try this link from the SEI http://www.dtic.mil/ndia/2005cmmi/thursday/sherer.pdf, it will pull up a presentation that compares and contrasts the CMMI and PMBOK. In addition, this page http://www.sei.cmu.edu/cmmi/adoption/comparisons.html provides links to a number of comparisons between the CMMI and other models and standards.

Full Time Resources for Implementing the CMMI

I have been asked to estimate the number of full time resources required by my company to facilitate its drive to Maturity Level 3 PM, SYS, SW, HW and ACQ. Is there any documentation or published information that will help in putting together a robust estimate of resources required?

First and foremost the driving factor for estimating the number of full time resources needed to implement the CMMI is the size of the organization. Over time we have seen that it takes 3 – 5% of the organization to perform PPQA, 3- 5 % of the organization to perform CM, and 3 – 5% of the organization to perform the necessary CMMI implementation activities.

So, if your organization is about 20 – 30 people, then you may only need one full time resource. However, if your organization is about 100 people, then you may need 3 to 5 full time resources.

Other factors contributing to this estimate is how strong a ML 2 foundation is already in place and how much of what you currently have in place is at ML 3. Documenting the processes and procedures is the easy part, and it can be done by a small core group. The larger task is deploying the new processes and process assets and having people use them to change how they approach their jobs.

Interview Questions to Hire a CMMI Expert

We are implementing the CMMI within our organization and are looking to hire someone to help us achieve this goal. We don't necessarily need a certified Lead Appraiser as of yet, but would like to hire someone with CMMI experience and who may beinterested in becoming a Lead Appriaser. I have a couple of internal candidates that are not Lead Appraisers, but have had CMMI experience (according to their resumes anyhow). What would be some good questions to ask them in an interview to gauge how much experience they truly have? I appreciate any help I can get with this.

One word of caution first. It may not be in your best interests to hire someone who wants to become a Lead Appraiser. There usually aren’t enough internal appraisal opportunities for a candidate Lead Appraiser to get the minimum experience or to maintain their Lead Appraiser credentials, so the person would have to look for appraisal work outside of your organization or company.

Here are some questions that I would ask a candidate for a CMMI position:

1. Have you taken the SEI’s 3-day Introduction to CMMI class? If yes, when did you take the class? Who was your instructor?
2. Have you participated as an appraisal team member? If yes, how many times? What were your duties? What was the scope of the appraisal (Maturity Level)? Who was the Lead Appraiser? What would the Lead Appraiser say about your CMMI capabilities and performance on the appraisal team?
3. Have you helped implement the CMMI in an organization?
4. How long have you been working with the CMMI?
5. Please compare and contrast Capability Level vs. Maturity Level
6. What is the only Process Area that can be categorized as Not Applicable? SAM
7. Have you prepared a PIID? If yes, what was the most difficult task and why?
8. How many years of project management experience do you have?
9. How many years of engineering experience do you have?
10. What is your favorite Process Area and why?

Accepting Items for Use in the Process Asset Library

The Configurable Items (CI) in our organization are controlled CIs [Any Project Related Artifact (PRA) received from any source, on which the project team does not exercise any control]. For example, documents obtained from the client or reference technical material. Documents of external origin, such as the ISO Standard, SEI CMMI, etc. are controlled and managed.

Any Project Related Artifact (PRA) is created and managed by the project team and the changing of which does not need any explicit change request, for example, Software Configuration Plan, Review Plan, Audit Plans etc. A baselined CI is any PRA that is managed by the project team and changing it needs an explicit change request for example: Project Plan, SRS ( Software Requirements Specifications) etc.

I am the lead responsible for building our Process Asset Library (PAL) and would appreciate guidelines for what could be the mandatory or acceptable criteria by which the baselined CIs would be updated in the PAL for use by other groups in the organization. I feel, it would certainly help if the criteria could be defined so that people in the organization would know the parameters based on which they could help contribute or share best practices, lessons learned, and any other artifacts in the Process Asset Library for use by anyone in the organization.

I really hate to do this to you, but the answer to your question is it depends upon your needs. Your organization has to decide for itself the acceptance criteria for PAL items. The CMMI does not mandate any criteria for accepting input to the PAL.

From a practical standpoint, you want to encourage the practitioners, project teams, and managers to submit everything of use to you for consideration as candidate PAL items. As the lead responsible for building the PAL, you might consider reviewing each submitted item to determine if you want it in the PAL. I always advocate that in addition to providing a template in the PAL for use by the project teams that you also provide an example of how you want the template to be correctly filled out. Providing a good example can be problematic sometimes. So you would have to review each submitted artifact of the completed template to determine if you want to post that as an example in the PAL. Other project related information may need to be sanitized or normalized by you before you post it to the PAL for use by existing or new projects.

If someone wanted to share a best practice or make a process improvement suggestion, then you should have a process in place for allowing someone to submit a process change. Many companies use their established product/project Change Request system as the tool for submitting Process Change Requests.

The Bottom Line is that you should encourage and accept all data, information, and input as candidate PAL items. Then the Software Engineering Process Group (SEPG), Engineering Process Group (EPG), or Process Group (PG) reviews the input for inclusion in the PAL.

Supplier Agreement Management Question

I have a question related to Supplier Agreement Management (SAM) SP 2.2 - Monitor Selected Supplier Processes. What is the basic intent of this practice and in what scenario does it fit in? It specifies "...situations of tight alignment between processes implemented by the supplier and those of the project..." - which is normally not the case in most (small) projects (as I know). I hope here we are not including "Acceptance" and "Transition" as aligned processes. Also it seems redundant to me with SP 2.1 - Execute the Supplier Agreement because in the contract/ SOW, it is usually mentioned how the supplier needs to monitor his processes (frequency to perform process audits etc.) and the frequency/condition when the customer may ask for a process audit/assessment. So doesn't executing the Supplier agreement covers these two practices?

I can see where you might have some confusion concerning these two SAM practices. SAM SP 2.1 says “Perform activities with the supplier as specified in the supplier agreement.” And your confusion comes about from sub-practice 1 “Monitor supplier progress and performance (schedule, effort, cost, and technical performance) as defined in the supplier agreement.” In essence SAM SP 2.1 is all about performing Project Monitoring and Control (PMC) over the supplier, which should be spelled out in the supplier agreement. You are basically acting as the Project Manager for the supplier by monitoring and controlling their project and technical performance. There is no intent to perform any Process and Product Quality Assurance (PPQA) audits or activities to support this practice.

In contrast SAM SP 2.2 says “Select, monitor, and analyze processes used by the supplier.” This practice is where you perform PPQA activities (process audits and work product audits) on selected supplier processes that are critical to the success of your project and business. Again, this ability to perform PPQA on the supplier must be specified in the supplier agreement. But you want to have the freedom to select any supplier process, so don’t indicate specific processes in the supplier agreement. For example you might decide to monitor and analyze how your supplier performs peer reviews or how they manage their requirements. If you have your supplier doing small projects (less than a month in duration) you may not have many opportunities to perform PPQA on a given supplier project. This situation is the same as when you have small projects done completely in house. There is no hope or expectation that you will be able to perform PPQA activities on every small project.

Look back at my blog on PPQA Audit Frequency http://ppqc.blogspot.com/2008/05/ppqa-audit-frequency.html for a simple way to adjust the frequency of the PPQA audits based on the quality issues discovered. You can use this same approach to determine the frequency of conducting PPQA activities on your supplier, assuming that you supplier regularly performs small projects for you.

Is CMMI only for Software Companies?

Can the CMMI be applied only for software developments companies, or can systems integration companies also derive benefit from it ? What I mean by "systems integration companies" are organizations who engage in selling IT solutions including sofware and hardware as a solution.

The CMMI is not a software only model. By the end of this year, the SEI will have released three CMMI constellations: CMMI for Development, CMMI for Acquisition, and CMMI for Services. The Development and Acquisition constellations are currently available, the Services constellation is due to be released this Fall. The CMMI for Development (CMMI-DEV) covers hardware, software, and systems engineering and so it will apply to systems integration companies as you have defined the term.

Defect Removal Efficiency (DRE)

I am a Defect Prevention team member in our CMMI Maturity Level 5 company. We are trying to plot the Defect Removal Efficiency (DRE) metric in our projects. I have a few questions:

1. Our DRE is based on phase level defect injection and detection concepts. If we go closely by the definition of the phase "testing/QA", bugs should not be injected in testing phase, as this is detection activity. If not then any examples can be useful for me to understand.
2. Can a common DRE format can be utilized for all kinds of projects as in sustaining engineering, maintenance, development and pure testing? Specifically what do to we do for testing or pure QA type of projects?
3. DRE is scoped for defects leaked by QA and reached to customer. How we can address defects in other lifecycle phases i.e. deployment and post production activities?

These are very interesting questions. Here is my two cents worth:

1. Your assumption that testing/QA phase is not a source of defects may or may not be a good assumption. Test cases can be a source of defects as well as the product. A test case that does not find any defects may in fact itself be defective. The purpose of a test case is to find defects in the product. In this case there might be undetected defects slipping through the test cases or erroneous test results. On the other hand testing can sometimes identify defects in the product that may not actually exist. I encountered this situation years ago in a small software development company when they hired a new tester. The company had no documented procedures and testing criteria. So the new tester did the best job he could under these circumstances and based his testing on the published User’s Manual. He proceeded to find tons of defects in the product. That got management’s attention until they realized that all of these “new” defects had been previously addressed. It turned out that the tester was unwittingly using an obsolete version of the User’s Manual. So that mistake invalidated all of his test results. Either way, each of these two situations would contaminate your DRE calculations. Therefore, I would be very careful in making the assumption that the testing/QA phase is not a source of defects, unless you have thoroughly peer reviewed each test case and validated each test result to ensure that what I have described has not happened.
   
2. In the context of the CMMI, QA usually means for most of us Lead Appraisers PPQA – conducting process audits and work product audits, not testing. So I am not clear as to the distinction you are trying to make between testing and "pure QA". It appears that in your organization they may be two aspects of the same activity. Personally, I think that you could use a common DRE format across all types of projects. However, it doesn’t make sense to mix the data for the various projects. So you will have to be very careful to keep the data segregated, otherwise you won’t be able to draw the proper conclusions. For example, the DRE for new development will be different than for sustaining engineering, different from a testing project, etc.
   
3. I think that you answered your question in your statement of the scope. Just change the definition of the scope for your DRE. You could define the DRE scope on a lifecycle phase by phase basis and then you would be able to measure it for deployment and post-production activities. You could also define a DRE for the entire project lifecycle as well.

SEI Published Appraisal Results

I have a question related to the published data in SEI web site: http://www.sei.cmu.edu/appraisal-program/profile/pdf/CMMI/2008MarCMMI.pdf Process Maturity Profile by All Reporting Organizations (Page 5):

1. 1.5% or the reporting organizations are (Initial - Maturity Level 1) rating. How is a Maturity Level 1 rating achieved?
2. Also, 8% of the reporting organizations indicate that a Maturity Level is Not Given. What does ‘Not Given’ mean…? Level 0 ?

In my understanding, Maturity Level is related to the Staged representation and can have
rating from ML 2 - 5.

It is great to see and hear that people are actually looking at this information and asking questions about how to interpret the data. You are on your way to understanding Measurement and Analysis!

To answer your first question, how is Maturity Level 1 provided? Obviously, an organization does not conduct a SCAMPI A appraisal to confirm that they are Maturity Level 1. So what happens in this case is the scope of the SCAMPI A appraisal is Maturity Level 2, 3, 4, or 5. But what happens is during the appraisal a serious goal impacting weakness in a Maturity Level 2 Process Area is found by the appraisal team. By the rules of the SCAMPI method then the resulting Maturity Level is 1. Since the SCAMPI A results must be submitted to the SEI, a rating of Maturity Level 1 appears. It doesn’t happen that often because most organizations take the appropriate steps to be prepared to achieve their target Maturity Level. That is why 1.5% of the reported results are for Maturity Level 1.

The Not Given category means that the organization did not report its resulting Maturity Level rating. I would hazard a guess that it probably means that they had successfully achieved Maturity Level 1. There is no Maturity Level 0, despite what many chaotic organizations say they are when first encountering the CMMI.

A Question About Estimation

I'm a bit confused about what the CMMI requires for estimation. Is it valid for us to define our process as simple as guessing? Could we use something similar to Planning Poker or other similar agile techniques? The problem is that we've been told we need to have a quantitative and repeatable process for estimating in order to meet Project Planning (PP) SP 1.4 "Estimate the project effort and cost for the work products and tasks based on estimation rational." But in reality we don't have historical data and many of us think estimating is subjective anyway.

When you start implementing Maturity Level 2 there is no expectation that you have any historical data for estimating. The best you can do at that point is guess, SWAG, or use engineering judgment. One of the characteristics of being a Maturity Level 2 organization is that you are learning. You are learning what it means to estimate a project. You are learning how to improve your estimates so that over time you will be able to produce accurate estimates to build the foundation to allow the organization to move to Maturity Level 3. So, by the time you are ready for a Maturity Level 2 SCAMPI A appraisal, the expectation is that you have a repeatable estimation process (repeatability is at the core of Maturity Level 2) that is based on historical project data. Estimation is not difficult, it just takes a little bit of brain power and being systematic in your approach. One of the purposes of achieving Maturity Level 2 is moving from being subjective in estimation to being objective. If you have people that believe estimation is subjective, then I am afraid that you are still operating as a Maturity Level 1 organization.

Delivering Process Training

Training plays a major role in the implementation of any process in the organization. The way it is done and the examples/illustrations explained during the session definitely helps the employees understands the need for such model implementation for process improvement. Can some videos, pictures, jokes work out well in a typical CMMI or QMS training session. How can the effectiveness of the training be improved based on these methods or innovative techniques? How do you cover the crowd?

There is no prescribed method in the CMMI for how you train people. Everything you mention in your note sounds like great ideas for getting the message out. The only caution I have is to be sensitive to your audience. A joke that works in one setting may not work in another. A good instructor should be able to read the audience and adjust his or her teaching style appropriately to allow for differences.

So whatever you do to liven up what can be some very dry information is a good idea. You may want to use a video or movie clip that illustrates some important process concept. Go for it! It will make the class much more enjoyable for all concerned.

I recently read a very good book on developing and delivering inspirational messages called “Fire Them Up!” by Carmine Gallo http://www.carminegallo.com/. The book presents seven simple ways to inspire colleagues, customers, and clients. The seven methods can be summarized as igniting your enthusiasm, navigating the way, selling the benefit, painting a picture, inviting participation, reinforcing an optimistic outlook, and encouraging people to reach their potential.

Technical Query vs. Technical Issue

What is the difference between a technical query and a technical issue? And, how do you track them when the projects are maintaning all their queries and issues in email?

In my mind, this is how I distinguish between a technical query and a technical issue. The design team receives a set of requirements to implement. When analyzing the requirements, they encounter a vague or poorly worded requirement such as “the product must be user friendly.” A technical query would be a question back to the requirements provider asking him or her what is meant by this statement. Or a technical query might be a question asking for more detailed technical information so the design team can make the proper design decisions. In contrast a technical issue arises when there is a conflict between requirements, between new or modified requirements and the existing design, between the requirements and the product, several possible design alternatives, etc. A technical issue may require a trade study or research in order to provide the correct information to resolve the issue, basically invoking Decision Analysis and Resolution (DAR).

As far as tracking this information, that is up to the organization to decide on a method that best fits their business practices. Queries could be tracked via email. But I would think a better method would be to include the queries with the requirements so you would capture the history and discussion of any unclear requirements in one location. When you think about it, technical queries are part of the knowledge capture for understanding the requirements. For tracking technical issues, you can perform this action in a variety of ways. Many organizations track all issues the same way in an Issues Log or Issues Tracking System. There are many off the shelf tracking systems that basically have the same functionality.

Understanding How Project Planning Evolves from ML 3 to ML 5

The primary difference between project planning at Maturity Level 3 (ML 3) and Maturity Level 5 (ML 5) is how you construct the project’s defined processes. At ML 3 a new project starts from the organization’s set of standard processes and applies the appropriate tailoring criteria or guidelines for the project, based on the project requirements. At Maturity Level 4 (ML 4) and ML 5 a new project first has to define what its quality and process performance objectives are based on the organization’s quality and process performance objectives (QPPOs). Then the project looks at the organization’s set of standard processes and selects the processes or sub-processes that are capable of being quantitatively and statistically managed to achieve the project’s QPPOs using the established Process Performance Baselines and Process Performance Models. These processes and sub-processes are selected based on historical stability and capability data along with the appropriate tailoring guidelines and criteria to construct the project’s defined process.

Understanding Causal Analysis and Resolution (CAR)

In the context of the CMMI, CAR is a Maturity Level 5 Process Area. You can perform CAR qualitatively at lower Maturity Levels, but you cannot realize the full benefits of CAR until you have stable processes and statistically understand the process capabilities. Let’s step through the practices one-by-one and talk about what they mean from a quantitative perspective;

SP 1.1 Select the defects and other problems for analysis.
You can perform this practice very simply and qualitatively just by having a gut feel that something is wrong and you want to investigate its causes. However, you should be using data and statistical tools such as Pareto analysis, histograms, or process capability analysis to determine which defects to analyze.

SP 1.2 Perform causal analysis of selected defects and other problems and propose actions to address them.
You can perform this practice qualitatively just by meeting with those people responsible for performing the process, using tools like cause-and-effect (fishbone) diagrams or check sheets. From a Maturity Level 5 perspective, you may have criteria that states you perform causal analysis when a stable process does not quantitatively meet its specified quality and process performance objective.

SP 2.1 Implement the selected action proposals that were developed in causal analysis.
Again it is possible to perform this practice qualitatively simply by implementing an action as the result of the cause-and-effect diagram. From a Maturity Level 5 perspective, you may be designing an experiment to see if the proposed action will have the desired quantitative results.

SP 2.2 Evaluate the effect of the changes on process performance.
This practice will be difficult to perform qualitatively. The intent of this practice is to measure the effects of the change on the process performance, which can only be done accurately if you have stable and capable processes in place and you are using quantitative methods to manage these processes.

SP 2.3 Record causal analysis and resolution data for use across the projects and organization.
If you are performing qualitative causal analysis you may not have any data to record other than results from the cause-and-effect diagram and rationale for the change. From a Maturity Level 5 perspective you might have data on the defects and other problems you analyzed and measures of the changes to the process performance resulting from the causal analysis.

Help Understanding Process Performance Models

To better understand the concept of a Process Performance Model (PPM), it helps to have a little background about both Process Performance Baselines (PPBs) and PPMs. Both are based on the historical process data that the organization has been collected and analyzing. The CMMI definition of a PPB is 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. In other words, the historical process data, when analyzed, will indicate how the process has behaved in the past and the expected range of the process performance. As an illustrative example consider hurricanes. Based on over 100 years of weather data, we know where hurricanes usually form and where they travel, either up the east coast of the US or into the Caribbean and Gulf of Mexico.

These data define an envelope that contains the expected range of data based on historical information. By statistically analyzing these data we can compute the central line and a set of control limits for the type of control chart that is appropriate for the data being analyzed: p chart, np chart, c chart, or u chart.

The CMMI definition of PPM is a description of the relationships among attributes of a process and its work products that are developed from historical process-performance data and calibrated using collected process and product measures from the project and that are used to predict results to be achieved by following a process. So by further analyzing the historical data, it is possible to derive PPMs that can be used to predict future process performance based on current process performance. The model may be as simple as merely extrapolating a straight line, or as sophisticated as running Monte Carlo simulations of the process if your model is based on a number of independent variables. Going back to the hurricane analogy there are a number of predictive hurricane models that the weather service uses to predict the ground track of the eye and where it might make landfall. Whereas the hurricane PPB is based on the statistics of ground track data from past hurricanes, the hurricane PPMs use that information plus additional parameters such as speed, barometric pressure, other nearby weather systems, high pressures, and fronts to predict the storm’s ground track. Every time there is a new set of storm data collected, the meteorologists revise their predictions by running the data through the PPMs. In addition, like the hurricane example, you may have more than one PPM because of the inherent complexity of the process you are trying to model. Sometimes the models agree fairly closely, as in the example shown. Other times there may be a big variance.

So, to answer your question, the PPB is the control chart, central line and the two control limits UCL and LCL. When you start plotting the actual data on the control chart, you can use the PPM to predict if the current data will violate the control limits in the future.

To gain a better understanding of a PPM you have to also understand what is meant by dependent and independent variables. In mathematical terms, an independent variable is an input to a function and a dependent variable is an output of the function. Thus if we have a function f(x), then x is the independent variable, and f(x) is the dependent variable. The dependent variable depends on the independent variables; hence the names.

In the design of experiments, independent variables are those whose values are controlled or selected by the person experimenting (experimenter) to determine its relationship to an observed phenomenon (the dependent variable). In such an experiment, an attempt is made to find evidence that the values of the independent variable determine the values of the dependent variable (that which is being measured). The independent variable can be changed as required, and its values do not represent a problem requiring explanation in an analysis, but are taken simply as given. The dependent variable on the other hand, usually cannot be directly controlled.

Controlled variables are also important to identify in experiments. They are the variables that are kept constant to prevent their influence on the effect of the independent variable on the dependent. Every experiment has a controlling variable, and it is necessary to not change it, or the results of the experiment won't be valid.

In other words:

The independent variable answers the question "What do I change?"
The dependent variable answers the question "What do I observe?"
The controlled variable answers the question "What do I keep the same?"

Back to the hurricane analogy, the independent variable is the storm’s current position. The dependent variable is the predicted ground track. The controlled variables are the current storm attributes that are assumed to remain constant for the next period of time between observations.

Therefore, a PPM is a predictive model based on one or more independent variables that can be used to predict an outcome (dependent variable). It is a mathematical model built using empirical process performance data.

In order to build a PPM, you have to use statistical and other analytic techniques to examine the historical data to construct a model that you can use to predict future states. Initially the PPM may not be very accurate. But each time you use a process you should incorporate the resulting process data into the model to improve its accuracy for its next use. A simple example is the estimation model used by the project manager. When first starting to use a project estimation model, the predicted results probably will not be very accurate. But collecting the project estimates and incorporating them into the model, the ability to predict accurately will improve over time.