Do you name your teams?
Do you name the projects they work on? Do you spend time at the water cooler with the users on your teams? Do you have T-shirts or coffee mugs printed up with the project team’s name and a slogan? Do you repeat your nicknames for the users on your team to their faces?
Do you and your team’s users all joke about management? Do you occasionally dig into your own pockets so everybody on the team — users and IT people alike — can have shirts that read, “We blew $2 million on The Project From Hell and all I got was this stupid shirt”?
And if you think that sounds like a lot of phony “morale-building” malarkey — well, where do you get off calling them “teams,” anyhow?
Sitting around the same table with users doesn’t make you all teammates. Reviewing the same specifications and agreeing on the same schedule isn’t teamwork. Running a pilot and collecting user comments doesn’t make you a team.
It’s not a team until team loyalty and cohesiveness are at least as strong as the cultural and political ties that pull users and IT people apart. It’s not a team until you’re all committed to making the project work.
It’s not a team until you trust each other.
That isn’t as crazy as it sounds. Users — real users, the people who actually spend their days trying to get work done using the systems we build — want systems that work. So do programmers and network administrators — the people who build those systems and keep them running. There’s common ground. Trust and teamwork aren’t impossible.
But they aren’t easy to achieve, either. A level up from users and developers on any team are bosses worrying about budgets, struggling for control and jockeying for leverage. All around the team are other users and IT people who may think those are two sides that shouldn’t mix.
There’s history and corporate culture that make real teams tough to build, politics and personal vendettas that make them difficult to keep together. Us and them are hard labels to overcome.
Which is where the team names, T-shirts and mugs come in. Sure, they sound like gimmicks. They are gimmicks. But they brand the people who get them as part of the team — a new group that’s neither us nor them.
Besides, they’re the cheapest part of building a team. Far more expensive in time and patience are the coffee breaks, the in-jokes, the process of getting to know your teammates’ likes and dislikes, weaknesses and strengths — gaining their trust and learning to trust them.
Is all that necessary? Not for easy projects. Easy projects are, well, easy. We don’t need user/IT teams for them — though they’re a good place to get practice at team building.
But face it, we don’t get many easy projects these days. Everything seems to happen on shifting ground. The requirements change from week to week. The technology is perpetually in beta. The schedule’s never long enough. And nobody’s exactly sure what they’re doing.
That’s when you need users on your team. They’re the ones who can tell you whether you’re on the right track. They can give you a heads-up for those requirements changes and keep you from heading down blind alleys. They can give you confidence that you’re building something useful, and provide real-world advice on making sure it’ll pay for itself.
And they can tell you when you’ve screwed up — maybe giving you enough advance warning that you can recover without the problem escalating to the point where your boss and their boss butting heads in front of the CEO while the project goes down in flames.
And whose morale will that build?
Frank Hayes, staff columnist for Computerworld US, has covered IT for more than 20 years. Send email to Frank Hayes.