Friday, July 2, 2010

Project Planning SP 1.2 - Task Attribute: Effort or Size?

Is it possible to establish estimates of work product and task attributes by means of task time estimates? Can the task effort be similar to the size of a task?

By going directly to task time estimates you have effectively skipped performing Project Planning Specific Practice 1.2. The intent of SP 1.2 is for you to perform some sort of basis of estimate for the project’s tasks and activities. This is a bottom-up approach. If you are not used to this approach, it can be a struggle at first to take a step backwards from task time estimates and really understand the underlying assumptions that people are making in their heads about the factors that are driving the task time estimates. Some very basic task attributes include estimating the number of pages in a document that is being produced or updated, the number of technical drawings being produced or updated for a hardware item, the number of new or modified interfaces, the number of new or modified screens , etc. Then based on your historical data from previous projects, it is possible for you to empirically determine a set of productivity factors that will convert these sizing parameters into effort and arrive at the task time estimates. The bottom line is effort of a task is not the same as the size of a task.

Do you think this practice would be Fully, Largely, Partially or Not Implemented? Would this be this a problem in a SCAMPI A appraisal? What do you think about that?

Taking this example out of context with everything else your organization is doing makes this a difficult question to answer. The appraisal team is the only group that would be qualified to make that judgment based on documented evidence and the interviews. However, as a Lead Appraiser, I would have to say that you have a problem that needs to be addressed before you conduct a SCAMPI. The SCAMPI rules state that if a Process Area is in the scope of the appraisal, then all of its Specific and Generic practices are applicable. And if you are not performing a practice, which may or may not be the case, then there could be issues in Project Planning that impact Goal Satisfaction and result in a Maturity Level 1 rating.

To provide you the best answer, you should be talking to your Lead Appraiser and have him or her give you the proper guidance on this issue. As a risk mitigation, I would recommend that you put a process in place to estimate sizing parameters that are then used to calculate effort. Your estimators are already doing this, but it sounds like they are doing it in their heads. You just have to break the process down into smaller steps to allow the sizing estimates to be captured first. There is benefit to doing this.

Thursday, July 1, 2010

Appraisal Sponsor Roles and Responsibilities

I am looking for information regarding the roles and responsibilities of the appraisal sponsor.

My organization is preparing for an external appraisal and I'd like to provide the sponsor with a summary of her role and what she will be expected to do for the appraisal such as review and sign the appraisal plan, attending the opening and findings briefings etc.

It sounds like you have a pretty good understanding already of the appraisal sponsor’s duties. It would be helpful to you to ask this question of your Lead Appraiser to see if he or she has any specific requests for the appraisal sponsor. As a Lead Appraiser, these are my expectations. The appraisal sponsor:

  1. Provides the funding and senior management commitment for process improvement and the appraisal
  2. Does not serve on the appraisal team
  3. Meets at least once with the Lead Appraiser to discuss the appraisal
  4. Provides the business objectives for the organization
  5. Signs the Appraisal Input Document, Appraisal Plan, and Appraisal Disclosure Statement
  6. Attends the Opening Briefing to reinforce why the appraisal is being conducted and the importance of everyone to support the appraisal team
  7. Meet with the appraisal team before the Final Findings presentation to privately receive the results and prepare the proper message for the organization at the Final Findings Presentation
  8. Attend the Final Findings Presentation and at the conclusion of the presentation thank the appraisal team for their efforts and thank the organization for their efforts regardless of the outcome. If the results were bad news, turn it into a positive statement of encouragement, etc.
  9. Complete the feedback form in SAS for the appraisal results
  10. Receive the appraisal results and maintain the appraisal record for three years
  11. Do not publicly disclose the appraisal results until the SEI has completed its quality review and announced the results to the Lead Appraiser and appraisal sponsor

Wednesday, June 30, 2010

How to Start With the CMMI

If a private software company wants to do get a certificate of quality for CMMI Level 2, what must this company do in order to obtain Level 2? And also what are the steps that must be followed from the start (initial) to achieve CMMI Level 2 (Managed)?

First let me state that there is no certification of any type for the CMMI. Individual Lead Appraisers will issue something looks like a certificate to the organization that was appraised indicating the SCAMPI A results. But this is not a certification. The only things that the SEI certifies are the CMMI instructors and Lead Appraisers.

Here are the necessary steps for achieving Maturity Level 2 for the CMMI-DEV. These steps are not necessarily sequential, some can occur concurrently.
  1. Hire an SEI-certified Lead Appraiser to conduct a Gap Analysis of the company to determine the current process strengths and weaknesses and help the company construct a Process Improvement Plan (PIP).
  2. Obtain executive management sponsorship for the process improvement effort.
  3. Train the people responsible for the company’s processes and for addressing the action items in the PIP on the 3-day SEI Introduction to CMMI v1.2 class.
  4. Address the issues from the Gap Analysis, document the necessary processes and procedures, and begin conducting the PPQA process and work product audits.
  5. Allow time for the new and/or modified processes to get some use on various projects.
  6. Conduct a SCAMPI B appraisal as a dress rehearsal for the SCAMPI A. Identify any issues and weaknesses that are potential risks to achieving Maturity Level 2.
  7. Create a new PIP to address the SCAMPI B identified weaknesses and risks.
  8. Address these issues
  9. Conduct the Maturity Level 2 SCAMPI A appraisal.

Wednesday, April 14, 2010

Using the CMMI-SVC to Transform an Organization into a High-Functioning, Customer-Driven Profit Center

For those of you who were not able to attend the 2010 North American SEPG Conference in Savannah, GA in March, here is a copy of my presentation on the CMMI-SVC.

As a company grows and matures from a startup entrepreneurial venture to a sustainable corporation, the departments and company services that begin as good ideas expand and evolve to support the company’s growing business. Many times these services simply develop without any strategic vision resulting in institutionalized behaviors that are incompatible with the company’s business goals and objectives. Consequently, the transition to a larger corporation becomes a challenge. A notable example is a company’s Engineering Services Department.

When people think of Engineering Services, the Customer Support or Help Desk team is what first comes to mind. However, other services such as Product Training, Field Services (product installation and troubleshooting), and Engineering Sales Support may be provided as well.

As a product development company begins selling product, the Customer Support function becomes one of its first service offerings whether or not it recognizes it as such. In addition, it is natural for the focus of the Customer Support function to be on pleasing their customer base, as many sales are contingent upon repeat business and word of mouth until the company and its product line become established in the marketplace. Nevertheless, without a clear idea of its charter and strategic direction to support business growth and identify new markets and service offerings, the Customer Support Specialists focus instead on supporting their customer base on non-company and non-product issues and questions that consume internal resources without any tangible benefit to the company. Once a company starts banging its head on the “glass ceiling” as it attempts to grow, the leadership may recognize that its current Engineering Services approach does not support its strategic business goals and objectives.

In these circumstances, the company is not necessarily interested in implementing the CMMI for Services (CMMI-SVC) and becoming appraised to either Maturity Level 2 or Maturity Level 3. However, by using the Continuous Representation, the CMMI-SVC can provide the needed guidance to help a company restructure and reorganize its Engineering Services approach in order to become a profit center or revenue generating function.

In this presentation, we will present a case study for OMNI Flow Computers, Inc., a company that specializes in the design, development, and manufacture of panel-mount multi-run, multi-tasking liquid and gas flow computers, and field-mount, hazardous area controllers/RTUs for liquid and gas custody transfer metering systems. The challenge facing OMNI was to develop its Engineering Services Department into a high-functioning, customer-driven profit center. OMNI’s Engineering Services Department consists of three groups: Customer Support, Training, and Engineering Field Services. Customer Support handles customer questions, concerns, and issues. The Training group provides training on the OMNI product line to its customers and users. Engineering Field Services provides on-site troubleshooting services on an as-needed basis.

As the Training and Engineering Field Services groups were recent additional capabilities, Customer Support presented the biggest obstacle to overcome. Noted management consultant Peter Drucker declared several years ago that Quality in a service or product is not what you put into it. It is what the client or customer gets out of it. Moreover, an obstacle to achieving this objective was one of the core challenges faced by the department: developing an appropriate customer focus and developing new service offerings. A major reason for these challenges is the nature of OMNI products. OMNI's customers integrate their products into custody transfer systems that involve a wide variety of large-scale hardware and electronic equipment from other manufacturers. OMNI’s customers usually develop and commission these systems for their clients and end users. Therefore, when calls come in to OMNI’s Customer Support group, the first challenge they had to overcome was determining if the customer’s issue was actually an OMNI product issue or the result of an external issue. The next challenge was to determine the root cause of the issue, so that the customer would receive a timely resolution of their issue.

Fortunately, the release of the CMMI-SVC came at the right time for OMNI. Of the seven new services Process Areas (PAs), many of the Specific Practices and associated informative material proved useful in guiding the transformation of OMNI’s Engineering Services Department. The Service Delivery PA provided excellent guidance for establishing and documenting Engineering Services’ existing service offerings, ensuring that each group was prepared to deliver the defined service offerings, and delivering the service offerings. The Incident Resolution and Prevention PA provided excellent guidance for identifying, documenting, tracking, reporting, and resolving customer complaints, issues, and other service interruptions. The Service Continuity PA helped focus the Engineering Services Department manager to identify and prioritize the department’s essential functions and necessary resources. The Strategic Service Management PA brought the needed focus to establish the Engineering Services strategic needs and plans for its standard services.

The OMNI Engineering Services Department’s journey is not yet over. They are still growing, maturing, and learning what it means to become a high-functioning customer-driven profit center. However, along the way they learned some valuable lessons. This presentation will discuss some of the pitfalls they encountered, what strategies worked and what did not work, as well as provide some practical advice to aid other organizations facing similar challenges.

If you make customers unhappy in the physical world, they might each tell six friends. If you make customers unhappy on the Internet, they can each tell 6000 friends. - Jeff Bezos

Customer service is not a department. It is an attitude. – Unknown

This presentation provides a case study of a computer manufacturer that used the CMMI for Services to help transform its Engineering Services department (Customer Support, Training, and Engineering Field Services groups) into a high-functioning, customer-driven profit center. Challenges, successful approaches, lessons learned, and practical advice to aid other organizations facing similar challenges will be presented.

Tuesday, April 13, 2010

Process Improvement vs. Process Maintenance

An organization on its process improvement journey may include process maintenance activities under the heading of process improvement. Most organizations do that. As far as I know, CMMI does not talk of process maintenance activities. To me, a few examples of process maintenance activities are those required for metrics data collection, project monitoring, process definition, making plans, etc. On the other hand, process improvement will include activities like metrics data analysis, identifying significant variations from planned arrangement, process re-definition based on improvement suggestions and metrics analysis, revising the plans in line to changing requirements, and taking appropriate preventive and/or corrective actions.

Are there any benchmarks for healthy process maintenance vs. improvement activities for software organizations?

These two concepts in inextricably intertwined. I would find it hard to believe that an organization does not identify any process improvement suggestions by just doing process maintenance. Even if you are just maintaining your Maturity Level, you will still identify improvements to the status quo. And I contend that even for process maintenance you have to perform data analysis, identify variations, and identify appropriate corrective actions, otherwise how would you be able to determine that you are maintaining what you have already achieved? I do not understand the need to define these two items as separate activities. What would be the point of merely maintaining your processes?

Sunday, April 11, 2010

Configuration Management - Change Request Number Traceability

I would like your help with understanding the following subject:

A change request is processed in a change control tool. Each change request has a number. If a proposed change is accepted, a schedule is created for making the change.
When it is necessary to store the configuration items modified in the configuration system, we have the option of describing what we have done. We record the implemented changes and the reasons for the changes, however we don't track the change request number.
Will the lack of tracing the change request number create a weakness in the Configuration Management Process Area? Is just recording the historical information about the changes in the comments and using the change control tool sufficient?

How important to your projects and business is it to track the change request number? Have you encountered issues with change control on the projects because you have not maintained this information? Recording and tracking the change request number is a very easy thing to do and I am wondering why you haven’t done that.

What also concerns me is that you imply that recording a description of the change made to a baselined item may be optional. If this is true, then it is then possible for someone to decide not to record this information. Recording the information should be mandatory.

Not tracing the change request number and the possibility of not recording a description of the change sound like high risk items that can cause you difficulties in the future. As a risk mitigation, I would record all change numbers and require that all changes made are clearly described in the event that someone else in the future needs to understand the nature and reasons for the change.

And since you are using a tool, which I assume is an off-the-shelf product, you may in fact be tracing the change request number and not even realize it. But from an appraisal point of view, it sounds like you might have most of Configuration Management covered and the problem you are asking about might be viewed by the appraisal team as a weakness. But is it a Goal breaking weakness? This a question that must be answered by the appraisal team.

Saturday, April 10, 2010

Configuration Management - SP 1.3-1 , SP 2.2.-1

I would like your opinion in relation to situation below.

Once a change was been verbally approved, is there some problem in relation to CM SP 1.3 (Create or Release Baselines) - sub-practice 1 and CM SP 2.2 (Control configuration items) - sub-practice 2, if the record of the modification in the schedule and the change control tool are done in subsequent periods until a maximum limit of time of the defined period for monitoring of the project?

Example:

Verbal approval of the change - Monday
Beginning of the work - Tuesday, with storage of the configuration items in the configuration system (without baseline).
Register of the change in the change control tool and record of the activities in the project schedule - Friday
Collection of the progress and effort - Next Monday (weekly Monitoring, all monday)

In advance, thank you very much.

The first problem I see is the verbal approval. Verbal approvals are difficult to document or provide as evidence and over time can be forgotten or misremembered, not to downplay the risks associated by not documenting decisions.

Secondly, since you are asking about the sub-practices, that makes me wonder if you have taken the SEI’s Introduction to CMMI class. If you have taken the class, your instructor should have made clear to you the distinction between the required, expected, and informative components of the model. The sub-practices are informative components and are therefore provided only as information to help you understand the intent of the Specific and Generic Practices and Goals. To be clear, you are neither required nor expected to implement the sub-practices.

If the weekly schedule you described works for your projects, then you should be able to map it to the Configuration Management (CM) Specific Practices (SPs). However, the described weekly schedule sounds like it may have some gaps.

I strongly suggest that you have an SEI-certified Lead Appraiser conduct a Gap Analysis (Class C appraisal) of your organization, especially CM, to determine the gaps between your implementation and the CMMI.