Project conversations

Synop has recently started a new major project, that is Gantt-charted to take some of us through until early next year. It's going to be a fun project I think, involving solving lots of hard problems, expanding and enhancing Sytadel, and dealing with lots of structured, richly related content (or metadata as they like to call it). I can't say who it is as yet, because we've not yet signed a contract, but will talk more later.

I've been running behind as a consequence on keeping up with the Jones in the blogosphere, but was struck this afternoon reading Jack Vinson's recent post on project networks as a social network, pulling together the ideas of Patti Anklam and Dennis Smith. This set of ideas struck home with me, since I'd been spending a considerable amount of time setting up different communication networks for the project - internally for us in Synop and in association with our customer - along with setting up early project management reporting and planning mechanisms.

Along the lines of another recent post by Jack on PKM (starts the conversation), I've been adopting an approach of trialling different communication/collaboration/information sharing tools and channels, in the hope that at least some of them will prove effective and useful. I'm not exactly sure which of these is going to be the most helpful - maybe it will be the group email, maybe the project weblog, maybe the shared file storage. Guess we'll just have to suck them all and see!

Most interestingly of all, I've been struck by the value of conversation. All cross-organisational teams in the early stages of a major project go through a team-forming process. While doing some hard use case analysis with Nigel, an expert consultant to the customer, we occasionally took time out just to sit down and chat about ourselves, our backgrounds, passions and hobbies, and our experiences in life. Nigel regaled a great story he learned on a team course many years ago. The story goes like this:

The course had 12 or so people, and was split into 3 groups, each with 4 people. His group was left behind in the room, while the other two teams were sent off, the first to be set a task, and the second to await information from the first, and who would then pass more information to the third. The whole thing was to be strictly limited to an hour's duration, and they would be observed by the course organisers throughout the hour. There were two (male) engineers, Nigel himself, and a (female) corporate affairs person for a major company. The two engineers got stuck into doing some risk analysis about what might happen and when; Nigel sat back to chill out and enjoy himself since there was nothing that could be done; and the corporate affairs person said, quietly, calmly, that she was totally confident in the team and its ability to do whatever job was put to them, whenever that might be.

As Nigel remarked, the value of this was the confidence it brought to the other members of the team, and the optimism that whatever their task might turn out to be, it was going to be achievable, and they would do a good job.

The story tells me a lot about Nigel, and is a fine anecdote and antidote to over reliance on Gantt charts for understanding what is happening in a project. Yes, they're important for getting a handle on what may be going to happen at a macro-task level, but they rarely will cover the richness of interactions that occur on a day to day basis. And they definitely don't address the need to tell each other stories, so that we can understand a whole lot more about the nature of the people we are working with, rather than everything that is going on in the project, which is where we began...