Part 2 of 5 – Trust

PricewaterhouseCoopers Project Team - India

PricewaterhouseCoopers Project Team - India

Inside organisations, trust is a significant and increasingly pervasive issue. I continue to experience this both in the UK and worldwide. Before arriving on this critical GSM portal project, I spent a great deal of time scenario planning for all the eventualities that could and did arise. One of those scenarios gave rise to the possibility of a project restart where Croatia would need to work with its Indian counterpart. The scenario came true, which led to my managing and working with; a small Indian team in Zagreb, the Zagreb team, and the remaining Indian team back in Chennai. What I did not realise straight away was that I would also be managing the London team – but while the teams trusted me, they had some difficulty in trusting each other!

——————-

Croatia led the GSM Portal development, not only because they held a significant skills advantage, but because they were closest to the client. London continuously (and strategically so) vied for the rights of client management. India took the backup role; assisting development by providing quality assurance for example. It soon became clear that the project was being deliberately sabotaged because the protocols for establishing project trust were being hindered by; the jostle for project control, poor communication, lack of respect for working culture differences and an onslaught of bad decision making.

Onsite in Zagreb for example, there were territorial management issues with London. Zagreb believed it held the right to manage the client. London fought back on the basis that a more professional image (financial perspectives withstanding) was important to be demonstrated. Although roles and responsibilities in the project were agreed by all (including the client), these territorial issues were systematically grinding the project down (which later, indirectly led to the client suspending the project).

The territorial issues on the GSM Portal project were a direct consequence of the inability to make good decisions and  maintain the agreed upon roles and responsibilities. There was no consistency to generate learned trust. For example suppliers were constantly letting the project down; IBM deliberately hindered the project by not making available its AIX experts. IBM was immediately pushed into action when I discovered – through the audit – that there was no AIX technical expertise.

Ego was constantly distracting the major players from operating in a professional and inclusive manner. The impact of the lack of consistency to maintain our roles and responsibilities, for example, created a distrustful environment. It affected all of the project stakeholders. Trust issues were also brought on – and were contributed to – by external factors. For example, we faced hostilities in the form of; being blamed for not attending the client paid training, new ideas, lack of senior management support, low esteem across all project teams, poorly consulted implementation processes, disparities in functional and technical process viewpoints.

The impact of this deliberately caused distrustful environment was realised by the project slowing down. Conditions became so bad that they were breaching non-compliance levels.

-\/-

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s