How Can I Manage Both Legacy and Maintenance Projects?

The nature of the work does not preclude the organization from having to follow processes. The organization simply has to define the processes correctly for the different types of work and domains. For a Maturity Level 2 (ML 2) organization, this approach comes down to how the organization defines a project. In my experience, clients who are managing legacy and/or maintenance projects initially define individual changes as a project and it kills them because of everything required by Project Planning (PP) and Project Monitoring and Control (PMC). So the organization then has to think about how they manage work. At what level do they create a project schedule? Is it for each change? Or is it for a group of changes? Or is it on an annual basis? Basically the changes for maintenance work tend to be treated as a “job jar” and the organization pulls different jobs out of the jar to work on. So my clients in this situation, then consider work being managed annually, meaning that there is an annual project plan covering staffing levels, training, etc. That is, most of the PP Specific Practices (SPs). Then when they work on a specific job or task, they have a mini-schedule that is reviewed and compared to the annual plan to ensure that everything is compatible and they work to the mini-schedule using the annual project plan.

For legacy projects, the project plan, if it exists, was created well before the organization heard of or considered implementing a process improvement model like the CMMI. Consequently whatever exists was not developed per the current PP processes and there is no business value to go back and attempt to retrofit the old plan to the current process. What does make sense is for all project re-planning and re-baselining activities from this point forward to follow the new PP processes.

What is the Difference Between a Physical Configuration Audit and a Functional Configuration Audit?

A Physical Configuration Audit (PCA) is a Configuration Management (CM) audit that verifies that whatever you have built conforms to the technical documentation that defines the build. What that means is that CM must compare the configuration of the as-built product to the design documentation of the product. For example, CM looks at the list of all the configuration items (versions, etc.) in the as-built product and compares that list to the list of what is supposed to be in the product.

A Functional Configuration Audit (FCA) is a CM audit that verifies that the functions of the as-built product match the baselined functional requirements and that the operational and support documentation is complete and satisfactory.

Challenges With SEPG Staffing

Amir Shahzad Khan posted these two fairly realistic scenarios to the CMMI discussion group.

Scenario 1
We have resources that are on the bench waiting to start a new project and/or new billable work. We have decided to draw on this pool of idle resources to staff the SEPG and the ML 3 process teams. Each person has accepted these new responsibilities and they are working their assigned SEPG tasks. Suddenly, there is new billable work or a new project starts. Now management reassigns these resources that were on the bench to the new work leaving their assigned SEPG tasks incomplete, severely impacting the SEPG schedule. How to do tackle this kind of situation?

Scenario 2
People are selected from the organization to staff the SEPG. They are assigned to Process Areas that match their area of expertise. However, most people are reluctant to work on their assigned SEPG tasks and they either don’t deliver or deliver much less than expected, which impacts the SEPG schedule. The primary reason of their reluctance to deliver is that they don’t consider their assigned SEPG tasks as their core area of responsibility. Since the SEPG support will not affect their performance appraisal they don’t take it seriously. They only receive verbal appreciation. What kind of reward or penalty can be introduced in this regard so that people deliver what they have committed?

What is described in both scenarios is a serious lack of Management Commitment to process improvement, the SEPG, and the CMMI. Lack of Management Commitment is your worst enemy and will effectively kill all of your efforts, despite your best intentions. What is necessary is for management at ALL levels in the organization to actively support these initiatives, not just pay lip service.

Scenario One
First off it is a bad idea to assign people on the bench some SEPG “busy work” just to keep them occupied until a billing opportunity comes along. You should have recognized this problem as one of your major risks in the Process Improvement Plan and defined a Risk Mitigation strategy to use when people are reassigned and removed from their SEPG duties. The SEPG should report these issues to the Management Steering Group (MSG), who should be held accountable for allowing key SEPG resources to be reassigned. If these resources are also key people for billable work, they should have never been assigned to the SEPG. Instead they could be considered as Subject Matter Experts that can be called upon from time to time to consult with the SEPG. There should be a core set of dedicated people on the SEPG. Others who have “signed up” to work on the SEPG should be allowed by management to support the meetings, even if they have been reassigned. Look at the IPPD practices in OPD and IPM for guidance on establishing these types of management mechanisms.

Scenario Two
This scenario sounds like management has not given clear direction as to the importance of the SEPG to its members and the organization as a whole. If management doesn’t clearly think that the SEPG is important, then why should anyone else? The Process Improvement Plan should have identified this problem as a major risk as well. If someone has been assigned to the SEPG, their SEPG role should be part of their job and they should be held accountable for their performance of their assigned duties. The SEPG is effectively the project team and the MSG the project manager. The MSG should be taking a major role in reviewing the progress to the plan and resolving issues in both scenarios.

Process Improvement - A Twelve Step Process

1. We admitted we were powerless over quality/on-time delivery/estimates/project management/etc. – that our projects had become unmanageable.
2. We came to believe that a model greater than ourselves (the CMMI) could restore us to sanity.
3. We made a decision to turn our processes and procedures over to the care of Software Engineering Institute.
4. We conducted a searching and fearless gap analysis of our organization.
5. We admitted to our Lead Appraiser, to ourselves, and to our executive management the exact nature of our process weaknesses and gaps.
6. We were entirely ready to have our Lead Appraiser help us address these weaknesses and gaps.
7. We humbly asked our Lead Appraiser to help us remove our weaknesses.
8. We made a list of all projects that had suffered because of our bad practices, and became willing to take corrective actions to address the issues, as applicable.
9. We made direct modifications to our processes wherever possible, except when to do so would jeopardize the success a project.
10. We continued to appraise the organization, and when we had weaknesses we promptly admitted them.
11. We sought through the Engineering Process Group (EPG) and the Management Steering Group (MSG), to improve our direct contact with our Lead Appraiser and the SEI, asking only for their knowledge and expertise to guide us on our process improvement journey.
12. We have recognized the benefits of process improvement as the result of these twelve steps; we have tried to carry this message to other internal groups and external organizations and to practice these principles in all our affairs.

CMMI-ACQ - Agreement Management

Agreement Management (AM) is a Maturity Level 2 (ML 2) Process Area (PA) in the CMMI-ACQ. Basically this PA is a more robust treatment of the CMMI-DEV PA Supplier Agreement Management (SAM) Specific Goal 2 (SG 2), Satisfy Supplier Agreements. The Specific Goal and most of the Specific Practices have the same titles between the two PAs. However, the details are quite different.

AM only has one Specific Goal - The terms of the supplier agreement are met by both the acquirer and the supplier. SAM uses the term project instead of acquirer. This difference means that AM is applied in a broader sense than SAM. SAM focusses on the project's needs for acquiring a product or service from a supplier. AM focusses on the acquirer, which may be
· Procurement
· Purchasing
· Outsourcing
· Supply chain
· Buyer
· Contracting
· Logistics
· Supply sourcing
etc.
Mike Phillips/SEI said in the CMMI-ACQ class that he has a list of 17 different terms for acquirer.

How do I handle negative responses to process improvement or the CMMI?

Some people will always object. There is a saying, “you can take a horse to water, but you can’t make him drink”, which is so apropos to negative reactions to any process improvement initiative. What you have to keep in mind is that people generally fall into one of five populations when it comes to making changes: Innovators, Early Adopters, Early Majority, Late Majority, and Laggards. Innovators, Early Adopters, and the Early Majority are usually those people who are open minded, see the value of models and standards, and are willing to make a change. The Late Majority and Laggards resist change and do not see the value of any model or standard process. I have heard of these type of people referred to as CAVE (Citizens Against Virtually Everything). You may want to look at my presentation on Managing Cultural Change in the Slideshow sidebar on the right of this blog.

I ran into this problem years ago when I was the ISO 9000 Management Representative in a small software company. It was a constant struggle to get people to document and follow their procedures. I even had one developer who said “I just want to be left alone in my office with the door shut so I can write code.” I just had to maintain a positive attitude and continue working towards the end goal despite all the negativity and stupid comments like “OK, what is the documented procedure for making coffee now?”

I had another experience a few years back trying to teach the Software CMM class at a client site. Most of the students didn’t want to be in the class, but were forced to by management. In fact, there was one particular student who just sat in class, did not participate, and had a smug smile on his face the whole time. Half way through the second day the client decided, based on feedback from the students after hours on Day 1, to cancel the remainder of the class because they felt they didn’t need the training, it didn’t teach them anything they didn’t already know, and therefore it was of no value to them.

There isn’t a whole lot you can do with this attitude. You basically are a lone voice crying in the wilderness. They won’t listen to you no matter what you tell them. I characterize these types of people and organizations as being in the first step of the Twelve Step Process, they are in denial. They are a disaster waiting to happen and nothing is going to budge them to look at things differently until after something bad happens. About all you can do is “plant the seed” about the CMMI and process improvement and walk away. When things take a turn for the worse, they may remember what you told them and they may come back to you for help.

Help! I am Totally Lost When Interpreting the QPM Specific Practices

QPM SP 1.1 states “Establish and maintain the project’s quality and process-performance objectives.” When you are starting to implement the Maturity Level 4 PAs you won’t have a Process Capability Baseline, that is ultimately the goal of being at ML 4 so the organization can then move to ML 5. One of the main thrusts of ML 4 is to analyze the process data looking for Special Causes of Variation. Once those have been analyzed, then it is possible to determine the process capability. For SP 1.1 the project’s quality and process-performance objectives (QPPOs) are set by management and are based, in part, on the organization’s objectives (OPP SP 1.3). The Process Performance Models (PPMs) are then used to determine if the QPPOs can be met. If not, the QPPOs should be appropriately adjusted.

QPM SP 1.2 states "Select the sub-processes that compose the project's defined process based on historical stability and capability datat." One of the key words in this practice statement is "historical". Sources of historical stability and capability data include the organization’s process performance baselines (PPBs) and PPMs (OPP SP 1.4 and SP 1.5). And the intent of this practice is to tailor the organization’s standard processes (OSSP) so the project’s processes will support the project’s QPPOs defined in SP 1.1.

QPM SP 1.3 states “Select the sub-processes of the project’s defined process that will be statistically managed.” The model does not say that these sub-processes MUST be statistically managed, but these WILL be statistically managed. And this practice focuses more on than just selecting sub-processes. It also focuses on identifying the attributes of each sub-process that will be used to statistically manage the sub-process.

People appear to get confused with Maturity Level 4 (ML 4) sounds when trying to understand QPM independently from the rest of the model. You cannot do that. You have to consider OPP and QPM together when looking at ML 4. OPP provides the analysis of the historical data to build the PPBs and PPMs which are then used by the projects to help them appropriately tailor the OSSP to what will meet the project’s QPPOs. QPM SP 1.2 uses the word "compose", which may contribute to some of the confusion. Since compose is not in the CMMI Glossary, then the dictionary definition is applicable. The Webster definition of compose is “To form by putting together two or more things or parts; to put together; to make up; to fashion.” So for this practice, compose means going to the OSSP and selecting the processes and sub-processes that will meet the QPPOs and then applying the necessary tailoring criteria. What this practice implies is that the OSSP may have several different processes for each Process Area (PA) so the project manager can choose the most appropriate one when composing the project's defined process.

Another ML 4 concept that may be the cause of confusion is the notion of Quantitative Management vs. Statistical Management. QPM SG 1 is all about quantitatively managing the project, which means the Project Manager must be periodically reviewing progress, performance, and risks using the PPMs to determine/predict if the project will meet its QPPOs. If not, then appropriate correctives actions must be taken to address the deficiencies in achieving the project’s QPPOs (QPM SP 1.4) Statistical Management is covered by QPM SG 2. The intent is for the project to statistically manage those sub-processes that are critical to achieving the project’s QPPOs. There are only a small set of sub-processes that are critical to achieving the project’s QPPOs. If the organization were to statistically manage all processes, that would be insane. This approach would mean that the organization would need PPBs and PPMs for EVERY process, regardless of their importance to the QPPOs. And then the shear overhead of collecting, analyzing, and reporting data on every process would most likely bring the organization to its knees. Work would come to a standstill because it was taking far too much time to statistically manage each process and taking corrective actions that may not be necessary. Unless you have an infinite budget and dedicated staff to perform these analyses, that is why the model states to statistically manage SELECTED sub-processes.