The Engineering Firm’s Dilemma
Ed Brown | August 11, 2016In a 2001 paper entitled “Organizing Product Development1”, Thomas J. Allen laid out a fundamental dilemma facing engineering organizations: “Innovation can be depicted very simply as a process that mediates between two streams of activity,” he wrote.
“One of these is the development of technological knowledge or, as we more commonly call it, ‘technology.’ The other is a developing set of market needs...” Organizations can be structured to function well with either of the two streams, he wrote. The difficulty occurs “when we try to structure to serve both simultaneously.”
According to his idea, three basic forms of organization address these functions in different ways.
The first is called departmental or functional. Here, staff is organized into departments based upon their special knowledge. Since specialists in similar areas work in the same department, they more readily communicate with each other, keeping themselves current on developments in the field and balancing each other’s strengths and weaknesses. As a result, department organization maximizes expertise.
(Read “Building an Innovation-friendly Organization.”)
The downside is that manufacturing industries are oriented to develop products for the market, and product development requires cross-disciplinary skills, a blend of knowledge from different specialties. The problem is how to coordinate specialists from different departments to work together on a single project. The strength of departmental organizations is also their weakness when it comes to working on a project defined by marketing. Departments tend to operate in silos with department heads who are often oriented toward defending their boundaries.
In a project-based structure specialists are removed from different departments and grouped together under a project leader. Image source: NREL The second organizational form is project-based. Here, specialists are removed from different departments and grouped together under a project leader. This often improves the ability to coordinate specialists and move them toward developing the needed product on-spec, on-time and within budget. The downside is that specialists who work on a project team for an extended period of time are likely to fall behind in new developments in their field. "The technology, or core competencies of the organization are stored in the minds of the technical staff,” Allen wrote. Narrowing the focus of the specialists causes them to fall behind in knowledge. “The organization thereby weakens its own technology base."2
Matrix organization is an attempt to solve the problems of maintaining up-to-date specialized knowledge while coordinating the technical departments and marketing. Specialists from different departments contribute their expertise to the project. The specialists continue to work in their departments while a project manager is responsible for assigning and coordinating their efforts.
However, a built-in conflict exists between department heads and project managers. Department heads tend to want to keep working on a product until it has been perfected, according to their judgments. Project managers, by contrast, focus on issues such as time-to-market and budget constraints. The task of senior management is to keep these two conflicting goals in balance. If an imbalance exists in favor of departmental management, products may be kept in development too long. But if the balance shifts the other way, project managers may respond to market pressures before a product is ready.
(Read “Innovation, Engineering and the Arts.”)
It is healthy for this tension to exist, but the challenge is to keep it from tilting to either side. One challenge is deciding when a project is ready; often there is no hard and fast rule. Instead, the decision lies with the judgment of the responsible managers. If the product is shipped too early, valuable personnel may have to be sent to a customer’s facility to fix problems. If it is held back too long, a customer may be needlessly angered. And if there is a government contract involved, a penalty clause may be triggered that assesses fines for late delivery.
The sheer volume of studies that consider these issues is evidence of the fundamental nature of these management questions. This article summarize two such studies that represent attempts to discover how organizational structure affects these problems in practice.
Are Cross-Functional Teams a Solution?
An article by Floortje Blindenbach-Driessen in the February 2015 issue of the IEEE Transactions on Engineering Management3 argues that the answer is sometimes yes and sometimes no. The article reports on a study of “cross-functional teams” for 142 projects in 95 firms. The author explored the factors that improve or hinder the success of teams of functionally diverse specialists working on a single project. She concluded that success or failure was a function of the “organizational context,” namely, the form of the larger organization. The study compared manufacturing and service firms in construction, IT, engineering and allied services.
A distinction highlighted in the study was made between manufacturing and service firms. Manufacturers tend to have functional (departmental) units and a separate dedicated research and development department. Service providers, by contrast, tend to have more varied organizational structures. In general, however, innovation in these firms is more integrated into day-to-day activities.
The study concluded that:
• Cross-functional teams contributed positively to organizations that were more function-based.
• Cross-functional teams contributed positively where there were higher levels of separation of the innovation activities, for example, where innovation is segregated into a separate R & D department.
• Cross-functional teams did not contribute where there was a lack of connectedness in the organization, as measured by the degree to which functional departments and disciplines acknowledge each other's expertise and also how common such communication is within the organization.
Team Diversity
A study by Chen et al., reported in the November 2015 issue of IEEE Transactions on Engineering Management,4 came at the question of whether teams should be cross-functional from a different angle. The authors considered “diversity,” which they defined as varying degrees and types of functional experience, and length of time on the job.
In a literature survey, the authors identified two different views on the effects of team diversity.
First, according to behavioral theory, diversity of skills and backgrounds make for a mix of viewpoints and perspectives that enables them to “reframe problems” to generate more alternatives and get beyond “silo thinking.”
Second, according to social identity theory, team diversity leads to problems. People who are different from each other will be more resistant to interacting and collaborating because they view others as outsiders. Integrating them into an effective team would require more time, effort and resources.
In 1989, Boeing used the Dassault collaborative software suite CATIA to design the 777 jetliner. Image source: Wikimedia.orgThe authors accept the partial validity of both theories and suggest that an inverted U-shaped relationship exists between team diversity and new product performance. They wrote, “Since there are both positive and negative forces at play, there is an optimal level of team diversity. Before the optimal level, the increase of team diversity would enhance new product performance. On the other hand performance would decrease as diversity goes beyond the optimal level.”
They also suggested that a significant moderating factor exists and is called “slack” — a concept taken from traditional organization theory. Organizational slack refers to resources within a company that are in excess of what is committed to normal operations.
“In essence these are resources that can be used in a discretionary manner,”5 for example in funding innovation projects. Slack is generally divided into two categories: absorbed and unabsorbed. Absorbed slack is not easily redeployed. It might take the form of staff who are not vital to day-to-day operations, but are committed to fixed roles in the organization. Unabsorbed slack is more easily redeployed and might take the form of retained earnings.
The study found that “moderately heterogeneous team diversity exhibits better new product development than homogeneous teams or very heterogeneous teams,” but that the relationship is modified by the amount of available unabsorbed slack. When a significant amount of unabsorbed slack exists in an organization, although there is still an inverted-U relationship, overall performance is improved. The authors’ explanation is that extra resources can be committed to a project to overcome coordination and communication problems among team members.
Tools for Collaboration
Could collaboration software be an answer to the tension between functional and project-based organization? 3D computer aided design (CAD) software that can be used to create detailed and accurate virtual models was first developed by the French company Dassault Systèmes in the 1980s. In 1989, Boeing used the Dassault software suite CATIA to design the 777 jetliner. It was the first jetliner completely designed by computer without the benefit of building a physical model.
(Search products and services related to project collaboration software at Engineering360.)
The software enabled engineers from different functional departments to work on their portions of the design and share what they were doing in real time. Three hundred teams working on different design problems were able to view and assess their work as it was integrated into the virtual model. The marketing department was even able to include customers in the process by enabling them to view the model and make suggestions.
Today, a number of 3D collaboration suites operate via the cloud, thus making them cost effective and easily implemented even by small- to medium-size enterprises (SMEs).6
Structuring an Engineering Organization
Takeaways from this article include the following:
• Tension exists between project-based and departmental engineering organizations. A method for dealing with this tension is to combine the two with a matrix configuration.
• The study by Blindenbach-Driessen of project teams of diverse specialists found that whether these teams worked well depended on whether they were function-based and had a separate R & D department, and the degree of communication that existed among functional departments.
• Chen et al. concluded that an optimum level of diversity exists, and that diverse teams can produce better results if company resources are committed to enhancing their performance.
• The insights from these studies are useful for large organizations but perhaps not for SMEs, which have few available resources for maintaining teams or an R & D department.
• 3D CAD software is a tool that can facilitate matrix-style organizations. It enables collaboration by different specialists for a given project while those specialists remain in their own departments. SMEs as well as large firms can use it equally well.
In the final analysis, top management has to be open to implementing these kinds of structures and to staffing their organizations with people who are committed to implementing collaboration.
References
1. Thomas J. Allen, Organizing for Development
http://dspace.mit.edu/bitstream/handle/1721.1/83298/PLN_0102_Allen_Org4ProdDev.pdf?sequence
2. Allen, P.8.
3. Floortje Blindenbach-Driessen, The (In)Effectiveness of Cross-Functional Innovation Teams: The Moderating Role of Organizational Context, in IEEE Transactions on Engineering Management, Vol. 62, No.1, Feb. 2015
4. Chung-Jen Chen, Mo-An Chu, and Kae-Kuen Hu, The Relationship between Organizational Diversity and New Product Performance: The moderating Role of Organizational Slack, in IEEE Transactions on Engineering Management, Vol. 62, No.4, Nov. 2015
5. Gong Yi and Shi Yanjuan, Organizational Slack Resources and Their Effects on Innovation and Performance of Firms: A propositional Framework, in Proceedings of the 2007 International Conference on Management Science and Engineering
6. Autodesk 360