For some time now I’ve been suggesting that we re-examine the basics.
This has meant the basics of communication, the basics of project management, the basics of team dynamics, and the basic understanding of how a culture feeds into and affects the behaviors of teams.
I am in the midst of exploring Eric Weiner‘s The Geography of Genius. He offers an expansion of the definition of culture. That, and the resulting tweak of its impact on us as people, struck me.
According to Weiner,
“Culture is more than what the dictionary tells us: “a set of shared attitudes, values and goals”. Culture is the enormous yet invisible ocean in which we swim. Or, to put it in modern, digital terms, culture is a shared IT network. Yes, it’s temperamental and crashes too often for our liking, but without it, we can’t communicate with one another or accomplish much of anything.”
He also makes the point that within every culture are sub-cultures – a part of, but also apart from, the overarching culture.
Think of it as the difference between how a person from manufacturing might view a new product versus how a person from product development might view it. Then throw in the folks from finance and the human resources department.
Each area of expertise has also generated its own sub-culture. The finance department of a company, focused on manufacturing consumer products, will likely have a different sub-culture than one that focuses on services in a business to business perspective. The sub-cultures of these two finance companies will have a great deal in common with each other. They will also have significant differences due to the underlying culture of the organization where they work.
Project teams (and specifically new product development teams) are particularly vulnerable to this as each project team – temporary in its nature – will also develop a sub-culture of its own. That sub-culture is still connected to the ambient culture of their organization. It also has the opportunity to become something more than the best parts of the larger culture – more productive, more focused, more profitable – by the simple fact of being separate, temporary, and often smaller than other groups that will form their sub-cultures.
These sub-cultures are a bit independent of, yet must align with, the higher level organizational cultures, an Organizational Breakdown Structure that focuses on culture, if you will, that focuses on the culture. The dominant culture may prize precision. The new product development team has to be able to embrace a larger level of uncertainty. Each sub-organization, each team, must change their behaviors to embrace and align with the larger culture without losing their specific focus points. Additionally, how will you keep from accidently affecting beliefs and values, resulting in behaviors that are counterproductive or downright destructive?
Weiner opens his book with this quote from Plato. I have long felt that it is one that would bring great benefit if more people would spend some time and give serious thought to it. It proves how far back you need to go, sometimes, when you go back to basics.
“What is honored in a country will be cultivated there.” – Plato
What is honored in the ‘country’ that is your team’s home and how is it manifested in their behaviors and productivity levels?
Key Actions for Higher Performance:
Gain clarity: what is the existing cultural norm? Do a project team's specific SWOT (Strengths-Weaknesses-Opportunities-Threats) analysis on the potential impact of the organization’s overall culture on your team.
Enlist and enroll key stakeholders in this exercise. Each member of an existing sub-culture that will participate in the project’s lifecycle and eventual success can give you valuable insight into the questions – and even answer some issues for your stakeholder analysis.
Prioritize! Choose the single area that you believe can either make the greatest difference, the fastest win, or the most visible win – and, based on what is most valued in the dominant culture of your organization, pick that one thing to work on first. The Key Success Parameters of any high performing project team are so beautifully intertwined that you will begin to affect other areas with a solid shift in one.
Contact me if you want to put our Team MRI to use in this effort. You can reach me at email@example.com. I’ll be glad to set up a link for your specific teams so that your results are immediate, discrete, and actionable. What will you do first with the results of this diagnostic tool?
Come to the Orlando Premier CIO Forum on Dec. 13 and hear me speak on “Defining Teams and Cultures That Deliver”. Join me and your peers for networking and hearing experts discuss IT topics and trends that are important to CIOs and IT Executives. Register now
When you work with organizations to help accelerate the productivity and profitability of their project teams there are questions that keep coming up:
‘So this is project management, right? Do you teach scheduling or something? Can you fix our project management application?’
The long answer is that we work with teams and they become more productive because of how they work together rather than the tools they use as they work together. Project management is the cloak that covers the down and dirty business of changing the behaviors and dynamics within the team. This is because, as a seasoned project manager, there is an assumption that underlies each team.
The assumption is that they already know the basics of scheduling, estimating and risk management. Well……you know what they say about assumptions.
Regardless of whether you use Agile, eXtreme Lean, Six Sigma or Prince2 as an approach there are some things that remain true.
You need to be able to communicate to your stakeholders.
How long will it take?
What will it cost?
When will it be done?
Why might it fail and what can we do about it?
Are there possible opportunities to wring other benefits from this work aside even from the stated goals and objectives of this project?
Sometimes you find that even your most fundamental assumption is groundless. Sometimes you find that, under the extreme time pressure of an ever-faster pace of business, people have lost-forgotten-abandoned some of the basic tools and approaches that would serve them well.
With that in mind, I am delighted that Michael Bender has taken on the challenge and has begun the task of creating micro-lessons – called uLessons on YouTube. These lessons will be taking you back to the basics. No lesson is very long – you could probably take one or two in and still have time for coffee.
Teams that are on the way to becoming more productive will still actively consider the value of their tools and approaches.
And there are times when a refresher isn’t a bad idea.
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 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 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
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.
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.
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.
 In formal project management, precedence diagrams are built from activities, not work packages. Therefore, this paper focuses on activities rather than work packages.
Lively – sometimes even contentious! – discussions about the requirements and the stakeholders
Spontaneous peer reviews
Number 1 seems to invite revolution – it doesn’t. When teams are coming together in true collaborative spirit to get very clear definitions of work required and the circumstances surrounding it, you will hear it. Sometimes it’s pretty loud.
And that’s a good thing.
Because questions and answers on topics that matter to the questioners and answerers can get loud. That’s great – as long as loud doesn’t signal antagonism or bad behavior. A spirited conversation that teases out what they really meant is a good way for team members to learn constructive communication habits. Asking, and getting answers, and finding that it’s quite safe to do so can result in greater creativity and more innovative thinking. Remember the last time you shared an idea with a trusted colleague? Did you ever have the experience when the very act of sharing the idea prompted your mind to tweak it, shift it or change it?
Spontaneous peer reviews indicates that the requirements are clear and technologists and the other professionals on the team are willing to work together to achieve them. It means that the focus has shifted to rigorous quality and away from ‘keep your head down and off the radar’.
More conversations will sometimes start as simply more noise – don’t let that fool you. As your team builds the levels of internal trust you will find that they, like so many others, will begin to develop team-speak. Team-speak is a kind of short-hand that relies on the ability to trust each other. Combine that with a focus on both clear definition of the subject at hand, and always keeping the customer in mind as the deliverables are crafted, and you’ll have a powerful team dynamic that delivers quickly, well, and with less overall stress.
Which one of these are you seeing in your environment – in your teams?
Encourage open discussion and reward the candid questions that seek to clarify.
Introduce peer review practices on small pieces of work at first. This gives the team members a chance to experience it, see the impact it makes to improve the work product, and grow the productivity level of the team.
Encourage conversation outside of status meetings and formal hand-offs. Encourage or even direct (at first!) peer to peer conversations when questions arise. This builds intra-team communication practices and higher levels of trust.
And you can start seeing the 3 top signs that your teams are more productive!
3 Top Ways your Teams can Dive into the Muck of Mediocrity
There is a lot of nodding but not conversation in meetings.
Peer reviews are being rescheduled, postponed, or resisted entirely.
Hand-offs between colleagues signal the first contact between team members other than project meetings.