Can conflicts within Software Project teams kill Projects?

The simple answer: Yes it can.

Introduction

In any typical Software project team, there would be a natural mix of roles that include Business Analysts, Architects, Designers, Developers, Testers, Team leads & Project Managers, etc. As the complexity & size of the projects increase, the number of sub-teams & team members would increase.

As teams & team members increase, the communication load increases exponentially.

And as the communication load increases, the potential for project conflicts also increases.

Most importantly: When a team is in conflict, the tone of communications becomes confrontational, and the effectiveness of the team is negatively impacted as a result of:

  • Inappropriate or questioning focus being applied to performance shortcomings of sub-teams
  • Finger-pointing & blame games
  • Aggressive reactions to confrontational communications
  • As opposed to being focused on the larger vision of project success.

Controlling the tone of communications will be key to managing the emotions & the team dynamics in a project team, and thus, the effectiveness & productivity of the team.

A peek into the roles involved

In any Software project, there may be different roles involved:

  • Architects: Define the optimal Technology solutions for implementing the required Business processes for a given program or project. Leverages existing Technical architectures & Frameworks to the greatest extent possible, to drive up efficiency & maintainability of the solution. Architects are Technology experts who have expertise in specific Technology domains and possibly into Industry verticals.
  • Business Analysts: Translate the clients’ business needs into technically implementable solutions, possibly comprised of combining or enhancing existing products or product features to develop the solution. Business Analysts are typically Industry or Product experts who are able to assess the capabilities of existing solutions or products against the needs of a new Client project.
  • Designers: Develop an efficient, intuitive, highly usable, & highly likeable workflow for deploying the required business process or functionality. Designers are typically UX/ UI experts.
  • Developers: Convert the Business solutions into Code, using the inputs provided by the Business Analysts, and within the frameworks as defined by the Architects. Developers have deep skills in the specific Technology stacks adopted by the Architects for the project. Developers may bring different skillsets fo the table: Front-end, Back-end, Middleware, Integration, Database, Storage, DevOps, etc.
  • Testers: Perform verification & validation tests of the developed product at various stages, such as Integration tests, Regression/ Sanity tests, System Tests, Performance/ Stress tests, Security/ Penetration tests, Acceptance tests, etc. Each of these roles will also require resources with specific skillsets.
  • Team leads: Perform supervisory & advisory functions for their assigned teams. Will typically be resources with high skills in the specific areas that they are assigned to.
  • Project/ Program Managers: Are primarily responsible for client engagements, communication, overall planning, team coordination, governance, financials, etc.

Possible reasons for Project team conflicts

Timeline pressures:

The earlier stages (in case of Waterfall/ Hybrid) or Sprints (in case of Agile) of any project come with the lowest clarity, unless a project is a repeat implementation of a previously implemented solution. Hence, teams taking part in these stages would typically be under more tremendous pressure to generate clarity into work scope & implementation approaches, and then complete their work. There would also be more ambiguity that could exist at this stage, leading to more significant rework needs. The resulting complexity frequently drives schedule slippage, and places the burden on the following stages or sprints to achieve a catch-up, so that the overall project schedule can be achieved.

Prioritization challenges:

As the number of Client stakeholders on a project increases, the potential conflict due to Requirements prioritization would also increase. Client representatives on a complex project may be from different departments/ functions, and may raise conflicting requirements. Inadequate focus on qualifying & prioritizing these requirements appropriately would potentially lead to unhappy clients, Escalations, Rework, and Schedule slippage.

Mindset differences across Roles:

  • A developer has a “constructive” role inside a Project team – to build code, whereas a Tester’s primary job is to be “destructive” – to identify bugs & failures in the code or products built – even as he/she builds Test cases & Test suites to conduct the needed tests. This means that the Development & Testing roles are frequently pushed into confrontations.
  • A Team Lead’s responsibility is to both question his/her team’s progress and to guide them on their journeys, which at times creates a perception of micromanagement & intrusiveness.
  • A Manager’s responsibility is to plan at a high level and then monitor the progress of the various sub-teams as well as the overall project team. Sometimes, “pure technical roles”, such as Developers, Architects, etc consider the Manager as an overhead and not adding “real value” to the fundamentals of the project. This may lead to a lack of respect for the management function from the Technical roles, and a resulting unwillingness to align to the frameworks & boundaries set up by the Managers.
  • Each of the roles is thus configured to think and operate differently, and this leads to natural conflicts during project execution, especially during stressful times.

Relevance of Virtual teams & Remote work

With virtual teams and remote work, the co-location aspect of teaming is absent, which takes away the opportunity for people to come together & really go through the Teaming stages of Forming, Storming, Norming, & Performing, and thus iron out some of the differences in alignment.

Further, with the prevalence of cross-Geo / cross-cultural teams, the impact of cross-cultural differences is far more significant. What this means is: The barriers for “forming/ storming/ morning” teams is wider, and the potential for conflicts is greater.

How can we minimize Project team conflicts?

A reliable approach to minimizing team conflicts would include the following elements:

  • Alignment on the overall Project scope, goals, and constraints across the entire Project team. Broken down into scope, goals, and constraints at various project lifecycle stages, especially for complex projects.
  • Institution of a Team Charter, covering aspects like Team communications, Cross-cultural understanding, etc; Its’ communication via a Team Kick-off meeting, and supplemented periodically via Team meetings.
  • Definition of a clear RACI matrix (Roles & responsibilities) for the project team, and its dissemination to the entire team via a Team Kick-off meeting and supplemented periodically via Team meetings.
  • Developing mutual respect, driven by an insightful understanding of the value being brought in by each sub-team & team members. The insights into various sub-teams & roles by the Project team would be applied via the detailed RACI, and periodically reinforced during Team meetings.
  • Developing & institutionalizing a clear & structured Governance mechanism, preferably via a common Tool or platform, to assure information/ status capture & analysis at all required levels at the right frequency and granularity, so as to enable a “single source of truth” for project reporting.
  • Achieving clarity into project components and work tasks, and especially dependencies.
  • Achieving alignment across sub-teams, especially on dependencies.
  • The Governance mechanism must have systems to unearth issues & upcoming or missed dependencies, and escalate these to the appropriate action owners & impacted teams in a real-time fashion.

Where does the buck stop?

Clearly, the “Accountable” owner of the team conflicts minimization activities would be the Project or Program Manager, and supported (or “Responsible”) by the Team Leads.

The Project Management team must define a cadence of activities for:

  • Definition of the Team charter
  • Definition of the Team Roles/ Responsibilities RACI Matrix
  • Definition of the Governance model
  • Conduction of the Team Kick-off meeting & sharing of the Team charter, Team RACI Matrix, Governance model
  • Conduction of periodic Team meetings to reinforce the above aspects
  • Collection & analysis of Work status and dependencies
  • Assessment of risks & their impacts
  • Escalations for help needed, etc.

Diligently defining & adopting the above mechanisms can significantly help in minimizing the occurrences of project conflicts by addressing the root causes of conflicts.

Can these steps completely eliminate all such instances? Obviously not. At the end of the day, project teams are comprised of human beings, with their own individual stresses, pain points, and other circumstantial challenges. So people would continue to be stressed out & react.

However, those concerns that are primarily arising out of the project team issues can be contained to a great extent by adroit preparations & handling by the Project leadership.

Conclusion:

Project Management is a complex science, with parts of Engineering, Finance, Management, Human Psychology, Team Behaviour, etc all combining into a unique, large whole.

It is very important for Project sponsors & Project managers to assign appropriate value not just to the preparation, planning, execution, and monitoring/ control aspects of the technological & financial aspects of the project, but also to resources management and teaming as well, to ensure that the team is appropriately productive & predictably successful.

Towards this, the right thinking & planning must ideally be supported by the process framework and the right tools to really structure & execute the requisite actions at the appropriate times during the project.