Cut Off Time for Updating Documents Prior to a SCAMPI

What is the normal time-frame an organization is allowed to continue making changes to their documentation prior to a SCAMPI?

There is no hard and fast rule for this practice. You need to work this time frame out with your Lead Appraiser to see what he or she is comfortable with. But, think about what you are asking for a minute. Are you talking about process changes? Changes to artifacts? Or both?

If you are talking about process changes, then you need to consider the purpose of the SCAMPI. One of the jobs of the appraisal team is to determine the amount of institutionalization. In order to determine the degree of institutionalization (GGs and GPs), changes to the processes and procedures need to be minimized so there is sufficient time for institutionalization and to collect and present the proper Direct and Indirect Evidence. To be on the safe side and mitigate this risk, organizations may decide to have no process changes for six months before the SCAMPI.

If you are talking about the artifacts, then you need to keep in mind the definition of Focus and Non-Focus Projects and work with your Lead Appraiser to determine your evidence needs. In my experience, my clients have taken the risk mitigation approach of “freezing” the evidence about a month before the Readiness Review to build the PIIDs and then only allow changes after that point if there are weaknesses in the PIIDs that need to be addressed before the SCAMPI.

Please keep in mind that I am not advocating freezing the processes 6 months before an appraisal, it just has been my experience that as a risk mitigation some clients have held off making changes until after their appraisal. This behavior is typical for a first time SCAMPI A in a risk averse organization who wants to do everything possible to have a successful SCAMPI A. After all the CMMI is a set of process improvement guidelines, so I as a Lead Appraiser would expect to see evidence of continuous process improvement. But the org has to take an intelligent approach when rolling out new changes. The workforce gets frustrated with chasing a moving target if the processes and assets are frequently changing, i.e. major updates.

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.

What is the Difference Between OPF SP 3.1 and SP 3.2?

There are some fine shades of distinction here between these two Specific Practices that can cause some confusion. Both Specific Practices concern deployment. OPF SP 3.1 covers the deployment of process assets and OPF SP 3.2 covers the deployment of the standard processes. The CMMI defines process asset as “Anything that the organization considers useful in attaining the goals of a process area.” And organizational process assets as “Artifacts that relate to describing, implementing, and improving processes.” In other words, process assets are those things that help or enable you to follow the process. Process assets include the policies, measurements, process descriptions, templates, checklists, etc. It is always best to consult the CMMI Glossary for definitions when you have interpretation questions about the CMMI. There is a lot of helpful information contained in those pages.

So, OPF SP 3.1 is concerned with deploying the process assets (new or changed) across the organization. For example, deploying a new or modified template keeping in mind that the associated process may not have changed, just the template. OPF 3.2 is concerned with deploying new or changed processes across the organization. For example, deploying a new or modified Peer Review process, keeping in mind that the associated process assets may not have changed. The model is splitting these two practices apart for clarity because it is possible, as my examples indicate, to perform them independently. Now, from a practical standpoint, most organizations do these two practices together. When beginning process improvement, organizations usually modify BOTH the process and the associated process assets at the same time. As the organization matures, they may be able to modify a process asset without a corresponding process change and vice versa.

And if you remember back to when you took the Intro to CMMI class, your instructor should have emphasized that there is no implied flow from one Specific Practice to the next. They can occur in any combination or order, just as long as the Specific Goals are satisfied. However, in the Engineering PAs there are certain practices that most everyone performs in a certain order.