They say that everybody needs a hobby. A colleague claims that one of my hobbies is kind of a guilty pleasure.
Because project failures fascinate me. Not, may I point out, in the way we tend to slow down by a car accident to see the crushed bumpers and crumpled car doors. Mostly I like to stop so I can hunt through the rubble to see how things might have turned out differently. Of course, there’s another prize in this treasure hunt – were there moments when this mess could have been averted? How can we recognize these moments so that there’s no ‘next time’?
Sometimes you just have to face an uncomfortable reality. Project rescue becomes necessary not because you have a bad project or bad team, but because your team has a cultural environment that stymies rather than supports. And when the team’s environment gets in their way the project is way more likely to jump the track than follow the route to success.
You might be thinking ‘WHAT cultural environment?’
Well, that’s kind of the point.
There is always a team culture – an environment and unspoken ground rules that are specific to how that project team works on that project. And even if you don’t carefully craft and nurture one, you’ll still get one. What are the odds you will get what you need from that accidental culture?
When we are called in to help a team rescue a project, we start with a diagnostic survey and series of interviews to discover the root cause. Sometimes you need new eyes, and while we’re looking around, we move right past the symptoms. Don’t get me wrong - they’re interesting – sometimes a bit scary, but somewhere in there is a root cause (or two!) that’s responsible for the problem.
Find, then confirm, the root cause(s). THEN the team, with a bit of support, works to regain ground, whether it means some training, individual coaching, or even facilitating a re-launch of the project.
Now, you might think that we’d immediately start training people on our Key Success Parameters but no.
The secret power of a leadership driven project management approach lies in the interconnections between each of the seven parameters – each parameter is an element of higher performing teams and their cultures. It’s the way they work in concert with each other that drives the evolution of teams into ensembles.
The debriefings we conduct with leaders are focused on what they need to do differently to get the result they want. And then we show them how to take this into other projects going forward.
This means when we work with every level of stakeholder - from sponsors to technologists, this is how the team develops a more productive cohesion. We don’t necessarily rescue their project. We help them rescue their project. They learn – and sometimes relearn – how to strengthen their ability to avoid the same kind of situation. Instead, they learn ways to work together to create fewer cycles, stronger deliverables, and shorter schedules.
By doing this, the project is rescued, the team is stronger – and (shhhhhh – don’t spread it around) the new and reshaped team culture will begin advancing the entire culture of the organization - one team at a time.
If you are interested in starting the conversation let us know and we’ll arrange for your team to take a complimentary survey – have a great week!
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.
This is a culture of specialists. I get that. Companies have problems that need special resources to address. I know that. I am one of them. Our company rescues failing or failed projects.
But it's not a surprise to read that there are some positions that have the same skill set as others. I came across an intriguing article recently that looked at the world of product managers penned by one of their own.
What quickly became clear to me is how closely the worlds product and project management hew to each other. Both are results-driven roles that share a goal of delivering products designed and produced to customer specifications.
The article featured the product management skills the author, Brian de Haaff, leans on most in his work. And as I read it, I saw that most of these skills are shared with successful project managers.
Here they are…. 1. Vision A clear vision means an understanding of the ‘why’ for product / project decisions. Once determined this will be your driver for the project. 2. Motivation It’s often been said that people don’t work for money. Sure the work can be satisfying enough, but what drives a team is the guidance provided by the leader, step by product / project step. Success is incremental, and gaining momentum means being able to motivate yourself and others around a shared goal. 3. Prioritization Once you’ve got a project on track and scheduled, it’s simply a matter of considering any prioritization requests against the vision for the project. 4. Transparency Being candid about project challenges within the team is crucial. You are responsible for swaying your team, sharing plan changes and inspiring them through your comments and actions.
The kind of top level thinking in this article speaks to the importance of a vision at the core of every project / product.
How many times have you seen a product or project team fall apart almost before they get started?
All because they didn’t decide on a unifying vision.
