Reengineering of a development project


Ralph Maleus and Sture Karlsson

Have you ever experienced the frustration of the “invisible wall” in your development project? Where line managers change your project's priorities, and where key players with unique competence are assigned new tasks in other projects without your knowledge and approval? And where the customer's needs suddenly become of secondary interest? Unfortunately, this is not unusual. Particularly not in the ’90s, when many development projects have been globalized and the project manager no longer has a team under one roof.

Our company, Tetra Pak, is no exception. Most large development projects in our company experience these problems. We decided to approach solving the problems using the “reengineering” principles. Our task actually turned out to be a process referred to as “breakdown of customer needs to development process” {BD (CN) img DP}. It may be premature to say that all the problems have been resolved, but the results certainly look promising.


Tetra Pak is the market leader in liquid food processing and packaging. We are present in more than 124 countries, and most people in the world have probably come in contact with our products at some time in their life. The products are the packaging systems developed by product companies. The product companies are “globalized,” i.e., located in strategically important countries. The consumables (packaging material) are produced (converted) by a number of local factories throughout the world, based on specifications from the Product Companies. Since Tetra Pak is originally Swedish, it is commonly recognized that its core competence still comes from Sweden.

Tetra Pak is, by tradition, a very research-intensive company with approximately 6 percent of all employees directly or indirectly involved in research and development. Eight years ago the company began a definitive trend toward organizing development projects into project organizations, with dedicated project managers and “borrowed” resources from functional groups (for example, Mechanical Engineering, Controls and Automation, Testing). Almost all projects have been structured in this typical matrix setup.

We began this reengineering process because the problems in a strategically important project reached serious levels. We (the authors) were convinced that it would be possible to resolve these problems using reengineering methods. The task was compounded by the fact that the project is managed by members from different organizations in at least two different countries, the United States and Sweden (with the Atlantic and seven hours in between). Keep in mind, the traditional project structure is an organization that normally is a carbon copy of the organizational environment from which the project comes. We wanted to achieve a new project structure that would help us reach all the benefits shown in Table 1. Since the findings of the process seem very promising to us, and the process itself was so exciting for the participants, we are glad to be able to share the experience with other professional project managers.


We gathered a team of both “insiders” and “outsiders” with the objective of reengineering the case project. The insiders of the team had different backgrounds and different positions in the company. They came from four different states in the U.S. and from two different countries in Europe. Sture Karlsson (with experience from earlier reengineering sessions in manufacturing, logistics and administration, but not from product development projects) was the facilitator. Ralph Maleus was the project leader of the case project. Jim Bongiorno, consultant and president of Plan Tech, Inc., was the outsider. We included an outsider because we wanted to use a person with reengineering experience from another industry who could question our “industry axioms.” The reengineering took the form of a workshop, lasting two intense days. Before the workshop started, Sture organized separate pre-meetings to bring everyone to a common level of understanding of the problem, and to introduce the reengineering techniques. The pre-meetings included an exchange of experiences (in a semi-structured way) in the fields of reengineering, mind-mapping, how to bring jobs together, and how to take away non-value-adding tasks.

Table 1. Expected Benefits from Reengineering the Project

  • Faster
  • More market drive
  • Better interface between different organizations
  • Common understanding
  • Optimize development process
  • Management understanding the problems and taking actions
  • Simplified and more logical way of working, thereby minimizing market risks
  • Cross border working img understanding img involvement

The Workshop

The Case Project. The workshop started with a get-together on day “zero” to break the ice among the participants. Several individuals met for the first time. The following day started with what we thought would be a short introduction of the case project. It turned out to take the whole morning, and by lunch time we had made a rather conventional Work Breakdown Structure (WBS). At that time we all felt that we were close to falling into the old trap of “fixing” instead of complete reengineering. We decided to start all over again with an inventory of the problems.

Problem Inventory With Post-it Notes. We held a problem inventory session, where everyone contributed in silence, by noting on Post-it notes the problems with the existing project setup, one problem on each note. Without thinking about how to group them, we then put the notes up on a white board mounted on the wall. Seeing the other members' notes on the wall helped to trigger new perspective and soon the white board was almost full.

Aggregating Into Problem Areas. Now it was time to group the Post-it notes together into what we considered problem areas. The process began in silence, but after a while we argued about how to best group the notes.

The Chicken or the Egg? The reason for the difficulties in grouping the problems was their relation to one another. We therefore first established the relationships between the problem areas, one area at a time. We asked, “which other areas are effected by this problem?” In conjunction with “which areas have an effect on the problem area in question?” We asked “which problems are the causes and which are the effects?” The somewhat crude way we analyzed which problem areas were the most important ones was to count the number of in- and out-arrows (see Figure 2).

Brainstorming and Evaluating the “Chickens.” Taking the three most important problem areas (the “fattest chickens”), we began a brainstorming session for each one of them. The ideas became wilder and wilder, and in the end we had a couple of flip-charts to evaluate. Each member of the group picked the three or four ideas that he or she considered the best and then argued for them. Finally we boiled the ideas down to a set of headlines of the greatest interest.

Breaking Down the Project ... Difficulty in Finding a Method. The second day, with plenty of coffee, we started combining the case project, the problem areas, and the bright ideas. One of the ideas was to find a new way of breaking down the project. We tried from different starting points and with different approaches—without substantial results. We were struggling and making no progress.

After several tough hours, we started to break the project into processes strictly based on customer needs. We defined these processes as a set of activities that change the input values into a desired output with increased value to the customer. Our “golden rule” was not to mention departments or organizational structure. This was the turning point. We used a common mind-mapping method on the white board. Within half an hour we had broken the project into processes that described the job to be done in a way that related to the customer needs, instead of to departmental structure and hierarchy.

From the customer need, the breakdown starts with what this means in terms of product features and development processes. In the first step, the “feature level,” we identified which parameters were essential to the customers. In the second step, the “development process level,” we combined the parameters in such a way that they could be developed by dedicated process teams. We decided the split between the processes should be logical in terms of competencies, physical location, etc. The ideal situation is that the interfaces within a team are many, and that those between the teams are as few as possible.

Next, we went one step further and broke down one of the development processes into subprocesses. This looks more like a traditional WBS, but note that we still have not said a word about hierarchy or departments. We have only discussed what should be done, and the competencies needed. At this point we stopped working on the case and went back to other ideas from the brainstorming sessions and elaborated upon them.

Figure 1. Project Organization


Figure 2. Problem Areas and Interactions


If this had been a real project start-up we would have gone on with the following steps:

  • Assign process owners.
  • Estimate the resources and competence needed.
  • Establish where each job should be done.
  • Assign members of the teams according to competency.
  • Relate process steps and do the planning.
  • Discuss critical path in more detail.
  • When is value really added?
  • What about the rest of the activities?
  • Are there waiting times in the project? Reasons? (Find solutions and replan.)
  • Is it possible to do things in parallel?
  • Can we avoid bottlenecks?

The steps are shown in an overview in Figure 3.

Case #1 – Setup of a Project to Resolve Quality Issues

Tetra Pak had a problem area that urgently needed to be addressed. Since Development, Production and Marketing were included, the problem included connections to at least five different organizations within Tetra Pak. This traditionally makes it even more challenging to grasp the problem, and important issues tend to “fall through the cracks.” Before the first meeting it was almost certain that the task force was to consist of one person from each of the organizations—the “Hostage Manning Concept.” We wanted to get off to a good start for the project team that we were about to establish, so we decided to form a small group (from four of the organizations involved) to define the task. The problem existed in connection with a specific filling technique.

Action. When we started to define the problem/task/goal with the {BD (CN) img DP} method, we noticed the following:

Figure 3. Project Startup Steps

  • The customer focus helped us understand the problem in such a way that we had to redefine the problem “from scratch.” The original problem definition only focused on two out of the three areas from a customer point of view. We ignored one important area. The reason was that we overlooked the obvious and therefore did not identify it as a problem.
  • The breakdown itself helped us understand the complexity of the problem and thereby the task.
  • The development process was therefore different from what we expected when we went into the meeting.
  • The staffing of the project had to be different due to other, and more, competencies needed. The first competency needed was a statistician who could sort out all of the different aspects of the problem, and identify the existing knowledge. Another competence needed was for the filling process itself. Therefore we decided to invite and include personnel from the customer.

Conclusion. The {BD (CN) img DP} method definitely helped us understand the problem better and therefore made it possible to take better action.

Case #2 – Restructuring of a Development Project

The project was to develop an entirely new packaging system for a global market. Customers were primarily located in Europe, the United States and Japan. The development organization is located in the U.S. but critical competencies are also located in Sweden.

The major problem facing this project can be characterized by many interfaces among the five functional areas and many activities highly dependent on others. In some cases we had difficulty clearly defining the dependencies. The concurrent engineering principle, with a number of activities conducted more or less simultaneously, compounded the problem. Not surprisingly, the result of these problems made the customers' needs vague to the organization.

Action. In a series of meetings we identified what tasks needed to be done, and what had value to the customer. These tasks were then grouped into a number of development processes.

The development processes were then analyzed to determine what competencies were needed, and to what aspect of the process they applied.

We discussed the competencies and appointed relevant staff to these processes. The staff came from the existing organizations already involved in the project. A “process facilitator” was appointed whose selection was based on the individual's rate of involvement.

After structuring the development processes, a process headquarters (where most of the activities take place) was selected. The leading factor in this selection was “it should be done where it makes the most sense from a customer's point of view.”

Conclusion. The previous five functional areas were broken down to 12 development processes. These processes had one common goal—to add value to the customer. Needless to say, this improved the development focus dramatically.

The whole issue with interfaces almost disappeared from the table. Everybody knew what they had to do—and why.

The management group of the project increased from five sub-project managers to 12 process facilitators. This dramatically improved the communication within the project.

The ultimate result (how much faster and how much better the project proceeds) remains to be judged, but so far, so good.

How Far Did We Get?

Is this just another version of the old fairy tale about the “emperor's new clothes”? We don't think so. We feel very strongly that this will bring a new meaning into the development projects and help us reach the expected results faster and better. Table 2 summarizes the positive effects we could foresee. We are aware that so far this is just a “theory.” We have begun using this theory whenever we start new projects. But we have only just begun, which means that the results (the hard facts) have not as yet shown up. But we are convinced they will be favorable. We hope to be able to report on that later.

What is Beyond?

If we allow ourselves to look for a moment at the possible consequences of a {BD (CN) img DP} approach we can directly see that the focus is competence and network instead of departments and organizations. The process teams will be combinations of competencies found anywhere, not only within the organization but also outside our company or group of companies. Besides the actual results from the development projects, the development organizations will be measured on their ability to develop and maintain core competencies and on how they can handle networks. They will become “Information and Competence Brokers.” The virtual organization is here!

If we go one step further we can see that only three main types of employees are needed:

  • Management – making the decision on strategies and which projects to run
  • Project managers – with full authorities/responsibilities
  • People with competence! working in a network environment.

This is primarily the picture for a development organization, but it could also be used for other types of organizations. If you think of a manufacturing organization and change project managers to process owners for the sales process and manufacturing process, the concept will work there as well.

Table 2. Expected Results by Breaking Down by Processes

  • Reduces interface issues
  • Customer needs go directly into processes
  • Task identical to customer needs
  • Identifies owners/responsibilities
  • Mind mapping is a good method
  • Focus on customer needs and not department's
  • Groups work for larger scopes/processes
  • Diminishes matrix conflict
  • Building compentences in T (both depth and width) and real customer problems/needs
  • Reduces fragmentations and suboptimization of tasks, resources and goals
  • Easier to “see the cathedral and not only a bunch of stones”
  • Executed to reduce geographical issues
  • Pedagogically positive

A Note on Geography

As mentioned, geography can be a problem in an international and globalized company. The solution could be the floating office where you find the most suitable place to work at any given time. We concluded that the approach described here makes it vital to work closely together. It may be easier if the processes are defined with as few interfaces to each other as possible. The group would be easier to hold together. The point is to keep the process teams together as much as possible. The problems get bigger when the competencies are found in different countries or on different continents. The intensified use of information technology solutions will help, but there is always a good case for meeting in person, and not only on Internet or in a video conference. One possible way would be to work together in the team only every third week or so. The choice of location must come from the need; where is the biggest problem right now? Go to the problem! After that the group can split and work individually until they meet next time—somewhere else in the world where the process requires them the most. img

1. Hammer, M., and Champy, J. 1993. Reengineering the Corporation, A Manifesto for Business Revolution. Nicholas Brealey Publishing.

2. Buzan, T., and Buzan, B. 1993. The Mind Map Book. Dutton, a Division of Penguin.

3. Hedberg, B., Dahlgren, G., Hansson, J., and Olve, N-G. 1994. Imaginmaara organisationer. Liber-Hermods.


Ralph Maleus is a project manager for Tetra Rex Packaging Systems, Inc. in Buffalo Grove, Illinois. He holds a B.S. in engineering from University of Stockholm, Sweden with an M.B.A. equivalent degree in economics.

Sture Karlsson is president of Tetra Pak Converting AB, a company within the Tetra Pak Group. He holds an M.S. in chemical engineering from University of Lund, Sweden.

PM Network • August 1995



Related Content