It’s not always possible to know (or choose even if you did know) the skills and experience of everyone on a project team.
Sure, we may know the technical skills required (especially on a software application development project), but that is only part of the story when getting a team to work productively.
I guess we all will have heard of the “forming, storming, norming, performing, mourning” metaphor.
But in case you haven’t or can’t recall:
Forming – the team comes together and may well not know each other at all, people are usually initially polite and sound each other out, though forming impressions of each other very quickly
Storming – the next stage of project life – the team members start to ‘test’ each other, exert their influence, jockey for position (perhaps), argue, disagree, and push each other’s boundaries.
‘Norming’ – relationships normalise, initial impressions of each other have been reinforced or painfully changed through the storming phase and people react to each other in a more learned (about each other) way. The ‘johari’ quadrants have been expanded and realigned.
Performing – not all teams hit this stage, but when they do it’s usually from mutual respect and the team members recognise and play to key strengths of individuals whilst also compensating for each other’s perceived and real weaknesses.
Mourning – probably only a stage that is hit by a team that achieves the ‘performing’ phase. Team members lament the break-up of the project (the team really) because it was a supportive, rewarding and usually successful work-time. Even when many years have past the team members will recall ‘that project’ (that team) as being one of the best working experiences of their life.
Once past a few projects it is fairly obvious that this is forming, norming … process is exactly what happens each time a new project commences with people who have not worked together at all, or for a while, in a project team environment.
The team membership make-up directly contributes to how long and how intense each of these stages within a project lasts (or even if the latter stages ever occur).
And that can directly affect the success or otherwise of the projects goals.
At one extreme the project will just fall apart (despite you being a fantastic project manager!). At the other, the project will be a sublime positive experience that resides in all of the team member’s psyche for years.
The latter experience really makes projects fly and yes; you will yearn for these halcyon days in later projects that have poorly gelling team members.
So is there anything to watch out for? You may not always (if ever?) get the sublime experience of the emergence of a perfect team for the project/job in hand (I have a few times – am I just lucky?), but what can we try and influence to enable the chances that this will happen?
Firstly let us get the technical aspects out of the way. I assume from now that you can and have secured the correct blend of technical skills and experience required to carry out the specialised IT work. See, that was easy!
Yes I know in practice this can be as difficult to achieve as anything else, but it is reasonably obvious as we gain more detail and granularity of plans and solutions downstream as to what IT skills and experience is required, so I will just take this as a given.
So let’s get to the real successful project triangle…
People are complex. IT people often have egos ranging from the size of small planets to the size of the universe.
So, here is our first ‘gotcha’!
You have to be able to control people with massive egos. Especially those who have an ego that eclipses yours (is that possible?) If you can’t or won’t, then you must not have these people on the team. If you have no choice, then make sure you only have a few of these types relative to the team size.
The problem is that (usually but not always) there is a direct relationship between a massive ego and massive talent/success (albeit this might be in a narrow IT discipline that many people would not even have heard of).
Therefore first thing on our checklist is “ego-power” – it is the nuclear aspect of project teams – it can light the way for centuries or destroy all in its path. If you can’t control it, don’t use it. It really is that simple a rule. How honest you are about this to yourself is another factor though .
People are communication engines. IT people often and regularly misfire in this regard.
Our second gotcha has more difficult nuances to master.
The “N squared minus N divided by 2” rule (you know this one too right?) becomes all the more difficult to keep oiled if one of the nodes becomes asynchronous.
What am I talking about? Well the above is a self-illustrated example. Some IT people really find it difficult to construct meaningful verbal or written communication (but notwithstanding that, can often code programs faster than light) and others get so far entrenched in ‘consultant speak’ they obscure the real meaning of any communication.
Again it’s one extreme to the other, the middle way is needed. Too many AIs (Articulate Incompetents) or too may ICs (yes – Inarticulate Competents) and the team has a risk of meandering off course. ACs are what you need.
People like people. Mostly.
And finally, there are some people who just cannot perform as part of a team. Be brave don’t use them, specialist skills or not. It’s not worth the aggravation to you, the team and therefore the project.
The ECT project triangle…
It would be (relatively) easy to create a team based within the framework above if you had the required knowledge about potential team members (include yourself in the team – try a bit of self-analysis if your ego permits ) before the project kicks off.
And could choose team members at will.
But rarely is that the case. So mostly we just have to juggle, adapt and control within the real project iron triangle – the Ego/Competency/Team Player (ECT) triangle.
OK then, you got me, what is n squared – n etc all about?