Software Management Practices: Positive and Negative Practices for Quality

© 1996 Johanna Rothman.

Introduction

Many software organizations are working actively to improve their product and process quality. We can review their implicit and explicit management activities and ask:

  • Which activities have had a positive impact on process and product quality improvement?
  • Which activities have had a negative impact?

We can then develop a list of typical problems and solutions to those problems.

Paths to Software quality improvement

In order to define when software quality has improved, it is important to ask what software quality is. Crosby (Crosby80) defines quality as conformance to mutually agreed upon requirements. Weinberg (Weinberg92) defines quality as value to someone. Grady (Grady92) defines quality as adherence to the goals of the organization. For this discussion, we will define software product quality as the degree to which the product meets customer and organizational expectations along lines of pricing, specification, and schedule. For commercial organizations who need to move quickly in the marketplace, this definition covers both the speed at which they need to develop and sell their products and the importance of producing the appropriate product for the customer.

There are probably as many paths to software quality as there are managers. However, there is a common theme which many organizations follow: the need to balance the needs of the customer with the needs of the organization. The following cases are of managers in different software engineering organizations. The common themes to these cases are:

  • the need to make a particular market window
  • sophisticated users, able to use the product in an “expert” manner
  • talented software engineers, capable of designing, implementing, and verifying complex real time systems.

Case Studies

One company (here called ObjectWorld) is a manufacturer of hardware and software designed to make object oriented programming easier. Another company (PhoneHome) is a manufacturer of telecommunications equipment, designed for use in the commercial sector by the Regional Bell Operating Companies (RBOC). The last company (ViewIt) is a manufacturer of remote sensing equipment designed for the commercial sector. These companies have similar features:

– demanding, sophisticated customers
– quick development cycle to make additional features available quickly
– the need to publicly announce ship dates and then live up to those dates

For confidentiality reasons, real company names are not provided.

ObjectWorld

In the mid-1980’s, ObjectWorld realized that continuing its strategy of proprietary hardware to sell its software was untenable for the long term. It started to remake itself into primarily a software company with less reliance on internally developed hardware. As this strategy evolved, the software products became even more complex, and were harder to develop and debug. The company started spending more money and time on supporting product already in the field. The company thus had a difficult time planning and implementing project plans for new products. As a result, the software engineering organization spent less focused time on developing new products. The software engineers recognized that the processes were not sufficient to deal with the problem, and that other ways must be determined to bring the problems under control (See Figure 1).

5icsqfig1Figure 1: ObjectWorld Product Development Problems

There were three levels of “interested employees” at ObjectWorld: Senior management (President and VPs); middle management (Directors and Senior technical contributors); and the technical contributors (including first line managers). First line managers made technical contributions.

Senior Management took what they thought were reasonable steps- they put a number of managerial controls into place, told the development staff to develop better products, and started to refine a long-term competitive strategy. One of the managerial controls was biweekly “Operating Committee” meetings. Every two weeks, all Director level managers would present the status reports to the other directors and senior management. Resources could be channeled to projects in trouble.

Unfortunately, a number of unintentional events occurred.

1. The meetings took more time to prepare for and attend, so that the middle manager in charge was taking time away from the project and spending it on status generation and reporting.

2. The meetings were not well run, so there were discussions at the meetings that were inappropriate (too technical, not relevant to all attendees, etc.).

3. Too much detail at the senior level led to requests for more detail at the middle level which of course, led to more requests at the technical contributor level.

After a short time of this, both middle and senior management realized what was happening and stopped it. Senior management specified tighter agendas for these meetings and middle managers started tracking their projects very closely and presenting only the project information at the Operating Committee meetings. That slowed the drain on product development resources. Middle management proposed reengineering the software development process. Senior management didn’t understand why the process should be decomposed and reengineered, but they trusted middle management’s recommendation. Therefore, senior management didn’t resist the reengineering proposal.

The software process definition was addressed in three parallel steps:

1. How to define what the product was supposed to be- get the customer requirements.

2. How to develop software and do initial testing.

3. How to do final system test, beta test, and respond to bugs in the field.

Different middle managers took responsibility for each of the three steps.

There was a very active user group for the company, so there was substantial input by the current users for new features of the product. ObjectWorld did not understand the need for or how to determine customer requirements from future potential customers, so part of the first process was not implemented.

The software engineering staff agreed on a number of milestones (feature freeze, code freeze, beta freeze), and a number of accepted technical practices (code review of all code generated after code freeze, code review of all code in particularly difficult parts of the system to implement). Middle management and the engineering staff also agreed on how to develop schedules (iteratively), and how to publish them (broadly). There was a formal beta test process defined and successfully used for a number of years. The software manufacturing process had extremely well defined entry and exit criteria. Readiness reviews, for reviewing the number and type of outstanding bugs in each area of the software were held before beta and general releases. System testing was highly automated, and some developers worked as hard on test code development as they had on product code development.

As a result of these processes, the number of major bugs declined before the software was released, and the number of people required in software support declined over time.

The process changes became part of the culture of the software engineering organization. The technical contributors became responsible for integrating the process changes into the culture. They began to refuse project plans that weren’t based on the process.

ObjectWorld increased its product reliability and decreased the number of defects in its products. Customers and the company agreed that the software improved in quality.

ObjectWorld Positive practices

1. Management did not try to solve the problems of the engineering staff. Management defined the problems as it perceived them, but not the solutions. The engineering staff had the responsibility and capability to find and implement appropriate solutions.

2. Project planning was more defined, with specific milestones every project had to meet.

3. Dates for replanning were built into the schedule (iterative scheduling).

4. Each project’s schedule was published to the entire company, along with an integrated schedule highlighting all major milestones.

5. Instituting code reviews at particular milestones in the project enabled the engineers to find bugs as cheaply and quickly as possible.

6. The end game, the final test and release part of the process, was extremely well defined. If a project made it to the entry criteria for the end game, it was obvious how long it would take to ship.

7. The process was completely integrated into the company culture. It was integrated by choice (complete agreement by the technical staff), not by fiat from management.

ObjectWorld Negative practices

1. Insufficient requirements generation made for fuzzy project plans at the beginning. In turn, less capable developers were not able to understand how their pieces fit into the whole project.

2. The notion of critical path planning was not well integrated into the process.

ObjectWorld Conclusions

1. Management did not delude themselves into thinking everything was fine when it was not. Both technical contributors and management agreed that problems existed. Each set of people solved the problems they knew best how to solve.

2. Technical buy-in at the technical contributor level was the most useful component of process improvement changes made by ObjectWorld. Company culture can be a very powerful force, especially when used for process, project, and product improvement.

PhoneHome

PhoneHome had a very successful product introduction, and by the early 1990’s were in the midst of the negative feedback shown in Figure 2. To satisfy the market PhoneHome created, additional product features were required. It was difficult to find adequate resources to verify the product features throughout the lifecycle, and product was shipped prematurely.

5icsqfig2
Figure 2: PhoneHome Product Development Problems

PhoneHome started spending more money and time on supporting product already in the field. There were insufficient field people to support the current products, so engineering staff were frequently called on to support the products. At one time, there was an estimate that 40% of all Software Engineering product development time (development, documentation, SQA activities) was spent on support of products in the field, in addition to the technical support staff.

In addition, PhoneHome had a customer perception problem. The major customers (RBOC representatives) were quite willing and eager to work with PhoneHome representatives to define features for the product. At the same time, a major customer who was demanding the new features and early delivery was also concerned with the quality of the delivered products. In particular, some products and features were quite reliable, but a substantial minority of products and features were not sufficiently reliable. This major customer had encountered this problem themselves, and adopted TQM practices to solve it. The customer demanded that PhoneHome adopt appropriate management practices to solve this problem. The customer would then start to audit PhoneHome’s process to verify the changed product development process.

PhoneHome also had a difficult time planning and implementing project plans for new products. As originally happened with ObjectWorld, the software engineering organization spent substantially less focused time on developing new products (See Figure 1). There were few management controls on the production of software products. PhoneHome had just undergone tremendous personnel growth in the Engineering area, increasing in staff from 15 people to 50 and then to 100 people. The previous culture, including project management, was oriented around 5-15 people working on related components of a major project . For relatively small projects, the culture (informal reviews, informal planning, informal verification) worked quite well. That culture could not sustain a 50-100 person organization working on multiple major projects. There was insufficient communication among the technical contributors and middle management. One result of that communication lack was inadequate risk analysis of product state.

There were the same three levels of “interested employees” as at ObjectWorld: senior management (President and VPs); middle management (Directors and Senior technical contributors); and the technical contributors and first line managers. Many of the first line managers also made technical contributions.

Near the end of one product development cycle, the auditors requested a process audit. A process audit reviews the process documentation and project evidence that the process was followed. It does not specifically review a particular product’s quality.

The first process audit had a number of non-conformances in the areas of managerial control, and system testing. Managerial control refers to project phase definition of a project, entry and exit criteria for each phase, and how these phases interact with each other. For example, an initial planning phase would have specific entry and exit criteria for how to enter and leave the phase, and list activities related to how to plan a project, how to verify the plan, and how to monitor the plan.

Engineering management decided to write a Process Manual for phase definition and control. The auditors recommended this step. There were a number of good reasons for writing the manual- the customer wanted the company to do so, and Engineering needed a way to unite all the new employees from different cultures into one culture. Some negative issues regarding company culture and practices surfaced during the writing of the manual:

1. The technical contributors wrote less than 10% of the manual. The technical contributors did not have an opportunity to discuss the process issues involved in the manual. The Software Engineering Directors wrote the contents of the manual. The amount of technical contributor involvement was directly proportional to the immediate culture change.

2. The process chosen by the Software Engineering directors reflected what the company said was the corporate goal, but did not reflect how the company actually made decisions. A slightly modified waterfall model was chosen as the one and only development process. In reality, a spiral model would have met the needs of the customers and Engineering more for large system development, and a concurrent engineering model would have met needs for patch and very small system development.

A few positive things came out of the manual writing:

1. The appropriate use of the software configuration management system was defined.

2. Instructions for how to create the product for shipment were defined.

3. Specific entry and exit criteria for customer acceptance testing were defined.

4. System testing became more creative and had better coverage than in previous releases. PhoneHome increased the number of bugs found during system test as compared to the number of bugs found at acceptance testing or customer sites.

As a result of these process changes:

  • The number of bugs known before the customer acceptance test started was higher. PhoneHome found the bugs, not the customer.
  • Engineering knew the count of open bugs, and undertook appropriate risk analysis.
  • The number of major bugs declined before the software was released. The software was more reliable.

There were other high leverage activities that PhoneHome did not undertake. For example, PhoneHome did not use iterative scheduling techniques and broad schedule publication. Project schedules were extremely aggressive and difficult to achieve. Senior management had a concern: broad internal publication of the schedule would be potentially damaging to the company in case of schedule slips. Damage would come in the form of “leaking” the internal schedule to the customers and having to reset the customers’ expectations.

During this time, PhoneHome’s senior management was promoting TQM ways of thinking and working, but did not internalize TQM ways of working. Instead of posing problems to project leaders or managers, senior management frequently imposed solutions. There was a substantial amount of short-term thinking and action. One piece of evidence of this short-term thinking was the use of voicemail for asking people to work on “critical” or “urgent” activities, only to discover after one had finished the work that the product of that work was neither critical nor urgent. There were also many poorly run, lengthy meetings that were unrelated to product development.

The original process changes at PhoneHome did not become part of the culture of how the software engineering organization worked. After more audits and technical contributor rewrites of the process manual, the process started to become integrated into the culture. For example, people state their problems with another group instead of a solution. The process is not seamlessly integrated into the company culture. The company is still working to balance short term needs with long term needs in its daily activities.

PhoneHome Positive practices

Over time, PhoneHome increased its product reliability and decreased the real number of defects in its products. Customers and the company agreed that the software improved in quality. The positive key practices that PhoneHome implemented:

1. Defined a process that worked for large, customer-cooperative, complex system development. That process included entry and exit criteria for each phase, and code reviews for all new code. It also included bug tracking within each phase and within each project (bugs found per phase per product release).

2. The back end of the process, from customer acceptance through shipment, was extremely well defined. If a project made it to the entry criteria for customer acceptance, it was clear how long the acceptance testing and final debugging would take.

3. Major customers were consulted at many points during the software development process.

PhoneHome Negative practices

The negative key practices of PhoneHome:

1. Management stated solutions instead of stating the problems. This was a symptom of all management, with the most dramatic examples starting at the top of the company. This was partly due to lack of goal setting by senior management.

2. Not taking the current company culture into account when it was time to develop a new culture. The new process was defined by fiat, certainly not a way to guarantee acceptance into the organization.

3. Assuming that a strict definition of one software process was sufficient for all of Software Engineering’s responsibilities.

PhoneHome Conclusions

1. Management never asked: “Is there a problem with how we do things around here?” If middle or senior management had asked the question, the project and process problems would have surfaced earlier.

2. When a company is not focused on their business (product development and support) it is easy to let other interests take precedence over the business. For example, the supposed TQM practices involved many committees and extracurricular activities, both of which required substantial planning. Too often, managers who were supposed to be focused on products were focused on activities that were tangential to product development. Integration of TQM practices into a company starts with the definition of company and product goals, and then by acting on the those goals. This has the double benefit of keeping the company focused on the products and showing all employees how to use the TQM practices in daily work.

3. Technical contributors had many valuable comments about process improvement. The valuable components of the very first process manual were all developed by technical contributors. For process improvement to work, the technical contributors must be a part of the problem definition and solution.

ViewIt

In the early-1990’s, ViewIt experienced the typical software engineering crisis: there were too many features to put into its legacy software, not enough time to do it, and there were too many bugs uncovered during system testing.

5icsqfig3
Figure 3: ViewIt Product Development Problems

ViewIt had already started spending more money and time on supporting product already in the field. There were insufficient field people to support the current products, so engineering staff were frequently called on to support the products (see Figure 1). At one time, there was an estimate that 20% of all Software Engineering product development time (development, documentation, quality assurance) was spent on support of products in the field, in addition to the technical support staff.

The company also had a difficult time planning and implementing project plans for new products. The tendency was to develop project plans for the beginning of the project, and not update them as the project went on. Product shipment decisions were based on how the software “felt” to the SQA personnel, rather than by analysis of objective metrics. As with ObjectWorld, the software engineering organization spent substantially less focused time on developing new products. Software Engineers changed roles frequently: either they were pulled off development projects to work on field-generated crises, or as projects changed importance in the minds of senior management, project resources (people and machines) were reallocated.

There were only two levels of “interested employee” at ViewIt: senior management (President and VPs), and the rest of the company. ViewIt has a very controlling, strictly hierarchical organization. Only the Vice Presidents or the President truly have the flexibility to make resource tradeoff decisions- all other decisions, including those of project leaders, can be reversed by more senior management. Senior management has a very short-term vision- they believe that if they make all the correct decisions for the short term that the long term will take care of itself.

ViewIt has a very technological approach to some of the problems of software engineering- they bought and implemented a reasonable bug-tracking tool and an excellent configuration management system. On some projects, the technical contributors insisted on writing unit tests and doing code reviews. When management insisted code review and unit test time be eliminated to make a particular schedule, the engineers agreed but received management commitment that these practices would be instituted again once the deliverable was complete.

ViewIt has not had a significant catalyst for change yet, as ObjectWorld and PhoneHome did. There are a number of middle managers and individual contributors who would prefer to work differently. There are two tensions for employees: balance of short-term gains against long-term engineering investment; and the balance of work against the rest of people’s lives. ViewIt has technically challenging work, extremely aggressive schedules, and a young work force. In the past, people have worked whenever necessary to complete a project. As more technical contributors take on added responsibility outside work, such as additional education or families, they are less likely to work 12-16 hours per day for long periods of time.

Technical contributors demanded changing practices. The effects of those demands:

1. Project management practices are changing. Project leaders now update their project plans on a regular basis.

2. The SQA group gathers metrics for readiness reviews to determine the ship risk based on the state of the code instead of how the product “feels”.

3. The Engineering staff adopted a concurrent engineering methodology in order to reduce product development time.

4. Most projects use code reviews to decrease the number of bugs found during system test.

5. Most projects develop unit tests along with the code to reduce the time required for system test.

The effect of these changes has been to increase development efficiency during product development, reduce product development time, and to be able to predict when a product will be ready to ship. Quality and changing quality practices are defined by the software engineers and engineering management, and presented to senior management.

As the company grew, senior management also required a process change: project managers are expected to be able to describe the complete state of their projects at any time.

As a result of these process changes:

1. Projects tend to keep their resources for the entire duration of the project, unless the project is cancelled.

2. Product ship decisions are based on objective criteria.

3. The state of the software is understood (bugs, checkins, etc.).

4. For almost every project, the number of open major bugs has declined before the software was released.

ViewIt Positive practices

Over time, ViewIt increased its product reliability and decreased the real number of defects in its products. Customers and the company agreed that the software improved in quality. The positive key practices that ViewIt implemented:

1. Defined an objective ship-review process based on objective criteria.

2. Defined a planning process for projects and informal reviews which illuminate the effects of resource tradeoff decisions.

3. Defined and obtained sufficient technological tools to increase software engineering productivity.

4. Implemented code reviews and unit test development to discover defects earlier in the project.

ViewIt Negative practices

1. Management states solutions instead of stating the problems. Senior management still makes all the resource decisions. They do not always understand the data they have from the project leaders. Even though senior management claims to make decisions based on the short-term, frequently the short term interests are not served by their decisions.

2. Management’s lack of interest in a formal process undermines its stated desire to ship more products on time. There is substantial talk about “quality”, but no definition of what it means. Management’s definition appears to be “ship products that are good enough on time”. The rest of the company’s definition is “ship products that have very few bugs ASAP”. The key difference is in the short-term versus long-term thinking. Senior management has a very short-term approach, because they see the immediate financial issues clearly. The technical contributors have a very long-term approach because they see the support issues and longer term financial issues clearly. Either approach is fine, but the lack of consistency leads to strange and non-optimal product and ship decisions.

ViewIt Conclusions

1. Senior management is very focused on the business (product development and support). However, they have not fully articulated the goals of any of the products, specifically the quality goals. Senior management thinks the technical contributors are happy, but the technical contributors are frustrated with their jobs and the work they produce.

2. Technical contributors are driving the process improvement work. The practices are integrated into the company culture.

These three cases have some common themes regarding management practices and the effects of those practices on product and process quality.

Positive Corporate Management activities for quality

1. Software lifecycle definition provides a framework for technical contributors. Just the act of defining the lifecycle and all activities within it clarified technical contributors’ roles, the holes in the process, and in general, made everyone realize that a product depended on each function in the organization doing its work.

2. State the problem at hand, not a solution. It is imperative for management at all levels to trust their staffs to develop solutions, or to work with their staffs to develop solutions to problems. When a more senior manager attempts to develop a solution alone, there is frequently a key piece of information missing. This leads to non-workable or non-optimal solutions.

Positive Project Management activities for quality

1. Define project plans with specific milestones and communicate those plans broadly.

2. Find bugs earlier than final test- institute code reviews, unit test development, peer review- whatever it takes to find bugs more cheaply and earlier than final testing. The earlier in the process bugs are found, the more technical contributors can learn from their mistakes.

3. Define the end game, the final test and release part of the process, extremely well. When people know what they have to do to ship a product, they will do it.

4. Integrate the process into the company culture. This means that process definition has to be accomplished with the active participation of the technical staff.

Typical problems and ways to address them

1. State a solution to a problem instead of the problem itself. It takes more work to state a problem, but the optimal solution is rarely seen by the non-owner of the problem. The problem owner must be involved in finding the solution.

2. Confusing generic Total Quality Management (TQM) ideas with quality. TQM ideas promote process thinking which can improve quality. However, a process which has no relationship to the work is useless. The processes must be defined in the context of the work to be accomplished.

3. Lack of clarity regarding corporate goals. Every company or organization has an implicit or explicit risk analysis mechanism. Managers “know” which decisions will be made. When corporate goals are made explicit to all contributors, it is much easier to develop products against the known paradigm than one that seems to change.

4. The assumption that a company develops only one kind of product in one kind of way is not valid for many small commercial companies. Different products have different goals. Different goals require different processes for implementation. The technical contributors need to be aware of which process they should follow for which project.

5. Clear specification of requirements to the product team. If the requirements cannot all be determined at the beginning of the project, then the requirements specification must be a living document. Project management must frequently review which of the requirements can be completed within the scope of the project.

6. Insufficient critical path planning. It is crucial to define the components, resources, and people on the critical path and consider ways to mitigate the risks.

Different perceptions of success

If you asked senior managers at ObjectWorld, PhoneHome, or ViewIt, many of them would have said that they were successful at improving product quality and improving the process by which the products were created. If you asked the middle managers at ObjectWorld and PhoneHome, many of them would also agree. If you asked the technical contributors at ObjectWorld, they would agree. However, PhoneHome and ViewIt technical contributors have negative viewpoints on people’s productivity and product quality. These negative perceptions are tied to the remoteness the people feel from the decisions made by senior management.

When you review all three of the cases, there was always a period of change by one set of management that took time to be accepted by employees.

ObjectWorld had a brief period of product development turbulence, followed by rapidly improving product development practices.

PhoneHome had a very long period of product development turbulence, followed by slowly improving product development practices. Engineering management did not believe they were successful at the first iteration of the process improvement work, even though senior management claimed Engineering management was successful at improving product development.

ViewIt is still undergoing product development turbulence, because the lack of consistency in just what quality means has not yet been resolved. Management is not interested in process improvement as a goal, but in the financial aspects of any product development considerations. It is crucial to understand both the long-term and short-term financial considerations of product development. ViewIt needs to address long term costs and benefits to bring a consistency of vision to the employees. ViewIt has an even more interesting morale question- Senior management believes the company is extremely successful and the employees are all happy. The technical contributors are afraid of losing their jobs and tired from working too many hours to make schedules. The company’s success is not visible to the technical contributors.

True improvement in a software engineering organization’s practices

Improvement for software engineering requires a look at these components:

1. Management- people management and project leadership

2. Engineering practices- the process, how the process works

3. Tools- tools to support good software engineering

Excellent engineering management is a difficult commodity to find and keep. Engineering managers must understand the technology sufficiently, understand the components of each position that reports to them, understand how to define and run a project or program, and mentor people to learn how to do these things also. No wonder so few engineering managers are excellent! The range of required abilities is extremely wide. However, the world is changing such that these generalists will be more required, not less required. [Wheatley94]

The only constant in management is that it will not be the same this year as it was last year. The world continues to change, and the demands on management and companies change also. People management and project leadership are necessary skills. As companies continue to “rightsize”, there will continue to be fewer managers for more people. These managers cannot directly control everything, they must be able to facilitate solutions that everyone can agree to. Management work and priorities will continue to evolve- those who can practice facilitation and coaching will be more successful in the long term than those managers who cannot. Honest management- that is managers who are honest about the company’s goals, and how their organization’s work fits into those goals will also be more successful than those managers who cannot be honest with themselves.

Engineering processes will also evolve. A process that works for a company at a particular time may not continue to work over time. Process evolution is required, and software organizations must be ready to change their practices when warranted. At one point, many organizations used the waterfall model to develop products. Now, more companies are using concurrent engineering techniques, or the spiral model to develop products. As a company’s goals evolve over time, the product development model should evolve over time. It is imperative that the company articulate its goals for each of its products, so that all the people involved with product development can understand and make the appropriate decisions.

True quality improvement practices require sufficient technological tools for automating software engineering work, such as bug tracking, configuration management of source code and changes, and project planning.

Management Improvement

Given that the world will continue to change and that positions will continue to evolve, managers must look for ways to improve their practices. They must keep an open mind to new technologies. They must review different ways to organize their staffs. Managers need to facilitate process change with their staffs.

Managers must address all the ways they work, including meetings. Managers must review how they run meetings, and whether they facilitate discussion or stomp on it. Meetings should have a defined purpose, with agendas and minutes. Managers need to understand that meetings not related to product development waste valuable product development time (Maguire94)

Management needs to think about the roles people play in an organization clearly. Software architects in the Software Development and Quality Assurance functions can dramatically improve the work that goes on in those functional organizations. An architect-level person can mentor the other people and show them where the product has to go.

There are a number of technical practices that need to be employed in organizations: code reviews, unit test development, and test scenario design to name a few. Formal code reviews can be accomplished with as few as three people attending the review, and the benefit to the company is enormous. Developers who write unit tests tend to have a better perspective on the whole product, which leads to fewer module interaction problems. Test scenario design is a currently underrated activity. See Marick (Marick95) for suggestions for developer-oriented test design and testing. His ideas can also be used with independent testing organizations. In addition, just the act of thinking about how to design tests for the product (equivalence grouping, boundary analysis, etc.) and writing down the different scenarios will produce better test efforts.

ObjectWorld had the most successful product development organization of the three organizations outlined here, in terms of length of product life and the ability to add more features to the product. The managers were interested in management, and tended to solve problems in a consensus fashion. The company was not a democracy, but input was heard from a variety of sources, listened to, and acted upon.

ViewIt has the most problems in terms of product lifetime and the ability to add features to the products. Senior management does not facilitate the work of the lower level managers, who in turn do not facilitate or know how to facilitate the work of the technical contributors. There is a fundamental lack of knowledge about the role of the manager as a coach, and the value of mentoring (managerial or technical).

PhoneHome has few present problems in the area of product lifetime, but does have some technical problems with how to add more features to the product to continue to extend its lifetime. First line managers need to learn how to facilitate technical discussion and how to choose the participants of those discussions. The company did choose an internally consistent story about quality- and to forgo slogans, exhortations, and other irrelevant celebrations of a mode of working which the company was not willing to fulfill.

Conclusions

Traditional controlling management is becoming more rare. Managers are learning how to listen to their staffs, and how to bring other people’s viewpoints into the discussions. Managers must learn how to do this, because many companies do not have the time flexibility to make wrong decisions and recover.

A company must first prioritize its goals, in order to take large steps toward positive quality practices. Then, the company must review its activities considering those goals. Management must evaluate themselves honestly, and discard practices that do not add value or benefit to the product and therefore the company. Technical contributors also have the onus of keeping current with technical advances in how to approach and implement technology, apart from the few suggestions here. We have the exciting obligation to be proactive in managing for and implementing quality practices in our organizations.

References

Crosby, Philip B. “Quality is Free”. Penguin Books, New York. 1980.

Grady, Robert B. “Practical Software Metrics for Project Management and Process Improvement”. Prentice Hall, Englewood Cliffs, NJ. 1992.

Maguire, Steve. “Debugging the Development Process”. Microsoft Press. Redmond, Washington. 1994.

Marick, Brian. “The Craft of Software Testing” Prentice Hall. Englewood Cliffs, NJ. 1995.

Weinberg, Gerald M. “Quality Software Management, vol 1 Systems Thinking. Dorset House”. New York. 1992.

Wheatley, Margaret J. “Leadership and the New Science”. Berrett-Koehler. San Francisco. 1994.

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

Leave a Reply