Vol. 2, No.1 April 1995 How to communicate estimates clearly The communication of estimates is one of the most common weaknesses in project planning. A manager or customer will ask a project leader how long a task will take. The project leader may reply "15 weeks." The manager could assume that this includes padding and reduce it to 10 weeks. This seems simple enough, but what are the units and what is the estimate based upon? Too often the information needed to clarify the estimate is omitted. With this level of ambiguity, it should be no surprise when software is late. When you are given an estimate you must clarify what it includes. Is this calendar time? Does it include support of a previous release at 30 percent? Is it uninterrupted-effort time? A good format to use when conveying estimates is Assumptions/Rationale, Confidence (high, medium, low), Estimate. Assumptions indicate conditions that must remain true for the estimate to be valid. Rationale is the explanation the estimators use for the estimate and what data, if any, the estimate is based on. The Confidence parameter gives an indication of how likely this number is to change and whether further planning is necessary. Sharing this information is not only key to setting correct expectations, it forces the estimators to think about estimates and changes what management and affected parties agree to when they say "Yes, do it." --- Neil Potter Top of newsletter

Adopting ideas -Planning for change and knowing who to work with   by MARY SAKRY Adoption of new practices takes time and planning. When implementing new practices, it is important not to underestimate the effort for the new behaviors to become common practice within the organization. Writing policies and procedures is the easy part. Anyone can create shelfware pretty quickly, but it is the generation of buy-in that wins long-term success for process improvement.     This graph illustrates the adoption of an idea in an organization over time.   Commitment to change phases It is important to consider the non-technical issues related to adopting new behaviors. At a minimum you should consider that each individual must go through the following phases for every new practice that is learned [Conner, Patterson, 1982]. You must plan to help people through these phases. The steps to adopt any new practice are: Contact - People hear about a new practice. This is usually accomplished through newsletters, word-of-mouth and informal meetings. Awareness - After several contacts with the concept, people remember that they have heard about it but don't really know many details. Usually this is addressed by continuing the methods listed above. Understanding - Eventually the level of interest will become strong enough that people will pay attention to what is being said and start to learn. Short workshops, seminars and lectures are most helpful at this stage. Longer articles and books are also useful. Receptiveness - Once individuals have had time to learn about the new practice, they are able to make an informed choice about whether they would like to try the practice to see if they find it useful. Trial - This is the most important phase. You want to do everything possible to make the trial successful for the participant(s). If in doubt postpone the trial until you can set it up when the conditions are more favorable. An unsuccessful trial can do much damage to your efforts. Regardless of how well the trial goes, you must immediately analyze how well it went and prepare another successful trial or modify what you did to make the next trial go better. This phase takes much hand-holding and encouragement. You may want to facilitate the trial to ensure success. Adoption - Once people have experienced several successful trials they may decide to use the new practice on a regular basis. People need appropriate training so that they can become self-sufficient in the new practice. Institutionalization - When most people have adopted the new practice and are using it regularly, the organization may wish to adopt the practice overall. This is the point when it can become organizational policy. If an organization tries to rush to this stage, it may cause the method to be rejected. Internalization - An organization has reached this point when a practice is so ingrained that the people would not consider working without the practice. It usually takes one to two years to reach this point. Improvement planning should be an ongoing, incremental activity and must allow enough time for everyone to move through the phases at a reasonable rate. Adoption bell curve It is also important to choose participants carefully. By working with the willing at their pace, you can increase the rate of change in the organization. For the adoption of any practice, you can represent the distribution of people approximately by a bell curve [Rogers, 1983]. At the leading edge you have a few who may be perceived as crazies or fanatics, followed by some likely champions who are credible and would like to try the new practice. Use of these people for the early trial helps ensure positive results and the generation of success stories. Another 20 percent or so will make up the rest of the "early adopters" who are willing, once others have been convinced. Beyond that the challenges are greater. The last portion of the distribution consists of skeptics who resist very strongly. In the middle is a collection of people who are neither angry nor particularly interested. Once many people have tried the practice and like it, it is easier to move toward widespread adoption. Always target early adopters, then move on to the bigger challenges, taking some easy wins and building momentum. In summary Plan for the adoption of practices by selecting the right people to work with first and expect everyone to move through the successive steps of change at their pace. Most organizations mandate things too quickly. If you wait until most people have completed the adoption phase, it is much easier to implement group-wide mandates and policies. Top of newsletter

Using the CMM effectively   by NEIL POTTER The Capability Maturity Model (CMM), developed by the Software Engineering Institute (SEI), is a model to help software organizations improve their development capability [Paulk93]. Acceptance and use of the CMM for process improvement varies greatly in industry, from using it as an optional guideline to revering it as Gospel. In this article I will discuss using the CMM effectively, creating process documentation, and knowing when the next SEI level has been reached. Each audience of the CMM may have different objectives, from "passing the exam" to win a contract, to helping each organize its process-improvement activities. Organizations that focus too closely on the CMM as an examination tool can miss the intent and value of the model. Need-driven Process Improvement When organizations start process improvement, they frequently begin by writing and implementing the processes described by the CMM, for example, processes for schedule estimation and product change control. This approach is not necessarily harmful as the concepts in the CMM are based on sound engineering principles. The problem comes when managers and engineers try to get these processes adopted within the organization. Some people see them as unnecessary or inappropriate. This is a poor approach to improvement and a potentially superficial use of the CMM. The CMM is effective when it is treated as a prioritized collection of solutions applied to defined organizational problems and needs. When used this way, the solutions are seen as valuable and appropriate. Effective process improvement should therefore start with a phase seeking to clarify problems, followed by a period focusing on identifying solutions. Process assessments help an organization define and prioritize its problems. The approach of successively matching CMM solutions to defined problems is very effective, regardless of which level an organization is trying to achieve. Some problems uncovered by an assessment fall outside of the scope of the CMM and need to take higher priority. In organizations that are SEI Level 1, there are usually cultural barriers that must be addressed first to enable process improvement to succeed. For example, the lack of clear business priorities and the perceived lack of management commitment to improvement would take higher priority than addressing Configuration Management (CM). Creating a Foundation Many organizations prematurely focus on developing detailed engineering processes when they suffer from the chronic scheduling problems of level 1. The processes are bound together to become the best-practices guide or procedures manual, regardless of how good or applicable the content is. Progress is then declared. When organizations plan inadequately and overcommit themselves, there is little time to perform even the basic tasks of development and testing. Product defects become numerous, rework increases and detailed procedures are ignored. The intent of adopting the practices of SEI Level 2 is to provide a solid management foundation for software development. This results in a stable environment that enables further improvements to be made. Process stability comes from the increase in accuracy and predictability of schedules, early identification and attention to problems, the management of commitments, and the control of changes to the product. The Key Process Areas of Level 2 are some of the most difficult to implement, the most effective and the most avoided. Process Improvement and Process Documentation Many organizations that initiate a process-improvement program rush to write process documents. These documents can become large, all-encompassing, overwhelming - and are often ignored. The process-improvement effort is seen mostly as generating paper, and the concept is abandoned. If "process improvement" is defined as improving processes, not just documenting them, and "process" is defined as "people, tasks, tools and the interaction of these to achieve a specific result," "process improvement" becomes the improvement of many key aspects of the organization, not solely process documentation. Process quality is also important. For example, a schedule-estimation process needs to demonstrate accurate or improving estimates. A CM process must enable a team to effectively control changes and reduce the number of mistakes caused by the lack of CM. The SEI has some standard items to consider for the overall effectiveness of each Key Process Area (and process). I have added some notes to each item: Defined - describes specific steps Documented - written, but try keeping it to two pages to keep it simple Trained - people can learn it easily Practiced - it is used (even in crisis) Measured - keep the measures simple and results-oriented Maintained - someone owns and updates it Supported - management expects and rewards the techniques Controlled - changes are controlled Verified and validated - check that processes are executed correctly As you look at each process you are improving, consider the above quality criteria. The Common Features section of the CMM provides more detail. Knowing When You Reach the Next SEI Level Some organizations use written processes and policies as an indicator of their process maturity rather than looking at the results of the organization. For example, sometimes claims of SEI Level 2 are made with insufficient attention placed on how effectively software development is managed. Organizations at Level 2 need to have mastered the six Key Process Areas, not be novices! Level 2 also requires process discipline-the ability to plan and use the defined processes in and out of a crisis. Summary The CMM is a reasonable and well-thought-out collection of activities to help organizations improve. Its beauty is that it does not contain every known practice and that it provides a road map for improvement. When it is used in balance with a business focus and a problem-definition mechanism, it provides a clear model for improvement. Top of newsletter

Report review "Benefits of CMM-Based Software Process Improvement: Initial Results," Technical Report CMU/SEI-94-TR-13 ESC-TR-94-013 This technical report examines initial results of the effects of CMM-based process improvement efforts in an attempt provide a stronger business case for investing in software process improvement. The paper provides descriptions of improvement activities and aggregate results. It includes case studies for Bull HN, Hughes Aircraft, Schlumberger, Texas Instruments, and Oklahoma City Air Logistics Center. Also providing data for the report was GTE Government Systems, Hewlett Packard, Loral Federal Systems (formerly IBM Federal Systems Co.), Lockheed Sanders, Motorola, Northrop, Schlumberger, Siemens Stromberg-Carlson, and the U.S. Navy Fleet Combat Direction Systems Support Activity. Every organization has done different things and kept different data, but all organizations have convincing data and anecdotal evidence that together provide a compelling business case for process improvement. --- Mary Sakry Top of newsletter