Who I Am

Carolla Development is a software process consulting company headquartered in Columbus, Ohio. We specialize in teaching corporate software development groups how to build guaranteed software (no defects and finished on time). We offer mentoring in setting up QA and Quality Engineering processes, deploying state-of-the-art technology, founding technology management centers, and SEI and ISO 9000 standards compliance.

I am the lead consultant and President of Carolla Development, which has been doing business for the last six years. Our track record shows 52% of our software projects have come in with no defects [1] and on time. About 30% of the remaining projects have come in with minimal defect rates, and all repairs have been completed within 10% of the development time of the project. Not one project has been more than 15% late. From this track record, our company offers a guarantee unlike any other in the city. Carolla Development trains large and mid-size corporations in our new methodology, which includes the political, cultural, and deployment aspects of bringing in new products.  

Where I Have Been

As a consultant, I have initiated process improvement teams and worked with corporate interdepartmental process teams to develop a process that will maximize quality while minimizing the cost and time of development. I have reorganized the development process in entire MIS departments to allow ISO compliance and minimal defect development. I help install technology management centers and mentor the corporate mentors.

My role includes working with the executive management to bring about commitment and propagate accountability, as well as with the developers to train them on new processes and technique. Carolla Development advocates a 5 x 5 development model: 5 scopes and 5 perspectives. The model manages the five scopes of cost, time, technology, documentation, and corporate organization from each of the five perspectives of user, manager, tester, developer, and documenter. The process is scaleable for in four dimensions: project size (large, medium, small), type of project (new build, conversion, systems integration, maintenance), priority (urgent, normal, backburner), and quality (minimize defects or minimize time-to-market).  

What I Have Seen

Management perceives on-time and zero-defect products as a technical problem. While technical problems do exist, clearly the larger and more difficult problem lies in the management domain. If we assume that the ideal goal is to transfer the technical and managerial skill sets and the cultural and professional values of a zero-defect software development environment to the client company, then we can classify several kinds of sociotechnical barriers. Each is stereotyped below.  

Barrier 1:  The Lost.

Some groups do not want to improve their process. They shun the accountability or resist the change for non-business reasons. One large management organization was more concerned with foiling their political rivals than with increasing productivity within their department. Bluntly, they do not care if they have a problem; they exhibit professional and cultural resistance to change. One manager actually refused to incorporate computers in his shop because machines had displaced his parents in the employment ranks years earlier!

Response:

Carolla typically does not sell to these kinds of clients. Unless they can be convinced that they have a problem, ignorance is bliss in their case. In our profession’s highly competitive, global market, the Lost companies will not be able to continue business as usual. They will feel the pain of competition and change or go out of business, sometimes without ever knowing why. Yourdon has suggested that Lost companies will only last two to three years in today’s competition.

Barrier 2:  The Special.

The people in this barrier are related to the Lost group. They believe that they, or their company, or their way of doing things are so special that nothing anyone else has will work for them. This barrier reflects the "Not Invented Here" syndrome that is so prevalent in American companies. One manager from a Special company told me, with great frustration, that even if I parked in the no parking towaway zone, the company would not tow away my car. Why? Because the company hadn’t invented tow trucks.

Response:

These people are not as special as they think. If they can be shown that they use the same tools, have the same problems, and endure the same indignities as other companies, then they will often be open to accepting a similar solution within their scope of control. Carolla tries to do this by referencing convincing research studies in a general process training class and providing informational solutions to problems the employees have identified. A survey to identify the perceived problems of the company is often our first step.

Barrier 3:  The Ignorant.

This is facetiously referred to as Level 0, alluding to the SEI Capability Maturity Model (CMM); Level 1 being the official process maturity level of the SEI CMM standard. These people want to do their best, but they do not know they have a problem. This is also commonly referred to as a "cowboy environment" - the development shop is based on a few superhero-style personalities and no repeated or documented process. The Management mandates unrealistic deadlines and strenuous amounts of employee overtime. Requirements, design, and testing are minimal if they exist at all. Programmers begin coding shortly after they hear the problem, prematurely implementing a solution before the problem is well understood ("solution fixation"). Management is satisfied with this state of development because they think that if someone is coding (a highly visible activity), then productive work must be happening-also known as the WISCY Syndrome ("Why Isn’t Sam Coding Yet?"). This "skunkworks" mentality produces prototypes, which are then sold (ill-advisedly) as designed and manufactured products.

Response:

Carolla provides a general process training to management, and training classes for specific techniques (for example, object-oriented development or requirements management) to improve the developers process tactically (transfer of technical skills). Boehm [2] showed that improved tools does result in improved process. Too often, managers think that technical solutions are all that are needed. Carolla requests they be part of a working session to develop their own process (see "What We Should Do" below), and then they will attend a process management training session to get ready for it. The training session introduces the Carolla method used as a framework in the working sessions.

Barrier 4:  The Trapped.

The development shop and management recognize a problem, either from competitive forces or productivity pains. To escape from their crisis, they want to improve their processes, and they see standards or formalization as the answer. I have seen this in companies that are growing larger and trying to move from the skunkworks environment to a structured, and possibly standardized, software development factory. However, the forces that allow a manager or a technical lead to manipulate the cost, time, and quality of a product are complex and counter-intuitive. These manipulative factors, or process levers, are represented by equations of high complexity in both management (Rummler-Brache [3]) and technical project development (Putnam [4]). They cannot be calculated within individual’s heads, although long experience will give some leaders a gut-feel for what has to be done, so some successes do occur. Unfortunately, these successes contrast sharply against the more numerous failures of cost- and time-overruns, or high defect rates, which further entrenches the idea that software development is not a science, but a craft better left to the experienced masters. The skunkworks mentality is supported by a feedback process that inhibits moving to the more rigorous approach of software engineering.

Response:

Carolla tries to imbue the idea of "cognitive illusion" — the concept that people’s intuition in dealing with numbers and certain concepts yield totally wrong answers [5]. Calculation is needed, not educated guessing. People cannot trust their intuition in the field of project management;they must rely on data to make decisions. Typical cognitive illusion: "We don’t have time to test the product, let’s just ship it." Of course, the product undergoes a debugging cycle longer than the time it would have taken to test it, or a maintenance cycle that drains the programming resources far more costly and longer than the original testing time.

Barrier 5:  The Entrenched.

Management has so often attempted process or organizational change that the rank-and-file perceive each new attempt at process improvement as a new "flavor of the month". The rank-and-file will dutifully attend the training, follow the procedures for their next project or two, then they will be back to business as usual. The few that find improvement in their projects are frustrated when management moves to the next new flavor of the month, and the developers must start new processes all over again. The net result is a cynicism in management to ever do the right thing, so all new ideas are tainted before they are given a chance. One manager actually announced to his group, after a VP presentation to commit to SEI Level 2, "until it is in writing, we will do things as usual." The VP thought a simple meeting and a verbal announcement of commitment was sufficient. The VP refused to commit in writing, however, arguably because he did not want to take a stand that his political opponents could use against him (see barrier 1).

Response:

Carolla requires executive commitment for a new process, including a long term contract. On national average, it takes 2 - 3 years to convert from Level 1 to Level 2 or Level 3. Management must be aware that they are in for the long haul. Carolla has successfully converted an MIS department in 18 months by using its off-the-shelf method, but still requires a long-term contract. Once the rank-and-file see that they are continuing to use the same method, and are exposed to its obvious benefits, it will become part of their culture. The deployment plan outlined below is critical to this success.

Barrier 6:  The Oppressed.

Developers say they want to follow better processes but management will not let them do what needs to be done. Management says they want to follow better processes but the developers will not put up with the discipline to follow the methods. In a corporate survey I conducted in a large company, this situation repeated itself, even to be obvious to the developers. The reality was that the developers were willing to follow the discipline, and management was willing to allow the change to happen, as long as they were not held accountable if the results were not exemplary. Again, the oppressive cultural or political forces inhibited managers from taking a chance on change.

Response:

Although I have suggested putting these people in a room together and letting them talk it out, managers have been slow to do that. I focus each group on themselves and ask if each will do what is needed, and leave the other group to me. Usually there is no problem and the deployment goes smoothly. The general approach of developing an interdepartmental process with managers and technical people together has had even better success. (See the deployment plan outlined in the section "What We Should Do" below.)

Barrier 7:  The Undeployed.

The company develops a good interdepartmental product development process that is suitable as a de facto standard: deliverables and procedures are defined, the methodology is validated by the stakeholders, and by experience with other organizations using a similar successful methodology. The tasks ahead lie in deploying the templates, tactics, and accountabilities at the rank-and-file level - the implementation of the methodology. However, from lack of experience, or historic practice within the company, the deployment is so poorly done that the people who originally wanted it are now irritated, frustrated, and confused. The poor deployment strategy results in unacceptance of the method, and management perceives the method as the problem. Managers say things like, "We tried that here and it didn’t work," confusing the deployment with the method. In an attempt to solve the rising morale and attitude problem, someone changes the deployment strategy, adding more to the confusion. Many of the symptoms of this barrier result from departments working too autonomously and not focusing their efforts on contributing to a corporate process goal, resulting in erroneous transitional tactics.

The three most common erroneous transitional tactics I have seen that cause the undeployment barrier are (1) the "eat the whole thing at once" tactic, (2) the "French traffic syndrome" tactic, and the (3) the "local impedance mismatch" tactic. In the first transition tactic, management mandates the new practice to all groups at once, advocates and resisters alike. This causes battles to be fought on many fronts at once: battles with the resisters on general principle, and battles with advocates on particular style of implementation. The battles make waves that ripple upward to higher management until the executives are convinced that the change is either not worth the in-fighting or not feasible.

Tactic (2) refers to a story in that the French were going to change from their left-side of the road motor traffic to the American-like right-side of the road traffic. However, they decided to make the transition in two phases: all trucks on Monday, all cars on Tuesday. In our context, this means the developers are ready to go, but no support exists yet from the non-transition groups. I have seen this most clearly manifested in companies that, as part of the transition plan, require requirements to be collected and analyzed, but does not require marketing to participate in the requirements process. There are now actually two conflicting processes in place; in effect, no process at all.

Tactic (3) is similar to tactic (2) except the conflicting processes are not concurrent, but sequential; development deliverables generated by one group are not required by the "downstream" group. For example, the developers transition to building use cases and test plans, but the QA group and test group are not required to use the validation documents supplied by the developers. The testing group proceeds to build their own test cases as usual, ignoring the developers, and the developers become frustrated in doing useless work. Each department or group focuses on their own efforts, and not focused on the corporate development process. Much time and effort are wasted as the product traverses various departments and goes through the "impedance mismatching" between departmental or group boundaries. Although the product may get done, the people involved in the process are not satisfied and think too much overhead went into the process. Again, managers fall into the "we tried that here and it didn’t work" syndrome.

Response:

See the deployment plan outlined in the section "What We Should Do" below.

The success of a project is political, not technical. The technically perfect project will be considered a failure (and the project leader will take the consequences) if the users do not like it or do not use it. User satisfaction must be the key to defining a successful project.

From the successes of overcoming the barriers mentioned above, our lead consultants are given a general approach. The approach is summarized below, and its success has allowed Carolla Development to be the only company in central Ohio to offer guarantees on finishing a project on time and without defect.

1. Get executive sponsorship. Ensure that an executive has committed to process improvement at the level any reorganization may need to occur. If the processes of an MIS department are being improved, get the executive commitment from the MIS director, and ascertain that he or she has approval for the change from upper management.. If the entire company is working toward SEI compliance, for example, then the CEO must be actively involved. If the appropriate executive sponsor will not get involved, then discuss what level of support can be obtained, and set goals at these lower levels. Sometimes, Carolla can only offer technical training.
2. Mentor a PIT crew. Ask management to select a few process-minded individuals to form a Process Improvement Team (PIT crew) as a steering committee. Mentor the PIT crew members and work with the relevant managers indirectly in working sessions.
3. Develop an interdepartmental framework (product life cycle). The working session is ostensibly to develop a good intergroup process, but is critical to developing buy-in for the resultant process. The consultant acts as subject matter expert and protects the sessions from developing a process that will not work. The working sessions will produce a high-level process suitable to develop a product (not necessarily a software product) for all departments. Each department can then implement the specifics within their own policies and practices, keeping the interdepartmental process as a framework. Implementation deliverables include project meeting minutes, accountability matrices, requirements traceability matrix, validation techniques, cost benefit analysis techniques, etc. Each department customizes the framework to meet the technical and business goals. In many companies, business goals and justifications do not exist, and must be defined before the working sessions can finish. These questions are escalated to upper management.
4. Develop local variants of the framework. Each department customizes the framework to meet their specific problems, practices, and goals-sometimes called a route map. The scalability of the 5 x 5 model is important here to allow the process to scale for the size and type of products usually developed by that department. Some departments are typically maintenance heavy, others develop new build products, others do large system integration work. Each department customizes their route map until the technical and business goals are met.
5. Mentor a pilot project. Once the local route map is finished, a careful deployment schedule must be developed. Institute a project to showcase the results and validate the process. Developing the route map has been an exercise on paper so far, but the pilot project provides the data that indicates how well it works in practice; where the process must be changed. The pilot project is the only place the process can become real, and move the undeployable into success. The route map is a product that results from the contributors’ internal analysis of all the factors they perceive they will need, but real data from the pilot project incorporates the complex experiential factors as a whole. Mentoring the pilot project is important to ensure that the process is followed as documented, not as may be deemed changeable in the eyes of the project leader.
6. Deploy to the enthusiasts first. Develop a careful schedule of deliverables to the enthusiastic groups-the people likely to want to be involved on the pilot project, for example. Do not try to involve the resisters, or force the entire method on everyone at once. The method is still unproved until after the pilot project, and there is no need to fight battles getting resisters on board until the method has been smoothed out a little. Implementation details can be resolved and the revised process can then be expanded to other sympathetic groups. Eventually, as success shows up on the bottom line (cost, time, or defect results), the hard-core resisters will be hard pressed to defend themselves against not using the method. They will be in the minority; management may then mandate a corporate- or department-wide process, and the resistance battles can be fought then, with the pressure of the culture against the resisters.

This approach is based on Carolla’s last six years in optimizing corporate development processes and assimilating reports from the research literature. ComSoft [6] has shown that mentoring and pilot projects are by far the most effective way to get past the common cultural and professional barriers. Thomas Kuhn [7] has said that crisis stimulates paradigmatic change, but often the only way to bring in new paradigms is to wait until the resistors die off, literally.

Alan Cline
Carolla Development, Inc.
September 15, 1997

References:

1. "Defect" is defined as a discrepancy between the requirements and the behavior or appearance of the product. Statistically, a product can never have zero defects for an infinite amount of time. Therefore, a "no defect product" refers to a product that exhibits no defects after release of the product equal to the time it took to develop it (one development cycle). A "minimal defect product" refers to a product that exhibits defects for only 20% of a development cycle after release of the product.
2. Barry Boehm, "Software Engineering Economics", Prentice-Hall PTR, 1981.
3. Rummler, Geary and Alan Brache, "Improving Performance: How to Manage the White Space on the Organization Chart", 2/e, Jossey-Bass, 1995.
4. Putnam, Lawrence and Ware Myers, "Measures for Excellence: Reliable Software on Time, Within Budget", Yourdon Press, 1992.
5. Savant, Marilyn vos, "The Power of Logical Thinking", (St. Martin’s Press, 1996) published in popular form the result of neuropsychologist Massimo Piatelli-Palmarini’s idea that our brain does not deal well with numbers at certain levels. Even worse, cognitive illusions haunt us in the non-numerical world too. An example of a non-numerical cognitive illusion: someone swimming in an ocean riptide can not trust their intuition to swim directly for shore-a fatal mistake. They must be educated to swim along the shore until they are out of the riptide.
6. Vaishnavi, Vijay and Tim Korson, "Role of a Corporate Object Technology Center", OOPSLA’95, Addendum to the Proceedings, and subsequent tutorials for OOPSLA’96. Comsoft is a non-profit consortium of companies dedicated to initiating and improving Object Technology Centers in business.
7. Kuhn, Thomas, "The Structure of Scientific Revolutions", 2/e, University of Chicago Press, 1970.

Copyright © 2000 by Carolla Development, Inc. All rights reserved.