Navigating Complex Projects: Managing Team Dynamics for Success - There’s an “i” in “id”, but not in “team”

The oversize digital project

Earlier this year, we successfully delivered one of the largest Sitecore projects Konabos has so far undertaken.

The project’s objectives were nothing uncommon: upgrade all our websites from Sitecore 9 to Sitecore 10.2, and in the process, move them from the existing AWS cloud hosting environment to a new (better) AWS environment.

Sitecore upgrades, whilst by no means easy, are a known quantity. Konabos have done plenty before, and there is both official and community documentation on how best to go about it.

Setting up a new Sitecore 10.2 environment on clean, new AWS infrastructure, is also straightforward enough. From both a logistics and risk perspective, it was more practical to create new 10.2 versions of the Sitecore-based websites on new infrastructure, leaving the version 9 websites to run on the existing production infrastructure.

So far, so good.

But as every seasoned PM will tell you, when you start mapping out a project, you should take time up-front to discover the risks and challenges unique to the project before you. These are the project-specific risks you should seek to mitigate and the challenges you should plan for, not generic risks like “my lead developer gets the flu”.

For this project, the most significant unique challenge was the sheer number of Sitecore 9 websites we needed to reproduce in Sitecore 10.2 on the new infrastructure. 136.

The most significant risk was that each of these sites had been created and worked on by multiple different agencies, staff, and consultants in their history; what would we find? Equally, whilst we were busy creating upgraded versions of the sites in the new environment, the Sitecore 9 production websites were still being changed by the agencies, client staff and consultancy partners. Both code and content.

So that brings us to the topic of this blog: how to successfully manage large-scale digital projects with multiple stakeholders across multiple organizations. More specifically, how to leverage the team dynamic to mitigate project risk and improve the project outcome.

People are people

At least for now, a project team is made up of people. We can speculate about how AI might change that for the worse or better, but for now everyone involved in a project is an individual human. Each team member comes with their own personal history, their likes and dislikes, abilities, and preferred way of working. The number of stakeholders across the organizations will dictate the frequency and complexity of team interactions.

As much as your whizz-bang project management tool is fantastic at calculating KPIs like velocity, projected end-date and cost based on current data, and so on, it will hopelessly fail at factoring in the differences and similarities between team members. The behaviours and preferred working styles of each team member are going to impact every other aspect of the project. The KPI outputs of a project management tool are, at best, an estimate based on the past data it can refer to.

As with unique risks to a project, there will be some unique inter-personality issues to overcome, or at least learn to live with. Yes, people will get flu, go on holiday, perhaps leave the company, or be pulled onto a more important project. This is all par for the course. But what can’t be predicated is how the team members will interact with each other and how that impacts project progress and staff morale.

Human psychology, Myers-Briggs and all that

The group dynamic is driven by the personal psychology of each team member. What makes them tick. Think about that for a minute.

As much as your project management software cannot factor in the human element of projects, often (sadly) the budget holder doesn’t want to hear about the group dynamic either. He or she just wants to know if it’s running to schedule and if more cash is likely needed.

But if the team is unhappy, you can guarantee the project will over-run and thus go over budget. The quality of the work is likely to be poor.

The Briggs Myers Type Indicator Handbook was published in 1944, named after the two researchers Katharine Cook Briggs and Isabel Briggs Myers who formulated their MBTI theory as an extrapolation of Carl Jung's writings in his 1921 book Psychological Types.

Contemporaneous to this, Sigmund Freud introduced his psychoanalytic theory: the mind is divided into three parts: the id, ego, and superego. The "id" represents the primal, instinctual part of the mind that operates on the pleasure principle, seeking immediate gratification of basic desires and needs. It operates on unconscious drives and is devoid of reason or morality. It unavoidably finds its way into project team dynamics.

The official MBTI “test” in its modern form was created in 1987. It attempts to assign a personality type to each team member so there is some way to predict how different members are likely to interact with each other. This topic would make a fascinating blog in itself!

To simplify the process of choosing people to establish a harmonious project team from the outset, David Keirsey developed the Keirsey Temperament Sorter based on the MBTI system. He maps people’s temperaments to the Myers–Briggs groupings and gives each of the 16 MBTI types a name, as shown in the table below.

According to Keirsey’s model, I am personally an archetypal ENFP “Champion”. Happy me!

Discord arises when there is dissonance between people’s pre-conceived notions of what a “Developer”, “Product Owner” or “Project Manager” ought to be, and how they should act and interact. Simply put, people just assume each team member will drop their own personal style for a project and adopt some kind of generic interpretation of a what a “QA Leader” (for example) should be.

Once the team gets to know each other, successful teams will find ways to accentuate individual behaviours that are positive and improve the project dynamic. Unsuccessful teams will get stuck in their pre-conceived notions of how people are supposed to behave when playing a given role, leading to poor morale and lowered productivity.

But humans are humans. And there is always a way to make a team greater than the sum of its parts; even if that means releasing people from the team. A simple example: any team that has two “Field Marshals” will incur constant friction and turf wars; just exactly what you don’t want.

Be assertive

Just to touch on this briefly, how a human behaves to try and get things done, or get their opinion and/or feelings across, will have an enormous impact on a project. There are four modes of being, and only one that has proven success. Those being:

• Passivity – “I’m not really qualified to do this, and I don’t think this is a good idea, but I’d better not say anything”
• Aggression – “I don’t care what’s going on in your private life, just get your bit of the project back on track”
• Passive-aggression – “Oh, please don’t tell me that we’re running low on budget again”
• Assertiveness – “This is the best way to achieve this deliverable, let’s get this done as a team”

Effective team interaction relies on all team members being assertive, avoiding the other three negative modes of behavior.

Conclusion: optimizing team interaction for successful project outcomes

A good team, whether completely internal, cross-departmental, supplier/client or any other configuration, will always quickly self-organize and divine people’s personality traits and communication styles. And they will live and let live. Whoever is the best speaker, presents, Whoever is the best analyzer, crunches the project KPIs, and so on.

Back to the outsize Sitecore upgrade project.

Given the scale of the project and its duration, it was inevitable that team dynamics would begin to fray by the mid-point. People get stressed; their personalities are laid bare. Passive-aggressiveness creeps in. Our extended team was assertive enough to catch this quickly and course correct (with some humble pie being consumed). Over time, the team warmed up and we became an efficient self-managing unit, playing to our strengths. I wonder how much better we could have done if we had considered project psychology and team dynamics during the planning and resourcing phase?

In any case, “Vive la différence”! The project was a great a success – and just as importantly, people have fond memories of the project and are intensely proud of their achievements as part of the wider project team.