A common theme in these parts is enable different areas of Penn State to effectively work together. I have been on a few projects where cross-unit projects which have come out reasonably well – the products are still in use, and I’m comfortable communicating with previous team mates.
I think the secret is that there is a crucial mix of top-level and bottom level communication. The top levels (the deans/directors/provosts) were important in establishing the importance of the project. In project land, this often corresponds a kick off meeting to establish main parameters (deadlines, budgets, staffing, etc), but afterwards that person may fade out except for extreme emergencies.
On the other hand, the bulk of the project communication happens below the top level at the project manager level. These are the people who will be implementing the project who need to talk to each other in a regular basis to resolve different issues. If you look at the diagram below of a cross ITS-Library project, you’ll see lots of horizontal arrows across units and some vertical arrows within each unit. The key is that the implementers need to know who to talk to within the other unit.
This seems fairly straightforward, but a lot can go wrong to derail this structure. One of the worst of them I think is mistiming of the kick off meeting where people are introduced to each other and the scope of the project. If it happens too early (before majority of project members come on board), then late comers may feel left out of the loop. If it happens too late or not at all, then the implementers may not have enough confidence or knowledge to formulate a viable project plan. It’s amazing how much time can be wasted because no one is sure what the original project intentions are.
Yet if the top-level is too involved I think two bad things can happen. One is that the the top level can feel frustrated at being committed to one project when many other decisions need to be made. The second is that if the implementers don’t feel comfortable contacting each other directly, the rate of progress can slow down quite a bit.
I suspect a lot of directors know this, and look forward to the days when implementers can self-organize…but it hasn’t happened yet. Why? I will be cynical and say that it’s because implementers can’t make the key decisions needed to self organize.
I may have a great idea, but can I convince another busy soul to tag along when he or she is already booked 40+ hours? I certainly can’t offer the kinds of incentives offered to other busy people like buying better software, an iPhone, generating publicity or a good staff review…because I’m just not a manager. In terms of collaboration, I’m limited in what I can promise on my own without top-level involvement.
Personally, I think the mixed model is fine already. It’s a model I wish were followed a little more consistently.