Relationship management: The unsung art of optimizing IT teams
Here is an example: Let’s say you are developing a retail sales system that will be used in Europe and the US. The European countries charge a value-added tax (VAT) to goods, while the US uses a sales tax that varies by state.
Here is an example: Let’s say you are developing a retail sales system that will be used in Europe and the US. The European countries charge a value-added tax (VAT) to goods, while the US uses a sales tax that varies by state. In Europe, VAT taxes also vary by country, so you have business analysts working with end users on screen formats and process flows for sales order entry, and so on, but you also have an IT infrastructure programmer on board to develop a callable, internal tax calculator module that can apply the correct VAT or sales tax rate to a given transaction based on the applicable country or US state involved.
In our example, the infrastructure programmer normally works — and prefers to work — on her own. Her domain is pondering and developing highly complex technical work, and if she doesn’t talk to anyone in a day, it’s preferable.
You understand this, so to limit this individual’s time on the “people” side of IT, you assign QA to the quality assurance team, as well as to the business analyst and end user involved in the project. If for some reason there is a problem with the tax calculator module, it is the IT-savvy business analyst, who can speak the infrastructure programmer’s language, who engages with her on any needed changes.
This example sounds straightforward, but it emphasizes something subtle about relationship management that goes beyond roles-based working arrangements. Contrary to development methodologies like agile, here you’re not trying to engage the entire project team on every phase of the project. What you are doing is taking account of everyone’s preferred mode of performance so they can do their best work.
Putting personality to work
I’ve talked to other CIOs about scenarios like this, asking them whether they take staff personalities into account when establishing work processes. Many counterargue, saying, “We don’t think about personalities. But we end up running our projects that way anyway, because we don’t want our most expensive infrastructure programmers wasting their time in user meetings.”
Touché. But there is also an ingredient in project team staffing that should take into account the natural synergies between people. And this requires learning about the individual personalities on your team.
About Author
