Abstract

This is the story of my experiences helping implement change and improve software development practices at Lotus, a multi-billion dollar company, over a two-year period. We used the Software Engineering Institute’s (SEI) Capability Maturity Model (CMM) as a framework for improving software development processes. During these two years, senior management changed four times. As a result, we continually realigned our goals. We used Lotus Notes as a corporate information repository and as the basis for generating reports that were (and still are) used to track project progress and coordinate shared components and products in a manageable hierarchy.

Before this work started, there was no shared divisional information for the suite of products including:

  • No shared, coordinated project schedule information
  • No integrated project and cross-functional program plans for a suite of five products
  • No integrated project plans for 22 shared components used by the suite or the products

Process improvements can occur with and without direct senior management sponsorship if changes are implemented carefully and flexibly. Thoughtful change management includes attentiveness to the organization, the culture, and most importantly to the people that are affected.

In The Beginning

(Or what the Elephant looked like to the Ant)

Once upon a time there was a big multi-billion dollar company that developed software. This company had five different software development organizations under one business unit headed up by two Senior Vice Presidents. One VP was operational and the other VP was business focused. The operational VP knew that they could develop software better through improved practices. The other VP did not think positively of process improvements and thought that it would incur unnecessary bureaucracy, delay product releases, and inhibit creativity. So, we had one clear champion and one potential detractor.

At that time, there were 1300 engineering personnel distributed in five vertical product line divisions with decentralized functions and five Vice Presidents. The only centralized functions were finance and process improvement. The product line divisions each had different cultures, varying degrees of process, tools and methods, and were geographically dispersed. The business unit was just starting to release products under the Suite umbrella so understanding and coordinating interdependencies and connections were crucial.

There were five products using a common set of components incorporated into a suite; however, schedules and functional information were not known or shared. Most of the products or components did not document or communicate their requirements, schedules, project plans, or functional specifications.

The company had tried at least four times over the past two years to help the vertical product line divisions “work together” by implementing common processes and using technology without success. Now, the operational Senior VP knew that they needed someone who had experience with process improvements and could help move the organization forward. I was hired to head up the Process Improvement Group, a team of 5 people including me; three people allocated 100% of their time to process improvement and two dotted line reports from the corporate process group who dedicated 75% of their time helping our efforts. This group was different from the development groups. It had no direct product responsibility and was four levels away from the Senior VPs. And yet, positive changes happened and flourished.

Establishing a Baseline

(Or how the Ant checked out the Elephant)

Prior to initiating any changes, I felt it crucial to understand the current environment as well as the history of the organization, cultures, people, and previous improvement activities. I utilized the following set of steps to identify what changes would work and what would not work. As it turned out, I used these steps several times, every time the organization changed.

Step 1: Walk about, talk about – Learn and capture all you can about the environment, the organization, the people, how to get things done, unwritten rules, any problems that are being encountered, and desired changes.

Step 2: Set the Stage – Tell everyone what you plan to do.

Step 3: Identify and align yourself with key influencers and early adopters – Find out who will try out things and who, organizationally, will help deploy improvement activities.

Step 4: Identify and establish ties with the resistors – Although it may be easy to figure out who the resistors and detractors are, it is harder to get them to work with you. In some cases, the influencers or peer pressure can help.

Step 5: Communicate – Tell everyone what you are doing and what has been accomplished.

Step 6: Involve yourself in development projects – Attend meetings and let people know you are willing to help, consult, listen, advise, whatever they need.

Step 7: If the organization changes at the Senior VP level, go back to Step 1! (I encountered this step 3 times in a two-year time frame.)

Step 8: Don’t get discouraged – Look back every six months and see what you’ve done and what still needs to be done. Communicate improvements and don’t lose your perspective.

The rest of this paper describes the changes made during the tenure of each of the senior Vice Presidents.

Senior Vice Presidents 1 and 2

(Or the home of the Elephant)

A structured and documented development process had been developed before I started. Unfortunately, it was not being followed. A handpicked team of development people developed a wonderful set of guidelines, standards, and templates. This team utilized a lot of the literature and took advantage of some consultants. However, they developed the process in isolation. They did not include the rest of the organization to get buy-in at various stages. When it was rolled out, there was resistance to the proposed process. Some key lessons from this attempt are:

  • Developing a perfect process does not mean that it will be used.
  • People will not adopt something that does not demonstrate value.
  • People want to be included in developing the process
  • People don’t want “hand me downs.”

The second attempt used the Lotus Notes technology to produce a database repository that contained critical project information, such as features and schedules. The responsible group managers (or their delegates) were supposed to update and maintain the database regularly. There was resistance to this too and the database became inaccurate and thus not used or useful. There were two reasons why the database was not used actively. First, individuals were not required to update it. It was not part of anyone’s goals and objectives, other than the database’s creator. Second, they did not see any demonstrated value after the information was entered. As one person said, “A database will not change the culture.” The key lessons of this attempt can be summarized as follows:

  • A stagnant database is not useful.
  • An inaccurate database is worse than not useful.
  • When people are not held accountable, they won’t maintain the database.
  • The database by itself is worthless. In my experience, it’s worse than not having anything.
  • People will not adopt something that does not help them.

The Operational Senior Vice President still continued to be concerned about the development environment. The next attempt was to get the managers involved in identifying and solving the organization’s key problems. The business unit management team, consisting of Vice Presidents, General Managers, and Directors, had gone through a series of brainstorming sessions to identify the nine most important problems to solve and had created short-term task forces to resolve these problems. This also occurred before I had joined. The task forces that I participated in included Requirements Management for the Suite, Scheduling Effectiveness, and Process Improvement. The key lessons learned from this attempt are:

  • Short term is not necessarily short. One task force remained in effect for 2 years. However, most only lasted one or two meetings.
  • Senior managers don’t necessarily follow through.
  • Task force members should be held accountable for results.
  • Task forces should be implemented consistently.

Another set of initiatives (and attempt at improving the development environment), that was not related to the aforementioned task forces, had also been started. Because the engineering functions were decentralized, the various managers of these functions wanted to work together to minimize redundant efforts, learn from each other’s experiences, share best practices, and combine and leverage their resources for mutually beneficial results. They formed functional Steering Committees or Councils for Quality Assurance (QA), Documentation, Development, Program Management, User Interface, Product Management, Architects, and Process Improvement.

As we began to learn about each Steering Committee and Council, we identified several differences. Councils were communications vehicles. Steering Committees were problem-solving vehicles. Steering Committees consisted of handpicked representatives. Councils usually had one focal point person (with some supporting people) who set up meetings for the community they represented.

A different VP sponsored each Steering Committee or Council. Each Steering Committee and Council had one specific requirement: identify and solve problems in their areas and resolve them through task force initiatives. The Steering Committee structure was very similar to Total Quality Management (TQM) with one big difference. Training on the necessary structure and guidelines for successful implementation was not provided. Without this guidance, some of the Steering Committees were floundering. They were unsure of what they should be doing and how to accomplish results.

Some groups were more successful than others. They identified and prioritized key opportunities and began pursuing them. The QA and Documentation Steering Committees were making great progress promoting best practices, standardizing on tools, developing common standards, addressing automation, and improving translation and localization efforts. One of the Process Improvement Group members was chair of the QA Steering Committee and was able to dedicate significant time to the various projects and efforts. Having a dedicated resource was key to the success of this Steering Committee. The Process Council also had a dedicated chair.

In spite of VP sponsors, the Steering Committees encountered difficulties getting resources, setting priorities, and resolving cross-divisional issues such as implementing a common defect tracking system. The management layers under the VP sponsors were generally not aware of who was participating on what committee or task force. The participant’s managers were not holding people accountable for participating in these Steering Committees or Councils. Lessons learned from this attempt included:

  • Some Steering Committees worked better than others.
  • Training should have been provided to task force participants and sponsors.
  • Task forces should have guidelines.
  • Participants need to be held accountable for completing task force assignments.
  • Steering Committees need to communicate with each other.

The Process Improvement Group assessed the organization informally, using the Capability Maturity Model as a guide. We identified five areas that needed improvement or needed to be started:

  • Requirements analysis and management
  • Project planning and tracking
  • A common metrics program
  • A mechanism for approving and deploying task force and process improvement initiatives
  • A common process, starting with common milestones and terminology

The Process Improvement Group began working on all five areas. We developed requirements and project plan templates in conjunction with the Product Management and Program Management Steering Committees and began to roll them out. A Freelance Graphics presentation was not considered formal requirements. We sent one person to the Software Engineering Institute’s “Implementing Goal-Driven Software Measurement” course and then started a metrics project and identified and started tracking productivity, schedule accuracy, estimating effectiveness, and quality.

The Process Improvement Group also focused on the Steering Committees and Councils. We formed a group of all the Steering Committee and Council chairs so we could share common experiences, identify problems, and clarify roles. The Process Improvement group developed task force guidelines for sponsors and participants, task force steps, and then rolled them out to all the Steering Committees. The steps are the standard problem solving steps including go/no go decision points at steps 2, 3, and 4:

  • Problem identification
  • Problem analysis
  • Solution identification
  • Solution selection and planning
  • Solution implementation
  • Solution review

There were several problems we had to overcome to ensure a more successful implementation. First, the General Managers, who were responsible for deploying and committing to the task forces and process improvement activities, were not involved or even aware of who was doing what and why. Second, the Vice Presidents under the Senior VPs were not a cohesive team and did not communicate effectively with their direct reports (the General Managers) on these activities and what people were doing.

I worked with the operational Senior VP, my VP, my boss, and the VP responsible for the Process Improvement Task Force to create a General Manager’s Board (GMB) consisting of all General Managers or VPs that had operational responsibility. This group was one level down from the Vice Presidents. The GMB was chaired by one of the key VPs who was a process proponent. It was not easy to get all the appropriate people to participate. This was the first time that people at this level had worked together. This group reviewed all Steering Committee and task force initiatives, determined if they were focused appropriately, and helped with resource tradeoffs and prioritization. We held our breaths during the first meeting, especially with the detractors. However, all members felt that the first meeting was valuable, focused appropriately, and they wanted to continue the meetings.

The Scheduling Effectiveness Task Force stayed active during my tenure and was key to implementing many process improvements. This task force became the prime mover of process improvement initiatives throughout the engineering organization. Directors, managers, and technical contributors from most functional areas (development, QA, documentation, program management, international, and process improvement) and from each of the products or shared components participated. The Scheduling Effectiveness Task Force had one over-riding goal: Improve our ability to meet our schedule commitments. Since the task force had a specific focus, we were able to leverage the task force members to implement many process improvements. Part of our task force success was because we took “baby steps”&emdash;small, coherent, specific actions that generated specific results&emdash; in the organization. We knew the “big bang” approach would not work (it had already been tried), and we knew it would be met with major resistance.

Our first goal was to identify common milestones that all groups used. We knew that these milestones meant different things to each group. We knew that the groups were not aware that each term had a multiple meanings. We selected five milestones (Alpha, Beta, Feature Freeze, Code Freeze, and Gold) and produced a set of milestone clarification questions related to each term so that people could understand these differences.

For example, in some cases, Beta meant product qualification by an external source. In another case, Beta was used for customer evaluation of the features and user interface. In yet another case, Beta was used as a quick sanity check to indicate product readiness to the press. This meant that Beta could last from 4 weeks to 6 months. Just saying “yes” could lead to a real misunderstanding of how long you would be in Beta if additional clarifications were not determined. So, if someone said they had a product going to Beta, we would ask, “Who is getting the product? How many customers will use it? What testing has occurred? Is it suitable for production work?” and so on.

We also developed a guide for developing products, entitled Survival Handbook for the Project Development Cycle. It contained

  • An overview of the project development cycle
  • A description of project meetings and reviews
  • Scheduling and project tracking tips and techniques
  • Information on what to do when you are thrown in the middle of a project (and the project has no documentation)
  • Milestone clarification questions
  • International considerations
  • A set of project documentation templates (for example, Market Requirements Document, Project Plan, Development Plan, QA Test Plan, Global Planning Checklist, etc.)

We rolled the Survival Handbook for the Project Development Cycle out in a variety of ways. We used the Process Council to communicate our status to the organization. The Scheduling Effectiveness Task Force members were responsible for distributing it within their organizations and ensuring VP and GM sponsorship and deployment.

We were really making progress and getting buy-in and support from all areas of the organization during this time. Then, guess what…. It was time for an org change!

Senior Vice President 3

(Or the Elephant changes spots)

This organizational change split the business unit into two divisions, one for communications and one for the desktop. Senior VP 3 was responsible for the Desktop Division, although, several communications products and components were required for the desktop suite. The VP layer was eliminated. The General Managers now reported into the Senior VP. The General Manager’s Board was no longer needed because the GMs were now working together at the VP staff level and it was disbanded. In addition, the QA, Product Management, and Program Management functions were centralized with the Process Improvement group reporting into the Program Management group (only 2 layers away from the Senior VP now!). At this point, the VP decided to release the suite before the individual products. This change made most of the improvement initiatives from the previous VPs critical. The products and the developers had to work together and communicate in similar ways. Common terminology was crucial if we were to share and depend on each other’s schedules.

We started by producing and maintaining a suite project schedule and plan based on the key milestones. The master schedule consisted of the schedules and plans for 22 shared components and five products. We used the project plans to manage the current suite and to help plan for the next suite release. We still had synchronization issues, especially with shared components. When we prepared to demonstrate early releases of software at a trade show, we discovered that not all products were using the same version of shared components. This caused product operation failures when products were run on the same machine. We knew we had to coordinate and synchronize these versions for the show. We also knew we had to do something different to improve our productivity and to prevent suite execution problems.

We developed a Notes database that contained information about all products and shared components. It was clear that people would not “use” this (or any other) database if they did not receive anything of value from it. We began collecting information on all products and shared components and populating the database. We had one document for each product and shared component. We determined the parent/child relationships of all shared components and products. The information we gathered included:

  • File names
  • What shared components were used (the children)
  • What products or shared components used this shared component (the parents)
  • Installation information (requested by the common install shared component group)
  • Schedules based on the milestones
  • Contact names and numbers, including all functional areas and international contacts

After we had established a baseline of information, we could determine who was using what. This was a very illuminating exercise. Several shared component owners were not aware of all the other shared components that were using them. We were able to fill in several missing pieces. We then produced a cross-reference chart at the DLL level. This was useful but very difficult to read. We had talked about the shared component “food chain” but, due to its perceived complexity, no one had mapped it out. >From the cross-reference information, we were able to produce a hierarchy chart. This chart gained immediate acceptance by the products and shared components groups. It provided needed information in a clear unambiguous way. See Figure 1. In fact, this chart became the main vehicle for managing suite development. Since we were able to identify which shared components needed to be provided first in the build process, we expanded the chart to include component and product build numbers and availability dates. It is still in use today (more than 2 years after I left).

Tier 0 &endash; A SC with no dependencies and not used in any other SC (just used by products)

Build No.

Availability Date

Files

Component 1

V6.1.10

4/1/97

COMP01.DLL
COMP01.HLP

Component 2

551

4/3/97

COMP2.DLL
COMP2.LIB

Tier 1 &endash; A SC with no dependencies and in another SC

Build No.

Availability Date

Files

Used in Tier #

Component 3

 7.0.1.9

 3/22/97

COMP3.DLL

(T2, T3, T4)

Component 4

 3115a

 1/10/97

COMP4.DLL

(T3, T4)

Tier 2 &endash; SC Client with Tier 1 dependencies

Build No.

Availability Date

Files

Used in Tier #

T1 Components Used

Component 5

V3.1.4.9

2/22/97

COMP5.DLL

(T3, T4)

Component 3

Tier 3 &endash; SC Client with Tier 1 and Tier 2 dependencies

Build No.

Availablity Date

Files

Used in Tier #

T1 Components Used

T2 Components Used

 Component 6

1.9.17

4/10/97

 COMP6.DLL

(T4)

Component 3
Component 4

Component 5

Tier 4 – Products

Build No.

Availablity Date

Files

T0 Components Used

T1 Components Used

T2 Components Used

T3 Components Used

Product A

 

 

 

Component 1
Component 2

Component 3
Component 4

Component 5

Component 6

Product B

 

 

 

Component 2

 

Component 5

 

Product C

 

 

 

 

Component 3

 

Component 6

Figure 1

Now that the build data was visible, we encountered another problem. Products were getting shared component builds from the individual groups in an inconsistent manner. The product and shared component groups met and decided to use a shared server that was available at all sites worldwide. This made it possible for the geographically dispersed groups to get shared components as soon as they were posted. This was also a tremendous help to the international groups as we were producing simultaneous releases in seven languages.

Because all this information was stored in the Notes database, we were able to demonstrate additional value. We generated many other reports that were stored in this repository, including an alphabetized list of shared component files, a contact sheet for each product/shared component by function, synchronized build schedules, and a suite schedule. As this database became recognized as the place to go for suite information, project participants began posting product and component guidelines, such as naming conventions, directory and registry structure guidelines, and linking and loading guidelines. Project guidelines were also stored in this database, for example, Checklists, Templates, Task Force Guidelines, and Processes.

The Notes database evolved to become a key element of the software development process. It was replicated at ten sites worldwide, updated regularly, and considered an accurate and necessary part of the development process. The international sites depended on it heavily, especially the Far East. They were able to get accurate information without having to make a phone call or send an email and wait 12 hours for a response.

Senior Vice President 4

(Or the Elephant has stripes)

This change was very short lived. This VP was not actively involved in the suite. We did not have to change anything we were doing. We were very focused on releasing the current suite and improving the build and test environment. We just kept doing what we had been doing and improving it.

Each product group was responsible for building and testing their product. These products were then passed to the suite team for integration testing. Because we had schedule information, we were able to map out what we were doing and when. We identified what suite tests could be run in parallel and those tests that had to be run serially. This allowed us to improve our test cycles, shorten the build and release cycle, and not sacrifice testing time.

Senior Vice President 5

(Or the Ant decides to find another Elephant)

This VP eliminated the General Manager layer and had the Development Directors reporting to him. The directors were many of the same people (both influencers and resistors!) who had been and were involved in the Scheduling Effectiveness Task Force. We had accomplished a lot. We had plans and schedules that were communicated organizationally. The hierarchy chart was used to manage the suite releases. People were updating the Notes database. And it was time for me to find different challenges.

Summary

(Or reflections of the Ant)

In my experience these situations and challenges are not unique. Organizations are constantly being changed, realigned, downsized and stretched. By identifying and solving problems that the people in the organization recognized and wanted solved, we were able to change the development process and implement measurable process improvements.

At the end of two years of process improvement work, we had:

  • Shared divisional information for the desktop suite of products
  • Shared, coordinated and managed project schedules
  • Integrated project and cross-functional project plans for a suite of five products
  • Integrated project plans for 22 shared components used by the suite or the products
  • Common terminology with common meanings
  • A practical, useful, and dependable database repository used worldwide
  • A mechanism for shared component and product build distribution

The Process Improvement Group was able to make changes because we persevered. We also learned a lot. We were successful for a variety of reasons.

  • The work we did was directly related to the ongoing projects, the things people have to do for a living. The project participants understood the problems and helped develop, push for, and implement the changes.
  • Small specific changes worked. Many “baby steps” added up to significant changes.
  • We were willing to do whatever it takes to start improvements and we involved everyone along the way. We used several techniques. In one case, we developed templates including the appropriate functions in the development and rollout. We did not mandate their use. Instead we encouraged usage. In another case, we did all the database collection and entry. We included the appropriate functions to identify their information requirements.
  • People helped improve processes when they saw the value of what they did. We provided information in an understandable and palatable way. This information filled several needs and people began to depend on it.
  • Finally, every process needed to be nurtured. It can’t be rolled out and left alone. We paid attention to how each process was being used and what problems were being encountered. We then fixed it or provided clarification.

Every product organization’s goal is to produce products on time that meet or exceed your customer’s needs. Remember that everyone in the engineering organization is your customer. If the products don’t “look good,” the process probably doesn’t look good either. The key to successful process improvement implementation is to establish a living, flexible process that is improved based on experience. It can not ignored or thrown out when there are problems. One person can make a difference. I did and you can too!

References

Capability Maturity Model for Software, Version 1.1

Weinberg, Gerald M. (1995-1999) The Quality Software Management series, Volumes 1-4