How to Coordinate Product Development Activities
Virtually every product development effort includes more than one person. For maximum benefit, the efforts of all individuals on the development team must be coordinated to best meet the needs of the project. With poor coordination between individuals, effort will be duplicated, work will become irrelevant, critical items will be missed, and resources (e.g., time, money) will be wasted.
Product development involves a lot of work. Making sense of what needs to be done and in what order, and how one bit of work on the team relates to another is a major challenge. Nevertheless, effective teams put in the effort to understand (even if only in a small way) how the various product development activities for a project relate to each other. Such teams use this understanding to work in a complementary way, where each person spends effort on something that contributes meaningfully to the overall success of the project.
To help new teams gain a higher level of team effectiveness, this article describes three types of relationships that can exist between product development activities. Relative to each other, product development activities may be independent, dependent, or interdependent. These relationships are collectively referred to as activity dependency. Understanding activity dependency allows teams to effectively and efficiently sequence the work and divide the labor in sensible ways.
The following sections introduce activity dependency with basic definitions from [1]. Simple examples are also provided to help solidify the meaning. Further below, a process for using these definitions is presented.
Coordinating Independent Activities
Independent activities have no impact or influence on eachother. In relation to each other, it does not matter which activity is accomplished first. Independent activities should be carried out in parallel whenever possible to increase the overall product development speed. Because the activities and their outcomes are independent, there is no logic-related barrier to parallelizing them [1].
General example of independent activities
For the design of any physical product, a common product development activity is to interview end users about their needs. Another activity could be to interview assembly line workers about their needs. These two interviewing activities are independent. One does not need to be completed in order to start the other, nor does the outcome of one affect the process that would be used for the other. These activities are independent of each other. To evolve the design as fast as possible, these activities should be assigned to two different people/sub-teams and be completed in parallel.
Engineering example of independent activities
Consider the design of a smartphone. An important mechanical engineering decision is which material to use for the touch screen (e.g., gorilla glass [2]). Another important design decision is which apps will come pre-installed on the smartphone. Both of these decision making activities are important – but independent. The timing and choice of one does not affect the timing or choice of the other. They simply both need to be completed during the development process. If development speed is the goal, the team should parallelize these activities.
Coordinating Dependent Activities
Dependent activities must be carried out in series. The defining characteristic of dependent activities is that the outcome of one activity is the starting point of another activity. The critical path [3] – or the set of activities that determine the minimum overall product development time – will involve multiple dependent activities. To that end, the product development team should pay close attention to dependent activities and make sure their progress is well-tracked since failure to successfully complete them affects downstream product development work and therefore the overall development time. Whenever it is possible to decouple dependent activities and make them independent, it is worth doing [1].
Image representing independent, dependent, and interdependent activities.
General example of dependent activities
Imagine that we want to hold a focus group [4] and have a discussion about three product variants for a product we’re designing. Before that focus group can be held, the three product variants need to be chosen so they can be presented to the focus group. In this way, holding the focus group is dependent on choosing three product variants.
Engineering example of dependent activities
Consider the 3D printing of a prototype. The 3D print cannot begin until a CAD model is available. The 3D print is therefore dependent on a CAD model. Notice the directional relationship: the 3D print is dependent on the CAD model, but the CAD model is not dependent on the 3D print. In terms of planning, this clearly means that the CAD model needs to be created first, then the 3D printing activities can start. To be effective at transitioning from one activity (CAD modeling) to another (3D printing), it’s important to structure the output of the first activity so that it is a good input for the second activity. For this example, this means designing for 3D printing, and exporting the CAD file as an STL file.
Coordinating Interdependent Activities
Interdependent activities are such that the preliminary outcome of one activity affects another parallel activity. One characteristic of these interdependent activities is that they can be temporarily serialized where one of the activities is carried out first, followed by the second. The first activity may then be re-executed based on new information gained in the second activity. This process should be repeated, in an iterative fashion, until a mutually acceptable outcome for both activities is converged upon [1].
Interdependent activities require the most coordination, since the outcome of one activity affects the other parallel activity and vice versa. Individuals or sub-teams working on interdependent activities need to plan on having a structured scheme for collaboration. Perhaps the easiest way to do this is for the team to establish a short interval (period of time) between sub-team coordination, where the interval is no longer than the amount of lost time the sub-teams are willing to live with [1].
General example of interdependent activities
Imagine that you are building a brand for a product you’re developing. Due to the nature of new product development, there is uncertainty about the brand, the evolving product, and the understanding of who will actually purchase this product. Work on all three of these areas needs to be done, but no one area will be complete until all areas are adequately developed. This kind of relationship means all three of these are interdependent, meaning they all affect each other. For example, if you change the nature of the product, it changes who would be willing to pay for it, which changes who the product should be branded for. Likewise if you build and test a brand and realize that the target market is older and less tech savvy than you originally thought, you now need to adjust the product design to better match the new-found market. When interdependencies like this exist, it is useful for the team to parallelize the work and hold frequent coordination meetings to trade information about what was learned and how it affects all of the interdependent activities involved.
Engineering example of interdependent activities
Consider the design of a structural component for an aircraft, where the team seeks good lightweight manufacturable geometry, and excellent strength. Because it is unlikely that the team will stumble on a design that meets all of these objectives on the first try, the process will be iterative, ultimately leading to an optimal component. The geometry will influence the strength, and the strength evaluation will influence geometry changes, repeated until satisfactory strength results from satisfactory geometry. In this way, choosing optimal geometry and evaluating strength are interdependent product development activities.
How to use this information in a team setting
To begin making sense of the many things that need to be done by your product development team, and especially to begin understanding how those things relate to and complement each other, try these steps:
Write a clean project objective statement [5]. This statement lays out, in just a few dozen words, the overall goal of the project. This statement is something everyone on the team can and should get behind.
Break the project objective statement into a handful of smaller, possibly discipline-specific, sub-objectives. Iterate as needed to converge on a reasonable set of sub-objectives that are complementary and necessary to achieve the overall project objective (See Image Below).
Establish a small list of product development activities needed to achieve each of the sub-objectives. These can include things such as: carry out a benchmarking study, interview lead users, test usability prototypes, wire the circuit and connect it to the cloud, run an ad campaign to understand interest, etc. It can be helpful for future steps to write each activity on a separate sticky note so their order can be rearranged as needed. Don’t worry about this list being exhaustive; it can be added to later (See Image Below).
Pick one or two of the main activities from each list resulting from Step 3. Do a pair-wise evaluation by picking two and asking: are these independent, dependent, or interdependent? The answer to this will indicate the sequence of activities, and whether or not activities should be done in parallel or series. It will also point to interdependent activities that need deep coordination (See Image Further Below).
With the main activity sequencing emerging from Step 4, arrange the other activities from Step 3 in the context of the main activities. For each activity ask: is this activity dependent on the results of other specific activities? Does it have an interdependent relationship with one or more activities? When should this activity happen relative to the other activities being considered? With the effort required for this step, the team’s product development activities begin to be put into context of all other activities. Such context is an important part of knowing the timing of each activity, and which activities should be done in series versus parallel.
Assign team members to activities and establish a process for coordinating interdependent activities, a clear plan for transitioning between dependent activities, and a simple approach for tracking the completion of independent activities.
Image representing the decomposition of objectives, with activities added to achieve them.
Sample structure of activities, indicating order of operations.
References
[1] Mattson, C. A., and Sorensen, C. D., Product Development: Principles and Tools For Creating Desirable and Transferable Designs, 2020, Springer, Cham.
[2] Corning, “Gorilla Glass,” Gorilla Glass Website, https://www.corning.com/gorillaglass/worldwide/en.html, accessed 1 Feb 2023.
[3] Levy, F., Thompson, G., and Wiest, J., “The ABCs of the Critical Path Method,” Harvard Business Review, September 1963, https://hbr.org/1963/09/the-abcs-of-the-critical-path-method, accessed 1 Feb 2023.
[4] Wikipedia, “Focus Groups,” https://en.wikipedia.org/wiki/Focus_group, accessed 1 Feb 2023.
[5] Allen, C., “What is a project objective statement and why is it so important?” Cheryl Allen Blog, April 2014, https://cherylallen.com/2014/04/12/what-is-a-project-objective-statement-and-why-is-it-so-important/, accessed 1 Feb 2023.
