Team Autonomy vs. Common Process: Solving the Conflict

by Doug Boebinger, MS, PMP^®

INTRODUCTION

The tug-of-war occurs between project teams and corporate management. Neither side is willing to concede. Neither side should. The corporation wants common processes and the benefits which go with them. Project teams demand the autonomy that is essential to meeting the specific demands they encounter during the course of the project. Management and project teams cannot both get what they want, or can they?

THE PROBLEM

The constant demands from the marketplace to reduce product development time and cost while maintaining or improving product quality is increasing the pressure to implement the benefits of a common product development process, project management methodology, and project review process.

However, creating a product development process without understanding certain realities will impede its successful implementation.

The Realities of Project Life

There are certain “realities of project life” which must be recognized, understood, and accepted in order to make projects and processes successful. They are:

• If it’s not simple, it won’t be used.
• If it’s not right, it won’t be used.
• Not all teams work at the same level of detail and authority.
• Some teams are not exclusively dedicated to a single project and need to manage cross project efforts.
• If it’s not integrated, it’s not beneficial.
• If it’s over integrated, it’s not beneficial.
• People want to work independently.
• Just because one part is late doesn’t mean the project is late.

THE SOLUTION

The philosophy and methodology outlined in this paper is a proprietary strategy by Douglas B. Boebinger, an independent project management consultant and trainer, titled “The MAPD™ Strategy.”

The solution is to create a triad of the following inter-related entities:

• product development process,
• project management procedures, and
• project review process.

This triad must be flexible to meet the specific needs of the project teams but consistent to provide management with uniform information. Thus, it must achieve the following:

• The corporation establishes a common product development process to be used as the basis for the various project teams’ workplans, but allows for the teams’ flexibility to establish the details of their own work.
• Team templates are created with a manageable level of authority (manage, lead, support) sensitivity in workplan content thus keeping the workplans simple while maintaining the integrity of the product development process.
• Each team’s workplan contains all the work required to produce the product while maintaining a manageable workplan size thus reducing the “manage the workplan” effort.
• The teams’ workplans are integrated along the natural team information exchange requirements.
• There is electronic integration of all the project workplan data but without a large, complicated integration workplan which increases “manage the workplan” effort.
• Inter-personal integration of all the project workplan data is developed without the need to understand a large, complicated integration network. In other words, communication is achieved without a computer in the middle!
• Integration of independent, stand alone workplans is implemented across independent teams without complicated, expensive network and/or enterprise wide computer solutions.
• High level reporting of workplan information is acquired from lower level teams but allows for stand alone workplan analysis without complications of external logic relationships between workplans.

HOW TO ACCOMPLISH THIS?

The cornerstone for obtaining an equilibrium between team autonomy and common process is to develop an agreement between the corporation and the project teams that outlines the roles and responsibilities of each. The common process must define the philosophy, methodologies, and procedures that all the teams will follow for their product development efforts. However, the project teams must have the freedom and ability to modify the process, as required by the project scope, to achieve their successful result. Also, an understanding must be achieved as to the level of detail that will be required by management in order to review the project’s progress and the procedures that will be followed for a formal Project Review Process (PRP).

We start where the project ends, with the product. One false paradigm that needs to be shattered early in this effort is the “my product is different” syndrome. True, products differ from each other, but the work necessary to produce those products can be common. For example, Ford Motor Company produces many varieties of automobiles and trucks but the process steps Ford product development teams follow can be common.

The “typical” product needs to be defined. Traditionally, an all-new product is used as the basis for this effort. An all-new product represents the worst case scenario and thus assures a comprehensive look at the entire process.

Creating the Product Partition 

Products are made up of various subsystems and components. The product partition is simply a system engineering cascade of the product from system level down to component. The result is an hierarchical breakdown of the product which produces the total project Bill of Material (BOM).

The methodologies of System Engineering should be utilized in order to understand the detailed interactions of the:

• product to the customer
• product subsystems to each other as well as to the system
• product components to each other as well as to the various subsystems

This information will become extremely beneficial during the creation of the common product development process.

Creating the Common Product Development Process (PDP)

The typical rules established to create a work breakdown structure are used when creating the Process Breakdown Structure (PBS). However, the PBS is specifically designed around the process and must be developed with the product partition in mind.

The starting point of this effort is to determine the categories of work which, at the highest level, are common across the product. Each category is then broken down into its subcategories, noting major deliverables which are produced from each subcategory.

The amount of “drilling down” into the details of the PDP varies depending on the intended purpose. Three different levels of detail should be established, from highest to lowest:

• Management Level of Detail
• Training Level of Detail
• Validation Level of Detail

Starting with the Validation Level Of Detail. Referencing the systems engineering documentation, this level of detail defines the time element for each interface and interaction between the product system, its various subsystems, and components. The interface and interaction information needs to be validated to assure the corporation and the project teams that the PDP is capable of producing the product and the PDP has been fine tuned to accommodate the subtleties which can cause teams to abandon newly established processes. However, this level of detail is much too extensive to use for day-to-day management of the project.

The Training Level Of Detail is utilized for its noted purpose, to train the project teams on the PDP. Training can be developed either by category or by time frame, depending on the desires of the corporation. This level shows the recommended level of detail that project teams may use for their day-to-day management, but the specifics outlined are not required. This will be discussed in greater detail later in this paper. This allows the team to get a jump start on their project planning by providing a strawman workplan.

The Management Level Of Detail outlines the level of information required by the corporation and the customer to assure themselves the project is progressing on track to a successful completion. This level also describes the level of information at which teams must report out their progress at regularly scheduled phase exit reviews as outlined in the Project Review Process.

Each element in the PDP, regardless of its level in the PBS, has a supporting Task Sheet. The Task Sheet serves as an encyclopedia of information for that respective PDP element. The task sheet system, typically a relational database integrated with the PDP, can be designed to roll up and cascade down information as the user moves through the PDP. The task sheet becomes a “process knowledge base” of valuable information which the teams can reference during the execution of their work. The task sheet system also serves as a bridge between the how of the engineering documentation (e.g. design guides, test procedures, etc.) and the when, where, what, and who of the PDP and project workplans.

With the PBS established, it can then be cross referenced against the product partition. This results in an understanding of which PDP elements need to be performed for which aspects of the product (system, its subsystems, and components). PDP elements performed by multiple components and subsystems should be coordinated to gain the effectiveness of common procedures.

Creating the Team Structure

With the PDP defined, it is necessary to establish the functional responsibility for each PDP element. Care must be taken not to drift into identifying the organizational responsibility (as organizations change too frequently) but instead to determine the functional person (e.g. design engineer, draftsman, testing technician, etc.) responsible for each process element. Also, it is beneficial to identify the functional people who support each PDP element. All of this can be documented in the task sheet system.

An analysis of the functional responsibility vs. the PDP will yield natural workgroups structured around the product partition. Typically, projects require multiple teams in order to facilitate the development of the subsystems and components of the product. Also, an overall project team is required to manage the entire project as well as the interactions with the customer(s) and the corporation. In such a multi-team environment the various teams’ roles and responsibilities need to be identified.

In addition to the functional responsibility versus the PDP, a cross analysis needs to be performed against the product interactions identified in the systems engineering documentation. This is necessary to keep the teams functional. Effective teams are not restricted to communication channels which follow the lines of the organizational chart. Cross communication (horizontal, vertical, as well as diagonal) is necessary for the efficient exchange of information. If two or more teams require substantial interaction, it may be more efficient to combine them into a single team or, at a minimum, they should have a core group of people who are members of each team to assure “cross-pollination” of information.

The Manage-Lead-Support Exercise

At this point in the game, a multi-dimensional matrix is developing which cross references the PBS against the product partition, functional responsibility, and the team structure. Armed with this information, the teams may now determine who is going to do which PDP elements. The Manage-Lead-Support (MLS) exercise is a simple, yet effective, way to define which aspects of the PDP will be contained in the workplans of the various project teams.

The basic premise of the MLS exercise is that the various teams do not need to have every element of the PDP in their respective workplan. Based on their need, they can choose to have a higher level “summary” PDP element or the group of lower level “detailed” PDP elements. Using sourcing as an example, the overall project team needs to manage at a high level the outsourcing of subsystems and components. The project team does not need to manage the detail steps of the sourcing effort. The detail steps are led by the subsystem teams and the component teams respectively. Therefore, the project team should choose to use only the high level PDP element in its workplan. However, the subsystem team will need to have the detail PDP elements for the outsourcing of the subsystem. The component team will need to have the detail PDP elements for the outsourcing of the components.

To accomplish the exercise, a two dimensional matrix is developed of the PBS vs. the Team Structure. Each team then reviews the PBS, and its various levels of detail, and selects which elements it manages, leads, or supports by simply placing an “M,” “L,” or “S” in the respective row box.

Process Scaling

To add another degree of complexity, it is also necessary to scale the PDP for projects which are not “all-new,” as was the premise of the base PDP. Not every project produces an all-new product. Projects which produce all-new products may reflect a small percentage of the corporation’s total projects. Therefore, the PDP needs to be scaled for the following classifications: · All-New Products · Major Redesign Products · Medium Redesign Products · Minor Redesign Products

The product and project scope for each of these classifications will need to be defined in order to assist in determining which aspects of the PBS are necessary for the various scales. The PDP utilized by the various scales may result in not only an elimination of the activities from the overall PDP, but also in the PDP element durations being reduced. The reduced durations are a reflection of the decreased amount of time necessary to perform the work due to the reduced complexity of the lower scaled projects.

Creating the Team Workplans

With the development of the product partition, the PDP, the team structure, the MLS exercise, and the process scaling complete, it is now possible to create specific workplans which the respective teams will apply to their aspects of the project.

A twist to this is that the MLS exercise allows teams to select PDP “summary” elements if it is not necessary for them to lead at the lower level of detail. Also, scaling can cause the elimination of PDP elements not necessary due to the reduced scope. Both of these cause logic relationships developed in the overall PDP to be broken. Therefore, it is necessary to create the PDP model which will accommodate a variety of logic relationship scenarios based on the specific activities selected by the various teams and the specific scale of the product.

To understand the complexity of this, let us use the following example. Based on the Exhibit Z, the typical project has 12 teams. With four different scaling possibilities, the result is 48 possible team workplans. Since processes do not remain constant and process improvement is a necessary aspect of corporate life, every process change would need to be posted against each of the 48 possible team workplans. Maintaining 48 different workplans while ensuring that all process modifications are posted accurately and validating that the enhanced process is feasible is next to impossible. Therefore, the need arises to create a single process model which will reflect all of the previously discussed complexities while providing single point updating of the PDP. The result is a revolutionary process modeling technique which is based on a very complex algorithm and process coding.

What is typically constant data in a normal process based workplan (e.g. logic and durations) is now variable based on the selection criteria. The specific algorithm is more complex than can be outlined in this paper. However, to put it into simple terms, all the algorithm requires is the team designation, project scale, and project completion date. The result is a team specific workplan with full logic continuity, scope dependent durations, scaled to the complexity of the product, and timed to meet the project’s completion date that can be instantly employed by the project team.

If desired, the team can further refine the workplan by adding, modifying, and deleting activities. However, the main structure of the workplan, team interface activities and milestones, and certain key activities and milestones required by the Project Review Process must be maintained for reasons to be discussed. The flexibility to add, modify, and delete activities further provides the teams with the autonomy they require.

MANAGING THE PROJECT WITH AUTONOMOUS TEAMS

It is a difficult task to get all the project’s teams starting off from the common PDP. It is even more difficult to mandate all the project teams follow a common project management methodology. Nobody likes to be told what to do. Project teams cannot have their hands tied behind their backs, preventing them from managing the day-to-day requirements of the respective aspects of their projects. They have to be nimble enough to react swiftly to issues as they arise. They must be allowed to control their own destiny if they are going to achieve customer satisfaction, especially in an ever increasing dynamic marketplace. However, the corporation must verify that the projects are following the PDP, are being run properly, as well as to allow corporate wide cross-project analysis.

Some of the difficulties of implementing a common project management methodology typically revolves around the update process, intra-project workplan integration, inter-project workplan integration, and workplan summarization.

Project management software companies are developing more and more complicated methods of integrating project workplan files. However, the results are sometimes more complex to manage than the projects themselves. This distracts the teams from their main purpose of managing the project, causing them to spend too much time managing the workplan. Integration methods may also result in large, complex computer systems with fixed communication paths. Difficulties may arise on projects with shared product components. A single product component may be used by multiple products. It is not efficient for a component team to maintain separate workplans necessary for each project for a single, shared component.

One of the other downfalls of traditional integration is that it results in “false” critical paths which, technically, may be correct, but do not reflect reality. An example is that if one activity in one sub-sub-team’s workplan is late, full integration will indicate that the entire project will be late. This is not necessarily true and is probably not what is desired to be presented to the customer and to the corporation. Yes, the late activity needs to be identified and, yes, it needs to be understood and actively managed, but it doesn’t mean the entire project is late. It just means there is a risk which needs to be controlled.

An integration methodology which follows the natural communication lines of the teams is more effective than a “hard-wired” integration method. As mentioned previously, teams need to communicate and exchange project data not only vertically, horizontally, and diagonally, but also backward and forward in time. “Hard-wired” integration methods are not this flexible.

Therefore, a new method of integration is preferred. This new methodology, simply explained, allows a project team to compare its team workplan versus one or more other team workplans. By identifying pre-defined integration points and using a specific coding method in the workplans, like activities and milestones can be cross referenced. To use an analogy, if you are going to chat with your next door neighbors, you just need to know where to meet them and when. You don’t need to know the specific layout of their backyard and the path they plan to take to meet you.

The following are different comparison scenarios which may be used for analysis purposes (See Exhibit 4). · The Project Team (PT) can compare its activities versus the three Subsystem Teams (SST1, SST2, SST3), the Cross Project Team (CPT), and the Vertical Team (VT). This allows the Project Team to determine how well the primary support teams are working against the overall project schedule. · A Subsystem Team 2 (SST2) can compare its activities versus the two End Item Teams (EIT3 & EIT4). This allows the Subsystem Team to determine how well its support teams are working against the SST2 workplan. · End Item Team 1 (EIT1) can compare its activities against that of another End Item Team 3 (EIT3). This allows EIT1 to see how key activities and/or deliverables it requires from EIT3 are supporting its workplan. · End Item Team 2 (EIT2) can compare its activities against that of a Subsystem Team 2 (SST2). This allows EIT2 to see when information required from SST2 will be delivered. · Any team can compare its current update versus the previous week’s (or month’s or year’s) workplan. This allows the team to see what has changed since that previous saved workplan. · Changes are inevitable on projects and the impact of these changes on the project’s workplan need to be conveyed to the other teams. Once the Project Team (PT) has integrated the project change into its workplan, it can send the file to the other teams. They can then compare their workplan versus the revised Project Team workplan to see where changes have occurred.

DEGREES OF RISK

This method of cross referencing supporting team workplans adds a new layer of risk analysis to the mix. In addition to the traditional total float and baseline variance analysis, the team can also do an analysis of the degree to which the other teams are supporting the team’s workplan. Thus, if a key milestone in a team’s workplan has negative total float and schedule finish later than its baseline finish and the supporting teams will be even later than your scheduled finish, then it is apparent the milestone is at high risk. On the other hand, if the milestone has positive total float and is ahead of the baseline and the supporting teams will finish even earlier, then it has a very low risk potential.

PROJECT REVIEW PROCESS

A corporate project review process is essential. The corporation needs to review the projects on a consistent basis at key phase transitions. The projects also need to be reviewed on a level playing field. Therefore, a corporate wide Project Review Process (PRP) needs to be established.

During the PDP process, key activities and milestone which management wants to review are identified. The PDP schedules the activities and milestones, allowing them to be clustered together for each phase exit review meeting. At the phase exit meeting, the status of these process elements are reviewed and a determination is made as to whether the project should continue.

The purpose of the PRP is to inform the corporation and the customer, if so desired, on a regularly scheduled basis, of the current status of the project, verify the final project objectives are still achievable, and the project is on track towards that end within the required time, cost, and quality constraints.

The PRP must contain the following elements: · Project scope statement and major scope changes since the previous phase exit review meeting; · Project budget statement which includes the original project budget, approved change order budgets, pending change order budgets, and costs-to-date; · Project quality standards, their respective matrix, and current status against them; · Project schedule comparing current status vs. baseline vs. PDP generic timing; · A corporate risk assessment procedure which defines various levels of risk for cost, quality, and time; and · An issues reporting system with a consistent reporting format. The consistent reporting format allows the corporation to find easily the information it requires. It also is a time saver as the teams do not need to create their own reports.

With project teams working under the common PDP and reporting against key activities and milestones from the PDP, the corporation is able to develop a corporate wide view of all the active and planned projects. One of the other aspects of the PRP is that the corporation can compare the various projects against each other to fine tune the overall resource balance of the corporation.

CONCLUSION

Despite the obvious conflict of interests between a common process and the team’s desire for autonomy, it is possible to find a middle ground. The methodology to achieve this middle ground is complex, but the rewards are worth it.

© by Integrated Process Developers, Inc., all rights reserved.  Please contact us for permission before reprinting in whole or in part.