A + B = X Factor: The Formula for Improving IT Performance

How is it that high-performing teams work so well? Is it something innate? Is it luck? Or is there a repeatable formula that results in outstanding team performance? The spoiler is in the title of this post! Leaders can produce superior results by consciously managing team dynamics to create ideal environmental factors for a team’s unique demands.

It’s all about giving teams what they need to thrive. Here is the model we use to determine what a given team needs to succeed. 

The Nature and Nurture of Teams

What forces decide who we are as people? What shapes us, determining our motivations, methods, or fears? Are genetics the primary determinants of behavior? Or is it a person’s environment, such as upbringing and life experiences, that form a person’s ways? As is often the case, the truth tends to be somewhat in the middle. It’s particularly difficult to determine which is more important, as for most people, our parents provide both our genes and the environment in which we are raised, and it’s the combination of those two that makes us who we are.

Applying this concept to project teams, both nature (the leadership and composition) and nurture (organizational culture and team history) are important in driving performance. And just as parents are often responsible for both in a household, so are we as IT leaders.

We have control over team values, behaviors, and culture. To be effective, we need to understand how to influence team behaviors and manage the dynamics that can make or break a team.

A Primer on Behavioral Profiles

One framework that seeks to define these models is called Structural Dynamics, developed by David Kantor. The Structural Dynamics model breaks down behavioral profiles into three categories:

  • Communication domains: the specific words that we use to communicate our thoughts
  • Action domains: the responses we have when we communicate with others
  • Access domains: the group environment in which we work best

Each individual is partial to a certain combination of communicating, behaving, and interacting with others. This fact presents an opportunity to understand and use these preferences as a tool to improve performance.

Communication Domains

Recognizing various communication styles helps team members speak the same language and reduce misunderstanding.

POWERAFFECTMEANING
Action & productivity
Time-bound
Completion-oriented
“I do”
“I want / need”
Trust & relationships
Emotions
Consideration of others
“I feel”
“I care”
Data & analysis
Purpose & mission
Ideas & understanding
“I think”
“I wonder”

Action Domains

One team member’s first impulse after learning new information may not be the same as the others. 

MOVEOPPOSEBYSTANDFOLLOW
Initiate
Take action
Be first
Challenge
Push back
Vet concepts
Connect
Be unbiased
Big picture focus
Support
Carry ideas forward
Get behind

Access Domains

Some environments are better for certain outcomes than others.

CLOSEDOPENRANDOM
Formal leader
Defined roles
Plan-focused
Command-and-control
Egalitarian
Process-focused
Inclusive
Collaborative
No process or structure
Autonomy
Individuality
Creative

Let’s look at a few examples of how these ideas can help change the course of real-world projects:

Turning Around a Death March

An IT department found itself in Year 2 of a 6-month system implementation. The project had been passed back and forth between various departments, reprioritized, frozen, restarted, rescoped, and everything in between. Executive satisfaction with the project was low, and nobody on the team actually believed the tool they were standing up—a contract lifecycle management system—would benefit them in any way.

The project team was not even the same team that started the project. In fact, almost everyone on the original project team had resigned, been reassigned, or been terminated.

It was a dreaded death march project.

In project management, a death march is a project that the participants feel is destined to fail, or that requires a stretch of unsustainable overwork. The general feel of the project reflects that of an actual death march because project members are forced to continue the project by their superiors against their better judgment.

Wikipedia

The current team members seemed to operate best in an open meaning model, which called for collaborative work involving understanding the reasoning behind each decision. Unfortunately, the organization as a whole operated mostly in a closed power structure, which is typical of large corporations. Here, senior leaders set deadlines and expected fast results.

We facilitated a workshop with the project team and stakeholders and asked:

  • Why are we doing this project?
  • Who will benefit from it?
  • What do we need to do to get it done?
  • Who can get these things done?
  • When do we think we’ll be finished?

At the end of the day, the team came up with a new plan. Team members each took on various tasks to help drive the overall project to completion. The team became self-responsible, and morale improved significantly. After just a few weeks, we started to make real, measurable progress towards the final goal, which, in turn, increased satisfaction and engagement from executives.

Simply meeting the team’s need to be included, collaborate, and understand the reasons behind decisions created noticeable momentum. What had started as a project destined to fail went live in just 4 months.

Increasing Participation 

On a recent ERP package implementation project, the Finance team had not been participating much. On top of the testing, validation, and calls required for the implementation, the finance team still had their daily duties to attend to.

The root cause of these conflicts came from a lack of advocacy from the main project team. If the Finance team reported issues, they would often get lost in the shuffle. There was little representation from their specific team in the debriefs, and tasks were handed to them without consideration for their preexisting workload.

Turns out, the Finance team operated mostly in open and random affect, which conflicted with the overall project team’s operation in a closed meaning and power model. Where the Finance team sought consideration or at least acknowledgement of their situation, they received explanations for why a specific task was important, and questions about when it would be done.

Naturally, without participation from Finance, an ERP implementation is not going very far. It was critical to get them on board.

First, we put together a list of all issues that the team had identified and put them in the pipeline for resolution. Once the issues they had logged finally started getting resolved, the team felt much more motivated to participate in the other project activities.

Next, we addressed the matter of workload. Finance was short-staffed to start, and the amount of testing and processing was difficult to fit into the schedule. After evaluation of the process, we found that some procedures could be taken off their plate and performed by those who had more bandwidth.

Quickly thereafter, performance greatly improved. Once Finance felt their input was valued by the project team, their concerns were addressed, and their relater tasks were relevant to their function, participation increased dramatically.

When the system went live a few months later, the Finance team was heavily involved in the project. They went from being one of the last teams to complete their tasks to being one of the first. Better still, once the system went live, there were fewer issues in the Finance module than in any other.

The Magic Formula

Team Nature + Healthy Environment = High Performance

When the optimal environment is created to support a team’s natural inclinations toward communication styles, action, and access, you have the formula for success.

Leave a Reply

Your email address will not be published. Required fields are marked *