A common cause for resource conflict lies in understanding the answer to a deceptively simple question: how much is enough?
A staff member may become an overachiever in an attempt to please his or her boss, or to satisfy their own pride by applying ‘more’ to a project than it deserves.
An electrical engineer may try to make an amplifier “just a bit more sensitive,” or an IT specialist may keep working to get a few more messages per second out of a processor. These are both examples of work that doesn’t deliver any appreciable benefit to the company.
A good project manager must know when to push for more performance and when to stop and move onto the next activity. This type of judgement call is how organizations’ financial and marketplace health either thrive or start a downward spiral.
Measurements and metrics offer everyone clear guidelines for balancing project objectives.
When you offer clear and specific metrics, you enhance the project designer’s ability to develop a project plan that supports the organization.
A favorite framework that accommodates the iterative approach of Agile or Scrum lays out three achievement levels for organizational or project objectives. These include: minimum, target, and stretch metrics as defined below:
Minimum
Minimum acceptable metrics tell project designers the lowest acceptable value for an objective. They may drop to this measurement under pressure to achieve balance in other areas. By definition, if the project or product cannot meet this minimum criterion, the project should be rejected or abandoned.
Target
The target metric represents the strategic plan’s goals for the area. Once this target is achieved, project designers can focus on other areas. The target metric is the normal, steady-state metric portfolio and project designers should attempt to achieve it.
Stretch
Stretch metrics are objectives the organization strives to achieve to capture innovative ideas or unplanned opportunities. Frequently, these may represent upper limits that the project designer should not exceed to prevent overloading the resource pool. Achieving stretch metrics should not be the norm. If every project designer attempted to achieve stretch metrics, resource shortages would impair the chances of strategic success.
This model can be employed for all of the categories of objectives: schedule, cost, resource, technical, and quality.
Establishing a framework for balanced objectives allows you to distribute resources based on strategic direction, keeping the entire organization moving ahead.
A company has only so many resources. A good project manager ensures that resources saved in one area are more effectively used in another.
Managing task interdependencies is one of the most challenging aspects of project management. A recent study indicated that 70% - 80% of project changes can be attributed to internal (and controllable) issues, not client issues. Consider the following diagram:
Figure 1: Project Precedence Diagram
Most project managers will recognize this as a precedence diagram or PERT chart. Each node represents an activity within the project. In essence, it’s a work-flow diagram. Once the project starts, tasks A, B, and C can start and each can run in parallel. Task E requires the outputs of A and B. For example, task A might be surveying a plot of land to create a plat. Task B might be laying out the overall structure of a house. Task E might be locating the house on the lot. Errors or omissions in task A or B, therefore create problems in task E. In order for the team conducting task E to complete their work, they must re-engage team A and team B to resolve the issue.
Now, consider that any error or omission isn’t discovered until task Q. Issue resolution now requires engaging many of the previous teams, creating a large number of project changes.
The effects of these issues can be easily identified in a variety of ways:
Large number of changes found toward end of a project
Team members spend more time addressing issues, getting questions answered, or gathering information than they do performing the work
Frequent “emergencies” to address issues to get a product out on time
Project delays increase as the project proceeds
In its simplest form, ask yourself how many times you go to your favorite home improvement store to finish a home project (upgrade a closet, finish a basement, remodel a room, etc.) The common element in all these effects boils down to managing task interdependencies.
The Lexicon
The discipline of project management, like all disciplines, consists of a set of esoteric terms which may not be obvious to all readers. To address both formal project managers and the general readership, we define the following terms:
Task or Activity: A specific action that creates a deliverable, result, or work package. Formal project management defines a work package[1] as a well-defined component of a deliverable. Activities (or tasks) represent the steps needed to create the work package.
Predecessor: Task or activity that precedes (comes before) another activity. The result of the predecessor becomes the input to the successor.
Successor: Task which follows another activity.
Deliverable: The artifact that is transferred to the successor activity. Sometimes called the result.
Why are Task Interdependencies so Challenging?
Projects are likely the least understood of the work endeavors performed in organizations in both the fields of practical management and academia. Unlike other organizational endeavors, projects form a complex network of activities as depicted above.
If you have an MBA, you may have studied the subject of Task Complexity. While several models of task complexity have been offered over the last few decades, most fail to address the characteristics of complex networks (e.g. projects) (Haerem, Pentland, & Miller, 2015). Charles Perrow, for example, divided activities into four categories based on task variability and task analyzability (Jones, 2013). James D. Thompson (Jones, 2013) developed the theory of Task Interdependence. This theory categorizes organizational work based on the interdependencies of tasks needed to convert inputs to outputs. One such category is called Long-Linked Technology which is based on sequential interdependence. Thompson’s model suggests linear dependencies such as those found in production lines or business processes. In sequential interdependence, the output of one task becomes the input to the next task. The results of the first task, therefore, affect the performance of the second task (a domino effect).
While Thompson (Jones, 2013) and others recognize the domino effect of task interdependency; projects, by their nature exhibit a greater degree of complexity than seen in sequential interdependence. Haerem, Pentland, and Miller (2015) recognized the consideration of task antecedents regarding task complexity, expanding this view.
Simply put: sequential interdependence suggests that each task has a single predecessor and a single successor. However in projects, tasks have multiple predecessors and successors. In sequential interdependence, problems grow linearly as they move through the endeavor. In complex interdependence (e.g. projects), problems grow exponentially.
Managing Task Interdependence
Managing task interdependence is simple in form, however it requires a high degree of rigor. First, we consider the form (using a step-by-step analysis), second, we consider the rigor.
Managing Task Interdependence – the Steps
Step 1: Start with a complete list of activities
Most project managers are familiar with the Work Breakdown Structure (WBS). The project manager works with the team to create a complete list of activities for the project. Creating a WBS involves decomposing high-level deliverables into specific steps (or activities) needed to create each deliverable.
It is beyond the scope of this paper to present the details of either the activity of creating a WBS or its characteristics. For the sake of this presentation, we simply assume that the WBS creates a COMPLETE list of all activities needed to complete the project.
Step 2: Identify the Predecessors and Successors of each Activity
The project manager works with the team to determine what each activity needs to start. Using our previous example, we ascertain that determining where a house will be located on a plot of land will require the outside dimensions of the house and the plat of the land. Certainly, it also might require more inputs, such as the building requirements regarding the buffers needed between the building and edges of the lot. The project manager employs the expertise of his/her Subject Matter Experts (SMEs) to establish all the needed predecessors (inputs).
Step 3: Determine the Complete set of Requirements of Each Activity
Once the predecessors and successors have been established, the team SMEs must clearly define each activity. This includes determining the specific requirements that each predecessor needs to ensure the following-task performers have all the correct information they need. This step, perhaps is the most challenging within the framework. The activity requirements must meet two conditions:
Succeeding tasks need to have all the information and artifacts needed to complete their tasks
Activity requirements must support the ultimate customer’s requirements
Several tools exist to aid in development. One such tool is the Goals Breakdown Structure or GBS (see The Goals Breakdown Structure later in this document). Another common tool is called Requirements Traceability.
Step 4: Execute the Activity
Once the activity is well defined and contains all the requirements needed to satisfy both the customer and succeeding tasks, the project manager assigns a skilled team member (or members) to perform the activity.
During this step changes may be discovered. Requirements may be inaccurate or incomplete; or technical, design, or scheduling issues may arise. As they do, these need to be immediately communicated to both the project manager and succeeding task performers.
This is a crucial part of execution. This resolves issues quickly and at minimal cost ensuring a smooth project flow.
Step5: Ensure Rigorous Quality
Ensuring rigorous quality classically involves two sub-steps: unit testing and peer reviews. As each task completes, the task performer, with the aid of others, ensures that each task requirement has been met. The task performer first runs unit tests to ensure all requirements have been met. While necessary, unit testing is insufficient. Have you ever tried to proofread your own documents? Generally, you’ll manifest the same mistakes testing the results as you made in creating the results.
The next sub-step is a peer review. Peer reviews bring extra pairs of eyes to the results to ensure compliance. Peer reviews not only ensure all requirements have been met, they also allow the team to exchange best practices.
Step 6: Transfer the Results and Report Discrepancies or Changes
Once the peer review is complete, the task performer transfers any changes along with the task results to all the succeeding tasks, and completes their administration (recording actual times and costs, and handling any other administrative activities).
This completes the task.
The Goals Breakdown Structure
Breakdown structures simply are hierarchical decompositions of larger items into smaller items. Most project managers are familiar with the Work Breakdown Structure (WBS). With the WBS, project managers with help from their team members, break down higher level activities (or deliverables) into smaller activities (or components of deliverables).
Goals exhibit the same hierarchical characteristics (Juran & Gryna, 1988). For example, to build a table, one must first determine the overall characteristics (requirements) for the table (size, height, finish, weight requirements, etc.) Then, one can determine the characteristics of each component of the table (size and shape of the top, legs, etc.). The lower-level characteristics must align to ensure the completed table meets the higher-level characteristics. For example, the length of the legs plus the thickness of the table top must add up to the overall height of the table. The legs must be finished the same way the top is finished, etc.
In projects, there are at least four separate layers of hierarchy. These are:
Overall goal of the project
Organizational objectives
Product requirements
Component specifications or requirements
Larger, more complex projects may exhibit more layers, but we’ve found in our experience that these four layers do nicely for most projects. Consider figure 2.
Figure 2: Hierarchy of a Goals Breakdown Structure
The top layer is the primary mission or goal statement for the project (frequently called the Project Statement). Example: Create a beautiful dining room table to entertain 8 – 12 guests in a formal atmosphere.
The next layer is the business objectives. These include (typically) 5-7 measurable (if possible) goals the business desires the project to achieve. These are typically represented in the organization’s strategic plan.
A partial set of business objectives for the table project may include:
Table shall be a classical “old world” style
Table shall allow for a minimum seating of 8 people and a maximum seating of 12 people
Table shall cost no more than $4000
Table shall be ready for service by 11/17/18
Table shall resist staining from hot (180o) or cold (10o) plates placed directly on the top
…
The third layer is the project’s requirements. These include a (usually) large number of both product and project requirements (or characteristics) needed to meet the business objectives. These are created by the customer and the performing organization’s business analyst. A partial list of requirements may include:
Table shall be made of mahogany
Table shall be prepared with no less than 4 coats of polyurethane
Table shall be 12’ long x 3’ deep x 2.5’ high ± 1/8 inch
Table shall be able to support 400 lbs.
Table shall provide for an extendable leaf of 3’ x 3’
…
The last layer of the GBS contains the specifications or requirements of the individual tasks within the project. These are developed by the technical staff or SMEs. Specifications for the legs must take appropriate higher-level requirements into account. Assuming the thickness of the table top is set at ¾ of an inch, a partial list of component (or activity) specifications for the legs may include:
Legs shall be 2’ 11 ¼ inch in height ± 1/16 inch
Legs shall be mahogany
Legs shall be prepared with no less than 4 coats of polyurethane
…
As one can see, certain changes in the manufacture of the top may affect the legs. Using a simple example: if the team building the top discovers that they can’t use a 3/4 inch top, the height of the legs must be adjusted accordingly. If this issue is not communicated, the result will be a table of the wrong height, causing rework and potential “emergencies” at the end of the project.
The Issue of Rigor and Culture
Initially, the level of rigor needed for successfully managing a project may seem onerous. However, our research suggests that this issue is more about culture. Several pockets of cultures exist where this level of rigor is the norm, it’s just the way things are done. It’s habit, it’s standard, and it’s in the threads that bind the organization.
In such organizations, goals breakdowns are part of every design. Aligning lower-level requirements to higher-level requirements are incorporated within each project (in US government contracts, the process is called Requirements Traceability). Peer reviews are commonplace. Changes are immediately communicated to management and adjacent teams.
Such organizations complete projects faster and with higher-quality by eliminating the confusion, frequent interruptions, and problems associated with many projects.
Focusing on cultural improvements that align with productivity can substantially improve organizational productivity. These cultural characteristics (called Key Success Parameters, or KSPs) become the basis of designing a high-performance organization. In such organizations, managing task interdependency is not onerous, it is a norm, it is habit. A brief description of each KSP follows:
KSP 1: Clear Definition
Staff and management habitually clearly define the requirements of specifications of each activity within the project. They ensure requirements trace up to meet customer’s requirements and ensure all succeeding task performers have all the information they need to complete their tasks.
KSP 2: Ownership
The project manager assigns an individual who is responsible and accountable for the successful completion of each task, for communicating changes in schedule, cost, or requirements, and ensures all requirements have been met.
KSP 3: Customer Focused Deliverables
Team members ensure each activity’s requirements align and support the customer’s deliverables.
KSP 4: Collaborative Spirit
Team members proactively engage each other to communicate changes, resolve issues, and efficiently complete each activity.
KSP 5: Task Interdependencies
Project managers and staff proactively manage and communicate issues that affect adjacent tasks.
KSP 6: Rigorous Quality
The task owner ensures that they meet each requirement through unit testing and peer reviews.
KSP 7: Risk Management
Project managers and staff proactively address possible risks, communicate and manage risks as they occur to ensure smooth project flow.
Summary
Projects consist of a complex network of interdependent tasks. Each task may have multiple predecessors and multiple successors. Changes and quality issues in one task can have an exponential effect on tasks downstream. The longer issues remain unmanaged, the greater the impact on the project’s cost, schedule, and quality.
When properly managed, each activity within a project must be clearly-defined with measurable specifications. The results of each activity need to be verified to ensure quality. Changes that occur during activities need to be communicated to both management and downstream tasks owners to ensure issues don’t propagate.
Managing task interdependency can appear onerous. However, manifesting a culture of clear definition, rigorous quality, and communication will build teams that complete projects faster and with higher quality.
References
Haerem, T., Pentland, B. T., & Miller, K. D. (2015, July). Task complexity: extending the core concept. Academy of Management Review, 40(3), 446-460.
Jones, G. (2013). Organizational theory, design and change (7th ed.). Upper Saddle River, NJ: Pearson Education, Inc., as Prentice Hall.
Juran, J. M., & Gryna, F. M. (1988). Juran's Quality Handbook (4th ed.). New York, NY, USA: McGraw Hill, Inc.
[1] In formal project management, precedence diagrams are built from activities, not work packages. Therefore, this paper focuses on activities rather than work packages.
