Category: CMMi

A stakeholder is anyone who is impacted by the outcome of the project. This can be either in a positive or negative way. These are the people who have some sort of stake in the outcome of the project. It normally includes people like clients, internal sponsors, employees, management, suppliers etc. As a small business goes on to implement CMMI, it sees clearly that customer is identified as one of stakeholder but not the only one though, there are other stakeholders in the projects as well that are equally important. It may seem that CMMI does not explicitly mentions things like “Customer Satisfaction” and “Voice of Customer” which are prevalent in other frameworks like ISO and Six Sigma. This people feel that implementing CMMI will increase overheads while not doing anything for the customer directly. For a small business, this is a dreadful scenario! I think the whole thing is being misrepresented or misunderstood. Here is why: Although CMMI does not tells that you should keep your customer happy, but it asks you to define the flow of activities that is used to create the service or product that you are offering to the customer. So it may be a case that a customer value great looking design but look at the value chain – The requirements of web design must be captured by the project manager first. While capturing the requirement, the primary stakeholder for the project manager will be the designer and not the customer himself. Another example, think about quality and timeliness of delivery.  This is something that is important to most of the customers. Now if the project lifecycle consists of analysis, design, coding, testing and delivery then the each subsequent phase relies on timeliness and quality of the deliverables of its previous phase. If one phase has poor quality or is delayed then it will affect all previous phases as well. Thus, the primary stakeholder for the analyst is the architect who will do the architecture, for the architecture it may be the developer will do the coding and for the developer it might be the tester. Now, if the developer thinks that in order to please the customer, he should work fast and in the process he introduces several bugs. Now, if the tester also thinks the same and does not do thorough testing then customer will get a buggy delivery or otherwise, the developer will have to do a lot of rework and bug-fixing which will delay the delivery. In both scenarios, I don’t see a happy customer! I think CMMI talks about this “value chain” which leads to customer satisfaction rather than talking about “customer satisfaction” first then not defining means to achieve it. If this “value chain” is not defined properly then it may be possible for the organization to satisfy some customers in some situations but it will not be possible to satisfy all customers. CMMI makes sure that everyone knows how their job connects to other jobs in making the deliverables. To conclude, CMMI does not say that customer is not important, it however talks about that chain of practices, deliverables and mutual dependencies which allow an organization to deliver customer satisfaction project after project.

A process is series of steps or activities that you need to execute in order to solve a problem or come with an outcome or result. Processes exist within every organization, in some cases they are informal i.e. it is not documented but rather institutionalized by habit. Such as, signing the attendance register while entering or leaving office. Documenting the process is a great thing because it gives everyone within the organization a common way to solve the same problem. People often think that having a process will eliminate the need of having good people in the first place or limit their creativity. This is not true. For example, recipes for food is also sort of a process. A recipe for a chocolate cake may tell you all that is required to know about making one but still, if two people are reading the same recipe, the results that they come up will be different (and in some cases inedible). Same is true for software as well! Having a process makes people work smarter and not harder. Conduct a search for “Software Development Company” and try to navigate to process page (if you can find one!) and chances are that the general process for software development will be following: Analyze > Design > Code > Test If that is true then why the results from two software companies vary so much? In order to answer this question, ask the software engineers to tell you what they do within each of these four phases and the reason will dawn upon you. The above software development process is too generic in nature and hence it is open for interpretation. For example for you test may mean just mean ensuring that there is no spelling mistake on the page while for me it may mean that it should be XHTML validated as well. It’s actually the procedure that makes all the difference. While the process answers “what” will be done, the procedure answers “how” it will be done. The more detailed the procedure is, the lesser will be deviation for the expected results and the more consistently the process will be applied. Thus, although Process forms an outline of flow of activities but it is important to probe deeper and find out the procedures as well. Another important thing to point out is that too often, the process is focused more on the product itself then of the process that is used to create it. For example, writing a ten page document on how to format the code properly is an example of product focus. This will ensure that the code is formatted properly but how do we know that the “right” code has been written? I am not saying that code standards should not be there but I am stressing that the process focus means focusing more on the “means” rather thea of the “ends”.

Some of most frequently encountered problems in software development are faced due to poor configuration management practices such as: Previously fixed bugs miraculously reappear after latest update Development teams are working on separate versions of the code Changes implement earlier have miraculously disappeared A fully tested application stops working There is no way to trace the software requirements to the documents and deliverables. Software teams are using different versions of tools and resulting code is incompatible Configuration management falls under the category of Support process group of CMMI and falls at Level 2 in staged representation. In essence it is a discipline of establishing the integrity of the work products through proper identification, accounting, auditing and control. Here are the key things involved in this discipline:  Identifying Configuration Items Configuration items are identified at the very onset of the project. These typically include work products that are delivered to the customer, internal work products, acquired products, tools and intermediate work product that support the development effort. The following items are generally configurable items: Requirements specification, Architectural specification, Design specification, Code modules, Test data and plans, Project plan, Quality plan etc  Setting up a Baseline Establishing a baseline is most important part of configuration management discipline. A baseline represents an approved snapshot of the system at appropriate points in a system life cycle. A baseline serves a platform for further development. This is because before a baseline is established, change can be made informally but after establishing a baseline, change can only be made using a formal procedure. There are two important terms in respect to a baseline i.e. Build and Release. A baseline that is used for internal development is called a Build whereas a baseline that is delivered to the customer is called a release. Change Control As stated earlier, once a baseline is established the only way to make amendments to the “baselined” work product is through formal change requests. Each change request is recorded formally, their impact is evaluated, and they are formally reviewed and then tracked to closure. Changes are generally approved by a change control board (PM can also be a member of the group) and this ensure that adhoc changes are not made to the system. The change history of each work product should match its current baseline version. This helps the management to answer questions such as – what features has been added to the work product between release 1 and release 2? Often regression testing is also done on the configuration items to ensure that there are no unintended consequences on other configuration items. Configuration Status Accounting Configuration status accounting is quite similar to the financial status accounting in a sense it tells about the inflows and outflows that has resulted in the current state of the project. With a status accounting, the management should be able to answer questions like: How many changes have been received? How many changes approved / disapproved? How many have been implemented / pending implementation? What differences exist within successive baselines? Auditing the Configuration Finally, the system is audited, mostly prior to customer delivery to ensure that all change requests have been resolved and that the system contains only the work products that are required and nothing more. This is done by comparing the documentation (SRS, Manuals etc) to the product to ensure that it is ready for delivery. Word of Advice! Configuration Management is discipline in itself that requires infrastructure, effort and cost. Thus, these activities should be included in the original project plan itself otherwise it might seem like an overhead to do them later and the organization will make a costly mistake of ignoring this discipline

People often tend to compare CMMI with ISO 9001. The most common thing that I come to hear is that ISO 9001:2000 is same as CMMI Level 3. I am no expert on this but being an ISO 9001 organization which has started its journey for CMMI, I cannot resist but talk about how different CMMI is from ISO 9001. First off, CMMI-SW had been designed as a framework for addressing the problem that is faced by organizations that are into development of software intensive systems. ISO on the other hand is applicable for all manufacturing organizations that may or may not be into software development. Thus, both your software organization as well as a road-side bakery can be an ISO 9001 organization but the bakery won’t get a CMMI certification. Here are the few things there in CMMI which ISO misses or does not mention explicitly: Institutionalization Without institutionalization a process breaks under pressure of deadline. CMMI stresses the fact that the process should be ingrained into business so that it becomes the part of corporate culture. Focus on Organizational Training For any process to implemented uniformly across organization and to ensure that organization keeps learning and growing it important to identify training needs and impart it properly. It is for this reason that CMMI has a separate practice area in the area of training. Maintaining Process Asset Library This library contains process assets that include process related documentation such as policies, defined processes, checklists, lessons-learned documents, templates, standards, procedures, plans, and training materials. These assets are required for the process to interpreted and executed properly. Discipline of Risk Management CMMI looks at risk management as an organized and technical discipline to identify things that light cause harm or loss. Once a risk is identified it is quantified and prioritized and the risk is tracked throughout the project life cycle. Causal Analysis The causes of variation in achieving the project goals are analyzed formally and the root is identified and addressed so the variation is eliminated or their impact is minimized. Concept of Stakeholders CMMI states that a stakeholder is anyone who is affected by or is accountable for the outcome of the project. Thus, a stakeholder can include project team members, suppliers, customers, end users, and others. I know that being in the business for software services it make better sense to be a CMMI organization.

CMMI has 5 different levels i.e. from Level 1 to Level 5. I have tried to explain these levels in plain English so that you can understand and appreciate the whole process improvement initiative that we have taken up. CMMI Level 1 CMMI Level 1 is lower-most (or Inital) maturity level of an organization when we refer to the staged representation of of CMMI. Any organization which does not belong to any other level is considered to belong to Level 1 (or Level 0 as it should be). This level is characterized by following: There is no predictability in schedule, budget, scope or quality. The organization has some “pockets of excellence” – which basically means that there are only a few people or things that the organization can do well. The success of a project depends on the heroism of a few key players. The organization is people-dependent. Infact, all organizations are people dependent but in the context of CMMI this basically means the risk due attrition is very high. The knowhow of a project is lost with the developer who was working on it and there is no organizational learning. There is no formal or very poor planning process. The discipline of management and engineering is weak and inadequate CMMI Level 2 Level 2 is the “Managed Level”. At this level the organization sort of wakes up and instead of blaming its people it starts looking at its current processes as the main cause behind its inefficiencies. The following are the main characteristics of a Level 2 organization: The organization starts making realistic project commitments and key projects elements like cost, schedule and scope is tracked The organization defines a clear policy for project management and begins to plan the projects formally. The discipline to tracking actual project performance and comparing it to the planned performance is also instilled. So, the organization can take some proactive corrective actions if the project get delayed or exceeds it allocated budget. All the projects requirements and work-products are change managed. The changes to scope are always consolidated back into the main requirement document so that a single document containing all customer requirements are always available. Relationships with both internal and external suppliers are formally managed. All stakeholders outside the control of the project team may be treated as a supplier. Quality assurance becomes a formal process. All issues in a project are recorded for future analysis. Still at Level 2, there specific implementation of a process may differ from project to project. This happens because the employees may interpret same thing in different ways. Thus, projects may be doing there things in their own separate ways. Even at level 2 the although the organization builds project discipline, but there is still no process discipline. Things like coding practices, documentation practices etc may differ across different projects within the same organization. Thus, the results of each project may vary to a large extent. The feeling of “This is how we do things here” is non existent. This can also be seen from the fact that at Level 2 there is no process area under “Process Management” thread. CMMI Level 3 CMMI Level 3 or the “Defined” level is a stage when the processes and its interpretation gets institutionalized across the organization. The following are the main characteristics of a Level 3 organization: An Engineering Process Group or EPG (as it more commonly known) is formed. This is headed by someone from the senior management to ensure proper management commitment is there. This group is then responsible to managing the organization processes. Quality Management System or QMS document is generated which contains documentation regarding all processes. All projects must refer to this QMS and contribute back to it. It is very important as it leads to Organizational Learning. Here is how it works: Suppose “Project A” has made some process improvement or innovations, these are then fed back to the QMS. So when “Project B” is starting, it automatically shares the best practices of Project A. This ensures that organization keeps on improving and all projects share the common process. Continuous organizational training ensures that QMS is interpreted in the same way by everybody Engineering and Management activities are more aligned with each other. The engineering discipline gets more effective and the capability of the organization to delivery quality products is greatly enhanced. In reference to CMMI , Level 3 contains the maximum number of process areas that needs to be addressed. CMMI Level 4 At Level 4 or “Quantitatively Managed” level, the organization focuses on managing the projects and processes through the usage of statistical tools. This brings into picture the usage of data that the organization has started to collect at Level 3. Here is an overview of an Level 4 organization: Threshold values are established for each process area. For example, you may want to control the scope of the project more rigorously . So, you may define a threshold value that says that if the requirement is changed by more than 20% then re-planning and re-estimation will be required. All projects then need to ensure that requirements remain within the defined threshold values. All variations from the threshold value is determined and assigned to either special causes or common causes. Common causes can be thought of, as the causes for deviation that exist within the organization, for example improper training, improper risk management etc. Special causes can be though of reasons that exist beyond organizations direct control. This can be things like continuously changing customer requirements, no access to validation area etc The focus of the organization is to narrow down these threshold values i.e. if today the threshold for delivery schedule is 10% then the focus it to narrow it down to 7% or less. The quality of projects that the organization delivers it of high quality. All projects are managed and controlled using quantitative data. CMMI Level 5 CMMI Level 5 or the “Optimizing level” is different